Высоконагруженные концентраторы VPN, сетевые маршрутизаторы и выходные шлюзы (egress gateways) регулярно обрабатывают совокупный сетевой поток свыше 40 Гбит/с на современных многоядерных серверах. В классической модели сокетов Linux каждая операция отправки через send(2) или sendmsg(2) принуждает ядро копировать байты из буфера пользовательского пространства в буферы сетевых пакетов ядра (sk_buff).

Для небольших объемов трафика эти накладные расходы незаметны. Однако при непрерывной передаче десятков гигабит в секунду постоянное дублирование памяти превращается в узкое место: процессорные ядра тратят до 35% времени на выполнение инструкций копирования (copy_user_generic_string), перегружая системную шину памяти RAM и вытесняя активные криптографические данные из кэшей L1 и L2.

Ядро Linux устраняет данное архитектурное ограничение с помощью флага MSG_ZEROCOPY (появившегося в Linux 4.14 и поддерживаемого для сокетов TCP, UDP и raw packet). Закрепляя физические страницы памяти приложения в таблице страниц ядра и связывая их через списки разметки (scatter-gather list) для прямого доступа сетевой карты к памяти (DMA), MSG_ZEROCOPY полностью исключает копирование данных на пути передачи.

Перегрузка системной шины при стандартной передаче через сокеты

Чтобы понять причины снижения производительности высокоскоростных шлюзов VPN, проследим путь данных зашифрованного туннеля в оперативной памяти:

[ Демон VPN в пользовательском пространстве ]
       | (Буфер данных расположен в RAM приложения)
       | sendto(fd, buf, len, 0, ...)
       v
[ Уровень сокетов ядра: Вызов __copy_from_user() ]
       | (Дублирование полезных данных в страницы sk_buff)
       v
[ Сетевой стек ядра: Маршрутизация IP, Netfilter, Qdisc ]
       v
[ Кольцевой буфер драйвера сетевой карты: Привязка DMA ]
       | (Сетевая карта считывает данные из RAM через PCIe DMA)
       v
[ Физический сетевой адаптер (NIC) ]

Когда приложение передает блок размером 16 КБ, процессор считывает байты из виртуальной памяти процесса через свои регистры и записывает их в заново выделенные страницы памяти ядра. На скорости 40 Гбит/с этот конвейер перекачивает более 5 ГБ «сырых» данных в секунду через шину оперативной памяти.

Это вызывает три существенные проблемы:

  1. Конкуренция за пропускную способность шины памяти: Алгоритмы поточного шифрования (например, ChaCha20-Poly1305) и хэширования Blake2s активно нагружают память. Избыточное копирование сокетов забирает ценную пропускную способность у криптографических блоков.
  2. Засорение процессорного кэша: Непрерывное чтение и запись гигабайтов транзитных сетевых пакетов вытесняют таблицы маршрутизации и параметры сессий из сверхбыстрых кэшей L1 и L2.
  3. Увеличение задержки переключения контекста: Синхронное копирование удерживает поток выполнения в контексте ядра вплоть до завершения дублирования буфера.

Архитектурные особенности механизма MSG_ZEROCOPY

Механизм MSG_ZEROCOPY делегирует чтение памяти непосредственно аппаратному обеспечению сетевой карты:

[ Демон VPN: Буфер данных buf ]
       |
       | 1. send(fd, buf, len, MSG_ZEROCOPY)
       |    (Ядро закрепляет страницы через get_user_pages_fast)
       |
       +======================+ (Прямая ссылка, НОЛЬ операций копирования)
       |                      |
       v                      v
[ Структура skb: frags[] ] ---> [ Аппаратная часть NIC: Прямой DMA из RAM ]
       |
       | 2. Пакет отправляется в физическую линию связи
       | 3. Сетевой адаптер генерирует прерывание DMA
       v
[ Очередь ошибок сокета: SO_EE_ORIGIN_ZEROCOPY ]
       |
       | 4. Демон освобождает buf через recvmsg(MSG_ERRQUEUE)
       v
[ Безопасное повторное использование буфера для шифрования ]

1. Закрепление страниц функцией get_user_pages_fast()

При указании флага MSG_ZEROCOPY в системном вызове send(2) ядро Linux не выделяет память под полезную нагрузку. Вместо этого функция get_user_pages_fast() фиксирует физические страницы оперативной памяти приложения. Ядро лишь заносит ссылки на страницы в дескриптор сокетного буфера (skb_shinfo(skb)->frags[]).

Поскольку данные не копируются процессором, ядро обрабатывает исключительно заголовки пакетов (UDP и IP). Сетевой адаптер считывает тело пакета напрямую из оперативной памяти процесса через шину PCIe с помощью механизма scatter-gather DMA.

2. Очередь ошибок сокета и уведомления о завершении

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

#define _GNU_SOURCE
#include <sys/socket.h>
#include <linux/errqueue.h>
#include <netinet/in.h>
#include <stdio.h>
#include <unistd.h>

