На протяжении десятилетий стандартным ответом сетевой инфраструктуры на перегрузку каналов связи оставался принудительный сброс пакетов (packet drop). При классическом управлении очередями Drop-Tail и алгоритмах контроля перегрузки, таких как TCP Reno и Cubic, маршрутизатор на узком месте сигнализирует о заполнении буфера, попросту отбрасывая входящие пакеты. Отправитель фиксирует потерю подтверждения (ACK), делает вывод о перегрузке, уменьшает окно перегрузки (cwnd) вдвое и начинает повторную передачу.

Хотя этот цикл предотвращает коллапс сети, он приводит к значительным эксплуатационным издержкам. В интерактивных сервисах — голосовой связи реального времени, видеоконференциях, соревновательных онлайн-играх и финансовых транзакциях — потеря пакетов вызывает резкие скачки задержки и джиттер. Когда трафик проходит через зашифрованные туннели VPN (IPsec или WireGuard), эффект раздувания буфера (bufferbloat) и потери данных усугубляются из-за многоуровневой инкапсуляции.

Чтобы отделить уведомление о перегрузке от физической потери пакетов, инженерная группа IETF стандартизировала механизм явного уведомления о перегрузке (ECN - Explicit Congestion Notification) в спецификации RFC 3168 и уточнила правила работы с туннелями в RFC 6040. Развитием этой концепции стала архитектура L4S (RFC 9330, RFC 9331, RFC 9332), внедрившая алгоритм DualQ Coupled AQM, который обеспечивает задержку очереди менее 1 миллисекунды как на стандартных маршрутах, так и внутри зашифрованных VPN.

Парадигма потери пакетов: почему сброс Drop-Tail не работает в современных сетях

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

При bufferbloat промежуточные маршрутизаторы накапливают мегабайты данных во время объемных передач. Пакеты проводят в физической памяти сотни миллисекунд в ожидании сериализации. Для параллельного интерактивного трафика UDP эта задержка оказывается разрушительной. Реальное время кругового обращения ($RTT$) увеличивается по формуле:

$$RTT_{\text{actual}} = RTT_{\text{propagation}} + \frac{Q_{\text{bytes}}}{\text{Bandwidth}}$$

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

Архитектура ECN: 2-битное поле IP и согласование в рукопожатии TCP (RFC 3168)

Стандарт RFC 3168 исключает необходимость преднамеренного сброса пакетов за счет использования двух младших бит в поле ToS протокола IPv4 и поле Traffic Class протокола IPv6:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|      DSCP (6 bits)    |  ECN  |
+---+---+---+---+---+---+---+---+

2-битное поле ECN поддерживает четыре кодовые комбинации:

Значение бит Обозначение Семантическое значение
00 Non-ECT Транспорт без поддержки ECN (стандартный сброс)
01 ECT(1) Поддержка ECN включена (масштабируемые потоки L4S)
10 ECT(0) Поддержка ECN включена (классическая обратная связь RFC 3168)
11 CE Зафиксирована перегрузка (Congestion Experienced)

Для использования ECN конечные узлы согласовывают поддержку механизма на этапе трехстороннего рукопожатия TCP:

  1. SYN: Клиент выставляет флаги ECE (ECN-Echo) и CWR (Congestion Window Reduced) в заголовке TCP.
  2. SYN-ACK: Сервер, поддерживающий ECN, отвечает с установленным флагом ECE и сброшенным флагом CWR.
  3. ACK: Клиент завершает рукопожатие со снятыми флагами ECN, переводя соединение в режим активной передачи.
Клиент                                                  Сервер
  |--- SYN [ECE=1, CWR=1] ------------------------------->| (Предложение ECN)
  |<-- SYN-ACK [ECE=1, CWR=0] ----------------------------| (Подтверждение ECN)
  |--- ACK [ECE=0, CWR=0] ------------------------------->| (Соединение установлено)
  |                                                       |
  |=== Пакет данных [IP: ECT(0)] ========================>| (Маршрутизатор ставит CE)
  |<== Пакет ACK [TCP: ECE=1] ============================| (Возврат сигнала перегрузки)
  |--- Пакет данных [TCP: CWR=1, IP: ECT(0)] ------------>| (Подтверждение снижения окна)

