И что?

ну то что апач ложится быстро

Ну - и nginx тоже

пока память не кончитися?

Да при чем-тут память-то?

Ограничение на файловые дескрипторы

ну nginx же воркеров плодит

ну nginx же воркеров плодит

Нет

ага. потом кончатся пиды, но это можно увеличить. так и представляется. 512к воркеров, у каждого из которых по 65к коннектов.

щас кто-нибудь тут ляпнет про "кококо, в линуксе максимум можно открыть 65к коннектов, потому что портов ограниченное число".

щас кто-нибудь тут ляпнет про "кококо, в линуксе максимум можно открыть 65к коннектов, потому что портов ограниченное число".

Чо? O_O

раз в полгода стабильно слышу такие бредни.

Но какая связь?

мм. попробую объяснить. некоторые люди считают, что линукс может установить максимум 65k tcp-сессий, потому что число портов ограничено. почему - не знаю. может, это модно. из этого люди делают вывод, что нджинкс не сможет обслуживать больше, чем 65к клиентов одновременно. поэтому увеличивать число воркеров и worker_connections так, чтобы их произведение превысило 65к - бессмысленно. я просто раза три уже участвовал в срачике с такими аргументами.

почему на весь домен CloudFlare не привязан - там в бесплатном варианте ограничения (айпишники посетителей сайта не отдаются нормальные, кажется)

отдаются

отдаются

может, я не так понял "True-Client-IP Header Cloudflare will send the end user's IP address in the True-Client-IP header Requires an Enterprise plan"

гм, что-то не то.

опция требует платного тарифа, а без неё будут Ip'шники самого сервиса

как я понял

https://support.cloudflare.com/hc/en-us/articles/200170706-How-do-I-restore-original-visitor-IP-with-Nginx-

странно, зачем они тогда эту опцию сделали (True-Client-IP Header)

(вкладка Network там в админке)

тру-клиент-айпи упоминается в акамаи

клоудфлер вроде не пользует такие заголовки

то есть эти заголовки могут быть использованы для интеграции с каким-нибудь корпоративным софтом под акамай?

ну у меня есть пара крупных сайтов на кф, все бесплатно, ип доставляют

в этом смысл?

This feature adds a third header, True-Client-IP, for compatibility with another vendor.

интересно, как много людей подумали как и я, что реальные ипы только на платных тарифах и только ради этого купили у них платный тариф

тоесть если ты несколько цдн используешь, и чтобы не делать кучу настроек и костылей, ты просто вносишь айпишники прокси кф и акамаи в список и настраиваешь получения айпи из этого заголовка

ну там в хелпе все отлично расписано

а где оно лежит все? в амазоне и т.д.?

кстати, там раньше была проблема с блокировкой ипов в России, после появления CF в России они решили же проблему?

или чем-то еще облачном?

что все лежит?

вот как раз на такие случаи и удобно только media в CF ставить

не решили, все еще блокирует ркн их )

что все лежит?

я у саши, про сайты его

если очень продвинутый проект - то там будет сначала какой-нибудь сервис типа CloudFlare, потом региональный балансировщик, потом собственно сами хранилища данных

я экспериментирую пока)

думаю, что если сделать амазон + CF, то будет дешево

потому что с амазона будут запросы только к CF

не, я не об этом

кф кстати знатно траффик экономит

ну и амазон даёт этот API, можно по API файлы загонять из Django туда на амазон

удобно

https://s.esteq.net/airseemtyi.png

из этого умного кэша джанги?

удобно

см. личку

ну вот мне и кажется, что по соотношению качество/цена CF + S3 норм выбор получается

Любой веб-сервер подвержен

Нет

Ограничение на файловые дескрипторы

Нет

мм. попробую объяснить. некоторые люди считают, что линукс может установить максимум 65k tcp-сессий, потому что число портов ограничено. почему - не знаю. может, это модно. из этого люди делают вывод, что нджинкс не сможет обслуживать больше, чем 65к клиентов одновременно. поэтому увеличивать число воркеров и worker_connections так, чтобы их произведение превысило 65к - бессмысленно. я просто раза три уже участвовал в срачике с такими аргументами.

