how/network

TCP retransmission и fast retransmit

Что делает TCP когда пакет теряется? Не ждёт долго. Если три «дубликата ACK» подряд - сразу переотправляет, не дожидаясь таймера.

Сеть не идеальна: пакеты иногда теряются (полная очередь на роутере, сбой Wi-Fi, обрыв линка). А TCP обещает «надёжную доставку» - значит должен как-то восстанавливать потери. Как именно?

У TCP есть два механизма переотправки:

RTO retransmit - таймер. Если ACK на пакет не пришёл за определённое время (RTO = retransmission timeout, обычно ~200мс +) - пакет считается потерянным и переотправляется
Fast retransmit - быстрая реакция через dup ACKs. Если получили 3 ACK подряд с одним и тем же номером - это сигнал «у меня дырка, пожалуйста переотправь», и клиент немедленно переотправляет, не ждёт RTO

Нажми ▶ - посмотрим как fast retransmit срабатывает на потере одного пакета посередине потока.

step 1/8·00 · соединение установлено, шлём данные

§ шаги

Клиент и сервер прошли three-way handshake (см. tcp-handshake) и оба в ESTABLISHED. Готовы передавать данные.

TCP не ждёт ACK на каждый пакет - пайплайнит их. Окно отправки cwnd определяет сколько пакетов можно «в полёте» одновременно без подтверждения.

итого

Что важно запомнить:

TCP пайплайнит пакеты - клиент шлёт несколько подряд, не дожидаясь ACK на каждый. Это нужно чтобы канал не простаивал на RTT
Когда сервер получает пакет не по порядку (например 1400 при ожидаемом 1200) - он не отбрасывает его, а буферизует и шлёт отправителю dup ACK с номером дырки. «Я жду 1200, шли 1200»
3 dup ACK - стандартный триггер fast retransmit (RFC 5681). Почему именно 3? Эмпирическая константа - даёт хороший баланс между «не реагировать на банальное переупорядочивание пакетов» и «не ждать RTO впустую»
Современный Linux умеет SACK (Selective ACK) - сервер может сказать «получил 1400, 1600, 1800, но не 1200». Тогда клиент переотправляет только 1200, а не всё с 1200 и дальше
При массовых потерях RTO срабатывает первым (нет 3 dup ACK, потому что сами пакеты не доходят). RTO растёт экспоненциально при повторных таймаутах - защита от congestion collapse
В TCP-statistics (netstat -s / /proc/net/snmp) видно сколько retransmit'ов произошло - высокий процент = проблемы с сетью

Если хочется глубже - есть [[tcp-handshake|жизненный цикл TCP]] и урок intermediate-02-tcp-handshake где можно поснифать пакеты руками.

§ копнуть в базу знаний

§ шаги

Клиент и сервер прошли three-way handshake (см. tcp-handshake) и оба в ESTABLISHED. Готовы передавать данные.

TCP не ждёт ACK на каждый пакет - пайплайнит их. Окно отправки cwnd определяет сколько пакетов можно «в полёте» одновременно без подтверждения.