Карапайым файлдық жүктеу протоколы (TFTP) және оның қолданылуы

Кіріспе

UDP арқылы өте қарапайым тасымалдау протоколы

Тәуелсіз файлдарды тасымалдау протоколы (TFTP) – клиентке файлды қашықтан хосттан алуға немесе қашықтан хостқа орналастыруға мүмкіндік беретін қарапайым, синхронды файлдарды тасымалдау протоколы. Оның басты қолданыстарының бірі – жергілікті желіден жүктелетін түйіндердің бастапқы кезеңдерінде қолданылуы. TFTP осы мақсат үшін қолданылды, себебі оны іске асыру өте оңай. TFTP алғаш рет 1981 жылы стандартталды және протоколдың қазіргі нұсқауын мына жерде табуға болады.

Шолу

TFTP-нің қарапайым дизайны шағын жад көлемімен код арқылы оңай жүзеге асырылуы мүмкін. Сондықтан, BOOTP, PXE, BSDP сияқты кез келген желілік жүктеу стратегиясының бастапқы кезеңдерінде осы протокол таңдалады, әсіресе жоғары ресурсты компьютерлерден бастап, өте төмен ресурсты бір тақталı компьютерлерге (SBC) және Чиптегі жүйелерге (SoC) бағытталғанда. Ол сондай-ақ маршрутизаторлар, брандмауэрлер, IP телефондар сияқты желілік құрылғыларға микропрограммалық жасақтамалар мен конфигурациялық файлдарды беру үшін де қолданылады. Бүгінде TFTP интернет арқылы файлдарды беру үшін дерлік қолданылмайды. TFTP дизайнына бұрынғы EFTP протоколының әсері болды, ол PARC Universal Packet протоколы жиынтығының бір бөлігі еді. TFTP алғаш рет 1980 жылы IEN 133 арқылы анықталды. 1981 жылдың маусым айында TFTP протоколы (Ревизия 2) RFC 783 ретінде жарияланды, ал кейін 1992 жылдың шілдесінде RFC 1350 жаңартылды, ол басқа нәрселермен қатар, «сиқыршының шәкірті» синдромын жойды. 1995 жылдың наурыз айында TFTP опциясын кеңейту RFC 1782 жаңартылды, ал 1998 жылдың мамырында RFC 2347 арқылы толықтырылды, бұл файлдарды беру опцияларын беруден бұрын келіссөздер жүргізу механизмін анықтады, бұл механизм TFTP-нің бастапқы ерекшелігіне сәйкес келеді. TFTP – UDP/IP протоколдарының үстінде 69 нөміріндегі портты пайдалана отырып іске асырылатын, файлдарды берудің қарапайым протоколы. TFTP шағын және оңай іске асырылатын етіп жасалған, сондықтан ол файлдарды берудің сенімді протоколдары ұсынатын көптеген кеңейтілген мүмкіндіктерден мүлдем құрылған. TFTP тек қашықтан орналасқан серверден файлдарды оқиды және жазады. Ол файлдар мен каталогтарды тізімдей алмайды, жоя алмайды немесе атауын өзгерте алмайды, сондай-ақ пайдаланушының куәлігін тексеруге арналған ережелер де жоқ. Бүгінгі таңда TFTP көбінесе жергілікті желілерде (LAN) қолданылады.

Егжей-тегжейлер

