@alisaproxy Добрый день. Согласно новым правилам, рекламные тему можно поднимать не чаще чем 1 раз в 48 часов.
Спасибо за понимание.
ProxyShard — ⭐Резидентские⭐ Безлимитные резидентские⭐Датацентр⭐ ISP⭐Мобильные⭐ прокси с поддержкой UDP
-
Безлимитные резидентские прокси: лимит подключений
Условия для использований промокода
Скидка для стандартных резидентских прокси
Пробный период
Контакты
Telegram: @proxyshard
Сайт: proxyshard.com
Онлайн-чат: доступен на сайте для оперативной поддержки -
@sergerdn я ему тоже самое сказал, что nfqueue нормальное решение, уже делали все ок.
Но там походу мазохизм жесткий, нужно на 1 сервере держать 50 млн и больше тцп соединений. Тогда обработка пакетов нужна меньше 1 микросекунды.
В любом случае я могу сказать это первый прокси шоп, где прокси не говно. До хороших им еще далеко конечно, но тут походу впервые админ прокси шопа умеет и знает как работать с линукс, а не просто 3proxy скачал, завернул это говно в упаковку и выкинул со словами жрите.
-
@sergerdn
Nfqueue хорош для тех задач где нужно просто анализировать пакеты с минимальным вмешательством, но когда необходимо постоянное изменение пакетов, то даже при нагрузке в 200-300k RPS ему он становится узким местом из-за очередей, двойного копирования, гонки ядер, кэша и тд, а до бесконечности увеличивать количество очередей не выйдет. Т.к для максимальной стабильности нужно распределять очереди по ядрам, иначе у тебя может быть такое что одно ядро приняло пакет, а очередь у тебя в другом и система будет постоянно вызывать разные ядра, на что тратится приличное количество времени, не говоря о миграции кеша и тд, но даже правильно распределение по ядрам при высокой нагрузке не поможет, т.к ты не можешь сказать системе как распределять пакеты по ядрам и может быть такое что на одном ядре 5к соединений, а на другом 100к.По поводу переписывания стека это просто громкий заголовок, на деле просто переход к модели владением сокетами, то есть внутри прокси клиента свой user-spaсe стек, который формирует нужный пакет и через собственный хендлер отправляет минуя стандартный TCP стек ядра.
При таком подходе нет лишней цепочки ядро->user-spaсe, т.к ядро перестаёт обрабатывать TCP пакеты, оно сразу направляет их в userspace, где уже как угодно можно вертеть пакетами через хендлер не боясь за переполнение из-за двойных буферов, оверхедов и других проблем, которые могут возникнуть из-за nfqueue.В перспективе нагрузка будет до 10kk RPS, т.к в планах на резидентские прокси добавить подмену. Даже сейчас MVP вариант собранный на коленках без оптимизаций держит спокойно 3kk RPS
