RFC 114¶

RFC 114 — это меморандум, опубликованный 10 апреля 1971 года в рамках серии документов «Запрос комментариев» (Request for Comments, RFC) и озаглавленный «A File Transfer Protocol» (Протокол передачи файлов). Документ, автором которого является Абхай Бхушан (Abhay Bhushan) из Массачусетского технологического института (MIT), представляет собой одну из первых спецификаций протокола прикладного уровня для передачи файлов между компьютерами в сети ARPANET — предшественнице современного Интернета. RFC 114 заложил концептуальную основу для последующих протоколов передачи файлов, включая FTP (File Transfer Protocol), который впоследствии стал одним из фундаментальных протоколов Интернета.

¶Исторический контекст и предпосылки

К началу 1971 года сеть ARPANET, созданная Агентством передовых исследовательских проектов Министерства обороны США (DARPA), объединяла около 15 узлов (IMP — Interface Message Processors) в университетах и исследовательских центрах США. Основными задачами сети были обеспечение удалённого доступа к вычислительным ресурсам и обмен данными. Первоначально для передачи файлов использовались специализированные протоколы, такие как протокол передачи данных (Data Transfer Protocol, DTP), описанный в RFC 108, и протокол удалённого входа в систему (Telnet), описанный в RFC 97. Однако эти протоколы не были универсальными и не обеспечивали стандартизированного механизма для передачи файлов между разнородными системами.

Абхай Бхушан, работавший в проекте MAC (Project MAC) в MIT, предложил в RFC 114 единый протокол, который позволял бы пользователям одной хост-машины (host) инициировать передачу файлов на другую хост-машину, используя общие команды и форматы данных. Документ был опубликован как комментарий к RFC 108 и предназначался для обсуждения и доработки сообществом разработчиков ARPANET.

¶Основные положения RFC 114

¶Определение и цель

RFC 114 определяет протокол передачи файлов как набор правил для установления соединения между двумя процессами (пользовательским процессом на одном хосте и серверным процессом на другом), аутентификации пользователя, передачи файлов в одном или обоих направлениях и завершения сеанса. Ключевой целью была унификация операций, которые ранее выполнялись с помощью нескольких различных протоколов.

¶Архитектура протокола

Протокол, описанный в RFC 114, предполагает клиент-серверную архитектуру. Пользовательский процесс (клиент) инициирует соединение с серверным процессом (сервером) на удалённом хосте. Для передачи команд и данных используются два отдельных логических канала:

• Канал управления (Control Connection): используется для передачи команд и ответов на них. Он устанавливается на основе протокола Telnet (RFC 97) и остаётся открытым на протяжении всего сеанса.
• Канал данных (Data Connection): используется для непосредственной передачи содержимого файлов. Он может открываться и закрываться по мере необходимости для каждой отдельной операции передачи.

¶Команды протокола

RFC 114 определяет набор команд, которые пользовательский процесс может отправлять серверу. Команды представляют собой текстовые строки, заканчивающиеся символами возврата каретки и перевода строки (CRLF). Основные команды включают:

• USER: указание имени пользователя для аутентификации.
• PASS: указание пароля.
• ACCT: указание учётной записи (необязательно).
• CWD: смена рабочего каталога на сервере.
• LIST: запрос списка файлов в текущем каталоге.
• RETR: запрос на получение (retrieve) файла с сервера.
• STOR: запрос на сохранение (store) файла на сервере.
• APPE: запрос на добавление (append) данных к существующему файлу.
• DELE: запрос на удаление файла.
• QUIT: завершение сеанса.

Каждая команда возвращает трёхзначный числовой код ответа, который информирует клиента о результате выполнения (например, 200 — команда выполнена успешно, 500 — синтаксическая ошибка, 530 — ошибка аутентификации).

¶Формат данных

RFC 114 определяет два основных режима передачи данных:

• Режим потока (Stream mode): данные передаются как непрерывный поток байтов. Этот режим является наиболее простым и используется для передачи текстовых файлов.
• Режим блока (Block mode): данные разбиваются на блоки фиксированного размера, каждый из которых содержит заголовок с информацией о длине и типе блока. Этот режим предназначен для передачи двоичных файлов и обеспечивает более надёжную синхронизацию.

Также протокол поддерживает два типа представления данных:

• ASCII: для текстовых файлов, где каждый символ кодируется в соответствии с ASCII-таблицей.
• Двоичный (Binary): для произвольных двоичных данных, где каждый байт передаётся без изменений.

¶Значение и влияние

¶Переход к FTP

RFC 114 не был окончательной спецификацией. Он послужил основой для дальнейшего развития протокола передачи файлов. Уже через несколько месяцев после публикации RFC 114 были выпущены уточняющие и дополняющие документы, такие как RFC 133 (апрель 1971 года) и RFC 141 (май 1971 года), которые исправляли ошибки и добавляли новые возможности. В 1973 году был опубликован RFC 454, который стал первой официальной спецификацией FTP (File Transfer Protocol), заменившей протокол из RFC 114. FTP, в свою очередь, был стандартизирован в 1985 году в RFC 959, который остаётся основным стандартом для передачи файлов в Интернете по сей день.

¶Вклад в развитие сетевых протоколов

RFC 114 является одним из ранних примеров систематического подхода к проектированию сетевых протоколов. Он ввёл такие ключевые концепции, как:

• Разделение каналов управления и данных.
• Текстовый формат команд.
• Использование кодов ответов для индикации состояния.
• Поддержка аутентификации пользователя.

Эти концепции были впоследствии заимствованы и адаптированы для многих других протоколов, включая SMTP (электронная почта), HTTP (веб) и другие.

¶Историческая ценность

Сегодня RFC 114 представляет собой важный исторический документ, иллюстрирующий ранние этапы развития Интернета. Он показывает, как разработчики ARPANET решали проблемы, связанные с разнородностью систем, и как закладывались основы современных сетевых технологий. Документ доступен в архиве RFC и часто цитируется в исследованиях по истории компьютерных сетей.

¶Критика и ограничения

Как и многие ранние протоколы, RFC 114 имел ряд недостатков, которые были устранены в последующих версиях:

• Отсутствие поддержки пассивного режима: протокол предполагал, что сервер сам инициирует соединение для передачи данных, что создавало проблемы при работе через брандмауэры.
• Слабая аутентификация: пароли передавались в открытом виде, что делало протокол уязвимым для перехвата.
• Ограниченная поддержка типов файлов: протокол поддерживал только ASCII и двоичный режимы, что не учитывало особенности различных операционных систем.
• Отсутствие механизмов возобновления передачи: при обрыве соединения передача файла начиналась заново.

Эти ограничения были частично или полностью устранены в более поздних версиях FTP, а также в других протоколах, таких как TFTP (Trivial File Transfer Protocol) и SFTP (SSH File Transfer Protocol).

¶Источники

• RFC 114 — A File Transfer Protocol (A. Bhushan, 1971)
• RFC 959 — File Transfer Protocol (J. Postel, J. Reynolds, 1985)
• «Where Wizards Stay Up Late: The Origins of the Internet» (K. Hafner, M. Lyon, 1996)
• «A Brief History of the Internet» (B. Leiner, V. Cerf, et al., 1997)
• Архив RFC (rfc-editor.org)