Изменение limit_rate "на ходу" без обрыва подключений

[Andrey N. Oktyabrski]

Eugene wrote:
> Вобщем да. Задача стоит именно эта.
> Мне кажется, что более низкоуровнеыве средства значительно сильнее 
> напрягают железо.
> Если просто залить в фаерфол весь список то при большом трафике он 
> начинает активно жрать процессор.
> В общем это неудивительно - каждый пакет приходится проверять на 
> соответствие списку сетей, а работа это не маленькая, к тому же фаервол 
> "крутится" в ядре как привилегированный процесс.
> Я хотел как раз для облегчения нагрузки вынести проверку на уровень 
> приложения, чтобы nginx при подключении сам решал,
> что вот это соединение с такми-то ограничением  и дальше уже работал с 
> ним, не делая каждый раз проверку.
Не все пакетные фильтры одинаково полезны :-) Поставьте отдельн(ую|ые) 
машинку на openbsd, которая будет разруливать ограничения по скорости и 
больше ничего делать не будет. У неё пакетный фильтр работает с большими 
таблицами адресов/сетей очень хорошо. А ALTQ очень эффективно 
придушивает именно исходящий трафик. Эту машинку можно даже бездисковой 
сделать.

>> Так вам на сервере в целом надо обеспечить непревышение зарубежным 
>> трафиком русского?
>> Для этого более низкоуровневые средства надо использовать. На Linux
>> надо собрать ядро с патчем ipsets, залить в него базу сетей, сделать
>> чтобы iptables маркировал соединения, а tc - ограничивал скорость. На
>> FreeBSD как-то тоже с помощью dummynet можно (хотя насколько я
>> понимаю, классификация пакетов при большом количестве подсетей может
>> потреблять много процессора).