<br><br><div class="gmail_quote">16 июня 2009 г. 18:13 пользователь Sergej Kandyla <span dir="ltr"><<a href="mailto:sk.paix@gmail.com">sk.paix@gmail.com</a>></span> написал:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Защита от перегрузок это отдельная песня.<br>
Я думаю, стоит определиться с характером запросов и выделять агрессивных клиентов.<br>
Желательно банить таких на основе фаервольных фильтров --connlimit-above 15 -j REJECT || source-track rule (pf)<br>
Возможно, conn_limit для $remote_addr$http_user_agent, чтобы кто-то избыточно агресивно не нагружал бекенд</blockquote><div><br>верно но не всегда применимо, например в случае использования централизованных http и WAP шлюзов <br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Против мелко-средних DDoS, которые не забивают полностью канал, ничего лучше скриптов вроде еще не придумали. Т.е. получается мониторинг + трезвый админ + скрипты. Ботов в фаерволл.<br>
<br>
Все остальное будут условно нормальные юзера.</blockquote><div><br>наша задача как раз начинается здесь<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
При этом, nginx получает максимально быстро ответ от бекенда и уже сам обслуживает медленных клиентов.<br>
Если число ликвидных пользователей превысит число свободных чаилдов бекенда (апача), то вы будете получать ваше<div class="im"><br>
error_page 503 =200 /sorry.html;</div></blockquote><div><br>Нет! будет таймаут. Пожалуйста, еще раз перечитайте тред.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Чем проще - тем лучше!<br>
</blockquote></div><br>ну это несомненно :)<br>