При возникновении очереди промежуточный маршрутизатор перезаписывает поле IP с ECT(0) или ECT(1) на CE (11) вместо уничтожения пакета. Получатель, обнаружив метку CE, активирует бит ECE в последующих пакетах подтверждения. Отправитель уменьшает окно передачи и передает пакет с флагом CWR.

Дилемма туннельной инкапсуляции: потеря меток и образование черных дыр

Если для открытых соединений логика RFC 3168 прозрачна, то в контексте туннелирования возникли серьезные расхождения. Инкапсуляция является базой виртуальных частных сетей: внутренний пакет IP упаковывается во внешний транспортный протокол (IPsec ESP, WireGuard UDP или GRE).

Если инкапсулированный пакет проходит через перегруженный узел провайдера, этот узел маркирует внешний заголовок IP кодом CE (11). Однако обработка на выходе из туннеля исторически страдала от двух архитектурных дефектов:

  1. Потеря сигнала (ECN Blindness): Выходной шлюз снимал внешний заголовок IP и отправлял внутренний пакет с исходным состоянием (ECT(0) или Not-ECT). Метка CE бесследно исчезала при деинкапсуляции. Нагрузка продолжала нарастать до физического переполнения буфера.
  2. Неконтролируемое копирование (ECN Black-Holing): Входной узел копировал внутренние флаги во внешний заголовок без проверки возможностей внутреннего протокола. Если внутренний пакет без поддержки ECN (00) упаковывался во внешний заголовок с отметкой CE, перенос метки внутрь нарушал логику старых стеков, приводя к сбоям.

Из-за этих ошибок администраторы корпоративных VPN нередко отключали ECN.

Спецификация RFC 6040: режимы Normal, Compatibility и деинкапсуляция на выходе

Спецификация RFC 6040 устранила двусмысленность туннелирования, регламентировав правила обработки меток ECN на входе (Ingress) и выходе (Egress) туннеля независимо от используемого протокола.

Правила инкапсуляции Ingress: привязка внутреннего ECT к внешнему заголовку

На входе в туннель устройство формирует внешний заголовок IP на основе содержимого внутреннего пакета:

  • Стандартный режим (Normal Mode - по умолчанию в RFC 6040): Если внутренний пакет помечен как Not-ECT (00), внешний заголовок ОБЯЗАН быть установлен в Not-ECT (00). Это гарантирует, что промежуточные узлы сбросят пакет при сильной перегрузке, так как получатель не поймет сигнал CE. Если внутренний пакет содержит ECT(0), ECT(1) или CE, внешний заголовок зеркально копирует это значение.
  • Режим совместимости (Compatibility Mode): Применяется, если выходной шлюз не поддерживает RFC 6040. Для всех внешних заголовков жестко выставляется Not-ECT (00), заставляя сеть использовать стандартный механизм сброса.

Таблица состояний Egress: объединение внешнего CE с внутренним кодом

На выходе из туннеля шлюз сопоставляет внешний и внутренний коды ECN перед снятием внешней оболочки согласно строгой таблице состояний:

Внутренний заголовок Внешний заголовок Результат деинкапсуляции Действие и протокольная оценка
Not-ECT (00) Not-ECT (00) Not-ECT (00) Стандартная передача
Not-ECT (00) ECT(0) / ECT(1) Not-ECT (00) Ошибка конфигурации внешнего узла
Not-ECT (00) CE (11) СБРОС ПАКЕТА Обязательный сброс: внешний канал перегружен, внутри нет ECN
ECT(0) (10) Not-ECT (00) ECT(0) (10) Стандартная доставка: внешний участок свободен
ECT(0) (10) ECT(0) (10) ECT(0) (10) Штатная доставка без перегрузок
ECT(0) (10) CE (11) CE (11) Перенос сигнала перегрузки во внутренний стек
ECT(1) (01) CE (11) CE (11) Перенос сигнала перегрузки во внутренний стек
CE (11) Not-ECT (00) CE (11) Сохранение исходного внутреннего сигнала
CE (11) CE (11) CE (11) Сохранение метки перегрузки

Ключевое правило безопасности RFC 6040 отражено в строке 3: если внутренний пакет не поддерживает ECN, а внешний пришел с меткой CE, выходной узел обязан сбросить пакет. Это инициирует корректную реакцию устаревшего отправителя и исключает раздувание очереди.

