хых достаточно на отдельный раздел, и просто квоту поставить

ну, да, можно и квоту на nginx

тоже хорошая мысль

но смотри... вот есть канал 100М... что бы забить 100 гиг, тебе нужно... ну часа 2 с половиной...

да, и что?

причем частенько у проекто не один фронт-сервак

через 3 часа диск забивается, nginx дает - опс, закрывает все твои 1000 соединений, подчищает файлы.... и опа, 100гиг свободны

а это уже вопрос количества соединений

через 3 часа диск забивается, nginx дает - опс, закрывает все твои 1000 соединений, подчищает файлы.... и опа, 100гиг свободны

при этом, nginx, возможно, падает

с чего бы ему падать ;)

потому что не может писать в логи, напрмиер

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

так что уж проще соединения забить, а slow post атака в общем... известна с древних времен

slow post была актуальна с апачем

там сервак ложился с двух десятков запросов ?

да, с квотой на nginx проблема решается, вроде бы

или с отдельным разделом

не, с квотой проблема будет

nginx пишет толстые ответы от бекенда во временные файлы тоже

если диск забит - ответы поцокаются

да, пишет, я ему всегда поднимаю буфера

Да вот не рекомендуют его

Вот в этом случае джоин подходит самый простой и подходящий вариант

скока там дефолт соединений ... 512 на воркер ;) да даже 4к... не большая проблема 4к постов медленных захреначить, имхо ;) но в случае доса это в общем легко все фильтруется числом соединений с ip, а для ддоса есть более действенные решения

Вот в этом случае джоин подходит самый простой и подходящий вариант

уже использовал, спасибо

скока там дефолт соединений ... 512 на воркер ;) да даже 4к... не большая проблема 4к постов медленных захреначить, имхо ;) но в случае доса это в общем легко все фильтруется числом соединений с ip, а для ддоса есть более действенные решения

сделать тысячу-две запросов через пару сотен прокси можно не напрягаясь

беззатратно

запросами по скриптам все ляжет гораздо быстрее в общем

ну хз, по скриптам ответы на запросы легко масштабируются

если с архитектурой нет затыка - запросами к скриптам не положишь

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

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

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

какой-нить udp флуд зафильтровать можно, а вот валидный http запрос зафильровать очень сложно

мегабайтное тело было проблемой раньше, а щас есть лимит на количество элементов массива

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

на них можно поставить маленький размер тела

дефолтный client_max_body_size у эндженикса - 1 мег

и да, лимит на размер тела запроса на уровне ngin отрежет от php все большие запросы, если не нужен upload

а вот с upload получается вопрос

тут большой лимит по скорости, большой размер допустим

в общем отдельный раздел самое оно, можно просто loop файл сделать, подмонтировать и все дела...

по нагрузкам на скрипты есть такой момент: если ограничить регистрацию, запросы на тяжелую обработку получаются только от ограниченного круга лиц

обработка фоток - один из самых ресурсоемких легитимных процессов

тут выделить 200 мб на процесс - нормально

а то и 500

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

если маленько гугльнуть то можно найти интересную картинку https://i.stack.imgur.com/AfxPm.png

фильтры не задействуют базу

в сотмаркете было 700 к уников в сутки стандартно на 1 сервере

запросы никто не считал вообще

там сфинкс, его не положишь, а данные в memcached

тебя как всегда бросает от каких-то виртуалок с дефицитом диска до сотмаркета ;)

почему бросает? это одна ситуация

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

ну давай я тебе дам фронт с 4тер диском, и забивай его ;)

одна ситуация раз ;)

а вот часто ли такие диски на фронтах? в основном они порезаны на виртуалки

там же и процов не 4

так я и говорю - все зависит от архитектуры... и от мониторинга ;) застранный на 100% канал и рост занятого диска - уже тригер в эксплуатацию

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

почти везде ВНЕЗАПНО системы падали из-за отказа дисков ? и в Оракле с круглосуточным дежурством команды админов, и в маленьких проектах

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

прикол с диском в том, что проблема с ним часто приводит к каскаду проблем других подсисем

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

особенно радуют решения на рейд-массивах ?

ну, задавит POST - да, но это остановит upload ото всех пользователей

и что дальше?

если это не фотобанк- они переживут, пока не будет придумано решение ;)

ERROR: S client not available

так вот ? простого решения нет

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

гм, если это не видео - решается установкой вменяемого размера поста

Если картиночка выше верна то вы обсуждаете несуществующую проблему

тело поста даже качаться не начнет пока не будет получен хороший 2xx ответ от подзапроса.

Ну максимум может там оно вкачается в какой-нибудь буфер 64к

подзапрос уже выглядит как решение

аутентификация ничего не решает для сайтов с пользовательским контентом... создаю аккаунт и делаю флуд ;)

решает затруднением регистрации - например, через СМС

а новые номера не бесплатные

аутентификация ничего не решает для сайтов с пользовательским контентом... создаю аккаунт и делаю флуд ;)

Не, есть принципиальная разница между тем что ты в состоянии хоть как-то посчитать и грубо говоря толпой безликих анонимусов.

craigslist когда-то справился со спамом звонками на телефон

даже смс стоит на порядок дешевле номера

атака становится невыгодной

Если есть точка аутентификации - то это уже супер инструмент. У тебя посчитан каждый id пользователя, а дальше можешь запросто выставлять квоты по размеру аттачей на аккаунт, или на сумму для аккаунтов в день, в час, или считывать количество свободного пространства из хранилища - куча путей.

я ж о том же

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

доставят диск - это долго

и не во все сервера можно доставить диск

вменяемые размеры поста - ну, какие? 5 метров для фотки - недостаточно

Если есть точка аутентификации - то это уже супер инструмент. У тебя посчитан каждый id пользователя, а дальше можешь запросто выставлять квоты по размеру аттачей на аккаунт, или на сумму для аккаунтов в день, в час, или считывать количество свободного пространства из хранилища - куча путей.

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

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

ну да

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

Тогда выкидываем сторадж, думаем что временное хранилище это и есть наш сторадж, и сводим задачу к предыдущей.

Ничего не поменялось

А размер там у него 1 гиг или 100000 гиг это просто вопрос коэффициентов

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

google://php parse url

поменялось то, что у тебя нет механизмов понять кто что занимает во временном разделе

google://php parse url

уже проблему решил)

спасибо

гугл? это не самое лучшее решение

не засоряй эфир