Linux 6.x: UDP GRO/GSO и USO (tx-udp-segmentation) для ускорения VPN

Инструкции
13 фев, 2026
Время на чтение: ~13 мин
Автор: AI (GPT 5)

Искусственный интеллект

Данная статья была создана с использованием искусственного интеллекта (GTP-5). Пожалуйста, имейте в виду, что текст может содержать неточности или ошибки.

UDP-нагруженные VPN (в первую очередь WireGuard) часто упираются не в «сырой» канал, а в CPU на обработке пакетов: много мелких UDP-датаграмм, частые проходы по сетевому стеку, рост softirq и очередей. В Linux 6.x созрели механизмы, которые целятся именно в это: UDP GRO, UDP GSO и USO (в ethtool чаще виден как tx-udp-segmentation). Если они совпадают с вашим драйвером/NIC и топологией VPN, прирост VPN throughput может быть двузначным — но при неверной комбинации легко получить деградацию и «странные» симптомы.

Ниже — практический разбор: что именно ускоряют эти offload’ы, как понять, что они реально работают, где типично ломается путь (MTU/PMTU, туннели поверх туннелей, виртуальные NIC), и как безопасно откатиться.

Что такое UDP GRO, UDP GSO и USO — простыми словами

GRO (Generic Receive Offload) — агрегация на приёме. Ядро старается «склеить» несколько входящих пакетов в один более крупный буфер до передачи выше по стеку. Для TCP это давно привычно, для UDP — сравнительно новое и дорабатываемое.

GSO (Generic Segmentation Offload) — сегментация на отправке. Стек формирует один большой «логический» пакет, а разбиение на MTU-куски откладывается на поздний этап (и иногда уходит в драйвер/железо). Для UDP это часто обсуждают как UDP segmentation на TX.

USO (UDP Segmentation Offload) — более «узкий» вариант именно для UDP на TX: когда драйвер/NIC умеет дробить крупный UDP-буфер на датаграммы нужного размера. В Linux это обычно включается фичей tx-udp-segmentation. На части драйверов рядом встречается tx-udp_tnl-segmentation для UDP-туннелей.

Ключевая идея для VPN: если WireGuard (или другой VPN поверх UDP) может работать с «крупными» буферами на TX/RX, то на единицу полезного трафика будет меньше пакетов и меньше накладных расходов в ядре. Это часто повышает WireGuard performance именно по CPU.

Эти технологии ускоряют не «интернет» и не шифрование как таковое, а путь пакетов через сетевой стек, очереди и драйверы. Поэтому результат зависит от версии ядра, NIC/драйвера, виртуализации и даже от того, где именно стоит интерфейс WireGuard в вашей схеме маршрутизации и фильтрации.

Когда это реально даёт прирост VPN throughput

На практике наибольший эффект вы увидите, когда VPN упирается в CPU и PPS, а не в «канал». Типичная картина: скорость ниже ожидаемой, при этом одно-два ядра заняты системным временем, а в профиле доминируют сетевые обработчики и softirq.

Хорошие кандидаты на прирост:

VPN-трафик с высокими PPS (много мелких UDP-пакетов);
сервер — VPN-шлюз, который много форвардит (router/gateway роль);
современный NIC и драйвер, где offload’ы реально реализованы;
аккуратно выставленный MTU на подложке и внутри туннеля.

А вот если вы упираетесь в лимиты провайдера, шейпинг, перегруженный канал или «тяжёлую» криптографию на слабом CPU — offload’ы могут дать мало (или ничего).

Схема очередей NIC и сегментации UDP при включенном USO/GSO

Проверяем поддержку и текущие настройки через ethtool

Сначала определитесь, какой интерфейс трогаете. На «железе» — физический (например, ens3, enp1s0). В VM часто будет eth0 (virtio), и часть offload’ов «переедет» на уровень хоста/виртуального свитча.

1) Посмотреть фичи интерфейса

ip -br link
ethtool -k eth0

