TCP D-SACK RFC 2883: устранение ложных повторных передач в туннелях VPN

Высокоскоростная сетевая инфраструктура опирается на способность протокола TCP поддерживать стабильную скорость передачи данных в сложных топологиях интернета. Однако при прохождении зашифрованных туннелей, маршрутизации Equal-Cost Multi-Path (ECMP), использовании многоочередных сетевых карт и переключении базовых станций пакеты регулярно прибывают с нарушением исходного порядка. Стандартный стек TCP интерпретирует три последовательных дублирующих подтверждения (DupACK) как доказательство физической потери пакета, запуская алгоритм быстрой повторной передачи (Fast Retransmit) и урезая окно перегрузки (cwnd) в два раза. Когда причиной появления DupACK становится именно изменение порядка следования пакетов (reordering), а не физический сброс, отправитель выполняет ложную повторную передачу (spurious retransmission) и необоснованно снижает общую скорость соединения.

Для устранения этой проблемы на транспортном уровне инженерная группа IETF утвердила стандарт RFC 2883: An Extension to the Selective Acknowledgement (SACK) Option for TCP, широко известный как D-SACK (Duplicate SACK). Используя первый блок опции TCP SACK для информирования о дублирующемся пространстве последовательностей, D-SACK позволяет отправителю четко различать, вызваны ли полученные подтверждения изменением порядка доставки или реальной потерей данных.

[Стандартный SACK (RFC 2018): неопределенность при повторном получении]
Отправитель: передает сегменты 1, 2, 3, 4, 5
Сеть: сегмент 2 задерживается на резервном маршруте; сегменты 3, 4, 5 приходят первыми
Получатель: отправляет DupACK с блоком SACK [3-5]
Отправитель: считает сегмент 2 потерянным! Запускает Fast Retransmit, урезает cwnd на 50%
Сегмент 2 прибывает! Получатель шлет ACK, но отправитель не знает, подтвержден оригинал или повтор

[RFC 2883 D-SACK: явный отчет о дубликатах и откат окна]
Получатель: принимает исходный сегмент 2, затем повторно переданный сегмент 2
Получатель: отправляет ACK с блоком D-SACK [2-3] в первой позиции (Seq <= Cumulative ACK)
Отправитель: видит дубликат! Определяет, что недавняя повторная передача была лишней
Отправитель: отменяет урезание cwnd (Undo cwnd), восстанавливает скорость и адаптирует порог

Дилемма изменения порядка пакетов: почему ошибочный диагноз потерь снижает пропускную способность VPN

Потеря пакетов в физических каналах сигнализирует о переполнении очередей маршрутизаторов, требуя снижения интенсивности передачи для предотвращения коллапса. Напротив, изменение порядка пакетов представляет собой временную перестановку кадров без утраты данных. Когда стек отправителя путает задержку с потерей, пропускная способность соединения падает.

Многоочередные сетевые карты, ECMP и изменение порядка при инкапсуляции VPN

Инкапсулированный трафик подвержен характерным факторам изменения порядка. В архитектурах VPN на базе WireGuard, IPsec или OpenVPN исходные сегменты TCP упаковываются во внешние датаграммы UDP. При передаче через опорные сети провайдеров хеш-маршрутизация ECMP распределяет потоки по параллельным физическим трассам:

$$P_{\text{hash}} = \text{CRC32}(\text{SIP}, \text{DIP}, \text{Proto}, \text{SPort}, \text{DPort}) \pmod N$$

Если энтропия портов меняется или многопоточные криптографические модули обрабатывают пакеты с разной скоростью на нескольких ядрах процессора, датаграммы прибывают на шлюз с нарушением исходного порядка. Разницы всего в 2 миллисекунды во времени распространения сигнала по двум линиям связи достаточно, чтобы три последующих пакета опередили предшествующий.

В сетях сотовой связи (LTE, 5G NR) механизмы повторной передачи на канальном уровне (HARQ) также часто доставляют задержанный пакет сразу после того, как новые сегменты уже поступили в буфер сокета.

Ловушка ложной повторной передачи: как ошибочный Fast Retransmit урезает cwnd вдвое

По стандарту RFC 5681 получатель TCP немедленно отправляет подтверждение при получении пакета не по порядку, дублируя номер кумулятивного ACK. Получив три дубликата подряд (порог dupthresh = 3), отправитель констатирует потерю пакета:

$$\text{ssthresh} = \max\left(\frac{\text{FlightSize}}{2}, 2 \times \text{MSS}\right)$$

$$\text{cwnd} = \text{ssthresh} + 3 \times \text{MSS}$$

Это приводит к двойному негативному эффекту:

