Канал широкосмугового зв'язку зі швидкістю 1 Гбіт/с може зазнавати відчутних затримок відгуку під час одночасного навантаження. Якщо за відсутності фонового трафіку тест пінгу показує 15 мілісекунд (мс), то запуск завантаження великого файлу або резервного копіювання здатен раптово збільшити час очікування до понад 600 мс. Голосовий зв'язок переривається, сесії SSH зависають, а передача даних у реальному часі стикається з втратою пакетів.

Це явище має назву Bufferbloat (роздування буферів): штучна затримка, спричинена надмірною і некерованою буферизацією в мережевому обладнанні. У разі використання шифрованих тунелів проблема загострюється. Віртуальна приватна мережа (VPN) об'єднує різноманітний трафік застосунків у єдиний зовнішній потік UDP, приховуючи динаміку потоків від стандартних маршрутизаторів. Подолання цієї деградації вимагає впровадження сучасних архітектур активного керування чергами (Active Queue Management, AQM), таких як FQ-CoDel (RFC 8290) та CAKE, безпосередньо на фізичних і віртуальних мережевих інтерфейсах.

+--------------------------------------------------------------------------+
|                  ВУЗЬКЕ МІСЦЕ BUFFERBLOAT У ТУНЕЛІ VPN                   |
|                                                                          |
| [ Пакет VoIP (64 Б) ] \                                                  |
| [ Пакет SSH (96 Б)  ] ---> [ Віртуальний інтерфейс TUN ]                 |
| [ Потік відео 4K    ] /               |                                  |
|                                       v                                  |
|                 [ Монолітний шифрований потік UDP ]                      |
|                                       |                                  |
|                                       v                                  |
|                  +-----------------------------------+                   |
|                  |     Надлишковий буфер FIFO WAN    |                   |
|                  | [Файл][Файл][Файл][Файл][VoIP]    |                   |
|                  +-----------------------------------+                   |
|                                       |                                  |
|            Затримка очікування зростає з 15 мс до 650 мс                 |
|            Легкі пакети застрягають за масивними кадрами                 |
+--------------------------------------------------------------------------+

Природа явища Bufferbloat у мережевій передачі

Виробники мережевого обладнання десятиліттями сприймали втрату пакетів як технічний недолік. Щоб уникнути скидання кадрів під час раптових сплесків трафіку, інженери інтегрували значні обсяги оперативної пам'яті в маршрутизатори, кабельні модеми та оптичні термінали (ONT).

Більшість таких буферів працюють за принципом «першим прийшов — першим пішов» із відсіканням хвоста (FIFO tail-drop). За низького навантаження пакети проходять чергу без затримок. Проте стандартні алгоритми контролю перевантаження TCP (такі як Reno чи класичний CUBIC) розширюють вікно перевантаження (cwnd) доти, доки не зафіксують скидання пакетів.

Зустрічаючи буфери обсягом у кілька мегабайтів, протокол TCP не відчуває обмеження фізичної пропускної здатності вчасно. Натомість він повністю заповнює проміжну пам'ять. Пакети очікують у черзі сотні мілісекунд перед відправленням у фізичний канал. Пропускна здатність використовується на 100%, проте час перебування пакета в черзі (sojourn time) зростає в десятки разів.

Проблема інкапсуляції та мультиплексування в тунелях VPN

Створення тунелю VPN поглиблює затримки черг через два архітектурні обмеження:

1. Парадокс зовнішньої інкапсуляції

Маршрутизатори з базовими механізмами контролю якості обслуговування (QoS) аналізують заголовки 3-го (IP) та 4-го (TCP/UDP) рівнів. Вони зчитують значення DSCP, номери портів TCP/UDP і типи протоколів для відокремлення голосового трафіку від завантаження файлів.

Коли трафік проходить крізь тунель WireGuard (порт UDP 51820) або IPsec, зовнішній заголовок IP містить лише локальну адресу клієнта та IP-адресу шлюзу. Усі внутрішні потоки — запити DNS, команди SSH, завантаження HTTPS та кадри WebRTC — перетворюються на суцільний масив зашифрованих даних.

Для проміжного обладнання провайдера вся сукупність з'єднань виглядає як єдиний потік UDP. Маршрутизатор не здатен відрізнити пріоритетний запит DNS розміром 90 байтів від сегмента відеофайлу на 8 МБ. У черзі FIFO легкі пакети опиняються за масивними блоками даних, зумовлюючи блокування початку черги (Head-of-Line blocking).

2. Затримки черг усередині операційної системи

