Кратко

  • Экспериментальный RFC 1545 в ноябре 1993 года предложил команды LPRT и LPSV: указывать семейство сетевого адреса, длину хостовой части и длину порта. Старый PORT содержал шесть десятичных октетов — четыре для хоста и два для порта.
  • Ответ 228 предназначался для пассивного режима с длинным адресом, а 521 сообщал, что сервер понимает команду, но не поддерживает запрошенное семейство. RFC 1639 заменил первую редакцию в июне 1994 года и расширил описание других сетевых и транспортных вариантов.

Накладная оказалась короче груза

У FTP две разные линии разговора. По управляющему соединению идут команды и ответы, по соединению данных — содержимое файла или каталога. RFC 959 использовал PORT, чтобы назвать адрес второго соединения. Его формат можно уместить на маленькой карточке: h1,h2,h3,h4,p1,p2. Четыре октета образуют 32-битный адрес интернет-хоста, ещё два — 16-битный TCP-порт. Значения передаются десятичными числами через запятую. Для IPv4 и TCP такая карточка была удобна.

Карточка не растёт вместе с архитектурой сети. К началу 1990-х инженеры рассматривали несколько вариантов следующего поколения IP, в том числе адреса большей или переменной длины. Транспортные интерфейсы тоже могли принести селекторы шире порта TCP. Даже если новая сеть умела передать пакет, FTP сначала должен был назвать партнёру адрес соединения данных. Старые шесть полей образовывали узкую дверь прямо внутри команды прикладного протокола.

В ноябре 1993 года Дэвид Писчителло опубликовал экспериментальный RFC 1545FTP Operation Over Big Address Records, сокращённо FOOBAR. Название похоже на временное слово из рабочей тетради, пережившее редактуру. Конструкция команды была вполне деловой. LPRT начиналась с номера семейства адресов, затем следовали длина адреса хоста, сам адрес, длина адреса порта и порт. Каждое значение передавалось беззнаковыми десятичными октетами через запятую. Получатель узнавал, сколько полей читать, из самого сообщения, а не из прежнего правила «четыре плюс два».

Пассивный режим нуждался в такой же свободе. LPSV просила сервер слушать на адресе соединения данных. Ответ 228 Entering Long Passive Mode возвращал семейство, длины, хост и порт. Если увеличить только адрес, который предлагает клиент, а серверную сторону оставить в старой форме, переговоры всё равно упрутся в ограничение. FOOBAR раскрыл обе стороны адресного обмена.

Отдельный код 521 позволял серверу сказать: новую грамматику понимаю, указанное семейство не поддерживаю, вот список доступных. Ошибки синтаксиса по-прежнему относились к кодам 500 и 501. Между плохо составленной командой и отсутствующей сетевой возможностью появилась ясная граница. Партнёры могли попробовать общую семью адресов, если такая находилась в ответе.

RFC 1545 перечислял характерные для времени варианты: IP, ST Datagram Mode, SIP, TP/IX, PIP и TUBA. Это срез инженерных возможностей, которые тогда стояли на столе. Длина порта в новом формате тоже появилась не случайно. В TP/IX предусматривались более длинные транспортные селекторы. Если расширить только хостовый адрес, двухоктетный порт станет следующим тесным местом. Текст допускал даже разные семейства для управляющего соединения и канала данных: переходный период мог сочетать несколько сетей в одном сеансе.

В июне 1994 года вышел RFC 1639, объявивший RFC 1545 устаревшим. Принцип длинного адреса остался. Значения семейства от 0 до 15 зарезервировали под версии, связанные с IP; диапазон от 16 до 255 оставили для других протоколов сетевого уровня с назначениями IANA. Novell IPX получил 16. Переработанный текст прямо включил работу FTP через транспортные интерфейсы помимо TCP. Адресная книжка стала пригодна для нескольких сетевых языков.

Старая запись PORT h1,h2,h3,h4,p1,p2 выглядит мелочью на фоне планов нового Интернета. Но она закрепила в прикладном протоколе размер хоста и порта. Чтобы воспользоваться сетью с новым адресом, приложениям пришлось менять собственную фразу для назначения канала данных. FOOBAR показал, что большие архитектурные перемены иногда застревают между шестью клетками, напечатанными много лет назад.