|
Это малость
более кровожадно, чем следовало бы. По-настоящему актуальная задача - ограничить
число АКТИВНЫХ соединений. К примеру, нужно обеспечить каждого клиента одним
соединением с бэкэндом. При этом не важно, сколько соединений у него к статике и
уж тем более не нужно давать отлуп для второго и прочих соединений. Просто
каждому клиенту выделить один активный сокет, а остальные в режиме ожидания, как
делает апач при исчерпании maxclients и, видимо, nginx при загруженности всех
воркеров. Но сейчас очередь обработки живет своей жизнью, а вот в ней бы было
здорово порядок наводить - кого-то всегда ставить в конец, кому-то позволять
захватывать несколько воркеров, а кому-то - только один. Ну и
т.д.
Сейчас такую
задачу решить в принципе невозможно, приходится делать что-то подобное, ставя
между фронтэндом и бэкэндом на разных потоках еще апач с maxclients 5, скажем.
По крайней мере можно гарантировать, что на бэкэнд не посыслятся подключения с
низкоприоритетного потока и этот поток не сожрет все ресурсы. Но даже
такое нагромождение требуемого эффекта не дает - один герой может сожрать
весь поток, причем даже без злого умысла. Уж не говоря про накладные расходы,
геморой по администрированию и устойчивость.
Вообще,
гибкий инструмент с регуляцией числа http-соединений нужен и никакие
IPTABLES с reject тут не помогут. И то, что тема ограничения числа соединений
всплывает с завидным постоянством - тому подтверждение. Десятое
подключение можно отреджектить, но второе же так убивать нельзя. Я бы
даже на четвертое руку не поднял.
D&C GameMaster
www.the-game.ru
Для iptable можна использовать:
iptables -A INPUT-p tcp --dport 80 -m iplimit
--iplimit-above 10 -j REJECT
|