Операційні системи передають мережеві дані крізь абстрактні рівні. Коли застосунок надсилає дані через VPN, пакети прямують від сокета до віртуального інтерфейсу (tun0 або wg0), проходять стек ядра, зазнають криптографічної обробки й передаються на фізичний адаптер (eth0 або wlan0).

Якщо алгоритми черг налаштовані некоректно на віртуальному чи фізичному інтерфейсі, роздування буфера відбувається безпосередньо в ядрі операційної системи до виходу в кабель.

CoDel: Контроль затримки за часом перебування в черзі

Для ліквідації Bufferbloat без надлишкової втрати пакетів Кетлін Ніколс та Ван Якобсон розробили алгоритм CoDel (Controlled Delay, RFC 8289).

Ранні алгоритми AQM, такі як RED (Random Early Detection), регулювали буфери шляхом обчислення середньої довжини черги. Метод RED вимагав складного калібрування параметрів під швидкість каналу і час RTT, що нерідко призводило до передчасного скидання пакетів на швидкісних лініях.

+-------------------------------------------------------------------------+
|                  ДИНАМІКА ЧАСУ ПЕРЕБУВАННЯ В CODEL                      |
|                                                                         |
|  Надходження до черги ---> [ Фіксація часової мітки: t_enq ]            |
|                                     |                                   |
|                                     v                                   |
|                                 [ Черга ]                               |
|                                     |                                   |
|                                     v                                   |
|  Вилучення з черги   ---> [ Час перебування = t_deq - t_enq ]           |
|                                     |                                   |
|           +-------------------------+-------------------------+         |
|           |                                                   |         |
|  Час < Порогу (5 мс)                               Час > Порогу         |
|           |                                                   |         |
|    [ Пакет передано ]                    Таймер перевіряє тривалість    |
|                                          стану понад Interval           |
|                                                               |         |
|                                                               v         |
|                                             [ Режим відсікання Dropping]|
|                                             Скидання пакета з кроком:   |
|                                             1 / sqrt(count)             |
+-------------------------------------------------------------------------+

Алгоритм CoDel змінює критерій оцінювання: замість кількості пакетів вимірюється реальний час перебування кожного пакета в буфері:

  1. Корисна і шкідлива черга: Короткочасні сплески трафіка належать до корисної черги й не караються. Постійно заповнений буфер створює штучну затримку і класифікується як шкідлива черга.
  2. Параметри Target та Interval: CoDel використовує базові константи: цільовий час target (5 мс) та інтервал спостереження interval (100 мс — типовий RTT в інтернеті).
  3. Автомат скидання пакетів: Під час вилучення пакета з черги CoDel фіксує час його перебування. Якщо мінімальний зафіксований час безперервно перевищує 5 мс протягом 100 мс, алгоритм переходить у стан скидання (dropping state), відкидаючи пакет (або маркуючи його прапорцем ECN) зі зменшенням інтервалу:

$$\Delta t = \frac{\text{interval}}{\sqrt{\text{count}}}$$

Така залежність змушує джерело TCP плавно зменшувати вікно передачі доти, доки затримка в черзі не опуститься нижче 5 мс.

Порівняння FQ-CoDel та CAKE: Еволюція розділення потоків

Застосування CoDel до єдиної черги FIFO все ще дозволяє масивним потокам заважати дрібним пакетам. Вирішальним проривом стало об'єднання CoDel із розділенням потоків (Flow Queuing).

FQ-CoDel (RFC 8290)

FQ-CoDel розподіляє пакети за 1024 незалежними чергами за допомогою хешування п'яти параметрів (IP джерела, IP призначення, протокол, порт джерела, порт призначення).

Диспетчер Deficit Round Robin (DRR++) забезпечує:

  • Пріоритет ненасиченим потокам: Черги з малим обсягом даних (інтерактивні сесії SSH, пакети VoIP, оновлення мережевих ігор) передаються першочергово.
  • Ізоляцію перевантаження: Якщо інтенсивне завантаження заповнює свою виділену чергу, скидання пакетів відбувається лише в цьому конкретному сегменті. Паралельний інтерактивний трафік передається без затримок.

CAKE (Common Applications Kept Enhanced)

Створений як нове покоління планувальників після FQ-CoDel, алгоритм CAKE інтегрує формування пропускної здатності, стійке хешування та компенсацію мережевих заголовків у єдиний модуль ядра Linux.