1. Неэффективный расход ресурсов: отправитель заново передает сегмент, который уже находится в пути или в буфере получателя, тратя полосу пропускания и ресурсы шифрования.
2. Снижение пропускной способности: окно передачи уменьшается на 50%, и соединение переходит в фазу предотвращения перегрузки (Congestion Avoidance). В канале со скоростью 1 Гбит/с и RTT 80 мс восстановление прежней скорости требует десятков оборотов RTT. Частые локальные сдвиги пакетов удерживают соединение в состоянии искусственно заниженной скорости.

Архитектура RFC 2883: как D-SACK сообщает о повторяющихся сегментах

Спецификация RFC 2018 определила базовый формат выборочного подтверждения, позволяя включать в заголовок TCP до 4 несмежных диапазонов принятых данных. Однако стандартный SACK описывает только данные выше точки кумулятивного подтверждения и не содержит средств уведомления о дублирующихся сегментах.

RFC 2883 расширяет этот синтаксис, сохраняя совместимость с исходным форматом опции TCP.

Структура блоков SACK и правила пространства последовательностей D-SACK

Опция SACK состоит из байта типа (Kind = 5), длины (Length) и пар 32-битных целых чисел, обозначающих левую (Left Edge) и правую (Right Edge) границы принятого диапазона:

+---------------+---------------+
| Kind = 5      | Length = N    |
+---------------+---------------+-------------------------------+
| Левая граница 1-го блока (32-битный номер последовательности)  |
+-------------------------------+-------------------------------+
| Правая граница 1-го блока (32-битный номер последовательности) |
+-------------------------------+-------------------------------+

Стандарт RFC 2883 формулирует два правила для идентификации первого блока как D-SACK:

• Правило 1 (дубликат ниже или на уровне кумулятивного ACK): если левая граница первого блока SACK меньше или равна кумулятивному номеру подтверждения в заголовке TCP:

$$\text{Left Edge}_1 \le \text{Cumulative ACK}$$

• Правило 2 (дубликат внутри другого блока SACK): если левая граница первого блока целиком входит в диапазон одного из последующих блоков SACK в этом же пакете:

$$\exists i > 1 : \left(\text{Left Edge}_i \le \text{Left Edge}_1\right) \land \left(\text{Right Edge}_1 \le \text{Right Edge}_i\right)$$

Отличие повторяющихся сегментов от обычных блоков SACK

Блок D-SACK всегда размещается строго на первой позиции в опции TCP. Все последующие блоки продолжают передавать информацию о непринятых диапазонах в соответствии с RFC 2018.

Например, отправитель передал сегменты [1000–1500] и [1500–2000]. Получатель уже подтвердил данные до байта 2000, но затем получил задержавшийся дубликат [1000–1500]. Получатель генерирует подтверждение:

• Cumulative ACK: 2000
• SACK Block 1: Left Edge = 1000, Right Edge = 1500

Поскольку левая граница (1000) меньше кумулятивного ACK (2000), отправитель мгновенно определяет, что получатель принял повторный экземпляр сегмента [1000–1500].

Заголовок TCP ACK: 2000
Опция: Kind=5, Length=10
SACK Block 1: [1000, 1500]  <── (1000 <= 2000) Обозначение дубликата D-SACK!

Без поддержки RFC 2883 получатель просто отбросил бы дубликат и вернул стандартный ACK, оставив отправителя в неведении относительно избыточности выполненной повторной передачи.

Отмена штрафа окна перегрузки: механизм Undo cwnd и восстановление передачи

Основное эксплуатационное преимущество D-SACK состоит в устранении неопределенности повторной передачи (retransmission ambiguity), предоставляя отправителю точные данные для отката штрафа.

Механика отката cwnd при обнаружении ненужной повторной передачи

Когда отправитель передает сегмент в момент $t_1$, а затем повторно отправляет его в момент $t_2$, стандартный стек не может сопоставить входящий ACK с первой или второй посылкой.

При включенном D-SACK:

1. Если дошли обе посылки, получатель возвращает блок D-SACK, подтверждая избыточность второй.
2. Если первая посылка действительно потерялась, получатель принимает только вторую и не формирует блок D-SACK.

Получив блок D-SACK, отправитель выполняет процедуру Undo CWND:

$$\text{cwnd} = \text{prior_cwnd}$$

$$\text{ssthresh} = \text{prior_ssthresh}$$

Мгновенный возврат cwnd к значению, зафиксированному до ошибочного срабатывания Fast Retransmit, позволяет соединению сразу продолжить передачу на максимальной скорости.

Динамическая адаптация порога изменения порядка и параметр tcp_reordering

Помимо разового отката окна, данные D-SACK позволяют ядру Linux оценивать фактическую степень перестановки пакетов на маршруте.

По умолчанию TCP использует фиксированный порог dupthresh = 3. Если на канале глубина перестановки пакетов стабильно составляет 5–6 единиц, фиксированный порог приводит к постоянным ложным повторам. Получив подтверждение D-SACK, ядро вычисляет величину смещения:

$$\Delta_{\text{reorder}} = \text{HighDataSeq} - \text{RetransmitSeq}$$

Система автоматически увеличивает внутренний порог (tp->reordering), масштабируя его с исходного значения 3 до 5, 8 или 12. Адаптация порога под свойства маршрута предотвращает новые ложные срабатывания.

Архитектура ядра: интеллектуальный арбитраж пакетных потоков в RiceGuard

Магистральные туннели VPN обрабатывают разнородный трафик, от чувствительной к задержкам голосовой связи до интенсивного обмена данными. VPNRice интегрирует телеметрию RFC 2883 D-SACK в транспортный движок RiceGuard, оптимизируя арбитраж потоков на узлах сети.

  [Поток данных приложений]
              │
              ▼
  [Внутренний TCP-стек: активен D-SACK] ──> Отчет о дубликатах, вызов Undo cwnd
              │
              ▼
  [Арбитр потоков RiceGuard] ──> eBPF RSS-хеширование и защита от перестановок
              │
              ▼
  [Модуль шифрования AEAD] ──> Производительное шифрование ChaCha20-Poly1305
              │
              ▼
  [Внешняя физическая сеть] ──> Устойчивость на трассах ECMP и в сотовых сетях

RiceGuard повышает стабильность передачи на трех уровнях:

1. Консистентное хеширование потоков: внутренние потоки TCP привязываются к стабильным внешним портам UDP с помощью eBPF, что заставляет промежуточные маршрутизаторы направлять пакеты по единому пути ECMP и минимизирует вероятность перестановки.
2. Динамическая калибровка очередей: при колебаниях маршрутизации RiceGuard использует сигналы D-SACK в сочетании с современными алгоритмами /news/tcp-rack-tlp-rfc-8985-time-based-loss-recovery-vpn и /news/tcp-early-retransmit-rfc-5827-small-window-rto-vpn, разделяя потери и задержки с микросекундной точностью.
3. Управление буферами и формирование трафика: механизм D-SACK работает совместно с алгоритмами Fair Queuing (FQ), устраняя блокировки очереди и эффект bufferbloat, как подробно описано в /news/tcp-hystart-plus-rfc-9406-bufferbloat-slow-start-vpn.

Диагностика и аудит: проверка работы D-SACK в операционных системах Linux

Инженеры и администраторы могут контролировать работу протоколов SACK и D-SACK в среде Linux с помощью штатных утилит диагностики.

Мониторинг метрик SACK и D-SACK в реальном времени с помощью команды ss

Команда ss отображает внутренние метрики TCP из блоков управления ядра:

# Просмотр детальных параметров сокета, включая SACK и D-SACK
ss -ti '( sport = :443 or dport = :443 )'

Ключевые поля вывода:

• sack: признак согласования поддержки RFC 2018 SACK на этапе рукопожатия.
• dsack_dups:<count>: число дублирующихся пакетов, зафиксированных и переданных в блоках D-SACK.
• reordering:<val>: текущий порог перестановки пакетов, адаптированный ядром для данного соединения.
• rcv_ooopack:<count>: общее количество пакетов, принятых не по порядку и помещенных в буфер.

Оптимизация параметров ядра и sysctl для эффективной работы SACK

Параметры работы подсистемы на уровне всей ОС проверяются через sysctl:

# Проверка активности SACK (1 = включено, по умолчанию)
sysctl net.ipv4.tcp_sack

# Проверка активности D-SACK (1 = включено, по умолчанию)
sysctl net.ipv4.tcp_dsack

# Проверка начального порога изменения порядка (по умолчанию = 3)
sysctl net.ipv4.tcp_reordering

# Суммарная статистика SACK и D-SACK по всей системе
cat /proc/net/netstat | grep -E "TCPDSACK|TCPSack"

Значения счетчиков в /proc/net/netstat:

• TCPDSACKRecv: количество принятых блоков D-SACK, свидетельствующих об успешном выявлении ложных повторов.
• TCPDSACKSent: количество отправленных блоков D-SACK с уведомлениями о дубликатах.
• TCPDSACKUndo: число успешных откатов окна перегрузки после верификации D-SACK.

Практическая проверка и замеры производительности в реальной среде

В условиях нагруженных туннелей VPN со склонностью к перестановке пакетов активация RFC 2883 D-SACK обеспечивает качественный прирост стабильности:

Благодаря сочетанию явной отчетности о дубликатах и адаптации порогов RFC 2883 превращает перестановку пакетов из деструктивного фактора в штатное событие. Реализация D-SACK в составе высокопроизводительных протоколов гарантирует сохранение максимальной скорости и минимальных задержек на любых сетевых маршрутах.

Скачать VPNRice.