Сетевой стек тормозит не «сам по себе» — узкое место обычно видно в одном из слоёв

Сетевой стек тормозит не «сам по себе» — узкое место обычно видно в одном из слоёв

Оптимизация начинается не с тюнинга «на всякий случай», а с разложения пути пакета по этапам: приём IRQ, обработка очередей, копирование буферов, планировщик, сокеты, прикладной код. Если нагрузка растёт, а latency скачет, сначала смотрят не на линк, а на распределение времени по этим этапам.

Практически полезный минимум проверки:
— выравнивание прерываний и очередей по ядрам;
— размер ring buffer и очередей на стороне NIC;
— offload-функции: checksum, TSO/GSO/GRO;
— backlog, conntrack и лимиты сокетов;
— saturation по softirq и context switch.

Если пакетный поток упирается в CPU, часто помогает не «ускорение», а снижение количества операций на пакет: батчинг, уменьшение копирований, более крупные буферы при стабильном RTT, аккуратная настройка affinity. Для UDP и высокочастотных TCP-потоков особенно важно убрать лишнюю конкуренцию за ядра и память. Данные подтверждают следующую корреляцию: чем меньше межъядерных миграций и копирований, тем ровнее p99.

Отдельно стоит проверять MTU, фрагментацию и очереди на выходе: перегрузка egress нередко выглядит как «медленная сеть», хотя фактически это локальный шедулер или буферизация.

Рекомендуется обращать внимание на метрики drops, retransmits, softirq time и run queue. Если они растут вместе, сначала лечат путь обработки пакета, а уже потом — сам канал.