@sergerdn
Nfqueue хорош для тех задач где нужно просто анализировать пакеты с минимальным вмешательством, но когда необходимо постоянное изменение пакетов, то даже при нагрузке в 200-300k RPS ему он становится узким местом из-за очередей, двойного копирования, гонки ядер, кэша и тд, а до бесконечности увеличивать количество очередей не выйдет. Т.к для максимальной стабильности нужно распределять очереди по ядрам, иначе у тебя может быть такое что одно ядро приняло пакет, а очередь у тебя в другом и система будет постоянно вызывать разные ядра, на что тратится приличное количество времени, не говоря о миграции кеша и тд, но даже правильно распределение по ядрам при высокой нагрузке не поможет, т.к ты не можешь сказать системе как распределять пакеты по ядрам и может быть такое что на одном ядре 5к соединений, а на другом 100к.
По поводу переписывания стека это просто громкий заголовок, на деле просто переход к модели владением сокетами, то есть внутри прокси клиента свой user-spaсe стек, который формирует нужный пакет и через собственный хендлер отправляет минуя стандартный TCP стек ядра.
При таком подходе нет лишней цепочки ядро->user-spaсe, т.к ядро перестаёт обрабатывать TCP пакеты, оно сразу направляет их в userspace, где уже как угодно можно вертеть пакетами через хендлер не боясь за переполнение из-за двойных буферов, оверхедов и других проблем, которые могут возникнуть из-за nfqueue.
В перспективе нагрузка будет до 10kk RPS, т.к в планах на резидентские прокси добавить подмену. Даже сейчас MVP вариант собранный на коленках без оптимизаций держит спокойно 3kk RPS