XDP и eBPF для высокопроизводительной обработки пакетов

XDP (eXpress Data Path) и eBPF (extended Berkeley Packet Filter) позволяют Linux обрабатывать сетевые пакеты до того, как в процесс вступает обычный сетевой стек ядра. Вместо выделения структур памяти для каждого входящего пакета, XDP перехватывает трафик прямо на уровне драйвера сетевой карты, решает, что с ним делать, и либо отбрасывает, либо пересылает, либо перенаправляет его. В результате обеспечивается обработка миллионов пакетов в секунду на каждое ядро при значительно меньшей нагрузке на ЦП по сравнению с традиционными инструментами, такими как iptables.

Как eBPF и XDP работают вместе

eBPF — это виртуальная машина внутри ядра Linux. Она запускает пользовательский байт-код, который был проверен на безопасность (отсутствие бесконечных циклов, отсутствие несанкционированного доступа к памяти), а затем скомпилирован с помощью JIT в нативные инструкции процессора. Программы имеют ограниченную область действия. Они не могут вызывать произвольные функции ядра, а только набор предопределенных вспомогательных функций для таких задач, как поиск по карте и перенаправление пакетов.

Для управления состоянием eBPF использует карты — хранилища ключей и значений (хэш-таблицы, массивы, LPM-деревья), которые сохраняются при поступлении новых пакетов. Карты доступны для чтения и записи из пользовательского пространства, поэтому вы можете обновлять списки блокировки или правила маршрутизации без перезагрузки программы.

XDP — это точка подключения eBPF. Он подключается к пути приема драйвера сетевой карты до того, как ядро выделяет структуру sk_buff структуру (объект метаданных размером 200–300 байт на пакет, от которого зависит традиционный сетевой стек). Пропуск этого выделения и является источником прироста производительности.

XDP работает в трех режимах:

• Нативный режим: работает внутри драйвера сетевой карты. Наилучшая производительность.
• Режим выгрузки: работает на ASIC сетевой карты. Полностью освобождает ЦП.
• Общий режим: работает после sk_buff выделения памяти. Полезен для тестирования на неподдерживаемом оборудовании, но не дает прироста производительности.

После обработки каждого пакета программа XDP возвращает вердикт:

XDP против iptables: тесты производительности

Цифры говорят сами за себя. iptables Обрабатывает примерно 200 000 пакетов в секунду на ядро. nftables повышает этот показатель до примерно 400 000 пакетов в секунду. XDP в нативном режиме обрабатывает от 10 до 40 миллионов пакетов в секунду на каждое ядро на том же оборудовании.

Причина проста: XDP_DROP требует одной проверки границ и возврата значения. iptables DROP требует sk_buff выделения памяти, обхода цепочки netfilter, поиска в системе отслеживания соединений, самого действия DROP, а затем освобождения памяти. При скорости 100 Гбит/с с пакетами размером 64 байта сервер обрабатывает 148 миллионов пакетов в секунду, что оставляет около 100 наносекунд на каждый пакет. В таких масштабах sk_buff выделение памяти становится узким местом.

Экономия ресурсов ЦП столь же значительна. Перенос списка блокировки из iptables в XDP в одном тесте снизило загрузку ЦП программными прерываниями с 28% до 3% при 1 млн. пакетов в секунду. Освободившиеся ресурсы можно использовать для запуска прикладных процессов, баз данных или виртуальных машин на том же сервере

Защита от DDoS-атак и безопасность

Наиболее эффективным применением XDP в хостинге является защита от DDoS-атак. Поскольку он работает на уровне драйверов, вредоносные пакеты отбрасываются до того, как они достигают сетевого стека ядра. Одно ядро, на котором работает XDP, может отбрасывать 26 миллионов пакетов в секунду.

Cloudflare использует систему на базе XDP под названием L4Drop для защиты от объемных DDoS-атак по крайней мере с 2018 года. Система обрабатывает и отбрасывает трафик атак в контексте XDP, не давая ему достичь уровня приложений. Katran от Meta, открытый балансировщик нагрузки XDP уровня 4, обрабатывает трафик для Facebook и Instagram со скоростью более 10 миллионов пакетов в секунду на ядро.