В выводе ethtool -k ищите строки, похожие на:

generic-segmentation-offload (GSO);
generic-receive-offload (GRO);
tx-udp-segmentation (USO);
tx-udp_tnl-segmentation, tx-udp_tnl-csum-segmentation (если есть);
rx-udp-gro-forwarding (встречается на части драйверов/ядер, полезно для форвардинга).

Важно: «флаг виден» не означает «в вашем трафиковом пути это точно отработает». На разных драйверах часть фич может быть объявлена, но фактически не задействована (или работать только в определённых режимах).

2) Уточнить контур измерения: хост, VM, контейнер

Если WireGuard работает внутри VM, у вас может быть два независимых уровня:

внутри гостя — virtio/offload’ы гостевой ОС;
на хосте — физический NIC и offload’ы хоста.

Иногда включение в госте почти ничего не меняет, потому что узкое место на хосте (и наоборот). В спорных случаях полезно сравнить метрики и на госте, и на хосте.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Быстрая диагностика: есть ли шанс, что offload’ы помогут

Прежде чем крутить флаги, снимите базовую картину. Так вы поймёте, что именно улучшилось (или ухудшилось) после изменений. Если параллельно занимаетесь общей оптимизацией сервера, полезно держать под рукой чек-лист по лимитам systemd и CPU/памяти: практика настройки лимитов systemd для сервисов.

Нагрузка CPU и softirq

uname -r
mpstat -P ALL 1
top -H

Если под нагрузкой VPN одно ядро стабильно «горит» в системном времени, а доля softirq заметно растёт — это типичный сценарий, где GSO/GRO/USO могут дать выигрыш.

Статистика дропов и ошибок на интерфейсе

ip -s link show dev eth0
ethtool -S eth0

В ethtool -S имена счётчиков зависят от драйвера. Ищите рост rx_dropped, tx_dropped, признаки переполнения очередей и ring buffer.

Проверить MTU и симптомы PMTU blackhole

UDP segmentation особенно требователен к «правильному» MTU. Если в туннеле неверный MTU, возможны фрагментация/дропы, нестабильная скорость, плавающий RTT.

ip -d link show dev wg0
ip link show dev eth0

Для WireGuard MTU на wg0 обычно задают осознанно (меньше физического MTU на величину накладных расходов). Если у вас подложка с VLAN/PPPoE или есть второй туннель поверх первого — MTU нужно пересчитать. Включение offload’ов часто «вскрывает» проблему, которая ранее маскировалась общим спадом производительности.

Как включать/выключать UDP GRO/GSO/USO безопасно

Практическое правило: меняйте по одному параметру и каждый раз измеряйте throughput, CPU, дропы и (если важно) задержки. Некоторые комбинации полезны, некоторые — вредны именно на вашей связке «ядро + драйвер + топология».

Включить USO (tx-udp-segmentation) на интерфейсе

ethtool -K eth0 tx-udp-segmentation on

Откат:

ethtool -K eth0 tx-udp-segmentation off

Проверить/включить общие GRO/GSO

ethtool -K eth0 gro on
ethtool -K eth0 gso on

И, если нужно, выключить для теста:

ethtool -K eth0 gro off
ethtool -K eth0 gso off

Если меняете offload’ы на проде, делайте короткие «окна» и имейте активную консоль. Неверная комбинация может не «уронить» сеть полностью, но даст деградацию и труднообъяснимые таймауты именно в UDP-нагрузке.

VPN и offload’ы: типовые грабли и как их распознать

1) Неправильный MTU и «скрытые» потери

Симптомы: скорость WireGuard «пилой», периодические подвисания UDP-приложений, рост потерь на верхнем уровне (например, QUIC поверх VPN), при этом TCP может выглядеть терпимо из-за собственной адаптации.

Что делать: временно снизить MTU на wg0 и повторить тест; параллельно смотреть, исчезли ли дропы/ошибки на интерфейсах. Если после уменьшения MTU всё резко «ровняется» — сначала чините MTU/PMTU, а потом возвращайтесь к offload’ам.

