Боротися з цим можна по різному, хтось використовує скрипти на подобу htb.init. хтось пише скрипти шейпінгу самостійно і ділиться вдалим досвідом на Хабре. а деякі і зовсім використовують PHP для обмеження швидкості віддачі файлів. Тільки уявіть собі, яким буде оверхед і витрата пам'яті, при використанні PHP в подібних цілях.
На даний момент Nginx не вміє обмежувати швидкість для IP і робить це тільки в рамках окремих сесій. Що це означає? Якщо адміністратор встановив в конфіги обмеження швидкості в 100 Кбайт / сек, то створивши 10 з'єднань з сервером можна отримати швидкість в 1 Мбайт / сек, що ніяк не вписується в плани адміністратора. Досягти бажаного засобами самого Nginx можна лише встановивши ліміт, наприклад
Але, як виявилося, не все так похмуро і вихід із ситуації є. Це простий маленький модуль від yaoweibin під назвою nginx_limit_speed_module. Давайте розглянемо як працює цей модуль:
Для складання Nginx з цим чудовим модулем досить додати в параметри ./configure такий запис:
--add-module = / шлях до папки з модулем / nginx_limit_speed_module
/ Configure --prefix = / etc / nginx --sbin-path = / usr / sbin / nginx --conf-path = / etc / nginx / nginx.conf --error-log-path = / var / log / nginx /error.log --http-log-path = / var / log / nginx / access.log --pid-path = / var / run / nginx.pid --lock-path = / var / run / nginx.lock --http-client-body-temp-path = / var / cache / nginx / client_temp --http-proxy-temp-path = / var / cache / nginx / proxy_temp --http-fastcgi-temp-path = / var / cache / nginx / fastcgi_temp --http-uwsgi-temp-path = / var / cache / nginx / uwsgi_temp --http-scgi-temp-path = / var / cache / nginx / scgi_temp --user = nginx --group = nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with -http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-file-aio --with-ipv6 --with-http_spdy_module --add-module = / root / nginx_limit_speed_module --with-cc- opt = '- O2 -g -pipe -Wp, -D_FORTIFY_SOURCE = 2 -fexceptions -fstack-protector --param = ssp-buffer-size = 4 -m64 -mtune = generic '
Докладно зупинятися на складанні Nginx я не буду, на цьому тему вже написано чимало статей. В якості короткого керівництва по збірці можна використовувати цю інструкцію.
Це був натяк на те, що в нормальних Linux-дистрибутивах в цьому столітті зазвичай потрібно дуже мало робити руками. І тому існує маса користувачів, які до ./configure можуть відноситься нервово :)
Більш того. Сьогодні вважається хорошим тоном на бойовому сервері не тримати девелоперскую підсистему. Так що ./configure на продакшн може просто не спрацювати :)
Про source-based дистрибутиви чули? При належному умінні на них ставляться відмінні інформаційні системи.
А ще бувають такі люди розробники. І буває у них теж Linux.
До того ж воно open source, що ніби натякає. Що іноді буває компіляція з початкових кодів.
Я до того що це ні разу не застаріла і застосовується багатьма людьми команда.
Це не кажучи вже про те, що я саме розробник, і Linux до останнього року був основною системою :) Тільки зараз, у міру остаточного згасання Gentoo, на робочому столі пересаджуюся на Windows.
Я до того що це ні разу не застаріла і застосовується багатьма людьми команда.
Ну я для нерозведений холівара пропущу спірне шматок про згасання Гент.
І що заважає людині, що володіє достатніми навичками, щоб пробити Ваш сервер до отримання локального доступу залити туди то саме складальне оточення?
А більш досвідчені товариші поміняли опції в налаштуваннях збірки свого пакета nginx'а в CI, звідки він потрапляє на свій власний мірор, звідки мирно розповзається yum / apt'амі по серверам.
Мене давно займає питання: чому все так люблять nginx (який, на мою думку, злегка кривуватий і злегка заморочені) і при цьому мало хто знає про lighttpd, який вміє практично те ж саме (і навіть більше), тільки за столом і логічніше?
Більш того, більшість серверів, які я піднімаю з lighttpd, і зовсім не потребують apache, бо lighttpd має на борту простенький, але цілком придатний менеджер процесів fastcgi.
І так, обмежувати швидкість по IP він теж вміє.
у nginx скажена продуктивність при мінімумі споживаних ресурсів
За моїй практиці можу сказати, що якщо lighttpd і отстатёт по продуктивності, то дуже незначно. При цьому відмова від apache теж дає певний виграш.
Так, відмова від apache не дається безкоштовно (доводиться, наприклад, транслювати .htaccess-и в конфігураційні директиви lighttpd), але коли потрібно зробити швидкий хостинг для пари сайтів на заздалегідь відомих двигунах, на це цілком можна піти.
Дивіться, Nginx лімітує швидкість для кожного запиту приблизно так (мої припущення):
r-> main-> limit_rate = $ limit_rate; (А саме $ limit_rate вказаний в конфіги запитаного location або хоста)
Модуль представлений в статті так само лімітує швидкість кожного запиту (з'єднання), але трохи інакше, ось витяг прямо з коду модуля:
speed = lscf-> speed; r-> main-> limit_rate = speed / ls-> conn; (А саме limit_speed вказаний для зони в конфіги запитаного location або хоста)
тобто швидкість ділиться на кількість поточних з'єднань з сервером. Як бачите все гранично просто.
Більш того, оскільки використовуються зони, то замість $ binary_remote_addr можна використовувати все що завгодно для створення потрібної зони обмежень. Можна встановити ліміти на домен, країну (geoip), та хоч на ім'я браузера або зарізати швидкість для Googlebot.
Чи правильно я розумію, що якщо ви виставили сумарний ліміт на швидкість 100k і, по доброті душевній, дозволили робити до 100 соедіеній, то у вас по кожному з'єднанню буде жорсткий ліміт 1k. Відповідно якщо користувач буде використовувати лише одне з'єднання, то він все одно буде качати на швидкості лише 1 до, а не 100к. Або ж ls-> conn - це _текущее_ кількість з'єднань?
да, це мене теж збентежило :)
хоча ні, звичайно ж це поточна кількість з'єднань, але все одно алгоритм якийсь занадто прямолінійний.
Якщо ми робимо кілька різних запитів - то обмеження завжди буде менше, тому що з'єднання не використовується і повністю
Таке відчуття, що крім особистих знакоий Сисоєва, ніхто в nginx додати нічого не може. Ну або ймовірність цього дуже маленька.
Форкніте nginx і підтримуйте свій nginx-ng. Якщо зможете, звичайно.
З точки зору адміністратора можу сказати, що переважна більшість сторонніх модулів написано як курка лапою. Сегфолти, витікає пам'ять, незрозуміло звідки беруться гальма та інші смаколики дістануться вам безкоштовно.
Nginx не є веб-сервером загального призначення, багатьох фич в ньому немає, тому що це не його завдання. Ніхто ж не плаче, що в ньому немає mod_php.
І все ж - як бути користувачам за NAT-ом після установки даного модуля на сервері? Один клієнт заб'є собою весь канал і іншим на сервер не пробитися?
Скільки завгодно причин можна придумати - тонкий канал (дешева або взагалі безкоштовна VPS наприклад)
тонкий канал - це по-любому погано, ну буде у 1000 користувачів завантаження по 1кб \ сек, вони взагалі все плюнуть і обірвуть закачування ...
навала GoogleBot, YandexBot і інших сканерів або павуків
якийсь Delirium tremens прям ...
ddos
це навряд-чи ... за будь-якої більш-менш серйозної атаці вам доведеться виставити такий низький ліміт на ІП вашим модулем, що на сайт буде взагалі нікому не прорватися.
цей модуль обмежує кожне з'єднання, тобто у першого користувача не буде переваг перед наступними
З приводу тонкого каналу - припустимо у мене Гбод на сервері, хтось Вася має гігабітний лінк і забиває мені весь канал ...
Я розраховую на обслуговування мінімального пулу в. скажімо для рівного рахунку, 256 клієнтів ... ставлю обмеження на 4Мбод і канал буде забитий тільки при одночасному прихід більш 256кліентов ...
Загалом, логіка зразкова така ...