Эволюция к L4S: низкая задержка, минимальные потери и масштабируемость (RFC 9330)

Классический ECN решает проблему сброса пакетов, но не устраняет задержки в буферах. Традиционные алгоритмы TCP реагируют на сигнал CE так же жестко, как на потерю данных: уполовинивают окно передачи. Чтобы избежать недогрузки каналов, пороги маркировки выставлялись высокими, допуская накопление задержки в 10–50 миллисекунд.

Архитектура L4S (RFC 9330) решает эту проблему за счет трех компонентов:

  1. Масштабируемый контроль перегрузки (TCP Prague / QUIC L4S): Отправитель непрерывно корректирует скорость передачи с высокой частотой. Вместо деления окна пополам Prague реагирует на отметки CE минимальными шагами масштабирования ($O(1)$), сохраняя очередь близкой к нулю.
  2. Кодовая точка идентификации (RFC 9331): L4S задействует код ECT(1) (01). Промежуточные маршрутизаторы используют его для разделения потоков L4S и классического трафика ECT(0) или Not-ECT.
  3. Связанное управление очередями DualQ Coupled AQM (RFC 9332): Сетевой шлюз делит трафик на две параллельные логические очереди, изолируя интерактивные потоки от объемных загрузок с сохранением баланса полосы.
Входящий поток пакетов
       |
       v
+-----------------------+
| Классификатор (9331)  |
+-----------------------+
       |               |
       | [ECT(1)]      | [Not-ECT, ECT(0)]
       v               v
+-------------+ +---------------+
|  L-Очередь  | |   C-Очередь   |
| (Малый буфер| | (Глубокий буф,|
|  Step-марк.)| |  Классич. AQM)|
+-------------+ +---------------+
       \               /
        \             /
         v           v
+-------------------------------+
| Связанный планировщик (9332)  |
+-------------------------------+
                |
                v  Передача без задержек (<1мс)

Механизм DualQ Coupled AQM: изоляция классических потоков и Prague (RFC 9332)

Механизм DualQ Coupled Active Queue Management по RFC 9332 обеспечивает сосуществование чувствительных к задержкам сервисов и традиционных закачек на одном физическом интерфейсе.

Классическая очередь: взаимодействие алгоритмов FQ-CoDel и PIE

Классическая очередь (C-Queue) принимает пакеты Not-ECT и ECT(0). Она использует проверенные временем алгоритмы AQM, такие как PIE или FQ-CoDel.

Очередь C удерживает целевую задержку в пределах 10–20 мс. При перегрузке она отбрасывает пакеты Not-ECT или маркирует ECT(0) кодом CE с вероятностью, пропорциональной квадратному корню из перегрузки ($p_C$).

Очередь низкой задержки: пороговая маркировка и субмиллисекундные буферы

Очередь низкой задержки (L-Queue) обрабатывает исключительно пакеты ECT(1). Поскольку алгоритм Prague мгновенно реагирует на единичные метки, очереди L не требуется глубокий буфер.

В ней применяется ступенчатая маркировка (Step Marking): если задержка в очереди превышает порог в 500 микросекунд – 1 миллисекунду, входящие пакеты немедленно маркируются кодом CE. Сброс пакетов исключен вплоть до полного исчерпания памяти.

Для сохранения справедливости распределения пропускной способности RFC 9332 связывает вероятности маркировки формулой:

$$p_L = k \times p_C^2$$

Вероятность маркировки в очереди L ($p_L$) динамически зависит от квадрата вероятности перегрузки в очереди C ($p_C$), что гарантирует равное разделение емкости между потоками L4S и TCP Cubic.

Реальный эффект производительности: гейминг, видеосвязь и туннели VPN

Совместное внедрение туннелирования ECN по стандарту RFC 6040 и архитектуры L4S DualQ AQM кардинально повышает качество связи.

В облачном гейминге, потоковом рендеринге и телеметрии нестабильность задержки (джиттер) наносит больше вреда, чем ее абсолютное значение. В обычных туннелях с политикой Drop-Tail параллельная отправка файла на скорости 500 Мбит/с увеличивает пинг в игре с 25 мс до более чем 200 мс из-за заполнения буферов.

