Быстрая повторная передача

Быстрая повторная передача — это механизм управления перегрузками в протоколах транспортного уровня (прежде всего в TCP), позволяющий отправителю данных обнаружить потерю сегмента и повторно передать его без ожидания истечения таймера ретрансмиссии (RTO). Данный метод ускоряет восстановление после потери пакета в сети, сокращая время простоя соединения и повышая общую пропускную способность.

История и предпосылки

В ранних реализациях TCP (RFC 793, 1981) потеря сегмента обнаруживалась только по истечении таймера RTO, который обычно устанавливался на значение, кратное среднему времени кругового обхода (RTT). Такой подход приводил к значительным задержкам: при потере одного пакета отправитель мог ждать несколько сотен миллисекунд или даже секунд, прежде чем начать повторную передачу. Это было особенно критично для приложений, чувствительных к задержкам (например, интерактивные сервисы, голосовая связь).

В 1988 году Ван Якобсон в своей работе «Congestion Avoidance and Control» предложил алгоритмы медленного старта и предотвращения перегрузок, а также концепцию быстрой повторной передачи. Идея заключалась в том, что получатель может сигнализировать о потере сегмента, отправляя дублирующие подтверждения (Duplicate ACKs), а отправитель, получив несколько таких подтверждений подряд, может сделать вывод о потере и немедленно начать повторную передачу. Механизм был формализован в RFC 2001 (1997) и уточнён в последующих спецификациях (RFC 2581, RFC 5681).

Принцип работы

Механизм дублирующих подтверждений

В протоколе TCP получатель подтверждает успешный приём данных, отправляя сегмент ACK с номером следующего ожидаемого байта (кумулятивное подтверждение). Если пакет с порядковым номером N потерян, а последующие пакеты (N+1, N+2 и т.д.) доходят успешно, то получатель продолжает отправлять ACK с номером N, так как именно этот байт он всё ещё ожидает. Такие ACK называются дублирующими (Duplicate ACK).

Порог срабатывания

Отправитель отслеживает количество полученных дублирующих ACK для одного и того же порядкового номера. Как только это количество достигает порогового значения (обычно 3), отправитель делает вывод, что соответствующий сегмент был потерян, а не просто задержан в сети. Причина выбора трёх дублирующих ACK: при случайной перестановке пакетов (reordering) может возникнуть один или два дублирующих ACK, но три — крайне маловероятно для нормального порядка доставки.

Действия отправителя

При получении третьего дублирующего ACK отправитель немедленно выполняет следующие действия:

1. Повторная передача потерянного сегмента — без ожидания таймера RTO.
2. Корректировка параметров перегрузки:

• Устанавливает порог медленного старта (ssthresh) равным половине текущего размера окна перегрузки (cwnd), но не менее двух сегментов.
• Устанавливает cwnd равным ssthresh плюс три сегмента (для учёта уже отправленных дублирующих ACK).

1. Переход в режим предотвращения перегрузок (congestion avoidance), а не в медленный старт.

Этот процесс называется Fast Retransmit. После повторной передачи отправитель продолжает получать дублирующие ACK для того же номера, что позволяет ему увеличивать cwnd на размер одного сегмента за каждый дополнительный дублирующий ACK (алгоритм Fast Recovery), что частично компенсирует потерю пропускной способности.

Взаимосвязь с другими механизмами TCP

Fast Recovery

Быстрая повторная передача почти всегда реализуется в паре с алгоритмом Fast Recovery (быстрое восстановление). После повторной передачи отправитель не переходит в медленный старт (который резко снижал бы cwnd до 1), а продолжает отправлять данные, используя уменьшенное окно. Fast Recovery позволяет поддерживать поток данных, не дожидаясь полного опустошения окна, что снижает колебания загрузки сети.

Selective Acknowledgment (SACK)

Стандартный механизм дублирующих ACK имеет недостаток: он сообщает отправителю только о первом потерянном сегменте, но не о последующих. Если в одном окне теряется несколько сегментов, отправитель может неверно интерпретировать ситуацию. Расширение SACK (RFC 2018, 2883) позволяет получателю указывать в ACK не только ожидаемый номер, но и блоки успешно принятых данных. Это даёт отправителю возможность повторно передать только действительно потерянные сегменты, а не все после первого пропуска, что повышает эффективность быстрой повторной передачи при множественных потерях.

NewReno

Модификация TCP Reno, известная как NewReno (RFC 2582, 3782), улучшает поведение при множественных потерях в одном окне. Вместо того чтобы после каждой повторной передачи снова ждать трёх дублирующих ACK, NewReno использует частичные ACK (Partial ACK) для обнаружения следующих потерь, что позволяет выполнить несколько быстрых повторных передач в рамках одного цикла Fast Recovery.

Преимущества и недостатки

Преимущества

• Снижение задержки восстановления — потеря обнаруживается за время, равное примерно одному RTT (вместо нескольких RTT при ожидании RTO).
• Повышение пропускной способности — уменьшается время простоя соединения, что особенно важно для высокоскоростных каналов.
• Автоматическое управление перегрузками — механизм встроен в TCP и не требует дополнительной настройки со стороны приложений.

Недостатки

• Чувствительность к перестановке пакетов — в сетях с нестабильной маршрутизацией (например, многопутевые сети) дублирующие ACK могут быть вызваны не потерей, а задержкой. Это приводит к ложным срабатываниям и неоправданному снижению окна перегрузки.
• Неэффективность при множественных потерях — без SACK отправитель может повторно передавать сегменты, которые уже были успешно доставлены, что тратит пропускную способность.
• Зависимость от получателя — механизм требует корректной реализации на стороне получателя (отправка дублирующих ACK), что не всегда гарантируется в старых или нестандартных стектах.

Применение в современных протоколах

Хотя быстрая повторная передача была разработана для TCP, аналогичные принципы используются и в других протоколах транспортного уровня:

• QUIC (протокол на основе UDP) использует концепцию «немедленной повторной передачи» при получении нескольких подтверждений одного и того же порядкового номера.
• SCTP (Stream Control Transmission Protocol) реализует механизм Fast Retransmit на уровне фрагментов данных.
• DCCP (Datagram Congestion Control Protocol) включает алгоритмы, основанные на дублирующих подтверждениях.

В современных реализациях TCP (например, CUBIC, BBR) быстрая повторная передача остаётся базовым элементом, но дополняется более сложными алгоритмами оценки потерь (например, использование временных меток или ECN — Explicit Congestion Notification).

Критика и альтернативы

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

• Таймерные методы — использование адаптивных таймеров RTO с более точной оценкой RTT.
• Forward Error Correction (FEC) — добавление избыточных данных, позволяющих восстановить потери без повторной передачи.
• Proactive retransmission — отправка дублирующих сегментов до обнаружения потери (используется в некоторых потоковых протоколах).

Тем не менее, быстрая повторная передача остаётся стандартным и широко применяемым механизмом в подавляющем большинстве TCP-соединений в Интернете.

Источники

• Jacobson, V. (1988). «Congestion Avoidance and Control». ACM SIGCOMM Computer Communication Review.
• RFC 793 — Transmission Control Protocol.
• RFC 2001 — TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms.
• RFC 2581 — TCP Congestion Control.
• RFC 5681 — TCP Congestion Control (обновлённая версия).
• RFC 2018 — TCP Selective Acknowledgment Options.
• RFC 3782 — The NewReno Modification to TCP's Fast Recovery Algorithm.
• Stevens, W. R. (1994). «TCP/IP Illustrated, Volume 1: The Protocols». Addison-Wesley.