2) Форвардинг через VPN-шлюз и UDP GRO forwarding

Если сервер — именно VPN-шлюз (маршрутизирует трафик клиентов дальше), полезными бывают режимы, связанные с форвардингом (например, rx-udp-gro-forwarding, если он есть в вашем драйвере). В этом сценарии особенно важно следить за дропами на входе/выходе, очередями и балансировкой по CPU.

Отдельная тема — контроль трафика и шейпинг на шлюзе. Если вы упираетесь в полосу и планируете ограничивать клиентов, смотрите материал: мониторинг и шейпинг трафика на VDS.

3) Виртуализация и виртуальные свитчи

В VM и контейнерных сетях offload’ы иногда:

работают частично (например, GRO есть, а USO «заявлен», но не даёт эффекта);
дают эффект только на хосте, а в госте лучше выключить часть фич из-за особенностей virtio/bridge/vSwitch;
влияют на наблюдаемость: захват трафика видит «крупные» пакеты и вводит в заблуждение.

4) Захват трафика (tcpdump) и «большие UDP-пакеты»

Частая паника после включения GSO/USO: в tcpdump внезапно видны UDP-пакеты «больше MTU». Это не всегда реальная отправка по проводу — часто вы смотрите на пакет до сегментации (внутри стека).

Чтобы не гадать, сопоставляйте:

счётчики интерфейса ip -s link и статистику драйвера ethtool -S;
фактическую пропускную способность и потери (на прикладном уровне тоже);
нагрузку CPU и softirq.

Про gro_flush_timeout и почему он всплывает рядом с UDP GRO

Параметр gro_flush_timeout встречается в обсуждениях UDP GRO, потому что GRO по сути «держит» пакеты, чтобы успеть их агрегировать, и затем «сбрасывает» пачкой. Это баланс между throughput и latency: более агрессивная агрегация повышает шанс улучшить пропускную способность, но может добавить микрозадержки и джиттер.

Практически это означает:

для bulk-трафика через VPN (бэкапы, синхронизации, репликации) GRO чаще полезен;
для latency-sensitive трафика (голос, игры, real-time протоколы) измеряйте p95/p99 задержки и джиттер, а не только Mbps.

Доступность и поведение gro_flush_timeout зависят от версии ядра и сетевых компонентов. Если вы нашли параметр в sysfs именно в вашем окружении — меняйте осторожно, небольшими шагами и только под измерениями.

Чек-лист диагностики MTU и дропов при настройке UDP offload в VPN

Что делать, если стало хуже: быстрый чек-лист

Откатить последнее изменение (важно: по одному флагу).
Проверить MTU на wg0 и подложке; временно уменьшить MTU на WireGuard и повторить тест.
Посмотреть рост дропов/ошибок в ip -s link и ethtool -S.
Если вы в VM — уточнить, где именно включаете offload’ы: в госте или на хосте, и нет ли конфликтов с настройками vSwitch/bridge.
Сверить версию ядра и драйвер NIC: иногда помогает обновление ядра/драйвера, а не «магия» в ethtool.

Вывод

UDP GRO, UDP GSO и USO (tx-udp-segmentation) — это практичные механизмы, которые могут заметно повысить VPN throughput и WireGuard performance на Linux 6.x за счёт снижения накладных расходов на обработку пакетов. Лучший результат получается, когда вы подходите к настройке как к инженерному эксперименту: включили один флаг, померили, проверили дропы и задержки, закрепили успех или откатили.

Если вы поднимаете VPN на сервере под стабильную нагрузку, чаще удобнее тестировать и фиксировать настройки на отдельном экземпляре, а потом переносить в прод. Для таких задач обычно выбирают VDS, чтобы контролировать ядро, драйверы и сетевые параметры без сюрпризов «общего хостинга».

Поделиться статьей