TCP-IP крупным планом
Обмен пакетами в случае TFTP.
Рисунок 15.2 Обмен пакетами в случае TFTP.
В строке 1 показан запрос на чтение от клиента к серверу. Порт назначения UDP для TFTP - заранее известный порт 69, tcpdump просматривает TFTP пакеты и печатает RRQ и имя файла. Длина UDP данных печатается как 19 байт и получается следующим образом: 2 байта - код операции, 7 байт - имя файла, 1 байт равный 0, 8 байт для netascii и еще 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 используется при загрузке X терминалов.
