TCP GSO та GRO в Linux: Прискорення інтерфейсів TUN і оптимізація швидкості VPN

Мережеві інтерфейси та ядро операційної системи передають мережевий трафік через безперервне переміщення структур даних крізь межі пам'яті. У ранніх архітектурах мереж Ethernet кожен окремий кадр розміром 1500 байтів генерував апаратне переривання, потребував виділення окремого буфера сокета (sk_buff) та проходив незалежний аналіз таблицями маршрутизації та правилами мережевого екрана. Якщо для каналів зі швидкістю 100 Мбіт/с такий підхід був достатнім, то на сучасних мультигігабітних швидкостях поштучна обробка кадрів стає критичним вузьким місцем. Коли дані проходять крізь шифровані тунелі віртуальних приватних мереж (VPN), накладні витрати на програмну інкапсуляцію додатково навантажують процесор, стримуючи реальну пропускну здатність.

Щоб подолати обмеження поштучної обробки пакетів, розробники ядра Linux створили механізми агрегації та апаратного розвантаження: TCP Segmentation Offload (TSO), Generic Segmentation Offload (GSO) та Generic Receive Offload (GRO). Розуміння того, як ці підсистеми взаємодіють із віртуальними інтерфейсами TUN, криптографічними протоколами та мережевими драйверами, дає чітке пояснення, як сучасні транспортні канали досягають повної швидкості фізичної лінії без перевантаження процесорів.

Вузькі місця CPU при обробці окремих пакетів: Обмеження MTU у віртуальних мережах

У класичних мережах IP максимальний розмір одиниці передачі (MTU) для стандарту Ethernet зафіксований на рівні 1500 байтів. Віднявши 20 байтів заголовка IPv4 та 20 або 32 байти заголовка TCP, отримуємо максимальний розмір корисного сегмента (MSS) у 1460 байтів. Щоб повністю завантажити канал зв'язку зі швидкістю 10 Гбіт/с, операційна система має надсилати та приймати приблизно 820 000 пакетів щосекунди.

Обробка окремих кадрів по 1500 байтів:
[Дані] -> Нарізка TCP (1460B) -> [skb_1..skb_45] -> Netfilter -> Маршрутизація -> Драйвер -> 45 переривань

Агрегація GSO (Суперпакет 64 КБ):
[Дані] -> Єдиний суперпакет (64 КБ) -> [Один skb] -> Netfilter -> Маршрутизація -> Пізня нарізка / Карта мережі

Шторми апаратних переривань та накладні витрати перемикання контексту

Кожен пакет, який опрацьовує ядро системи, спричиняє послідовність витратних операцій:

Виділення пам'яті та ініціалізація структури буфера ядра (struct sk_buff).
Перевірка маршруту в кеші та зіставлення правил фільтрації через хуки netfilter або eBPF.
Виконання криптографічних перетворень (ChaCha20-Poly1305 або AES-GCM) на кінцевих точках тунелю.
Генерація програмних переривань (NET_RX_SOFTIRQ та NET_TX_SOFTIRQ) на ядрах процесора.

Коли потік пакетів перевищує 500 000 кадрів за секунду, процесорні ядра витрачають основну частину ресурсів на обслуговування переривань та витіснення кешу L1/L2 замість виконання прикладних обчислень. У віртуальних приватних мережах кожен пакет, що проходить через адаптер TUN або TAP, додає затримки на передачу метаданих демонам у просторі користувача та на регулярне перемикання контексту системи.

Навантаження на пам'ять при передачі між просторами користувача та ядра

Служби VPN у просторі користувача зчитують дані з дескриптора віртуального пристрою (/dev/net/tun) системними викликами на зразок read() чи recvmsg(). Якщо тунель працює виключно з сегментами розміром у MTU 1500 байтів, передача файлів на швидкості 1 Гбіт/с змушує ядро здійснювати понад 80 000 перемикань контексту щомиті.

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

Прискорення передачі: Апаратний TSO та механізм Generic Segmentation Offload (GSO)

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

Побудова суперпакетів: Збереження інваріантів протоколу через TCP Pacing

Технологія TCP Segmentation Offload (TSO) дозволяє транспортному стеку TCP формувати неперервний блок даних обсягом до 64 КБ (GSO_MAX_SIZE), обробляючи весь масив як одну неподільну одиницю передачі. Замість подрібнення корисного навантаження на шматки по 1460 байтів безпосередньо на рівні сокета:

Стек TCP створює єдиний дескриптор sk_buff, що містить обсяг даних, еквівалентний 45 стандартним кадрам MTU.
Суперпакет повністю проходить правила міжмережевого екрана, обчислення контролю перевантаження та черги регулювання трафіку як єдина сутність.
Механізм таймінгу TCP витримує точні часові інтервали між пакетами, дотримуючись принципів контролю затримок, проаналізованих у статті про /news/bufferbloat-active-queue-management-vpn-fq-codel-cake.
Розподіл порядкових номерів та перевірка ковзного вікна виконуються лише один раз для всього блоку, а не десятки разів поспіль.