Для динамической фильтрации eBPF-карты, такие как BPF_MAP_TYPE_LPM_TRIE позволяют управлять списками заблокированных IP-адресов, охватывающими отдельные IP-адреса и подсети CIDR, за один запрос. Обновления происходят из пользовательского пространства в режиме реального времени, перезагрузка программы не требуется. Во время активной атаки вы можете отправлять новые сигнатуры за миллисекунды с помощью bpftool:

bpftool map update id <MAP_ID> key <KEY_VALUE> value <VALUE>

Для обеспечения наблюдаемости eBPF собирает метрики по приложению, IP-адресу и потоку непосредственно из конвейера данных ядра. Контекст xdp_md контекст предоставляет телеметрию, такую как ingress_ifindex и rx_queue_index, что позволяет определить, какой интерфейс или очередь испытывают нагрузку. Для долгосрочного мониторинга такие инструменты, как ebpf_exporter преобразуют необработанные данные карты eBPF в метрики, совместимые с Prometheus, для визуализации в Grafana.

Инструменты, развертывание и требования к оборудованию

Набор инструментов начинается с Clang и LLVM для компиляции ограниченного C в байт-код eBPF. Затем вам понадобится библиотека загрузчика:

• libbpf: стандартная библиотека C для производственного использования. Поддерживает CO-RE (Compile Once, Run Everywhere) для переносимости между ядрами.
• libxdp: специфична для XDP, поддерживает запуск нескольких программ XDP на одном интерфейсе.
• cilium/ebpf: чистая библиотека Go для стеков на основе Go.

Для управления bpftool позволяет просматривать работающие программы и отображать содержимое. xdp-loader (из xdp-tools набора) обрабатывает загрузку и выгрузку. BCC полезен для прототипирования с интерфейсами на Python/Lua, но libbpf с CO-RE — лучший выбор для производства.

Включите JIT-компилятор BPF перед развертыванием:

sysctl -w net.core.bpf_jit_enable=1

Для обновлений без простоев используйте флаг XDP_FLAGS_REPLACE флаг для атомарной замены запущенной программы. Закрепите карты в /sys/fs/bpf/ , чтобы они сохранялись после завершения работы загрузчика.

Совместимость с аппаратным обеспечением и ядром

XDP был введен в ядре версии 4.8, но для полного набора функций рекомендуется версия 5.x или более поздняя. Проверьте свое ядро с помощью uname -r и убедитесь, что файловая система BPF существует в /sys/fs/bpf/.

Драйвер вашей сетевой карты определяет, какие функции XDP доступны:

Проверьте драйвер с помощью ethtool -i <interface>. Если нативный режим не поддерживается, система переключается в общий режим, который запускается после sk_buff выделения памяти и не дает никакого прироста производительности.

Отключите GRO и LRO перед подключением программы XDP, так как они конфликтуют:

ethtool -K <iface> gro off lro off

Стандартный XDP требует, чтобы пакеты помещались на одной странице памяти размером 4 096 байт. На i40e и ice драйверах ограничение MTU для x86 составляет 3 046 байт.

Начало работы с XDP

Начните с оценки вашей среды. Запустите uname -r , чтобы убедиться, что ядро версии 4.8+ (предпочтительно 5.x), и ethtool -i <interface> , чтобы проверить наличие поддержки нативного драйвера XDP.

Начните с наблюдаемости, а не с принудительного применения. Используйте карты eBPF для классификации и подсчета трафика, чтобы получить базовые показатели нормальной активности. Как только вы поймете свои модели трафика, переходите к принудительному применению: сначала тестируйте в xdpgeneric режиме, а затем переключитесь на xdpdrv (нативный) для рабочей среды.

Помните, что XDP обрабатывает фильтрацию на уровне пакетов, а не сырую пропускную способность. Для крупномасштабных атак со скоростью 100 Гбит/с сочетайте его с инфраструктурой на баре-металле и BGP FlowSpec, чтобы управлять входящим трафиком до того, как он достигнет сервера.

Если вы выполняете рабочие нагрузки с высоким трафиком, требующие быстрой фильтрации пакетов, выделенные серверы FDC предоставляют «bare-metal»-основу для максимально эффективного использования XDP.