Кратко

  • RFC 1106 предложил рекомендательный NAK и 30-битное окно приёма TCP. Расширения были реализованы и показаны в работе с использованием ресурсов NASA, но документ называл их экспериментом, а не предложением стандарта Интернета.
  • RFC 1110 выявил условие за пределами опыта: окно выросло, а пространство 32-битных номеров последовательности — нет. Номер мог повториться через четыре круговых задержки, и старый дубликат становился похож на новые данные.
  • NAK подтверждал лишь разрыв, увиденный получателем. Он не различал опоздание и окончательную потерю, шум и перегрузку, а также не доказывал повторную отправку, восстановление или доставку.

Результат был действителен вместе со своими условиями

RFC 1106 Р. Фокса вышел в июне 1989 года. В статусе документа сказано, что два расширения TCP реализовали и показали в работе с ресурсами NASA. Там же они названы экспериментальным протоколом, исходной точкой исследований, а не предложением стандарта Интернета.

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

Само резюме называло незакрытую границу: перегрузка или шум, а также применимость ко всей инфраструктуре Интернета вместо изолированной спутниковой среды. Удалить эту оговорку ради короткого слова «работает» означало бы изменить исходное утверждение.

Нынешняя карточка RFC Editor относит документ к Historic и Legacy, а IETF Datatracker хранит запись. Поздний статус описывает принятие и авторитет, но не превращает ограниченный опыт в несуществующий.

Приёмник видел пробел, но не видел путь

NAK должен был ускорить реакцию на длинном канале. Когда пришедший вперёд сегмент показывал разрыв, получатель просил повторить данные, необходимые для движения левого края окна. Это могло не дать спутниковому «каналу данных» опустеть в ожидании таймера.

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

Сам NAK был рекомендательным и ненадёжным. Его не посылали повторно. Отправитель мог не делать ничего или немедленно передать данные ещё раз; при исчезновении NAK оставалось обычное восстановление TCP. Запись NAK отправлен доказывала наблюдение и просьбу, но не потерю, действие отправителя, успех и доставку.

Такой же пробел возникал из-за шума, сброса в очереди, перестановки или необычной задержки. Точка, увидевшая отсутствие, не получала тем самым наблюдение за всей трассой и полномочие назвать причину.

Большое окно обещало память конечного узла

16-битное поле ограничивало окно 64 КиБ. На пути с большим произведением полосы на задержку этого не хватало для достаточного объёма неподтверждённых данных. RFC 1106 оставлял младшие биты в обычном заголовке и передавал старшие в option, получая 30 бит.

Обе стороны должны были согласиться в SYN и SYN-ACK; затем старшая часть ожидалась в каждом пакете. Согласование подтверждало общую интерпретацию между реализациями. Оно не подтверждало безопасность пространства последовательности и времени жизни пакетов на любом пути.

Окно приёма не было пропускной способностью сети. Оно выражало буферы и локальную готовность получателя. RFC 1106 предупреждал, что произвольно большое окно способно исчерпать память, вытеснить другие задачи или обрушить машину. Обсуждаемое с ресурсами NASA ограничение больших окон отдельными программами управляло памятью хоста, а не выдавало полосу по маршруту.

Номер вернулся не через 65 536 оборотов, а через четыре

В августе А. Маккензи опубликовал RFC 1110. Интернет мог терять, переставлять и дублировать пакеты. 32-битные номера TCP циклически повторялись; маленькое окно и предел жизни пакета делали их фактически уникальными, пока старые данные могли оставаться в сети.

В модели RFC 1110 окно 16 бит составляло 1/65 536 пространства, поэтому номер использовался снова лишь через 65 536 круговых задержек. При окне 30 бит и прежнем пространстве — через четыре. NAK мог породить копию через одну. Если старый пакет задерживался примерно на пять кругов, он возвращался, когда тот же номер входил в новое окно, и мог заменить новые байты старыми.

Критика не утверждала, что опыт был ложным. RFC 1110 допускал, что изолированная спутниковая сеть могла быть «без памяти»: доставить по порядку или потерять, но не хранить и вернуть позднее. Проблема возникала в более широком множестве состояний общего Интернета. Не измерение, а перенос вывода потерял силу.

История развела дефект, распространение и новые механизмы

RFC 4614 позднее назвал RFC 1106 дефектным для общего применения, RFC 1110 — его опровержением, а options — не принятыми широким сообществом. Упоминание NAK в SCPS-TP оставалось узким исключением.

RFC 6247 в 2011 году формально перевёл оба текста в Historic среди расширений без широкого использования. Отсутствие распространения не равняется отсутствию реализации.

RFC 7323 разделил родственные задачи: Window Scale — предложение в SYN, SACK описывает принятые и пропущенные сегменты, timestamps и PAWS защищают от старых дубликатов после оборота последовательности. Прямое происхождение от RFC 1106 не доказано. Раздельность этих фактов доказана самим контрактом механизмов.

Среда была частью объекта доказательства

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

Если оставить только «сработало», локальный результат получит чужую юрисдикцию. Если оставить только Historic, исчезнет реальная работа. RFC 1106 и RFC 1110 полезны вместе: первая запись говорит, что произошло, вторая — чего это событие не установило.

Источники