TFTP-де клиент сервердегі нақты бір файлды оқу немесе жазу үшін сұрау жіберу арқылы беруді бастайды. Сұрауға клиенттің RFC 2347 талаптарына сәйкес келісілген беру параметрлерінің жиынтығы да қосылуы мүмкін. Егер сервер сұрауды қабылдаса, файл әдетте 512 байттық немесе RFC 2348-де анықталған блок өлшемі бойынша келісілген санмен белгіленген блоктарда жіберіледі. IP-фрагментациясын болдырмау үшін, әдетте бір IP-пакетімен тасымалданатын әрбір дерек блогы келесі блок жіберілгенге дейін растау пакетімен расталуы керек. 512 байттан кем немесе келісілген блок өлшемінен кем дерек пакеті беруді тоқтатуды білдіреді. Егер пакет желіде жоғалса, көздеген алушы уақыты бітіп, соңғы пакетін қайта жіберуі мүмкін (ол дерек немесе растау болуы мүмкін), соның салдарынан жоғалған пакеттің жіберушісі оны қайта жібереді. Жіберуші қайта жіберу үшін тек бір пакетті сақтауы керек, себебі бұғаттау қадамы барлық бұрынғы пакеттердің дұрыс алынғанын қамтамасыз етеді. Екі құрылғы да беруге қатысатындықтан, олар жіберуші де, алушы да болып саналады. Бірі деректерді жібереді және растауды алады, екіншісі растауды жібереді және деректерді алады. TFTP үш беру режимін анықтайды: netascii, octet және mail. Netascii – RFC 764-те анықталған ASCII-дің өңделген түрі. Ол 7 биттік ASCII таңбалар кеңістігінің 0x20-дан 0x7F-қа дейінгі 8 биттік кеңейтуінен (басылатын таңбалар мен бос орын) және сегіз басқару таңбасынан тұрады. Рұқсат етілген басқару таңбаларына нөлдік (0x00), жолдың соңы (LF, 0x0A) және тасымалдау қайтарымы (CR, 0x0D) жатады. Netascii сондай-ақ хосттың жол соңы маркерін CR LF әріптерінің жұбына аударуын және кез келген CR жолдың соңына (LF) немесе нөлге дейін болуын талап етеді. Octet кез келген 8 биттік байттарды беруге мүмкіндік береді, ал алынған файл жіберілген файлмен бір байттан бір байтқа сәйкес келеді. Дәлірек айтқанда, егер хост октет файлының көшірмесін алса және қайтарса, қайтарылған файл түпнұсқамен толық сәйкес болуы керек. Пошта режимі Netascii беруін пайдаланады, бірақ файл файл атауы ретінде алушының электрондық пошта мекенжайын көрсету арқылы электрондық пошта алушыға жіберіледі. RFC 1350 осы беру режимін ескі деп жариялады. TFTP өз тасымалдау протоколы ретінде UDP-ні пайдаланады. Беру сұранысы әрқашан 69 портына бағытталады, бірақ деректерді беру порттарын жіберуші мен алушы беруді бастау кезінде өздігінен таңдайды. Порттар желілік стектің параметрлеріне сәйкес кездейсоқ таңдалады, әдетте, уақытша порттар диапазонынан. Бастаушы хост А RRQ (оқу сұранысы) немесе WRQ (жазу сұранысы) пакетін хост S-ке 69 порт нөмірі бойынша файл атауы, беру режимі және RFC 2347 талаптарына сәйкес келісілген опцияларды қоса жібереді. S опциялар қолданылған жағдайда ACK опциясымен, ал WRQ үшін ACK (растау) пакетімен және RRQ үшін тікелей DATA пакетімен жауап береді. Пакет кездейсоқ бөлінген уақытша порттан жіберіледі және S хостына жіберілетін барлық келесі пакеттер осы портқа бағытталуы керек. Жіберуші хост нөмірленген DATA пакеттерін көздеген хостқа жібереді, соңғысынан басқасының барлығы толық өлшемді дерек блогын (әдетте 512 байт) қамтиды. Көздеген хост барлық DATA пакеттеріне нөмірленген ACK пакеттерімен жауап береді. Соңғы DATA пакеті соңғы екенін көрсету үшін толық өлшемді дерек блогынан кем болуы керек. Егер берілген файлдың көлемі блок өлшеміне дәл еселік болса, жіберуші 0 байт дерек бар соңғы DATA пакетін жібереді. Алушы әр DATA пакетіне тиісті нөмірленген ACK пакетімен жауап береді. Жіберуші алғашқы алған ACK пакетіне келесі блоктан DATA пакетімен жауап береді. Егер ACK пакеті уақытында алынбаса, қайта жіберу таймері DATA пакетін қайта жібереді. TFTP әрқашан желілік жүктеумен байланысты. Бұл бағыттағы алғашқы әрекеттердің бірі 1984 жылы жарияланған TFTP стандарты RFC 906 пайдалану арқылы Bootstrap жүктеу болды, ол 1981 жылы жарияланған Trivial File Transfer Protocol стандарты RFC 783 стандартты файлдарды беру протоколы ретінде пайдаланылатын файлдарды беру протоколын орнатты. Одан кейін 1985 жылы жарияланған Bootstrap протоколы стандарты RFC 951 (BOOTP) пайда болды, бұл дисксіз клиенттік машинаға өзінің IP-мекенжайын, TFTP серверінің мекенжайын және TFTP арқылы жүктеліп, жадыға салынып, орындалатын Желілік Bootstrap бағдарламасының (NBP) атын анықтауға мүмкіндік берді. 1997 жылы жарияланған Динамикалық хостты конфигурациялау протоколы стандарты RFC 2131 (DHCP) BOOTP мүмкіндіктерін жақсартты. Соңында, Preboot Execution Environment (PXE) нұсқасы 2.0 1998 жылдың желтоқсанында шығарылды, ал жаңарту 2.1 1999 жылдың қыркүйегінде жарияланды, файлдарды беру протоколы ретінде TFTP-ге сүйенді. Intel жақында жаңа UEFI спецификациясында PXE-ні кеңінен қолдауды шешті, TFTP қолдауын барлық EFI/UEFI орталарына кеңейтті. Бастапқы протоколдың файлды беру өлшемі шегі 512 байт/блок x 65535 блок = 32 МБ құрады. 1998 жылы бұл шек TFTP Blocksize Option RFC 2348 арқылы 65535 байт/блок x 65535 блок = 4 ГБ дейін ұзартылды. Егер анықталған блок өлшемі желілік жолдың кез келген нүктесіндегі ең төменгі MTU-дан асып кететін IP пакетінің өлшемін тудырса, IP фрагментациясы мен қайта құрастыру орын алады, бұл қосымша жүктеме ғана емес, сонымен қатар хосттың BOOTP немесе PXE ROM-дағы минималистік IP стегі IP фрагментациясын және қайта құрастыруды (немесе дұрыс орындамаса) орындамаған жағдайда толық берудің сәтсіздігіне әкеледі. TFTP пакеттерін стандартты Ethernet MTU (1500) шегінде сақтау үшін блок өлшемі 1500 минус TFTP (4 байт), UDP (8 байт) және IP (20 байт) тақырыптары = 1468 байт/блок ретінде есептеледі, бұл 1468 байт/блок x 65535 блок = 92 МБ шегін береді. Бүгінде көптеген серверлер мен клиенттер блок нөмірін ауыстыруды (блок санауышы 65535-тен кейін 0 немесе 1-ге қайта оралады) қолдайды, бұл іс жүзінде шексіз файлды беру өлшемін береді. TFTP UDP-ні пайдаланатындықтан, ол өзінің тасымалдау және сессия қолдауын қамтамасыз етуі керек. TFTP арқылы берілген әрбір файл тәуелсіз алмасуды құрайды. Классикалық түрде, бұл беру бірқатарда орындалады, тек бір пакет (дерек блогы немесе «растау») кез келген уақытта желіде болады. Осы бір дерек блогы стратегиясы үзіліссіз дерек блоктарының үлкен көлемін жібермей, растауды күтіп тоқтаудың орнына (терезелеу), TFTP әсіресе жоғары жалаңдық байланыстарда төмен өнімділікті қамтамасыз етеді. Microsoft Windows 2008-де Windows Deployment Services (WDS) бөлігі ретінде терезеленген TFTP-ті енгізді, 2015 жылдың қаңтарында TFTP Windowsize Option RFC 7440 жарияланды. Бұл PXE жүктеуі сияқты нәрселер үшін өнімділікті айтарлықтай жақсартады, кейде Blocksize Option RFC 2348-де байқалатын IP фрагментациясының жанама әсері болмайды.

