Кратко

  • RFC 2414 сделал увеличенное начальное окно TCP необязательным: не выше min(4*MSS, max(2*MSS, 4380 bytes)). Правило относилось к первой передаче в новом соединении, а не ко всем возобновлениям после простоя или потери.
  • Расчёт состоял в том, что второй сегмент может вызвать ACK без ожидания таймера задержанного подтверждения. Во многих смоделированных случаях ns-2-симуляции RFC 2415 показали меньшую медианную задержку веб-страницы.
  • Результаты для смешанных групп не сводились к одному выводу. При умеренной нагрузке IW=3 не ухудшал показатели группы IW=1; в сценарии крайней перегрузки с 32/32 веб-клиентами пострадала сама группа с большим окном.
  • Это были симуляции, а не обследование фактического развёртывания в Интернете. Скорость отдельного соединения и распределение эффектов на общем пути — разные вопросы.

Целью было первое подтверждение

Идея выглядела скромно: новому TCP-соединению отправить больше одного сегмента данных, прежде чем ждать. Выигрыш мог появиться ещё до крупной передачи. Если в пути только один сегмент, получатель с задержанными подтверждениями может ждать таймер. Приход второго сегмента способен вызвать ACK раньше. Для небольшого веб-объекта устранение этой паузы могло позволить завершить передачу за один обмен туда и обратно. RFC 2414 указывал, что для соединения, способного увеличивать окно перегрузки, изменение может убрать до трёх обменов и один тайм-аут задержанного ACK в начальной фазе медленного старта.

RFC 2414 не требовал начинать каждое соединение с четырёх сегментов. Опубликованный в сентябре 1998 года экспериментальный документ поднял разрешённый предел до min(4*MSS, max(2*MSS, 4380 bytes)) и сказал, что TCP MAY использовать большее значение. В зависимости от MSS это означало предел в два, три или четыре сегмента. Правило относилось к начальному окну после трёхстороннего рукопожатия. Окно при потере оставалось равным одному сегменту; возобновление после длительного простоя рассматривалось отдельным необязательным правилом. Это был ограниченный эксперимент, а не разрешение увеличивать любое окно после каждой паузы в трафике.

Конечный узел мог выбрать первую передачу, но не мог зарезервировать очередь, в которую попадут пакеты. RFC 2414 описывал обе стороны компромисса: пакетная вспышка могла обернуться потерями или тайм-аутами для инициирующего соединения, тогда как другие потоки могли понести потери или несправедливые последствия на перегруженном общем канале. Авторы также предупреждали: одновременное открытие браузером нескольких соединений усугубит проблему, если каждое начнёт с большего окна. Улучшение одного потока меняет нагрузку на очередь, которой пользуются многие.

Симуляции вели несколько счётов

Сопутствующий информационный RFC 2415 проверял спор с помощью ns-2; это не был отчёт о внедрении. Модель включала узкое место 1,5 Мбит/с с RTT 50 мс между более быстрыми линиями. В ней менялись число веб-клиентов — 8, 16 или 32, число длинных FTP-передач — до трёх, а начальное окно — от одного до четырёх сегментов по 1460 байт. Веб-модель использовала небольшие страницы с тремя встроенными URL и случайными паузами перед новыми запросами; FTP передавал файлы по одному мегабайту. Так обеспечивалось контролируемое сравнение, но тем самым задавались и пределы применимости результата.

Во многих смоделированных случаях большее окно снижало медианную задержку страницы, нередко примерно на 30%. Авторы связали значительную часть скачка от одного сегмента к двум с выбранным распределением размеров URL: медианный основной и встроенный объект помещался в два пакета. Иное распределение могло бы дать другую кривую. Это результат о механизме в конкретной модели, а не универсальный процент для браузеров или каналов.

Разделение клиентов на когорты уточнило вопрос. При делении веб-клиентов 8/8 и 16/16 между IW=1 и IW=3 авторы не обнаружили отрицательного эффекта для группы с одним сегментом; группа с большим окном сохранила преимущество. Но при 32/32 в сценарии, названном статьёй патологической перегрузкой, клиенты IW=3 пострадали. Авторы объяснили это множеством одновременных открытий соединений и несколькими потерями. Опыт не доказывал, что любой более крупный старт вредит соседям; он показывал, что улучшенная медиана или общий итог не описывают опыт каждой группы при всякой смоделированной нагрузке.

Это отличается от уже разобранной трассы одного соединения и трёх буферов из RFC 2416. RFC 2415 рассматривает множество потоков в модели, разделяющих узкое место, и зависимость результата от состава этой смеси. Ни одна из симуляций не устанавливает поведение реальных устройств во всём Интернете и не задаёт универсальную меру справедливости. Позже RFC 3390 заменил RFC 2414 необязательным пределом в стандарте; RFC 5681 зафиксировал правило, а RFC 6928 экспериментально исследовал старт с десяти сегментов. Последующая история публикаций не превращает модель 1998 года задним числом в перепись внедрений.

Running-Code Primacy Хэнга Лу здесь полезна лишь как дисциплина доказательств: не смешивать механизм с системой, которую действительно проверяли. On Reality Layers напоминает, что задержку страницы, потери в очереди и вывод обо всей сети нельзя свести к одному наблюдению. Эти заметки не служат историческим свидетельством о TCP; его дают RFC.

Источники