/* Активация режима Zero-copy на дескрипторе сокета */
int enable_zerocopy(int sock_fd) {
    int one = 1;
    if (setsockopt(sock_fd, SOL_SOCKET, SO_ZEROCOPY, &one, sizeof(one)) < 0) {
        perror("Ошибка setsockopt SO_ZEROCOPY");
        return -1;
    }
    return 0;
}

/* Освобождение буферов после завершения аппаратной передачи DMA */
void reap_zerocopy_completions(int sock_fd) {
    char control[1024];
    struct msghdr msg = {0};
    struct cmsghdr *cmsg;
    struct sock_extended_err *serr;

    msg.msg_control = control;
    msg.msg_controllen = sizeof(control);

    /* Асинхронное чтение уведомлений из очереди ошибок */
    while (recvmsg(sock_fd, &msg, MSG_ERRQUEUE | MSG_DONTWAIT) > 0) {
        for (cmsg = CMSG_FIRSTHDR(&msg); cmsg; cmsg = CMSG_NXTHDR(&msg, cmsg)) {
            if (cmsg->cmsg_level == SOL_IP && cmsg->cmsg_type == IP_RECVERR) {
                serr = (struct sock_extended_err *)CMSG_DATA(cmsg);
                if (serr->ee_origin == SO_EE_ORIGIN_ZEROCOPY) {
                    uint32_t lo = serr->ee_info;  /* Начальный индекс завершения */
                    uint32_t hi = serr->ee_data;  /* Конечный индекс завершения */
                    /* Буферы в диапазоне [lo, hi] готовы к повторному использованию */
                }
            }
        }
    }
}

Ядро присваивает последовательный 32-битный номер каждому пакету, переданному в режиме zero-copy. Когда драйвер адаптера завершает передачу дескриптора и освобождает sk_buff, в очередь ошибок сокета добавляется сообщение с диапазоном подтвержденных номеров (ee_info – ee_data).

Критерии эффективности применения Zero-Copy

Режим Zero-copy не дает выигрыша на пакетах малого размера. Закрепление страниц памяти через get_user_pages_fast() и разбор сообщений из очереди ошибок создают постоянные вычислительные затраты. Инженерам необходимо учитывать порог размера пакета:

Размер полезной нагрузки Классический sendmsg() Передача через MSG_ZEROCOPY Инженерная рекомендация
Малый (< 1 500 байт) Высокая скорость (из кэша CPU) Накладные расходы на фиксацию страниц Использовать sendmsg()
Средний (1 500 – 4 000 байт) Паритетная производительность Паритетная производительность Нейтрально
Большой (4 000 – 16 000 байт) Рост нагрузки на шину памяти Снижение затрат CPU на 30% Рекомендуется к внедрению
Сверхбольшой (> 16 КБ / GSO) Сильные задержки шины памяти Снижение затрат CPU на 55% Критически важная оптимизация

Для сетевых концентраторов VPN, использующих сегментацию UDP GSO (сборку пакетов в супер-блоки от 16 до 64 КБ), MSG_ZEROCOPY обеспечивает колоссальный прирост пропускной способности.

Внедрение в сетевую инфраструктуру VPNRice и протокол RiceGuard

В сетевой архитектуре VPNRice граничные маршрутизаторы Anycast используют MSG_ZEROCOPY на выходных интерфейсах протокола RiceGuard:

[ Криптографический движок RiceGuard ]
       | (Шифрование агрегированных блоков в циклический буфер 64 КБ)
       |
       | 1. sendto(udp_fd, ring_slot, 64KB, MSG_ZEROCOPY, ...)
       v
[ Уровень сокетов ядра Linux ]
       | (Фиксация страниц памяти ring_slot без копирования)
       v
[ Сетевая карта 100 GbE Mellanox / Intel ]
       | (Передача пакетов через PCIe DMA)
       |
       | 2. Уведомление через Error Queue возвращает слот в пул
       v
[ Возврат и повторное использование буфера RiceGuard ]
  1. Кольцевые пулы памяти: RiceGuard предварительно выделяет циклический пул зафиксированных страниц. Зашифрованные туннельные пакеты записываются непосредственно в эти слоты, исключая динамическое выделение памяти.
  2. Синергия UDP GSO и Zero-Copy: RiceGuard объединяет до 45 туннельных дейтаграмм в единый блок GSO размером 64 КБ и отправляет его вызовом MSG_ZEROCOPY. Это сочетает выполнение единственного системного вызова с полным отсутствием дублирования байтов.
  3. Сохранение ресурсов памяти для шифрования: Благодаря освобождению шины RAM от пересылки пакетов, вся пропускная способность памяти достается параллельным вычислениям ChaCha20-Poly1305, позволяя серверам поддерживать поток 40 Гбит/с без потерь пакетов.

Диагностика и проверка состояния в Linux

Для мониторинга активности сокетов в режиме zero-copy на серверах Linux применяются стандартные системные утилиты:

# Проверка счетчиков пакетов и сокетов
cat /proc/net/snmp | grep -E "Udp:|Ip:"

# Анализ состояния очередей и буферов сокетов
ss -u -m -i

Исключение избыточного копирования памяти позволяет современным VPN-платформам достигать физического предела сетевого оборудования, сохраняя вычислительные ресурсы процессора.