In TFTP, a transfer is initiated by the client issuing a request to read or write a particular file on the server. The request can optionally include a set of negotiated transfer parameters proposed by the client under the terms specified by RFC 2347. If the server grants the request, the file is sent in fixed length blocks of 512 bytes by default or the number specified in the blocksize negotiated option defined by RFC 2348. Each block of transferred data, which is usually carried within a single IP packet in order to avoid IP fragmentation, must be acknowledged by an acknowledgment packet before the next block can be sent. A data packet of less than 512 bytes or the agreed blocksize option signals termination of a transfer. If a packet gets lost in the network, the intended recipient will timeout and may retransmit their last packet (which may be data or an acknowledgment), thus causing the sender of the lost packet to retransmit that lost packet. The sender has to keep just one packet on hand for retransmission, since the lock step acknowledgment guarantees that all older packets have been correctly received. Notice that both devices involved in a transfer are considered senders and receivers. One sends data and receives acknowledgments, the other sends acknowledgments and receives data. TFTP defines three modes of transfer: netascii, octet, and mail. Netascii is a modified form of ASCII, defined in RFC 764. It consists of an 8 bit extension of the 7 bit ASCII character space from 0x20 to 0x7F (the printable characters and the space) and eight of the control characters. The allowed control characters include the null (0x00), the line feed (LF, 0x0A), and the carriage return (CR, 0x0D). Netascii also requires that the end of line marker on a host be translated to the character pair CR LF for transmission, and that any CR must be followed by either a LF or the null. Octet allows for the transfer of arbitrary raw 8 bit bytes, with the received file resulting byte per byte identical to the one sent. More correctly, if a host receives an octet file and then returns it, the returned file must be identical to the original. Mail transfer mode uses Netascii transfer, but the file is sent to an email recipient by specifying that recipient's email address as the file name. RFC 1350 declared this mode of transfer obsolete. TFTP uses UDP as its transport protocol. A transfer request is always initiated targeting port 69, but the data transfer ports are chosen independently by the sender and receiver during the transfer initialization. The ports are chosen at random according to the parameters of the networking stack, typically from the range of ephemeral ports. The initiating host A sends an RRQ (read request) or WRQ (write request) packet to host S at port number 69, containing the filename, transfer mode, and optionally any negotiated option under the terms of RFC 2347. S replies with an option ACK if options were used, and an ACK (acknowledgement) packet to WRQ and directly with a DATA packet to RRQ. Packet is sent from a randomly allocated ephemeral port, and all future packets to host S should be directed to this port. The source host sends numbered DATA packets to the destination host, all but the last containing a full sized block of data (512 bytes default). The destination host replies with numbered ACK packets for all DATA packets. The final DATA packet must contain less than a full sized block of data to signal that it is the last. If the size of the transferred file is an exact multiple of the block size, the source sends a final DATA packet containing 0 bytes of data. Receiver responds to each DATA with associated numbered ACK. Sender responds to the first received ACK of a block with DATA of the next block. If an ACK is not eventually received, a retransmit timer re sends DATA packet. TFTP has always been associated to network booting. One of the first attempts in this regard was the Bootstrap Loading using TFTP standard RFC 906, published in 1984, which established the 1981 published Trivial File Transfer Protocol standard RFC 783 to be used as the standard file transfer protocol for bootstrap loading. It was followed shortly after by the Bootstrap Protocol standard RFC 951 (BOOTP), published in 1985, which allowed a disk less client machine to discover its own IP address, the address of a TFTP server, and the name of a Network Bootstrap Program (NBP) to be TFTP transferred, loaded into memory, and executed. Dynamic Host Configuration Protocol standard RFC 2131 (DHCP) published in 1997 improved BOOTP capabilities. Finally, the Preboot Execution Environment (PXE) version 2.0 was released in December 1998, and the update 2.1 was made public in September 1999 counting on TFTP as its file transfer protocol. Intel has recently decided to widely support PXE within the new UEFI specification extending the TFTP support to all EFI/UEFI environments. The original protocol has a transfer file size limit of 512 bytes/block x 65535 blocks = 32 MB. In 1998 this limit was extended to 65535 bytes/block x 65535 blocks = 4 GB by TFTP Blocksize Option RFC 2348. If the defined blocksize produces an IP packet size that exceeds the minimum MTU at any point of the network path, IP fragmentation and reassembly will occur not only adding more overhead but also leading to total transfer failure when the minimalist IP stack implementation in a host's BOOTP or PXE ROM does not (or fails to properly) implement IP fragmentation and reassembly. If TFTP packets should be kept within the standard Ethernet MTU (1500), the blocksize value is calculated as 1500 minus headers of TFTP (4 bytes), UDP (8 bytes) and IP (20 bytes) = 1468 bytes/block, this gives a limit of 1468 bytes/block x 65535 blocks = 92 MB. Today most servers and clients support block number roll over (block counter going back to 0 or 1 after 65535) which gives an essentially unlimited transfer file size. Since TFTP utilizes UDP, it has to supply its own transport and session support. Each file transferred via TFTP constitutes an independent exchange. Classically, this transfer is performed in lock step, with only one packet (either a block of data, or an 'acknowledgement') alternatively in flight on the network at any time. Due to this single data block strategy instead of sending a larger amount of uninterrupted data blocks before pausing the transfer to wait for the corresponding acknowledge (windowing), TFTP provides low throughput especially over high latency links. Microsoft introduced windowed TFTP in Windows 2008 as part of their Windows Deployment Services (WDS), in January 2015 TFTP Windowsize Option RFC 7440 was published. This substantially improves performance for things like PXE booting without the IP fragmentation side effect sometimes observed on Blocksize Option RFC 2348

