Кратко

  • FTP распределял одну файловую операцию между управляющим соединением и соединением данных. Ответ 1yz был положительным, но предварительным: действие ещё не завершилось и требовало следующего ответа.
  • Соединение данных могло закрыться после нормального EOF, команды ABOR, смены порта, завершения управления или неустранимой ошибки. Один транспортный признак не выбирал между этими причинами.
  • Если ABOR прерывал активный перенос, 426 отрицательно завершал исходную передачу, а следующий 226 положительно завершал команду отмены. Последний код относился к другому действию.

Байты закончились, а вопрос остался

Для пользователя FTP-сессия выглядит единым процессом. Протокол видел два пути. По относительно долговечному управляющему соединению шли команды и трёхзначные ответы. Отдельное временное соединение несло список каталога или содержимое файла.

Процесс передачи наблюдал установление соединения, октеты, EOF и транспортную ошибку. Интерпретатор протокола знал, какая команда выполнялась, был ли уже отправлен предварительный ответ и какой финальный ответ закроет запрос.

Эти записи дополняли друг друга, но не были двумя копиями одной квитанции. Поток данных мог замолчать, не объяснив причину. Управляющий канал мог исчезнуть после локального эффекта. Гибкость отдельного пути данных требовала не наделять TCP-событие полномочиями прикладного результата.

Ранний FTP уже различал два закрытых исхода

В июле 1972 года RFC 354 определял 252 FTP transfer completed correctly. Отдельно существовал 452 FTP: File transfer incomplete, data connection closed.

В обоих случаях соединение данных могло быть закрыто. Различалось утверждение сервера о файловом действии: правильное завершение или неполная передача. Эта ранняя пара показывает, что аккуратный FIN не задумывался как самостоятельный сертификат успеха.

FTP соединял неодинаковые представления, логические размеры, структуры файлов и системы хранения. Сервер координировал интерпретатор, процесс данных и локальную операцию. Сетевой счётчик не мог один описать преобразование, запись и итог запроса.

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

Первая цифра стала переходом состояния

RFC 640 в 1974 году упорядочил классы ответов. 1yz — положительный предварительный: действие началось, остаётся незавершённым, и последует ещё один ответ. 2yz — положительное завершение. 3yz принимает предыдущий шаг, но ждёт данных. 4yz и 5yz завершают запрос отрицательно, по-разному влияя на возможность повтора.

Поэтому «положительный» не означал единую зелёную категорию. 150 мог перевести внимание клиента к данным, но не давал закрыть команду как успешную.

RFC 640 также разрешил более ранний предварительный ответ — когда передача возможна, а соединение уже существует или будет предпринята попытка открыть его. Диалог стал быстрее, зато граница доказательства яснее: готовность не доказывает ни установление, ни завершение.

После 125 или 150 оставался финал

RFC 765, а затем RFC 959 1985 года сохранили двухступенчатую схему. RFC 959 допускает не более одного 1yz на команду; после него сервер обязан прислать ответ завершения.

Для файловых команд 125 сообщает, что соединение данных уже открыто и перенос начинается. 150 сообщает о допустимом состоянии файла и предстоящем открытии. Финалом могут быть 226 или 250, либо подходящие ошибки 425, 426, 451, 551 и 552.

Таким образом, трасса с 150, ожидаемыми байтами и FIN остаётся неполной на уровне FTP, если потерян последний ответ. И отрицательный финал не исчезает из-за совпавшего размера. Несогласие наблюдений — самостоятельный факт.

Клиент обычно ждёт завершения перед следующей обычной командой, потому что предыдущий переход ещё открыт. ABOR и STAT требуют особых правил именно для доступа к выполняющейся работе.

У закрытия было несколько причин

RFC 959 перечисляет причины, по которым сервер закрывает соединение данных: нормальное завершение передачи, получение отмены, изменение спецификации порта, законное или аварийное закрытие управления, неустранимая ошибка.

На транспортном уровне они могут выглядеть сходно, но для команды это разные результаты. Даже упорядоченный FIN не доказывает достижение нужной границы файла, подтверждение локального эффекта или отсутствие намеренной отмены.

В режиме Stream закрытие может обозначать конец файла. Это правило кадрирования, а не расширенная гарантия успеха. При восстановлении виден предел: без управляющего контекста нормальный конец и преждевременный разрыв могут оставить одинаковый след.

Монитор должен хранить «наблюдался EOF/закрытие данных» и «FTP-команда завершилась кодом X» как разные события. Совпадение времени не уравнивает их полномочия.

Положительный 226 мог завершать отмену

Если прежний сервис уже закончен к приходу ABOR, останавливать нечего. Сервер всё равно может ответить 226, сообщая об обработке команды отмены. Это ответ на ABOR, а не новое поручительство за предыдущий файл.

Если передача ещё идёт, RFC 959 требует два ответа. Сначала 426 сообщает о закрытии соединения и прерывании исходной передачи. Затем 226 сообщает об успешной обработке ABOR.

Результаты принадлежат разным действиям:

  1. исходная передача → отрицательное завершение (426);
  2. запрос отмены → положительное завершение (226).

Хранение только последнего кода приписывает успех не той работе. Привязка обоих кодов к передаче, напротив, скрывает успешную отмену. Порядок и владелец действия — часть семантики.

Полномочия 226 заканчивались на границе FTP

В обычной последовательности 226 говорит, что соединение данных закрывается и запрошенное файловое действие успешно в FTP. Код не содержит хеша или идентификатора версии. Он не гарантирует долговечную запись, резервную копию, будущие права, потребление другим приложением или выполнение коммерческого обязательства.

Более сильным выводам нужны отдельные квитанции: digest для содержания, запись синхронизации для локальной устойчивости, неизменяемый ID для версии, подтверждение приложения для дальнейшего приёма.

Отсутствие 226 также не доказывает отсутствие эффекта. Сервер мог завершить запись и потерять управляющее соединение до доставки ответа. Слепой повтор создаст копию или перезапись. Честное состояние — «результат FTP неизвестен».

Управляющая история входила в досье передачи

Аудируемая запись сохраняет команду и порядок, 125/150, точку данных, результат открытия, байты, EOF, известную причину закрытия, все финальные ответы и время ABOR или STAT.

Рядом хранятся факты, которые FTP не подтверждает: представление и режим, разрешение пути, локальный эффект, устойчивость, хеш и версия объекта. Они не заменяют друг друга.

Одного done мало. Нужны состояния: предварительно принято; данные ожидаются; данные активны; данные закрыты, финал ожидается; передача завершена положительно; передача завершена отрицательно; отмена запрошена; исходная передача прервана; отмена обработана; управляющий результат неизвестен.

После сжатия до одного флага нельзя восстановить, какое действие завершил последний ответ. Необратима потеря смысла, а не закрытие сокета.

Источники и граница доказательства

Материал опирается на RFC 354, RFC 542, RFC 640, RFC 765, RFC 959 и RFC 1123. Они устанавливают классы ответов, два соединения, причины закрытия и последовательность ABOR.

RFC 1123 в 1989 году называл restart, ABOR и Block полезными, но не широко реализованными. Это историческое наблюдение, не современная статистика. Источники не доказывают поведение нынешних продуктов или долговечность файловой системы.