Огонь! Где такие дебилы водятся?

я думаю, тут можно найти.

Просто если человек такое говорит - это как на лбу написать "я профнепригоден"

Нет

раскрой тезис.

задача: есть nginx, 10 воркеров, worker_connections 10000. Подключается 100к slow-get клиентов. приходит легитимный клиент. что происходит?

задача: есть nginx, 10 воркеров, worker_connections 10000. Подключается 100к slow-get клиентов. приходит легитимный клиент. что происходит?

Ну будет в бэклоге одного из сокетов болтаться

сколько?

и что будет видеть клиент в это время?

и не наступил ли в этот момент DoS?

и что будет видеть клиент в это время?

Ничего

Я с таким же успехом мог выставить 1 в worker_connections

Это не про slowloris

постой, в описанной ситуации slow-get устроил нам недоступность сервиса для нормальных пользователей.

Тут misconfiguration, но никак не slowloris

ERROR: S client not available

ок. как правильно? :)

постой, в описанной ситуации slow-get устроил нам недоступность сервиса для нормальных пользователей.

Да нету тут чтения

Я с таким же успехом могу на scapy сделать честный хендшейк и забыть

как правильно сконфигурировать nginx, чтобы он не входил в DoS при описанном векторе атаки?

Смотри

хм, я немного неправильно наезжаю. ты не утверждал, что nginx не подвержен.

Ты можешь на своем nginx выкрутить лимиты хоть в 1млн на воркера

И запустить 64 воркера

Но задосить я смогу даже такой конфиг без 64 млн коннектов

И в этом смысл slow read

хз, имхо, slow read - это просто техника, чтобы по таймауту не обрубили. сама атака в любом случае на исчерпание некоторого ресурса. в случае с апачом на обычном сервере почти наверняка кончится память. в случае с nginx - вероятно другой ресурс. но он все равно кончится.

Просто у некоторых вебсерверов это решается опциями конфига, а у некоторых просто по дизайну жопа

хз, имхо, slow read - это просто техника, чтобы по таймауту не обрубили. сама атака в любом случае на исчерпание некоторого ресурса. в случае с апачом на обычном сервере почти наверняка кончится память. в случае с nginx - вероятно другой ресурс. но он все равно кончится.

Тоже память в случае с nginx

Тоже память в случае с nginx

сомневаюсь. на что она расходуется?

nginx тратит несколько десятков байт памяти на коннект

сомневаюсь. на что она расходуется?

SO_SNDBUF

И жопа в том, что это память ядра

Идея какая: найти файл больше чем so_sndbuf и попросить

А потом по 1 байту дергать, чтобы соединение считалось живым

Если админ ещё выставил его в 512кб по глупости, то один коннект будет жрать эти самые 512кб памяти ядра.

я не могу быть уверен, но у меня есть серьезное подозрение на два пункта 1) sendfile люто меняет картину. 2) nginx не забрасывает в память ядра мегабайты. мне щас нечем подтвердить, потому что я сварщик ненастоящий, но подозрение такое.

я не могу быть уверен, но у меня есть серьезное подозрение на два пункта 1) sendfile люто меняет картину. 2) nginx не забрасывает в память ядра мегабайты. мне щас нечем подтвердить, потому что я сварщик ненастоящий, но подозрение такое.

Нет, сендфайл не меняет картину

так постой

лол

так подвержен нджинкс slow-read или нет? :)))

а то похоже ты доказываешь мне, что подвержен

так подвержен нджинкс slow-read или нет? :)))

От конфига завит. В дефолте - да. Как только выставишь рейт-лимиты - нет :)

вектор, который я тебе описал со слоугетом, ты видимо не считаешь за слоугет? )

вектор, который я тебе описал со слоугетом, ты видимо не считаешь за слоугет? )

Не считаю, потому что это тупо misconfiguration

ну выкрутил ты цифры. атака тоже выкрутила.

Ну смотри, в случае с prefork типа того же апача тебе никакие крутилки не помогут

с тезисом, что нджинкс относительно лучше справляется по сравнению с апачом тут, мне кажется, никто не спорил.