Кратко

  • RDP стремился надёжно доставить каждое сообщение, но не делал порядок показа приложению обязательным; режим выбирался при Open на всё соединение.
  • Обычный ACK сохранял границу непрерывной последовательности, а EACK перечислял корректно принятые сегменты за пробелом, чтобы повторить только потерянное.
  • Приём транспортом, передача в пользовательский буфер и завершение операции оставались разными доказательствами; RST, NUL и номер 27 IANA их не объединяли.

Пробел не отменял то, что лежало за ним

Пусть отправлены 100, 101, 102 и 103. Сегмент 101 потерян, а 102 и 103 пришли с корректной контрольной суммой. Непрерывная граница остаётся на 100. Сказать, что получено всё до 103, было бы ошибкой. Но молчать о 102 и 103 — значит терять полезное знание.

RFC 908 использовал два вида подтверждения. ACK показывал последний корректный сегмент в последовательности. EACK содержал номера корректных сегментов, пришедших вне порядка. Отправитель повторял 101, не повторяя всё, что уже находилось у получателя.

Левая граница окна при этом не перескакивала через потерю. Если 101 долго не появлялся, новые сегменты приближались к правой границе и передача останавливалась. Выборочное подтверждение сохраняло работу и канал, но не превращало неполную последовательность в полную.

Надёжность отвечала за все сообщения, не за один порядок

RDP проектировался для удалённой загрузки, дампов памяти и отладки. В образе памяти нельзя навсегда потерять блок. Поэтому общими средствами стали номера последовательности, проверка повреждения, положительное подтверждение, таймер и повтор.

Однако блок с собственным адресом можно поместить на место сразу. Команды отладчика могут иметь причинную связь: поставить точку останова надо до продолжения программы. Первая задача выигрывает от ранней передачи, вторая может от неё сломаться.

Протокол не выбирал за обе задачи. Запрос Open задавал sequenced или non-sequenced delivery. В неупорядоченном режиме 102 можно было скопировать приложению сразу после приёма. В упорядоченном режиме тот же 102 подтверждался через EACK, но ждал 101 перед передачей пользователю.

Следовательно, подтверждение не было сигналом видимости для приложения. Оно было сообщением о состоянии транспорта. Видимость определялась контрактом, установленным при открытии.

Смысл середины задавался началом

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

Если наблюдение начинается после SYN, оно теряет часть смысла. EACK для 102 доказывает выборочный приём, но без режима нельзя узнать, был ли 102 уже отдан приложению. Начало соединения создаёт эпоху, к которой относятся последующие номера и доказательства.

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

Полуоткрытый транспорт и завершённая работа

RDP определял CLOSED, LISTEN, SYN-SENT, SYN-RCVD, OPEN и CLOSE-WAIT. Он обрабатывал одновременное открытие, когда SYN пересекались, сохраняя начальные номера обоих направлений.

Для некоторых полуоткрытых состояний служил NUL. Он занимал следующий номер последовательности; ACK показывал, что удалённый RDP ещё узнаёт соединение. Это не доказывало здоровье загрузчика или выполнение команды отладчика.

Закрытие также было узким. Close отправлял RST, переходил в CLOSE-WAIT и удалял запись. RFC 908 возлагал на пользователя обязанность до Close определить, что требуемые данные доставлены надёжно. Окончание транспорта не становилось подтверждением результата приложения.

Контрольная сумма подтверждала лишь прохождение заданной проверки. Она не была криптографической аутентификацией. ACK и EACK подтверждали принятие RDP. Буфер пользователя и необратимый эффект требовали следующих ступеней доказательства.

Вторая версия сохранила след эксперимента

RFC 1151 описал в 1990 году проблемы экспериментов 1986–1987 годов. Нелинейная 32-битная контрольная сумма v1 неожиданно зависела от представления данных в машине: оптимизированные реализации на сравнимом оборудовании различались по стоимости в пять раз. V2 перешла на 16-битную контрольную сумму TCP.

Поля портов выросли с восьми до шестнадцати бит. Изменение заголовка потребовало номера версии 2. Была исправлена и логика SND.UNA: после подтверждения SEG.ACK старейшим неподтверждённым становился SEG.ACK + 1.

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

Реестр номеров протоколов IANA сохраняет за RDP значение 27. Это доказательство соответствия имени и номера, а не существования трафика, версии, реализации или поддержки EACK.

Надёжность как набор проверяемых границ

Корректно ли пришёл сегмент? Подтвердил ли его транспорт? Получило ли его приложение? Завершило ли оно действие? RDP не заменял четыре ответа одним удобным словом.

Порядок оставался важен там, где существовала зависимость. Он просто не становился всеобщей властью транспорта над приложениями, которым такая зависимость не нужна.

Источники