TFTP протокол за трансфер на данни прост

Глава 15 TFTP: прост протокол за пренос на данни

TFTP - прост протокол за прехвърляне на файлове. Той обикновено се използва за бездискови системи (работни станции или Х-терминали). За разлика от Протокола от FTP (File Transfer - протокол за пренос на файла), който ще опишем в глава 27, и който използва TCP, UDP TFTP използва. Това се прави, за да се гарантира, че протоколът е толкова прост и кратък. Внедрявания TFTP (и желания UDP, IP, както и на драйвер на устройство) може да се побере в постоянната памет (ROM).

Обменът между клиента и сървъра започва с клиента подава заявка към сървъра или да четат или пишат файла на клиента. Стандартната бездискова система натоварване първата заявка - искане за четене (RRQ). Цифрата показва 15.1 съобщенията формат пет TFTP. (Код на операциите 1 и 2 имат същия формат).

Първите 2 байта на съобщението за TFTP е кодът на операцията (код на операция). Искането за четене (RRQ) и искането за запис (WRQ) на името на файла (името на файла), уточнява файла на сървъра, че клиентът иска и не поема нито един запис. Изрично е показано на фигура 15.1, което е името на файла завършва с нулев байт. Mode (режим) е ASCII низ: netascii или октет (всяка комбинация от големи или малки букви), който също завършва в байт 0. netascii означава, че данните са ASCII текстови линии, всеки ред завършва с два знака за връщане последователност, следвана от подаване линия (означен - CR / LF).

Фигура 15.1 Форматът на пет съобщения по ППФТ.

И двете клиент и сървър, трябва да може да се извърши преобразуване формат между тях и всички други (друг Разграничител струни), който се използва на локалния хост. Трансфер октет посочва, че данните ще бъдат предадени под формата на 8-битови байта без интерпретация.

В случай на искане за запис (WRQ) клиентът изпраща WRQ, което показва името на файла и режима. Ако файлът може да бъде написана от клиента, сървърът отговаря с потвърждение (АСК) с номер на блок 0. Клиентът изпраща първите 512 байта на номера на файла блок равен на 1, сървърът отговаря с номер АСК блок равен на 1.

Този вид пренос на данни протокол, наречен спиране и изчакване (спиране и изчакване). Той се използва само в прости протоколи като TFTP. Ще видим в "Resize" в глава 20, че TCP предвижда други средства за доказване, която ви позволява да се постигне по-висока производителност. TFTP е проектирана по такъв начин, че изпълнението е толкова лесно, колкото е възможно, а не за увеличаване на капацитета.

Последният вид TFTP съобщения, това съобщение за грешка, кодът за работа (код на операция) е равно на 5. Това е точно това, което сървърът отговаря в случай, че четат или пишат искане не може да бъде обработена. четене или писане на грешки по време на прехвърлянето на файлове и да доведе до това, което се изпраща съобщение за грешка, и трансферът се прекратява. Номерът на грешка (номер на грешка) включва цифров код за грешка, последвано от съобщението за грешка в ASCII формат, който може да съдържа допълнителна информация, предоставена от операционната система.

Нека да видим как работи TFTP протокол. Ние ще стартира на клиента TFTP на BSDi домакин и получаване на текстови файл с домакина SVR4:

BSDi% TFTP SVR4 започне клиент ППФТ
TFTP> получите test1.c получи файл от сървъра
Получени 962 байта в 0.3 секунди
TFTP> откажат разкъсване съединение

BSDi% ли -l test1.c колко байта файла?
-RW-R - r-- 1 rstevens персонала 914 20 март 11:41 test1.c

BSDi% тоалетна -l test1.c и колко реда?
48 test1.c

Първото нещо, което хваща окото е фактът, че файла на Unix съдържа 914 байта, но ППФТ изпраща 962 байта. Използване на тоалетната програма, ще видим, че файловете на 48 линии, така че 48 нови герои линия в Unix са допълнени с до 48 чифта CR / LF, тъй ППФТ по подразбиране предава netascii режим.

Фигурата показва 15.2 обмен пакет.

1 .0 bsdi.1106> svr4.tftp: 19 RRQ "test1.c"

2 0.287080 (0.2871) svr4.1077> bsdi.1106: UDP 516
3 0.291178 (0.0041) bsdi.1106> svr4.1077: UDP 4

4 0.299446 (0.0083) svr4.1077> bsdi.1106: UDP 454
5 0.312320 (0.0129) bsdi.1106> svr4.1077: UDP 4

Фигура 15.2 Pinging ако TFTP.

Линия 1 показва заявка за четене от клиента към сървъра. UDP порт дестинация за TFTP - добре познат порт 69, Tcpdump изглежда по ППФТ пакети и щампи RRQ и име на файла. Дължината на UDP данни отпечатани като 19 байта и се получава по следния начин: 2 байта - OpCode, 7 байта - името на файла на един байт от 0 до netascii 8 байта, и 1 байт е равен на 0.

