![[#]](themes/ubertechno/id.png)
![[Добавить метку]](themes/ubertechno/filter.png)
![[Редактировать]](themes/ubertechno/edit.png)
Что nginx имеет в виду под connections/requests?
Соединения (conn) вроде бы это то, что выдается на странице статуса или там netstat'ом. От чего зависит их количество? Это устанавливается в браузере параметром "max connections per server"? Обычно этих соединений не более 8 на одного клиента, но иногда бывает и за двадцать (не говоря уж про очевидные атаки, которые я и пытаюсь предотвратит). Если выставить в конфигурации лимит до 9 соединений на одну айпишку, то согласно документации остальные соединения получат 503. Как это выглядит на деле? Если у пользователя в браузере стоит большее количество этих самых соединений, то половина страницы не загрузится что-ли?
Далее, что такое requests и где их вообще смотреть? На странице статуса есть "handled requests", но это же количество запросов за определенное время (в данном случае, за все время работы энджинкса), так? А лимиты то выставляются на количество одновременных запросов, если я правильно понимаю. Что это вообще значит? И там ещё есть rate, это как раз количество запросов за время, да? Где можно посмотреть текущие статы во время реальной нагрузки, чтобы прикинуть, какие лимиты выставлять? В одном руководстве предлагают ограничивать 15 запросов в минуту, в другом 200 в секунду, нифига не понятно.
Альзо, да, я не жду ответов на все эти вопросы, куда лучше будет, если кто-нибудь подкинет ссылку на готовую статью, где все это разложено по полочкам. А то документация у энджинса явно не для простых смертных написана.
anonymous(*) (2012-05-07 12:06:56)
Opera/9.80 (X11; Linux i686; U; en) Presto/2.10.229 Version/11.60
Re:Что nginx имеет в виду под connections/requests?
Не знаю как там в нгинксе, но если у тебя вызывают вопросы общеупотребительные термины, то лучше разобраться с ними сперва... Пусть товарищи меня поправят если где навру:
Начну с экскурса в HTTP. Есть несколько стандартов этого протокола. До HTTP 1.1 работа с сервером заключается в том, что бровсер устанавливает _соединение_ с сервером и посылает есму запрос (_реквест_) некоторого ресурса, который потребен бровсеру. В простейшем случае запрос выглядит как "GET имя_файла.html" с парой переоводов строки. В ответ на такой запрос сервер находит требуемый ресурс и отдаёт его бровсеру либо, если ресурс не может быть одан по какой-либо причине, сообщает эту причину с соответствующим кодом ошибки. Ключевой момент: после передачи ответа сервер разрывает соединение.
В HTTP 1.1 если оба участника коммуникации - и бровсер и сервер - поддерживают данный протокол, между ними может быть временно установлено keep-alive соединение. То есть после отправки ответа бровсеру сервер не будет сразу же разрывать соединение и бровсер сможет запросить других ресурсов через то же соединение.
В HTTP 1.1 сделано так потому, что обычный сеанс обмена выглядит так, что бровсер запрашивает страничку с сервера, а потом, распарсив страничку, начинает запрашивать с того же сервера другие ресурсы, используемые в страничке - таблицы стилей, скрипты, картинки. Открытие нового соединения - медленная процедура, поэтому и используют keep-alive чтобы не не делать этого по многу раз раз на каждый запрос. Количество одновременно открытых keep-alive соединений на сервере должно ограничиваться в неких разумных пределах.
Для ускорения загрузки страницы бровсер может использовать несколько подключений к серверу. Если он обнаружил, что страничке нужно несколько картинок, стайл-шитов, скриптов и т.п. Он не обязательно будет тащить их все последовательно через единственное keep-alive соединение. Он может попытаться создать несколько соединений и затащить все необходимые ресурсы параллельными потоками. С протоколами до HTTP 1.1 это был единственный способ ускорить загрузку страниц, а в 1.1 наверное бровсер может действовать умнее, но ему никто не запрещает установить несколько соединений и в этом случае. Кроме того, некоторые пользователи держат открытыми в бровсере множество страниц и по этой причине при запуске бровсера тот может ломануться обновить сожержимое этих страниц для восстановления сессии (обычно для тех ресурсов, для которых сервером не была установлена дата устаревания) что может привести к созданию огромного количества одновременных подключений что может быть распознано механизмами защиты как DOS-атака не только на стороне сервера, но даже и на клиенском файрволле, поэтому для клиента также есть смысл ограничивать число подключений в бровсере. Ajax-приложения, время от времени обращающиеся на сервер, так же приводят к созданию соединений.
handled requests - запросы, ответы на которые сервер уже послал. Not handled requests - запросы, которые ещё не были обработаны сервером.
rate - это частота. Если речт про request rate - это количество запросов за единицу времени.
Если речь идёт об ограничении числа подключений с конкретного IP - надо учитывать что из-за NAT'а могут приходить запросы от разных пользователей, но IP у них будет один и тот же. Например, я сильно подозреваю, что livejournal одно время пытался защищаться от DOS-атак подобным образом, при том количество запросов было ограничено настолько, чито уже чтение ЖЖ из дома двумя пользователями иногда приводило к срабатыванию защиты и перенаправлению запросов куда-то нахуй (тут на форуме вроде были сообщения об этом).
Ну и бороться с атаками наверное нужно всё-таки не на стороне веб-сервера, а используя специализированное ПО на роутере. Хотя бы потому, что веб-серверов может на одной машине может крутиться много и коварный враг может попытаться загасить машину распределяя запросы по разным серверам и сервисам, запущенным на этой машине.