Параметр FQ-CoDel (RFC 8290) CAKE (Нове покоління AQM)
Колізії хешів Проста хеш-таблиця 8-напрямне асоціативне хешування
Формування смуги Потребує зовнішнього шейпера htb Вбудований регулятор високої точності
Накладні витрати Ручний розрахунок Автоматичний облік Ethernet, ATM, PPPoE
Ізоляція вузлів Лише за потоками Подвійна ізоляція: за вузлами та за потоками
Класи DiffServ Єдиний набір черг 4 пріоритетні класи трафіку

Режим подвійної ізоляції в CAKE запобігає перевантаженню спільних мереж: навіть якщо один вузол у локальній мережі активує сотні паралельних з'єднань, CAKE ділить пропускну здатність порівну між пристроями, перш ніж розподіляти її між потоками.

Передавання сповіщень ECN крізь тунельні межі

Скидання пакетів вимагає повторної передачі TCP, що марнує пропускну здатність каналу. Механізм явного сповіщення про перевантаження (ECN, RFC 3168 та RFC 6040) дає змогу повідомляти про затори без втрати кадрів.

ECN використовує 2 біти в заголовку IP: 00 (без підтримки ECN), 10 (ECT(0)), 01 (ECT(1)) та 11 (зафіксовано перевантаження, CE).

Коли планувальник фіксує переповнення черги, пакет із прапорцем ECT не скидається — планувальник замінює значення на CE (11). Отримувач фіксує цей статус і передає сповіщення відправнику через пакети TCP ACK, що спонукає джерело зменшити швидкість без повторного надсилання даних.

Згідно з RFC 6040, шлюзи VPN зобов'язані транслювати ECN за спеціальними правилами:

  • Під час інкапсуляції прапорець ECN копіюється з внутрішнього заголовка до зовнішнього заголовка IP.
  • Під час деінкапсуляції, якщо зовнішній заголовок містить позначку CE, цей стан переноситься у внутрішній заголовок перед передачею в сокет застосунку.

Налаштування AQM для тунельних інтерфейсів

Усунення Bufferbloat у середовищі Linux здійснюється за допомогою конфігурації планувальників черг на віртуальному та фізичному адаптерах.

Крок 1: Оцінювання затримки під час навантаження

Перевірте рівень стабільності часу відгуку за допомогою стандартних команд:

# Базовий вимір RTT до шлюзу VPN
ping -c 20 10.8.0.1

# Моніторинг затримки одночасно з тестом пропускної здатності
ping 10.8.0.1 | while read pong; do echo "$(date +%T.%N) $pong"; done

Крок 2: Призначення CAKE на тунельний інтерфейс

Підключіть алгоритм CAKE безпосередньо до віртуального адаптера WireGuard:

# Перевірка поточної дисципліни черг wg0
tc qdisc show dev wg0

# Заміна типового pfifo_fast на CAKE із чотирма класами DiffServ
sudo tc qdisc replace dev wg0 root cake bandwidth 150mbit diffserv4 ack-filter

Опція ack-filter видаляє зайві підтвердження TCP ACK на асиметричних лініях, звільняючи вихідний канал зв'язку.

Крок 3: Оптимізація параметрів ядра Linux

Додайте налаштування мережевих сокетів до конфігураційного файлу /etc/sysctl.conf:

# Встановлення FQ-CoDel стандартним планувальником системи
net.core.default_qdisc = fq_codel

# Перехід на алгоритм контролю заторів BBR
net.ipv4.tcp_congestion_control = bbr

# Обмеження розширення буферів сокетів TCP
net.ipv4.tcp_rmem = 4096 87380 6291456
net.ipv4.tcp_wmem = 4096 65536 6291456
net.core.netdev_max_backlog = 5000

Застосуйте зміни командою:

sudo sysctl -p

Реалізація контролю затримок у VPNRice

В інфраструктурі VPNRice принципи активного керування чергами інтегровані безпосередньо в протокол RiceGuard.

Завдяки розділенню потоків на 3-му рівні перед шифруванням, чутливі до затримок пакети (запити DNS, голос, ігровий мережевий код) спрямовуються в окремі конвеєри обробки. У поєднанні з трансляцією ECN за стандартом RFC 6040 та апаратним прискоренням ChaCha20-Poly1305 з'єднання зберігає стабільний пінг до 20 мс навіть за максимального завантаження загального каналу зв'язку.

Активне керування чергами змінює підхід до передачі даних, замінюючи некеровані черги FIFO збалансованим розподілом потоків. Налаштування FQ-CoDel або CAKE забезпечує низьку затримку та надійний зв'язок у зашифрованих тунелях. Підтримуйте стабільне з'єднання з мінімальним пінгом разом із Завантажити VPNRice.