Окно TCP: как протокол не даёт отправителю захлестнуть получателя

Если бы TCP ждал подтверждение после каждого сегмента, скорость ограничивалась бы размером сегмента за один RTT, то есть была бы ничтожной. Поэтому отправитель передаёт сразу серию сегментов и только потом ждёт подтверждений. Количество данных, которые можно держать «в полёте» без подтверждения, и называется окном.

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

Первое ограничение задаёт получатель. В каждом сегменте он сообщает размер окна приёма, то есть объём свободного места в своём буфере. Это управление потоком: медленный получатель может притормозить быстрого отправителя. Если буфер полностью заполнен, объявляется нулевое окно, и отправитель делает паузу, время от времени проверяя, не освободилось ли место.

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

Максимальная скорость одного соединения примерно равна размеру окна, делённому на RTT. Окно 64 КБ при RTT 100 мс даёт около 640 КБ/с, то есть примерно 5 Мбит/с, как бы широк ни был канал. Именно поэтому один поток на дальнее расстояние часто медленнее, чем несколько параллельных, и поэтому тестеры скорости используют несколько соединений.

Исторический предел поля окна в заголовке составлял 65 535 байт. Расширить его позволяет параметр масштабирования, согласуемый при рукопожатии: он умножает значение на степень двойки и допускает окна порядка гигабайта.

На быстрых каналах с большой задержкой: загрузка с зарубежных серверов, спутниковые линии, передача между дата-центрами. Современные системы подстраивают буферы автоматически, но неудачные настройки прокси, фильтров или очень старые устройства могут отключить масштабирование, и скорость упрётся в 65 КБ на круг.

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

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

В анализаторе пакетов откройте любой сегмент TCP: значение Window Size и коэффициент масштабирования показаны в заголовке. Диаграммы окон показывают, растёт ли оно и не упирается ли в потолок. В Windows и Linux размеры буферов настраиваются автоматически, и ручное вмешательство редко улучшает результат.

Не стоит слепо применять «оптимизаторы интернета» из сомнительных утилит: они часто меняют параметры без понимания и вредят. Если скорость низка на дальних серверах и хороша на ближних, начните с проверки задержки и потерь, а не окон.

Разберём числа, чтобы формула стала осязаемой. Допустим, требуется получить 100 Мбит/с при RTT 50 мс. Нужный объём данных «в полёте» равен произведению скорости на задержку: 100 Мбит/с умножить на 0,05 с даёт 5 Мбит, или около 625 КБ. Это называется произведением полосы на задержку, BDP. Если окно меньше, канал не заполнится.

Теперь тот же канал на RTT 200 мс, например при обращении к далёкому континенту: понадобится уже 2,5 МБ окна. Без масштабирования максимум 64 КБ даст только около 2,6 Мбит/с. Понятно, почему при отключённом масштабировании даже быстрый канал работает как медленный.

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

Из этого следует практический вывод: скорость одного потока зависит не только от канала, но и от расстояния до сервера.