Кратко

  • Кумулятивный ACK подтверждает непрерывную последовательность, но при нескольких потерях в одном окне не описывает островки данных после первого разрыва.
  • RFC 2018 разрешил получателю сообщать о несмежных диапазонах байтов, сохранив эти сведения рекомендательными, а кумулятивный ACK — окончательным.
  • RFC 3517 и RFC 6675 превратили карту в консервативное восстановление со списком диапазонов, оценкой данных в сети и ограниченной спасательной передачей.

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

RFC 2018, опубликованный в октябре 1996 года, дал TCP второй способ описывать прием. Предыдущая форма присутствовала в RFC 1072, но не получила широкого внедрения, в том числе из-за разногласий о сочетании с масштабированием окна. Новая конструкция разделила разрешение и передачу сведений. SACK-Permitted предлагается в SYN, после чего блоки SACK могут указывать левую и правую границы непрерывных принятых диапазонов.

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

Размер карты также ограничен. Под опции TCP отведено 40 байтов. Помещаются максимум четыре блока SACK, а при использовании временных меток обычно три. RFC 2018 требует ставить первым блок с самым новым сегментом и рекомендует повторять недавние блоки. Это сохраняет свежесть и повышает устойчивость к потерянным ACK на обратном пути, но передает лишь выбранную часть состояния буфера.

Стандарт 1996 года определил формат свидетельств, не закрепив целиком алгоритм отправителя. Он сохранил требования управления перегрузкой. В апреле 2003 года RFC 3517 описал консервативную процедуру. Отправитель ведет scoreboard кумулятивно и выборочно подтвержденных диапазонов, решает, какие пробелы считать потерей, оценивает через Pipe число байтов в сети и выбирает следующую передачу в пределах окна перегрузки.

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

В августе 2012 года RFC 6675 заменил RFC 3517. Новая версия использовала свежую информацию SACK в определении дублирующих ACK, улучшила вывод о потере для сегментов меньше максимального размера и добавила RescueRxt. Если потеря в конце окна и отсутствие новых данных грозят остановить часы подтверждений, разрешается одна оптимистическая спасательная повторная передача за период. Ее размер ограничен одним максимальным сегментом отправителя.

История SACK — не рассказ о бесплатной скорости, а распределение ограниченного доверия. Получатель видит свой текущий буфер, но не обещает хранить его всегда. Отправитель управляет восстановлением, однако наблюдает путь через запаздывающие отчеты. Заголовок сжимает состояние, а тайм-аут может обесценить прежние выводы.

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

Источники