Механизмы обеспечения надежности: Window Scaling, Retransmission и управление перегрузками

В предыдущей теме мы разобрали, как время кругового обхода (RTT) ограничивает скорость. Теперь выясним, как TCP обходит эти ограничения и выжимает максимум из канала, сохраняя целостность данных. Мы переходим от сухих метрик к механизмам, которые управляют «пульсом» интернета.

Sliding Window: конвейер вместо ожидания

Если бы TCP отправлял один пакет и ждал подтверждения (ACK), прежде чем отправить следующий, сеть бы простаивала. Этот неэффективный метод называют «Stop-and-Wait». Чтобы ускорить процесс, TCP использует Sliding Window (Скользящее окно).

Sliding Window — это объем данных, который отправитель может передать в сеть, не дожидаясь подтверждения от получателя.

Представьте ленту конвейера. Пока первые коробки едут к клиенту, вы продолжаете ставить новые. Как только клиент подтвердил получение первой партии, «окно» на ленте сдвигается, позволяя добавить следующую порцию.

• Плюс: Мы максимально загружаем канал данными «в полете».
• Риск: Слишком большое окно переполнит буфер получателя или «забьет» промежуточные роутеры.

Window Scaling: гигабиты в секунду

В заголовке TCP под размер окна выделено всего 16 бит. Это ограничивает его размер 64 КБ — критически мало для современных дата-центров.

Чтобы понять масштаб проблемы, используют формулу Bandwidth-Delay Product (BDP): $BDP = Bandwidth \times RTT$ Она показывает, сколько данных должно находиться в канале, чтобы использовать его на 100%. Если ваш BDP равен 5 МБ, а окно ограничено 64 КБ, вы используете менее 2% пропускной способности.

Для решения создали опцию Window Scaling. Она согласуется при установке соединения (Handshake) и вводит множитель, увеличивающий предел окна до 1 ГБ. В современных дистрибутивах Linux опция включена по умолчанию.

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

Когда пакеты теряются: RTO vs Fast Retransmit

Сеть нестабильна. TCP замечает пропажу пакетов двумя способами:

1. Retransmission Timeout (RTO): Это «план Б». Если подтверждений долго нет, срабатывает таймер и пакет отправляется повторно. Это дорого: ожидание таймера создает простой.
2. Fast Retransmit: Это «план А». Если получатель видит «дырку» в данных (пришли пакеты 1, 2, 4, 5), он шлет дублирующие подтверждения (Duplicate ACKs) на последний целый пакет (№2).

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

Selective ACK (SACK): точечный ремонт

В классическом TCP потеря одного пакета из десяти заставляла отправителя пересылать всю десятку заново. Это лишняя нагрузка.

Selective ACK (SACK) позволяет получателю уточнить: «Я получил пакеты 1–2 и 4–10. Не хватает только третьего».

• Отправитель досылает только один нужный фрагмент.
• Экономятся трафик и ресурсы CPU.

Это критично для микросервисов, где важна минимальная задержка (latency) при передаче множества мелких сообщений.

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

TCP — саморегулирующаяся система. Чтобы не «положить» сеть, используются алгоритмы:

• Slow Start: Начинаем с крошечного окна и удваиваем его с каждым RTT, пока не нащупаем предел.
• Congestion Avoidance: После достижения порога рост окна замедляется и становится линейным.

В ядрах Linux 6.x+ популярен алгоритм BBR. Он анализирует не потери, а реальную скорость и задержку, не создавая очередей в роутерах.

Практика: заглядываем в сокет

Посмотреть, как работают эти механизмы на живом сервере, можно утилитой ss (socket statistics):

# Просмотр параметров TCP для активных соединений
ss -ti

Ключевые параметры в выводе:

• wscale: коэффициент масштабирования окна.
• rto: текущее значение тайм-аута.
• cwnd: текущее окно перегрузки (Congestion Window).

Если cwnd постоянно скачет или подозрительно низок — это сигнал о проблемах со связью или неверных настройках алгоритмов перегрузки.

---

Мы научились выжимать из TCP максимум. Но у этих механизмов есть «ахиллесова пята». Если в идеально настроенном окне потеряется хотя бы один пакет, все остальные данные будут ждать его в буфере, не попадая в приложение.

В следующей теме разберем этот эффект — Head-of-line blocking. Вы поймете, почему он заставил индустрию перейти на QUIC и HTTP/3.