Linux SO_BUSY_POLL: Усунення мережевого джитера для VPN-шлюзів

В інтерактивних цифрових застосунках—від динамічних мережевих ігор та голосового зв'язку в реальному часі до віддаленого адміністрування інфраструктури—середній показник затримки (RTT) далеко не завжди відображає справжню стабільність каналу. Навіть коли середній пінг через VPN становить 25 мілісекунд, користувач може відчувати мікрозатримки та ривки кадрів, якщо 99-й процентиль (p99) затримки періодично підскакує до 60 чи 100 мілісекунд. Такі коливання часу передачі пакетів називаються мережевим джитером (jitter).

Фахівці нерідко пояснюють такі затримки перевантаженням публічних магістралей або бездротовими перешкодами. Проте суттєва частина коливань виникає безпосередньо всередині ядра операційної системи Linux. Традиційний мережевий стек ядра розроблено на основі обробки апаратних переривань, націленої на пропускну здатність, а не на мікросекундну стабільність. Для усунення цієї проблеми інженери використовують спеціальну функцію сокетів: Linux SO_BUSY_POLL.

Традиційний шлях обробки переривань (Висока варіативність затримок):
Кільцевий буфер RX мережевої карти ──> Апаратне переривання (Hard IRQ) ──> Пробудження CPU / Зміна контексту ──> SoftIRQ
                                             ▲                                                                             │
                                             └── Затримка групування переривань (Coalescing) ──────────────────────────────┘
                                                                                                                           │
                                                                                                                           ▼
                                                                            Черга сокета ──> Пробудження epoll_wait ──> recvmsg()

─────────────────────────────────────────────────────────────────────────────────────────────────────────────

Прямий шлях SO_BUSY_POLL (Детермінована субмілісекундна затримка):
Кільцевий буфер RX мережевої карти <══════ Пряме опитування з контексту користувацького потоку ══════ recvmsg() / epoll_wait
                                             ▲
                                             └── Без Hard IRQ ── Без таймерів накопичення ── Нульова затримка планувальника

Джерела апаратних затримок і підсистема NAPI

Коли мережевий адаптер (NIC) отримує інкапсульований тунельний пакет, він спрямовує його в кільцевий буфер оперативної пам'яті за допомогою прямого доступу до пам'яті (DMA). За стандартної схеми контролер генерує апаратний сигнал переривання (Hard IRQ) до призначеного ядра процесора.

Для захисту операційної системи від лавинного навантаження під час сплесків трафіку в Linux діє підсистема NAPI (New API). NAPI переводить адаптер у режим періодичного опитування за допомогою програмного преривання (NET_RX_SOFTIRQ). Додатково серверні карти застосовують адаптивну модерацію переривань (DIM). Замість переривання процесора для кожного окремого пакета, карта накопичує пакети протягом визначеного часу (зазвичай від 10 до 125 мікросекунд) або до заповнення встановленого ліміту.

Хоча групування заощаджує ресурси процесора під час передачі великих обсягів даних, воно створює часові розбіжності:

Затримка накопичення (Coalesce Lag): Окремий UDP-пакет з важливими діями користувача змушений очікувати спрацьовування апаратного таймера в буфері адаптера.
Витрати на зміну контексту: Обслуговування апаратного переривання вимагає від ядра призупинити поточний процес, зберегти вміст регістрів та перейти у простір ядра.
Вихід процесора з енергозберігальних станів (C-States): У періоди між пакетами процесорні ядра переходять у стан глибокого сну. Повернення ядра до активного режиму може додати від 20 до 120 мікросекунд.
Очікування у планувальнику: Після потрапляння пакета в чергу сокета робочий потік, що очікує у виклику epoll_wait(), повинен дочекатися виділення кванту часу планувальником CFS.

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

Архітектурний принцип роботи SO_BUSY_POLL

Функціонал SO_BUSY_POLL оптимізує отримання пакетів для чутливих до часу систем. Замість того щоб переводити робочий потік у режим очікування сигналу, процес починає самостійно та активно опитувати апаратну чергу драйвера безпосередньо з простору користувача.

Коли застосунок виконує системний виклик recv(), recvmsg() або epoll_wait() на сокеті з активованим SO_BUSY_POLL:

Потік спершу перевіряє наявність готових даних у буфері сокета.
Якщо буфер порожній, ядро без зволікань звертається до методу драйвера ndo_busy_poll.
Драйвер безпосередньо перевіряє апаратне кільце адаптера, опрацьовуючи пакети без створення Hard IRQ та фонових процесів ksoftirqd.
Якщо пакет надходить у встановлений період опитування, він одразу передається застосунку.
Якщо за відведений час нових даних немає, сокет повертається до звичайного режиму очікування, щоб не перевантажувати процесор під час простою.

Ця схема забезпечує дві важливі переваги:

Усунення перемикань контексту: Обробка зосереджена всередині активного робочого потоку, зберігаючи гарячі кеші L1/L2 процесора.
Висока точність таймінгів: Дані зчитуються одразу після завершення транзакції DMA мережевої карти.

Конфігурація параметрів сокета та підтримка в epoll

Механізм SO_BUSY_POLL можна налаштовувати як для окремих сокетів, так і для всієї операційної системи.

Програмне налаштування мовою C

Наведений приклад показує конфігурацію швидкого опитування для високопродуктивного сокета UDP:

#include <sys/types.h>
#include <sys/socket.h>
#include <sys/epoll.h>
#include <netinet/in.h>
#include <unistd.h>
#include <stdio.h>

int configure_low_latency_socket(int sock_fd) {
    // Встановлення часу опитування до 50 мікросекунд
    int busy_poll_usec = 50;
    if (setsockopt(sock_fd, SOL_SOCKET, SO_BUSY_POLL,
                   &busy_poll_usec, sizeof(busy_poll_usec)) < 0) {
        perror("Помилка конфігурації SO_BUSY_POLL");
        return -1;
    }

    // Увімкнення SO_PREFER_BUSY_POLL (підтримується з версії ядра Linux 5.11)
    int prefer_busy = 1;
    if (setsockopt(sock_fd, SOL_SOCKET, SO_PREFER_BUSY_POLL,
                   &prefer_busy, sizeof(prefer_busy)) < 0) {
        perror("Попередження: SO_PREFER_BUSY_POLL не підтримується");
    }

    return 0;
}

Загальносистемні параметри ядра

Для виділених мережевих серверів базові таймінги встановлюються через систему /proc/sys/net/core/:

# Встановлення часу активного опитування за замовчуванням (у мікросекундах)
sysctl -w net.core.busy_poll=50

# Встановлення часу опитування для операцій читання сокета
sysctl -w net.core.busy_read=50

Контроль навантаження та ізоляція процесорних ядер

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

Для досягнення балансу між мінімальною затримкою та енергоефективністю застосовуються системні практики:

Метод оптимізації	Механізм виконання	Очікуваний результат
Фіксація ядер (Core Affinity)	`taskset` або `pthread_setaffinity_np` на ізольовані ядра	Усунення міграцій між ядрами та збереження кешу
Обмеження режимів C-State	Параметр `idle=poll` або інтерфейс `/dev/cpu_dma_latency`	Запобігання переходу ядер у стан глибокого сну
Обмежений бюджет опитування	Встановлення значень у межах 30–80 мікросекунд	Захист від тривалого блокування ядра під час пауз
Прив'язка апаратних черг	Налаштування `smp_affinity` відповідно до локального вузла NUMA	Читання пакетів з локальної оперативної пам'яті

Практична реалізація в архітектурі RiceGuard

У сервісі VPNRice забезпечення стабільного відгуку для вимогливих сценаріїв базується на власному модулі прискорення RiceGuard. Замість негнучкого постійного опитування в RiceGuard впроваджено адаптивне керування ресурсами.

Система оцінює динаміку надходження пакетів для кожного клієнтського тунелю:

Виявлення інтерактивного трафіку: При виявленні чутливих даних (онлайн-ігри, аудіозв'язок або активні команди термінала) RiceGuard призначає сокету інтервал SO_BUSY_POLL у 60 мікросекунд. Пакети забираються з мережевої карти без затримок, стабілізуючи графік p99.
Плавний перехід до пасивного режиму: Якщо пауза між пакетами перевищує 500 мілісекунд, сокет повертається до звичайного режиму NAPI, зберігаючи ресурси сервера.
Пряма передача даних: Дешифровані пакети надходять одразу у віртуальний мережевий інтерфейс без повторного копіювання в пам'яті.

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