Оскільки фізичні мережеві адаптери потребують спеціальної апаратної підтримки для нарізки TSO, розробники ядра Linux запровадили механізм Generic Segmentation Offload (GSO), який поширив оптимізацію відкладеного розбиття на всі пристрої, включно з віртуальними адаптерами та тунелями.

Виконання skb_gso_segment(): Пізня сегментація на рівні мережевого драйвера

Коли вихідний суперпакет потрапляє до черги пристрою, ядро аналізує прапорці можливостей драйвера (netdev->features). Якщо драйвер чи обладнання підтримують NETIF_F_TSO або NETIF_F_GSO, агрегований буфер sk_buff без змін надсилається до апаратного кільцевого буфера передачі.

Якщо ж цільовий інтерфейс позбавлений апаратної підтримки сегментації (що характерно для інкапсульованих оверлейних мереж), ядро виконує функцію skb_gso_segment() під час виклику dev_hard_start_xmit(). Вона здійснює пізнє програмне розбиття:

struct sk_buff *skb_gso_segment(struct sk_buff *skb, netdev_features_t features)
{
    if (skb_needs_check(skb, true))
        return ERR_PTR(-EINVAL);

    /* Розбиває навантаження skb на блоки за розміром MTU з дублюванням заголовків */
    return skb_mac_gso_segment(skb, features);
}

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

Об'єднання на прийомі: Generic Receive Offload (GRO) у циклі NAPI

У той час як GSO прискорює відправлення інформації, вхідний потік потребує дзеркального рішення. Швидкісний мережевий порт приймає тисячі окремих кадрів по 1500 байтів, які перед подачею до транспортного стека необхідно згрупувати.

Сувора валідація протоколу: Злиття послідовних упорядкованих сегментів

Механізм Generic Receive Offload (GRO) працює всередині циклу опитування NAPI під час обробки програмних переривань. Коли мережевий драйвер дістає пакети з кільцевого буфера, процедура napi_gro_receive() перевіряє заголовки, визначаючи, чи належать суміжні кадри до одного потоку передачі.

Перед злиттям сегментів механізм GRO обов'язково контролює низку інваріантів:

Повний збіг вихідних і кінцевих IP-адрес, портів та протокольних ідентифікаторів.
Сувору послідовність порядкових номерів TCP Sequence Number без розривів і повторень.
Монотонність і коректність часових міток опції TCP Timestamps (RFC 7323).
Однакове значення прапорців явного сповіщення про перевантаження (ECN) на всіх кадрах блоку.

Якщо будь-який параметр не збігається або виявлено порушення порядку слідування, об'єднання припиняється, і буфер одразу передається вище. Такий строгий контроль зберігає точність обліку даних, що дозволяє алгоритмам /news/tcp-sack-rfc-6675-loss-recovery-pipe-algorithm-vpn та /news/tcp-rack-tlp-rfc-8985-time-based-loss-recovery-vpn своєчасно отримувати точні показники послідовності.

Скорочення проходів стеком: Доставка агрегованих блоків 64 КБ до сокетів

Після об'єднання єдина структура sk_buff із корисним навантаженням до 64 КБ рухається вгору мережевим стеком. Замість повторної 40-кратної перевірки маршрутизації та правил фільтрації для обсягу в 60 КБ ядро виконує всі дії один раз. Сокет програми робить єдиний системний виклик read(), що усуває зайві цикли пробудження процесів та зменшує навантаження на процесор на величину до 70%.

Інтеграція віртуального TUN: Прапорець IFF_VNET_HDR та розвантаження UDP у VPN

У віртуалізованих і захищених мережах основні втрати продуктивності зосереджені на межі між системним мережевим стеком та модулем інкапсуляції тунелю.

Передача метаданих Virtio Net через межу пристрою /dev/net/tun

Раніше інтерфейс /dev/net/tun у Linux відкидав метадані апаратного розвантаження, змушуючи віртуальні карти оперувати виключно невеликими кадрами за розміром MTU. Для розв'язання цієї проблеми в драйвер TUN/TAP додали прапорець IFF_VNET_HDR.

Коли сервіс VPN вмикає IFF_VNET_HDR, кожен пакет, переданий через /dev/net/tun, отримує спеціальний заголовок struct virtio_net_hdr:

struct virtio_net_hdr {
    uint8_t  flags;       /* Стан валідності чи потреба розрахунку контрольної суми */
    uint8_t  gso_type;    /* Тип сегментації VIRTIO_NET_HDR_GSO_TCPV4, UDP */
    uint16_t hdr_len;     /* Загальна довжина заголовків Ethernet + IP + TCP */
    uint16_t gso_size;    /* Цільовий розмір MSS для фінального розділення */
    uint16_t csum_start;  /* Зсув початку обчислення контрольної суми */
    uint16_t csum_offset; /* Зсув для запису значення контрольної суми */
};

Цей заголовок передає вказівки щодо розвантаження крізь межу ядра. Процес VPN у просторі користувача зчитує цілісний суперпакет 64 КБ одним викликом read(), зберігаючи метадані GSO. Далі процес виконує пакетне шифрування та передає блок фізичному адаптеру без проміжної нарізки.

Сегментація UDP та механізм GRO для тунелів WireGuard та IPsec

Більшість сучасних протоколів VPN інкапсулюють потік у датаграми UDP. Починаючи з ядра Linux 4.18, система отримала підтримку технологій UDP GSO (UDP_SEGMENT) та UDP GRO (UDP_GRO):

UDP GSO: Дозволяє програмі створити єдину датаграму UDP обсягом до 64 КБ і через опцію сокета UDP_SEGMENT повідомити ядру потрібний розмір кінцевого сегмента.
Векторне шифрування: Протоколи тунелювання шифрують масиви по 64 КБ за допомогою інструкцій AVX-512 або ARM NEON, уникаючи витрат на повторну ініціалізацію ключів для кожного дрібного пакета.
Апаратне надсилання: Фізична мережева карта розділяє кадри безпосередньо перед передачею в кабель, підтримуючи максимальний рівень MTU без небажаної фрагментації IP.

Така взаємодія запобігає падінню швидкості через раптові перевантаження буферів під час повільного старту — явищу, детально розглянутому в публікації про /news/tcp-hystart-plus-rfc-9406-bufferbloat-slow-start-vpn.

Архітектурна оптимізація: Високопродуктивний конвеєр передачі RiceGuard

VPNRice інтегрує всі передові розробки розвантаження ядра у власний тунельний стек через оптимізований модуль RiceGuard:

Багаточергова архітектура TUN: Створення окремих віртуальних черг із прив'язкою до виділених ядер процесора, що виключає блокування spinlock під час паралельної обробки трафіку.
Підтримка заголовків Vnet: Повна сумісність із IFF_VNET_HDR та TUNSETOFFLOAD, що гарантує пряму передачу 64 КБ суперпакетів GSO між шифрувальним ядром та мережевим стеком.
Адаптивне об'єднання UDP GRO: Динамічне визначення місткості буферів сокета на боці клієнта та укрупнення зашифрованих пакетів перед верифікацією підписів.
Кільцеві буфери без копіювання: Попередній розподіл пам'яті з вирівнюванням за межами рядків процесорного кешу, що зводить до мінімуму втрати TLB під час високих навантажень.

Завдяки цим рішенням VPNRice забезпечує високу пропускну здатність на швидкісних оптоволоконних лініях і мережах 5G, зберігаючи помірну температуру пристроїв та ощадливо використовуючи заряд батареї на мобільних телефонах.

Практична діагностика в Linux: Налаштування та перевірка функцій GSO і GRO

Мережеві інженери та системні адміністратори можуть контролювати та налаштовувати параметри сегментації на шлюзах Linux за допомогою стандартних команд термінала.

Аудит можливостей апаратного розвантаження за допомогою утиліти ethtool

Команда ethtool надає змогу переглядати та редагувати стан підсистем мережевого інтерфейсу:

# Перевірка активних параметрів розвантаження на фізичному інтерфейсі eth0
ethtool -k eth0 | grep -E "segmentation|receive-offload"

# Зразок виведених даних:
# tcp-segmentation-offload: on
# generic-segmentation-offload: on
# generic-receive-offload: on
# large-receive-offload: off [fixed]

Для ввімкнення потрібних режимів на пристрої:

# Активація GSO, GRO та TSO на зовнішньому інтерфейсі
sudo ethtool -K eth0 gso on gro on tso on

# Моніторинг показників групування пакетів драйвером
ethtool -S eth0 | grep -E "gro|gso|tso"

Тонке налаштування буферів сокетів і параметрів драйвера через sysctl та ip link

Для ефективного використання GSO та GRO системні буфери сокетів мають бути достатньо місткими, щоб утримувати суперпакети по 64 КБ без скидання даних:

# Збільшення максимальних лімітів пам'яті для сокетів ядра
sudo sysctl -w net.core.rmem_max=16777216
sudo sysctl -w net.core.wmem_max=16777216

# Встановлення порогів пам'яті TCP (мінімальний, стандартний, максимальний у сторінках)
sudo sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sudo sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"

# Перевірка обмежень GSO для віртуального інтерфейсу
ip -d link show dev tun0

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

Завантажити VPNRice.