На следващия пакет идва от сървъра (линия 2) и съдържа 516 байта: 2 байта - Кодът, 2 байт - единица брой и 512 байта от данни. Ред 3 - потвърждение на тази информация: 2 байта - Кодът байт и 2 - номера на блока.

И последният пакет от данни (линия 4) съдържа 450 байта данни. 512 байта от данни в ред 2 и те съдържат 450 байта 962 байта от данни, получени от клиента.

Имайте предвид, че Tcpdump не печата повече информация за TFTP протокол за линии 2 - 5, как той го е направил, да тълкува TFTP съобщение на линия 1. Това е така, защото номерът на порта на сървъра е променил между редовете 1 и 2. TFTP протокол изисква клиент изпраща първия пакет (на RRQ или WRQ), за да преминете добре познат UDP порт на сървър (69). Сървърът установи неизползвания краткотрайното порт (1077 на фигура 15.2), който след това се използва от сървъра за допълнително обмен на пакети между клиента и сървъра. клиентски номер порт (1106 в този пример) не се променя. Tcpdump няма никаква представа, че пристанището 1077 на SVR4 домакин използва TFTP сървър.

Причината за промяната номера на порта на сървъра, е, че на сървъра не трябва да се справи добре познат порт на голямо количество от време, необходим за прехвърляне на файла (което може да отнеме от няколко секунди до няколко минути). Вместо това, добре познат порт остава на разположение за други TFTP клиент, който може да изпрати в молбата си. Докато в този момент трансферът се осъществява чрез друг порт.

Позовавайки се на Фигура 10.6. RIP на сървъра, че клиентът трябва да изпрати повече от 512 байта, изпраща двете UDP дейтаграми с известна порта на сървъра. В случай на TFTP (поради различия в протокола), с продължителност на взаимодействието между клиента и сървъра не се извършва (което, както казахме, може да отнеме от секунди до минути). Ако един процес на сървъра ще използва добре познатата порта, докато файловете за прехвърляне, е необходимо да се отрече всички последващи искания, които ще дойдат от други клиенти, или на сървъра процес трябва да бъде в състояние да изпълнява множество файлови трансфери до множество клиенти в същото време с същото пристанище (69). Най-простото решение е, че сървърните превключва на друг порт на след получили RRQ или WRQ. Клиентът посочва ново пристанище, когато получи първи информационен пакет (линия 2 на фигура 15.2), а след това да изпрати всички последващи потвърждение (линии 3 и 5) на новото пристанище.

В "пример", в Глава 16, ще видим, как да се използва TFTP при зареждане Х-терминали.

Имайте предвид, че пакетите с TFTP (Фигура 15.1) не съдържат никакви данни за потребителското име или паролата за. Това нарушение в тайна характеристика на ППФТ. От TFTP е проектиран за използване в процеса на стартиране, тя не предоставя потребителско име и парола.

Тази характеристика на ППФТ е бил използван от много хакери да получат копия на файла с паролите на Unix, а след това се декриптира паролите. За да се предотврати такъв достъп, по-голямата част от ППФТ сървъри в момента управлява кои файлове могат да се приготвят с помощта на TFTP (обикновено файлове в директорията / tftpboot в Unix системи). Тази директория съдържа само за стартиране на файлове, необходими бездисковите системи.

За повишаване на сигурността на TFTP сървър на система Unix, обикновено си поставя потребителско име (UID) и група ID (GID) в стойността на които не могат да бъдат причислени към реална употреба. Това позволява достъп само до файлове, които са достъпни за четене и запис на всички.

TFTP - прост протокол проектирана по такъв начин да се поберат в ROM и да се използва само в процеса на бездискови системи. Той използва малко количество формати за съобщения и протокол с често спиране и изчакване.

За да се даде възможност на множество клиенти да бъдат заредени в същото време, TFTP сървър осигурява няколко форми на едновременна работа. Тъй като UDP не предоставя уникална връзка между клиента и сървъра (както прави TCP), TFTP сървъра се създава нов UDP порт за всеки клиент. Тя позволява на потребителите да се издават на дейтаграма да се демултиплексиран модул UDP сървър, базиран на дестинация номерата на портовете, вместо да го прави на самия сървър.

Протоколът TFTP не дава сигурност. Повечето приложения дава достъп чрез TFTP само до файлове, които са необходими при изтегляне.

В глава 27, ние ще разгледаме протокол за трансфер на файлове (FTP - File Transfer Protocol), която е предназначена за общо предназначение, а също така осигурява висока пропускателна способност за прехвърляне на файлове.