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(). Если туннель обрабатывает данные строго порциями по 1500 байт, то при скорости передачи 1 Гбит/с операционная система вынуждена выполнять более 80 000 переключений контекста каждую секунду.

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

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

Чтобы предотвратить перегрузку процессора на передающей стороне, стек ядра перекладывает нарезку данных на микрокод сетевого адаптера либо откладывает ее до момента отправки в драйвер.

Формирование суперпакетов: Сохранение инвариантов протокола через TCP Pacing

Механизм TCP Segmentation Offload (TSO) позволяет транспортному уровню формировать непрерывный блок данных объемом до 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) на всех объединяемых кадрах.

Если параметры не совпадают или обнаружено нарушение порядка следования пакетов, GRO немедленно завершает объединение и передает буфер на следующий уровень. Такая проверка сохраняет точность работы транспортных механизмов, позволяя алгоритмам /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 КБ направляется вверх по стеку протоколов. Вместо сорокакратной проверки маршрутов и правил фильтрации для порции данных в 60 КБ ядро выполняет все проверки один раз. Принимающее приложение выполняет один системный вызов read(), исключая накладные расходы на пробуждение сокета и снижая нагрузку на процессор до 70%.

Интеграция виртуального TUN: Флаг IFF_VNET_HDR и разгрузка UDP в протоколах VPN

В виртуальных сетях главная потеря производительности традиционно возникала на стыке между сетевым стеком ядра и процессом инкапсуляции туннеля.

Передача метаданных Virtio Net через границу устройства /dev/net/tun

Исторически интерфейс Linux /dev/net/tun сбрасывал метаданные аппаратной разгрузки, вынуждая виртуальные сетевые карты работать исключительно с кадрами стандартного размера MTU. Для устранения этого барьера в драйвер TUN/TAP был добавлен флаг IFF_VNET_HDR.

При включении флага 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, исключая перезагрузку криптографического контекста для каждого пакета.
Аппаратная отправка: Окончательное разделение кадров выполняет сетевой адаптер при передаче в физическую среду, сохраняя высокий КПД без фрагментации на уровне IP.

Такая схема исключает потерю производительности при переполнении буферов на этапе медленного старта, детально исследованную в материале про /news/tcp-hystart-plus-rfc-9406-bufferbloat-slow-start-vpn.

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

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

Многоочередная виртуальная архитектура TUN: Выделение независимых очередей под конкретные процессорные ядра, исключающее блокировки spinlock при параллельной обработке пакетов.
Интеграция с заголовками Vnet: Полная поддержка IFF_VNET_HDR и TUNSETOFFLOAD, обеспечивающая сквозную передачу суперпакетов GSO по 64 КБ между шифрующим ядром и сетевым стеком.
Адаптивная агрегация 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.