Управление потоком и перегрузкой

Свежее TCP-соединение между Лондоном и Сиднеем не знает, насколько быстра линия. Оно начинает осторожно, удваивая скорость отправки каждый round-trip, пока не достигнет предела — затем отступает и пробует снова. Этот танец между отправителем и сетью позволяет TCP заполнить 10-гигабитный канал или вежливо разделить мегабитный.

Скользящее окно и управление потоком

После установки соединения каждый TCP-сегмент несёт размер окна — количество байтов, которые получатель готов принять сверх последнего подтверждённого байта. Отправитель поддерживает скользящее окно неподтверждённых байт в пути, ограниченное минимумом из рекламируемого окна получателя и собственного окна перегрузки. По мере прихода ACK окно скользит вперёд, позволяя отправлять новые байты. Если приложение получателя медленно опустошает буфер сокета, окно уменьшается; при полном заполнении буфера получатель рекламирует window=0 и отправитель делает паузу. Это сквозное управление потоком: получатель диктует темп, отправитель подчиняется.

MSS, масштабирование окна и SACK

Три опции, согласуемые при обмене SYN/SYN-ACK, существенно влияют на пропускную способность:

Maximum Segment Size (MSS): максимальный TCP-payload, который стек может обработать без IP-фрагментации. Типично: 1460 байт на Ethernet (MTU 1500 минус 20 IP + 20 TCP заголовки), 1220 байт на туннельных сетях.

Window Scaling (RFC 7323): 16-битное поле окна умножается на 2^scale, допуская окна до 1 ГиБ. Без этого ограничение 64 КиБ на линке 100 мс RTT ограничивает пропускную способность примерно 5 Мбит/с независимо от реальной скорости линка (bandwidth-delay product = 64 КиБ / 0,1 с ≈ 640 КиБ/с). Необходимо для высокополосных путей с большой задержкой.

Selective Acknowledgements (SACK, RFC 2018): получатель перечисляет точные диапазоны байт, полученных за пропуском, чтобы отправитель повторно передал только недостающие части, а не всё после пробела. На потерянном пути с большим RTT SACK может удвоить эффективную пропускную способность.

Математика таймера повторной передачи (RFC 6298)

Если сегмент не подтверждён в течение retransmission timeout (RTO), отправитель пересылает его. RFC 6298 задаёт:

SRTT ← (1 − 1/8)·SRTT + (1/8)·new_RTT
RTTVAR ← (1 − 1/4)·RTTVAR + (1/4)·|SRTT − new_RTT|
RTO = SRTT + max(G, 4·RTTVAR)

SRTT — сглаженный RTT, RTTVAR — дисперсия RTT (экспоненциально взвешенные скользящие средние). Первый RTO по умолчанию 1 с; после таймаута удваивается (экспоненциальный откат) до прихода сегмента или разрыва соединения. Алгоритм Карна запрещает измерять RTT по повторно переданным сегментам, так как ответный ACK неоднозначен.

Современный Linux использует RACK-TLP (RFC 8985) для более быстрого обнаружения потерь: RACK объявляет сегмент потерянным, когда позже отправленный сегмент подтверждён и истёк интервал переупорядочивания — без ожидания таймера RTO. TLP (Tail Loss Probe) повторно отправляет последний неподтверждённый сегмент через один RTT после последней отправки, чтобы избежать зависания на последнем пакете отправки.

Slow start и congestion avoidance

Свежее соединение не знает, насколько быстра сеть. Slow start открывает congestion window экспоненциально (1, 2, 4, 8, … MSS за RTT) до тех пор, пока не произойдёт потеря или не достигнет slow-start threshold (ssthresh). После этого congestion avoidance увеличивает окно линейно (~1 MSS за RTT для Reno/CUBIC).

При потере алгоритм зависит от варианта:

• Reno: уменьшает окно вдвое, затем линейное увеличение.
• CUBIC (Linux по умолчанию с 2.6.19): уменьшает менее агрессивно, затем зондирует с кубической кривой — быстрее восстанавливает пропускную способность на путях с большим BDP.
• BBR: полностью игнорирует потери как сигнал перегрузки; использует RTT + измерения доставленных байт (разбирается в уроке о BBR).