Кратко

  • RFC 938 предписывал PORT NAK, когда DATA находился в окне подтверждения, но его порт был неизвестен: модуль возвращал текущий rcv_nxt и отбрасывал данные.
  • Ответ подтверждает приём номеров пакетов до указанной границы и отвергает номер порта. Он не доказывает, что приложение прочитало, разобрало, разрешило, сохранило или завершило обработку полезной нагрузки.

В истории протоколов слово «доставлено» часто становится слишком вместительным. Оно начинает означать и прибытие пакета, и готовность процесса, и успех операции. RFC 938, опубликованный в феврале 1985 года как Internet Reliable Transaction Protocol, предлагает более строгую лексику. PORT NAK, сказано в документе, NAK-ит номер порта, а не номер пакета. Состояние последовательности между хостами может продвинуться, хотя локальный адресат данных отсутствует.

Информационная страница RFC 938 обозначает статус как experimental/proposed. Следовательно, документ свидетельствует о спроектированной семантике, не о распространённости, трафике, производительности или текущем употреблении. RFC 791 устанавливает лишь то, что поле IP Protocol идентифицирует протокол следующего уровня. Реестр IANA и сейчас связывает номер 28 с IRTP. Это координация имени, а не перепись работающих систем.

Восемь октетов, два самостоятельных вопроса

Заголовок IRTP занимал восемь октетов: тип пакета, номер порта, номер последовательности, длина и контрольная сумма. Были определены SYNCH, SYNCH ACK, DATA, DATA ACK и PORT NAK. Последовательность относилась к надёжной связи между хостами; порт обозначал вышележащий протокол или локальный процесс, которому предназначались данные.

Процесс мог заявить несколько портов, но конкретный порт — только один процесс. При этом соединение IRTP задавалось удалённым Internet-адресом, а не каждой парой хост-порт. Таблица содержала, в частности, snd_nxt, rcv_nxt и snd_una; SYNCH и SYNCH ACK устанавливали или пересинхронизировали это межхостовое состояние. Порт не был именем надёжного соединения. Он становился вопросом локального выбора адресата уже внутри него.

Порядок приёма не случаен. Для DATA модуль сперва проверял, попадает ли номер последовательности в окно подтверждения. Для подходящего пакета он пересчитывал rcv_nxt, а затем проверял известность порта. Известный порт позволял после DATA ACK поставить данные в очередь пользовательского процесса. Неизвестный порт вызывал PORT NAK; данные уничтожались. В обоих ответах стоял текущий rcv_nxt.

Значит, один обмен содержит два правдивых, но разных утверждения: накопленный межхостовый приём дошёл до этой границы; локальный процесс не заявил этот порт. Это не просьба повторить данный пакет и не разрешение приложению. Трасса с NAK даёт основания только для ограниченного вывода о диапазоне приёма и отсутствии известного claim в данный момент.

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

Такое чтение согласуется с Note 64 Heng Lu: общее правило может быть минимальным, детерминированным и проверяемым в собственном слое, не присваивая себе последующее локальное решение. Проводной протокол говорит о своём состоянии; он не распоряжается за процесс, не заявивший порт, и не определяет смысл нагрузки для организации.

RFC 938 также не устанавливал единую эксплуатационную политику. Он требовал механизма запуска повторной передачи и повторной передачи snd_una, но оставлял таймеры и стратегию реализации. Ссылка на двухминутный quiet time в RFC 793 — ограниченное сравнение конструкции, а не тождество IRTP и TCP и не доказательство общей истории внедрения.

Источники и ограничения

RFC 938 подтверждает структуру и PORT NAK; его информационная страница — статус; RFC 791 — роль поля IP; RFC 793 используется только для quiet-time-сравнения; IANA — назначение номера 28. Эти источники не измеряют внедрение, трафик, производительность или современное использование. PORT NAK не становится от этого свидетельством безопасности или делового исхода. Правдивое подтверждение одного слоя не создаёт получателя на следующем.