Azərbaycanca
Беларускі
Dansk
Deutsch
Española
Français
Indonesia
Italiana
日本語
Қазақ
Lietuvos
Nederlands
Português
Русский
සිංහල
แบบไทย
Türkçe
Українська
中國人
United State
Afrikaans
TFTP (англ. Trivial File Transfer Protocol — тривіальний протокол передачі файлів) — простий, покроково синхронізований протокол передачі файлів, який дозволяє клієнтам зчитувати або записувати файли сервера. Одним із основних використань протоколу є первинне завантаження бездискових робочих станцій у локальній мережі. Найчастіше TFTP використовується саме через простоту його реалізації. Протокол працює поверх протоколу UDP.
TFTP уперше було стандартизовано у 1981 році, поточний стандарт протоколу — RFC 1350.
Застосування
Протокол TFTP створений з розрахунку на невеликий розмір і простоту реалізації. Через це він позбавлений більшості можливостей, які мають більш серйозні протоколи на кшталт FTP. Єдине, на що здатний цей протокол — це записувати та зчитувати файли на сервер та з нього. Він не може виводити список файлів та наразі не підтримує автентифікацію.
Основне призначення TFTP — забезпечення простоти реалізації клієнта. У зв'язку з цим він використовується для завантаження бездискових робочих станцій, завантаження оновлень і конфігурацій в «розумні» мережеві пристрої, записи статистики з міні-АТС (CDR) та апаратних маршрутизаторів / файрволів.
Деякі приклади використання, коли треба мати сервер для встановлення по мережі операційної системи, для запуску з PXE серверу різноманітних LiveCD (Hiren's BootCD [ 25 лютого 2021 у Wayback Machine.], Linux Mint, ) та окремих діагностичних застосунків, таких як перевірка пам'яті Memtest86+ [ 23 лютого 2021 у Wayback Machine.], Memtest86 [ 23 лютого 2021 у Wayback Machine.], Goldmemory test [ 12 лютого 2021 у Wayback Machine.], перевірка накопичувачів Victoria [ 21 січня 2021 у Wayback Machine.], MHDD [ 31 березня 2022 у Wayback Machine.].
Безпека
TFTP, на відміну від FTP, не містить можливостей аутентифікації і єдиний метод ідентифікації клієнта — це його мережева адреса (яка може бути підробленою). Зазвичай в Unix-системах TFTPD доступний тільки каталог / TFTPboot. Проте в старих TFTP-серверах було можливим отримати файл паролів командою RRQ ../[…]/шлях_до_файлу_паролів. Це було використано багатьма хакерами, щоб отримати копії файлу паролів з Unix і потім розшифрувати паролі. Щоб запобігти подібному, більшість сучасних TFTP-серверів регламентують, які файли можуть бути отримані з використанням TFTP (як правило, файли з директорії /tftpboot в Unix системах). Ця директорія містить тільки завантажувальні файли, необхідні бездисковим системам.
Демон TFTPD (одна з реалізацій TFTP-сервера) відмовляється обробляти файли, що містять в своєму імені комбінацію «/../» або починається з «../». Запис дозволяється тільки у файли, які вже існують (будь-якого розміру, наприклад нульового), і доступні для публічного запису (права доступу:-RW-RW-RW-).
Для додаткової безпеки TFTP-сервер на Unix-системах зазвичай встановлює свій користувацький ідентифікатор (UID) і ідентифікатор групи (GID) у значення, які не можуть бути призначені реальному користувачеві. Це забезпечує доступ тільки до файлів, які доступні для читання і запису всім.
Процес передачі даних
У TFTP існує 3 режими передачі: netascii, octet і mail:
- Netascii є модифікованою формою ASCII, визначений у RFC 764. Вона складається з 8-бітного розширення 7-бітних ASCII-символів з кодами від 0x20 до 0x7F (друкованих символів і пробілу) і восьми керуючих символів. Допустимі керуючі символи включають нуль-символ (код 0x00), новий рядок (LF, код 0x0A) і повернення каретки (CR, код 0x0D). Netascii також вимагає, щоб маркер кінця рядка був замінений на пари символів CR LF для передачі, і щоб за кожним символом CR слідував або символ LF, або нуль-символ.
- Octet використовується для передачі довільних необроблених 8-бітних байтів, причому отриманий файл в результаті побайтово ідентичний посланому.
- Режим передачі mail використовує передачу netascii, але файл відправляється одержувачу електронною поштою на адресу, яка вказується замість імені файлу. RFC 1350 визначає цей режим передачі застарілим і таким, що не повинен бути реалізованим.
Кожен TFTP-пакет належить до одного із 5 типів:
- Read Request (RRQ, #1) — запит на читання файлу.
- Write Request (WRQ, #2) — запит на запис файлу.
- Data (DATA, #3) — дані, передані через TFTP.
- Acknowledgment (ACK, #4) — підтвердження пакета.
- Error (ERR, #5) — помилка.
Для початку передачі даних клієнт повинен послати серверу WRQ або RRQ-пакет. В обох пакетів формат однаковий:
| 0x01/0x02 (тип пакета) | Ім'я файла | 0x00 (кінець рядка) | Режим передачі | 0x00 (кінець рядка) | Опції… (якщо є) |
|---|---|---|---|---|---|
| 2 байта | рядок в ASCII | 1 байт | рядок в ASCII | 1 байт | Див. «Опції TFTP» |
Після отримання RRQ-пакета сервером, він відразу починає передачу даних. У випадку з WRQ-запитом — сервер має надіслати ACK-пакет із номером пакета 0. Пакет надсилається із динамічного порту сервера, усе подальше спілкування з сервером відбувається через цей порт.
Сторона-відравник файла надсилає пронумеровані пакети даних (DATA) сталого розміру (за замовчуванням це 512 байт), а сторона-отримувач надсилає відповідні підтвердження (ACK). Якщо пакет даних або підтвердження було втрачено, то через певний час (таймаут) сторона, яка не отримала очікуваного пакета, повторно надсилає останній надісланий нею пакет. Така схема дозволяє тримати в пам'яті тільки останній надісланий пакет, у той час як підтвердження протилежної сторони гарантує, що всі попередні пакети було отримано і вони прийняті саме в тому порядку, в якому були надіслані. Така схема передбачає, що кожна зі сторін є і відправником, і одержувачем. Одна сторона надсилає дані й отримує підтвердження, інша — отримує дані й відправляє підтвердження.
Останній пакет даних має розмір менше 512 байт. Якщо розмір файлу кратний 512, то останній пакет DATA повинен мати нульовий розмір.
Опції TFTP
У RFC 2347 був передбачений формат опцій, які можна приєднувати до закінчення RRQ-пакета і WRQ-пакету:
| Код опції | 0x00 (кінець рядка) | Значення опції | 0x00 (кінець рядка) |
|---|---|---|---|
| Рядок в ASCII | 1 байт | рядок в ASCII | 1 байт |
Опцій може бути декілька, тоді вони йдуть одна за одною, порядок опцій не важливий. У відповідь на RRQ (або WRQ) з опціями сервер повинен надіслати OACK з переліком можливостей, які сервер прийняв. Найбільш поширені опції:
| Назва | Визначення в | Код опції | Означення |
|---|---|---|---|
| Розмір блока | RFC 2348 | blksize | Число від 8 до 65464 — розмір блоку. |
| Інтервал повторної передачі | RFC 2348 | timeout | Число від 1 до 255 — час очікування перед повторним надсиланням блоку в секундах. |
| Розмір файла | RFC 2348 | tsize | Розмір файлу, що передається, у байтах. |
Документація IETF
| Номер RFC | Заголовок | Опубліковано | Автор | Інформація про оновлення та застаріння |
|---|---|---|---|---|
| RFC 783 | The TFTP Protocol (Revision 1) | Червень 1981 | K. Sollins | Визнаний застарілим у RFC 1350 |
| RFC 906 | Bootstrap Loading using TFTP | Червень 1984 | Ross Finlayson | - |
| RFC 951 | Bootstrap Protocol | Вересень 1985 | Bill Croft | Оновлено в RFC 1395, RFC 1497, RFC 1532, RFC 1542, RFC 5494 |
| RFC 1350 | The TFTP Protocol (Revision 2) | Липень 1992 | K. Sollins | Оновлено в RFC 1782, RFC 1783, RFC 1784, RFC 1785, RFC 2347, RFC 2348, RFC 2349 |
| RFC 1782 | TFTP Option Extension | Березень 1995 | G. Malkin | Визнаний застарілим у RFC 2347 |
| RFC 2131 | Dynamic Host Configuration Protocol | Березень 1997 | R. Droms | Оновлено в RFC 3396, RFC 4361, RFC 5494, RFC 6842 |
| RFC 2347 | TFTP Option Extension | Травень 1998 | G. Malkin | - |
| RFC 2348 | TFTP Blocksize Option | Травень 1998 | G. Malkin | - |
| RFC 2349 | TFTP Timeout Interval and Transfer Size Options | Травень 1998 | G. Malkin | - |
| RFC 7440 | TFTP Windowsize Option | Січень 2015 | P. Masotta | - |
Примітки
- Sollins, K.R. . tools.ietf.org. Архів оригіналу за 19 березня 2016. Процитовано 26 квітня 2016.
- Sollins, K. . tools.ietf.org. Архів оригіналу за 16 квітня 2016. Процитовано 26 квітня 2016.
- Art, Harkin,; Scott, Malkin, Gary. . tools.ietf.org. Архів оригіналу за 16 березня 2014. Процитовано 26 квітня 2016.
Вікіпедія, Українська, Україна, книга, книги, бібліотека, стаття, читати, завантажити, безкоштовно, безкоштовно завантажити, mp3, відео, mp4, 3gp, jpg, jpeg, gif, png, малюнок, музика, пісня, фільм, книга, гра, ігри, мобільний, телефон, android, ios, apple, мобільний телефон, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Інтернет
TFTP angl Trivial File Transfer Protocol trivialnij protokol peredachi fajliv prostij pokrokovo sinhronizovanij protokol peredachi fajliv yakij dozvolyaye kliyentam zchituvati abo zapisuvati fajli servera Odnim iz osnovnih vikoristan protokolu ye pervinne zavantazhennya bezdiskovih robochih stancij u lokalnij merezhi Najchastishe TFTP vikoristovuyetsya same cherez prostotu jogo realizaciyi Protokol pracyuye poverh protokolu UDP TFTP upershe bulo standartizovano u 1981 roci potochnij standart protokolu RFC 1350 ZastosuvannyaProtokol TFTP stvorenij z rozrahunku na nevelikij rozmir i prostotu realizaciyi Cherez ce vin pozbavlenij bilshosti mozhlivostej yaki mayut bilsh serjozni protokoli na kshtalt FTP Yedine na sho zdatnij cej protokol ce zapisuvati ta zchituvati fajli na server ta z nogo Vin ne mozhe vivoditi spisok fajliv ta narazi ne pidtrimuye avtentifikaciyu Osnovne priznachennya TFTP zabezpechennya prostoti realizaciyi kliyenta U zv yazku z cim vin vikoristovuyetsya dlya zavantazhennya bezdiskovih robochih stancij zavantazhennya onovlen i konfiguracij v rozumni merezhevi pristroyi zapisi statistiki z mini ATS CDR ta aparatnih marshrutizatoriv fajrvoliv Deyaki prikladi vikoristannya koli treba mati server dlya vstanovlennya po merezhi operacijnoyi sistemi dlya zapusku z PXE serveru riznomanitnih LiveCD Hiren s BootCD 25 lyutogo 2021 u Wayback Machine Linux Mint ta okremih diagnostichnih zastosunkiv takih yak perevirka pam yati Memtest86 23 lyutogo 2021 u Wayback Machine Memtest86 23 lyutogo 2021 u Wayback Machine Goldmemory test 12 lyutogo 2021 u Wayback Machine perevirka nakopichuvachiv Victoria 21 sichnya 2021 u Wayback Machine MHDD 31 bereznya 2022 u Wayback Machine BezpekaTFTP na vidminu vid FTP ne mistit mozhlivostej autentifikaciyi i yedinij metod identifikaciyi kliyenta ce jogo merezheva adresa yaka mozhe buti pidroblenoyu Zazvichaj v Unix sistemah TFTPD dostupnij tilki katalog TFTPboot Prote v starih TFTP serverah bulo mozhlivim otrimati fajl paroliv komandoyu RRQ shlyah do fajlu paroliv Ce bulo vikoristano bagatma hakerami shob otrimati kopiyi fajlu paroliv z Unix i potim rozshifruvati paroli Shob zapobigti podibnomu bilshist suchasnih TFTP serveriv reglamentuyut yaki fajli mozhut buti otrimani z vikoristannyam TFTP yak pravilo fajli z direktoriyi tftpboot v Unix sistemah Cya direktoriya mistit tilki zavantazhuvalni fajli neobhidni bezdiskovim sistemam Demon TFTPD odna z realizacij TFTP servera vidmovlyayetsya obroblyati fajli sho mistyat v svoyemu imeni kombinaciyu abo pochinayetsya z Zapis dozvolyayetsya tilki u fajli yaki vzhe isnuyut bud yakogo rozmiru napriklad nulovogo i dostupni dlya publichnogo zapisu prava dostupu RW RW RW Dlya dodatkovoyi bezpeki TFTP server na Unix sistemah zazvichaj vstanovlyuye svij koristuvackij identifikator UID i identifikator grupi GID u znachennya yaki ne mozhut buti priznacheni realnomu koristuvachevi Ce zabezpechuye dostup tilki do fajliv yaki dostupni dlya chitannya i zapisu vsim Format p yatoh vidiv TFTP povidomlenProces peredachi danihU TFTP isnuye 3 rezhimi peredachi netascii octet i mail Netascii ye modifikovanoyu formoyu ASCII viznachenij u RFC 764 Vona skladayetsya z 8 bitnogo rozshirennya 7 bitnih ASCII simvoliv z kodami vid 0x20 do 0x7F drukovanih simvoliv i probilu i vosmi keruyuchih simvoliv Dopustimi keruyuchi simvoli vklyuchayut nul simvol kod 0x00 novij ryadok LF kod 0x0A i povernennya karetki CR kod 0x0D Netascii takozh vimagaye shob marker kincya ryadka buv zaminenij na pari simvoliv CR LF dlya peredachi i shob za kozhnim simvolom CR sliduvav abo simvol LF abo nul simvol Octet vikoristovuyetsya dlya peredachi dovilnih neobroblenih 8 bitnih bajtiv prichomu otrimanij fajl v rezultati pobajtovo identichnij poslanomu Rezhim peredachi mail vikoristovuye peredachu netascii ale fajl vidpravlyayetsya oderzhuvachu elektronnoyu poshtoyu na adresu yaka vkazuyetsya zamist imeni fajlu RFC 1350 viznachaye cej rezhim peredachi zastarilim i takim sho ne povinen buti realizovanim Kozhen TFTP paket nalezhit do odnogo iz 5 tipiv Read Request RRQ 1 zapit na chitannya fajlu Write Request WRQ 2 zapit na zapis fajlu Data DATA 3 dani peredani cherez TFTP Acknowledgment ACK 4 pidtverdzhennya paketa Error ERR 5 pomilka Dlya pochatku peredachi danih kliyent povinen poslati serveru WRQ abo RRQ paket V oboh paketiv format odnakovij 0x01 0x02 tip paketa Im ya fajla 0x00 kinec ryadka Rezhim peredachi 0x00 kinec ryadka Opciyi yaksho ye 2 bajta ryadok v ASCII 1 bajt ryadok v ASCII 1 bajt Div Opciyi TFTP W1 Kliyent A nadsilaye zapit na zapis W2 Server S pidtverdzhuye zapit W3 Kliyent A nadsilaye pronumerovani paketi danih R1 Kliyent A posilaye zapit na chitannya R2 Server S nadsilaye dani paketu 1 R3 Kliyent A pidtverdzhuye prijom paketu 1 Pislya otrimannya RRQ paketa serverom vin vidrazu pochinaye peredachu danih U vipadku z WRQ zapitom server maye nadislati ACK paket iz nomerom paketa 0 Paket nadsilayetsya iz dinamichnogo portu servera use podalshe spilkuvannya z serverom vidbuvayetsya cherez cej port Storona vidravnik fajla nadsilaye pronumerovani paketi danih DATA stalogo rozmiru za zamovchuvannyam ce 512 bajt a storona otrimuvach nadsilaye vidpovidni pidtverdzhennya ACK Yaksho paket danih abo pidtverdzhennya bulo vtracheno to cherez pevnij chas tajmaut storona yaka ne otrimala ochikuvanogo paketa povtorno nadsilaye ostannij nadislanij neyu paket Taka shema dozvolyaye trimati v pam yati tilki ostannij nadislanij paket u toj chas yak pidtverdzhennya protilezhnoyi storoni garantuye sho vsi poperedni paketi bulo otrimano i voni prijnyati same v tomu poryadku v yakomu buli nadislani Taka shema peredbachaye sho kozhna zi storin ye i vidpravnikom i oderzhuvachem Odna storona nadsilaye dani j otrimuye pidtverdzhennya insha otrimuye dani j vidpravlyaye pidtverdzhennya Ostannij paket danih maye rozmir menshe 512 bajt Yaksho rozmir fajlu kratnij 512 to ostannij paket DATA povinen mati nulovij rozmir Opciyi TFTPU RFC 2347 buv peredbachenij format opcij yaki mozhna priyednuvati do zakinchennya RRQ paketa i WRQ paketu Kod opciyi 0x00 kinec ryadka Znachennya opciyi 0x00 kinec ryadka Ryadok v ASCII 1 bajt ryadok v ASCII 1 bajt Opcij mozhe buti dekilka todi voni jdut odna za odnoyu poryadok opcij ne vazhlivij U vidpovid na RRQ abo WRQ z opciyami server povinen nadislati OACK z perelikom mozhlivostej yaki server prijnyav Najbilsh poshireni opciyi Nazva Viznachennya v Kod opciyi Oznachennya Rozmir bloka RFC 2348 blksize Chislo vid 8 do 65464 rozmir bloku Interval povtornoyi peredachi RFC 2348 timeout Chislo vid 1 do 255 chas ochikuvannya pered povtornim nadsilannyam bloku v sekundah Rozmir fajla RFC 2348 tsize Rozmir fajlu sho peredayetsya u bajtah Dokumentaciya IETFNomer RFC Zagolovok Opublikovano Avtor Informaciya pro onovlennya ta zastarinnya RFC 783 The TFTP Protocol Revision 1 Cherven 1981 K Sollins Viznanij zastarilim u RFC 1350 RFC 906 Bootstrap Loading using TFTP Cherven 1984 Ross Finlayson RFC 951 Bootstrap Protocol Veresen 1985 Bill Croft Onovleno v RFC 1395 RFC 1497 RFC 1532 RFC 1542 RFC 5494 RFC 1350 The TFTP Protocol Revision 2 Lipen 1992 K Sollins Onovleno v RFC 1782 RFC 1783 RFC 1784 RFC 1785 RFC 2347 RFC 2348 RFC 2349 RFC 1782 TFTP Option Extension Berezen 1995 G Malkin Viznanij zastarilim u RFC 2347 RFC 2131 Dynamic Host Configuration Protocol Berezen 1997 R Droms Onovleno v RFC 3396 RFC 4361 RFC 5494 RFC 6842 RFC 2347 TFTP Option Extension Traven 1998 G Malkin RFC 2348 TFTP Blocksize Option Traven 1998 G Malkin RFC 2349 TFTP Timeout Interval and Transfer Size Options Traven 1998 G Malkin RFC 7440 TFTP Windowsize Option Sichen 2015 P Masotta PrimitkiSollins K R tools ietf org Arhiv originalu za 19 bereznya 2016 Procitovano 26 kvitnya 2016 Sollins K tools ietf org Arhiv originalu za 16 kvitnya 2016 Procitovano 26 kvitnya 2016 Art Harkin Scott Malkin Gary tools ietf org Arhiv originalu za 16 bereznya 2014 Procitovano 26 kvitnya 2016