Кратко

  • Нулевое окно приёма — допустимое управление потоком: сейчас нет ёмкости для новых байтов. Это не доказательство отказа узла, пути или приложения.
  • Чистый ACK, открывающий окно, не передаётся надёжно. Малый зонд вызывает новый отчёт, а интервалы дальнейших зондов растут экспоненциально.
  • Пока получатель отвечает, TCP должен сохранять соединение. Приложение или ОС всё равно могут явно завершить его ради местных ресурсов.

Два правильных ожидания создали тупик

Принимающее приложение перестаёт читать, буфер заполняется, TCP объявляет ноль. Отправитель останавливается. Позже приложение освобождает место, и ACK несёт положительное окно. Если он потерян, отправитель по-прежнему знает только запрет, а получатель считает изменение уже сообщённым.

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

Окно описывало ёмкость, а не диагноз

RFC 813 разделил offered window получателя и usable window отправителя после вычета неподтверждённых байтов. Это инструмент управления потоком.

Ноль не объясняет, почему программа не читает. Канонический пример — принтер без бумаги: человек может вмешаться через минуты или дни, а хост и сеть всё это время исправны. Транспорт не видит основания объявлять работу погибшей.

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

Исключительный октет заново спросил разрешение

Основа появилась в RFC 793, а RFC 9293 сохраняет обязательный zero-window probing. Даже при нуле отправитель периодически посылает хотя бы один новый байт, если он есть, либо повтор; получатель отвечает ожидаемым номером и текущим окном.

Зонд не отменяет запрет. Он задаёт ограниченный вопрос. ACK с нулём подтверждает паузу; положительное значение повторно доставляет потерянное разрешение.

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

Подтверждённый ноль отличался от молчания

RFC 1122 разрешает получателю держать окно нулевым неограниченно. Пока тот подтверждает зонды, TCP отправителя обязан позволять соединению оставаться открытым.

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

Persist не отдавал чужой стороне право на память

«Неограниченно» ошибочно читали как запрет освобождать ресурсы. RFC 6429 уточнил: TCP не должен сам закрывать соединение лишь из-за persist, но обязан выполнить явный приказ приложения или ОС.

Множество клиентов может запросить большие ответы, перестать читать, объявить ноль и подтверждать зонды. Сервер сохраняет очереди и блоки соединений, пока законным пользователям не останется памяти.

Единый скрытый таймер тоже не различает честную печать и враждебное удержание. Решать должен слой, знающий сервис, клиента, стоимость и срок. TCP сохраняет общую семантику; локальная политика отвечает за локальный ущерб.

Открытие окна крошками создавало вторую устойчивую поломку

RFC 813 назвал Silly Window Syndrome режим, где малые приращения окна порождают малые сегменты, больше ACK, работы CPU, потерь и повторов. Приведённые там числа — исторические тяжёлые случаи, не универсальная норма.

Получатель может не объявлять каждый небольшой свободный участок, а дождаться полезного объёма. Отправитель не реагирует на каждое малое движение. RFC 9293 требует SWS-избегания на обеих сторонах и отделяет его от дополняющего алгоритма Nagle для мелких записей приложения.

Persist не даёт значимому открытию потеряться. SWS-защита не даёт каждой крошке стать неэффективным разрешением. Доставка разрешения и его размер — части одного механизма.

Пережило историю разделение ответственности

RFC 793, RFC 813, RFC 1122, RFC 6429 и RFC 9293 оставили не священное число таймера, а три роли. Получатель контролирует вместимость. TCP отправителя редко переспрашивает её. Приложение и ОС выбирают бюджет времени, памяти и закрытия.

Ждать при нуле — значит сохранять возможность продолжения, а не признавать безграничное право партнёра на свои ресурсы.

Источники и границы

Закрытый набор: RFC 793, RFC 813, RFC 1122, RFC 6429 и RFC 9293. Он не устанавливает таймеры каждой нынешней ОС, частоту атак или здоровье отдельного приложения.