Қауіпсіздік мәселелері

TFTP кіру немесе қол жеткізуді бақылау механизмдерін қамтымайды. TFTP арқылы файлдарды аутентификациялау, қол жеткізуді бақылау, құпиялылықты қамтамасыз ету немесе деректердің дұрыстығын тексеру қажет болған жағдайларда сақтық таныту керек. Мұндай қауіпсіздік қызметтерін TFTP жұмыс істейтін қабаттан жоғары немесе төмен де ұсынуға болады. TFTP сервер процесіне берілген құқықтарға да назар аудару қажет, осылайша сервердің файлдық жүйесінің қауіпсіздігі бұзылмауы тиіс. TFTP көбінесе тек TFTP арқылы оқуға қолжетімді файлдармен ғана орнатылады. Сондай-ақ, TFTP арқылы файлдарды тізімдеу, жою, атауын өзгерту және жазу әдетте рұқсат етілмейді. TFTP файлдарды беру протоколының ішкі шектеулері еңсеруге келмейтін жауапкершілік мәселелерін тудыруы мүмкін болған жағдайларда қолдану ұсынылмайды.

IETF стандарттарының құжаттамасы

RFC нөмірі Атауы Жарияланған автор Ескірген және жаңарту туралы ақпарат TFTP протоколы (1-ші нұсқасы) 1981 жылғы маусым К. Соллинс TFTP арқылы жүктеу 1984 жылғы маусым Росс Финлейсон Bootstrap протоколы 1985 жылғы қыркүйек Билл Крофт TFTP протоколы (2-ші нұсқасы) 1992 жылғы шілде К. Соллинс TFTP опциясын кеңейту 1995 жылғы наурыз Г. Малкин Динамикалық хост конфигурациялау протоколы 1997 жылғы наурыз Р. Дромс Жаңартылды: TFTP опциясын кеңейту 1998 жылғы мамыр Г. Малкин TFTP блок өлшемі опциясы 1998 жылғы мамыр Г. Малкин TFTP уақыт аралығы және аудару көлемі опциялары 1998 жылғы мамыр Г. Малкин Интернет хостын конфигурациялау принциптері 2009 жылғы мамыр Б. Абоба TFTP терезесі опциясы 2015 жылғы қаңтар П. Масотта