При интеграции RFC 6040 и DualQ AQM:

  • Задержка в очереди: Сокращается с 80–250 мс до значений менее 1 миллисекунды.
  • Потери пакетов: Стремятся к 0,00% при высокой утилизации за счет сигналов CE.
  • Блокировка начала очереди (Head-of-Line): Устраняется, сохраняя непрерывность передачи управляющих сигналов.

Кроме того, поддержка ECN органично дополняет механизмы защиты стека, такие как предотвращение паники ядра при TCP SACK, поддерживая стабильность буферов сокетов.

Архитектура RiceGuard: туннелирование ECN по стандарту RFC 6040 и DualQ

VPNRice внедряет спецификации RFC 6040 и RFC 9330 непосредственно в собственный сетевой стек передачи данных RiceGuard.

В распространенных решениях VPN внешние флаги IP нередко теряются в процессе криптографических операций. Когда ядро инкапсулирует пакет в WireGuard UDP или IPsec ESP, стандартная конфигурация часто не транслирует внешнюю метку CE обратно в сокет клиента при деинкапсуляции.

[ Пространство пользователя: TCP Prague / QUIC ]
       |
       | (Внутренний заголовок IP: кодовая точка ECT(1))
       v
[ Клиентский модуль RiceGuard ]
       |
       | Инкапсуляция на входе (RFC 6040 Normal Mode)
       | Зеркалирование ECT(1) во внешний заголовок UDP/IP
       v
[ Магистральный канал провайдера с узким местом DualQ ]
       |
       | Фиксация перегрузки: маршрутизатор ставит CE (11)
       v
[ Пограничный шлюз RiceGuard (модуль деинкапсуляции) ]
       |
       | Таблица состояний Egress RFC 6040:
       | Внешний=CE + Внутренний=ECT(1) ---> Пересылка внутреннего пакета с CE (11)
       v
[ Целевой сервер / Облачная инфраструктура ]
       |
       | Плавная адаптация скорости: дополнительная задержка в буфере = 0 мс

В архитектуре RiceGuard:

  • Строгое соблюдение правил Ingress/Egress RFC 6040: Криптографический конвейер обрабатывает внешние и внутренние заголовки на аппаратной скорости. При поступлении пакета с отметкой CE RiceGuard обновляет внутренний заголовок перед маршрутизацией.
  • Аппаратная разгрузка DualQ: На пограничных серверах VPNRice входящий трафик распределяется по аппаратным очередям DualQ с помощью фильтров eBPF/XDP. Интерактивные данные UDP и пакеты L4S направляются по выделенным трактам отдельно от очередей объемных данных.
  • Интеграция с контролем MTU: Заголовки туннеля формируются с динамическим MSS Clamping, что исключает фрагментацию и искажение меток ECN.

Инженерный контрольный список: настройка ECN и L4S в ядрах Linux и шлюзах VPN

Для развертывания и проверки поддержки RFC 6040 и L4S в операционной системе Linux и шлюзах VPN следуйте чек-листу:

  • Включение системной поддержки ECN: Задайте net.ipv4.tcp_ecn = 1 в файле /etc/sysctl.conf для согласования ECN во входящих и исходящих сессиях.
  • Проверка версии ядра Linux: Убедитесь, что используется ядро версии 6.4 или выше, содержащее модуль TCP Prague и планировщик DualQ AQM (sch_dualpi2).
  • Подключение дисциплины очереди DualQ: Настройте планировщик на физическом и туннельном интерфейсах:
    tc qdisc add dev eth0 root dualpi2
  • Контроль параметров RFC 6040 в туннелях WireGuard/IPsec: Проверьте сохранение битов ECN при инкапсуляции и маршрутизации интерфейса (sysctl -w net.ipv4.conf.all.rp_filter=2).
  • Аудит согласования ECN в дампах трафика: С помощью tcpdump проверьте выставление флагов ECE и CWR при обмене пакетами SYN, SYN-ACK и ACK:
    tcpdump -i any 'tcp[13] & 0xc0 != 0' -n -vv
  • Тестирование таблицы деинкапсуляции: Направьте тестовые пакеты с внешним кодом CE и убедитесь, что метка корректно переносится во внутренний заголовок на выходе из туннеля.
  • Мониторинг счетчиков меток и сбросов: Отслеживайте статистику очередей, чтобы убедиться в снижении потерь данных при появлении перегрузок:
    tc -s qdisc show dev eth0