Helyes "sebességhatár nginxben
Ezt különböző módon kezelheti, valaki olyan scripteket használ, mint a htb.init. Valaki önállóan alakítja a forgatókönyvet, és megosztja a Habr sikeres tapasztalatait. és néhányan a PHP-t is használják a feltöltési fájlok sebességének korlátozására. Csak képzeljük el, milyen lesz a felső és a memóriafelhasználás, ha a PHP-t hasonló célokra használjuk.
Abban a pillanatban, a Nginx nem tudja, hogyan korlátozza a sebességet az IP számára, és csak külön ülésen. Mit jelent ez? Ha a rendszergazda beállította a sebességkorlátot 100 KB / sec-ra a konfigurációban, akkor 10 kiszolgálóval történő kapcsolat létrehozása 1 MB / másodperc sebességet eredményezhet, ami nem illeszkedik a rendszergazda terveihez. A Nginx kívánt eszközeit elérheti, például csak korlátozással
De, mint kiderült, nem minden olyan komor, és van egy kiút a helyzetből. Ez egy egyszerű kis modul a yaoweibin nevű nginx_limit_speed_module. Nézzük meg, hogyan működik ez a modul:
Ha ezt a csodálatos modult fel szeretné építeni, akkor add meg a következő bejegyzést a ./configure paraméterekhez:
--add-module = / elérési út a modul mappához / nginx_limit_speed_module
/ Konfigurálása --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-kliens-test-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-fájl-AIO --with-IPv6 --with-http_spdy_module --add-modul = / root / nginx_limit_speed_module --with-CC- opt = '- O2-g -pipe -Wp, -D_FORTIFY_SOURCE = 2 -fexceptions -fstack-védő --param = SSP-puffer-size = 4 -m64 -mtune = generikus '
Nem foglalkozom részletesen a Nginx gyülekezettel, sok cikket írt már e témában. Az összeszerelés rövid útmutatójaként ezt az utasítást használhatja.
Ez arra utal, hogy a normál Linux disztribúciók ebben az évszázadban általában nagyon keveset kell tennie a kezével. És ezért vannak olyanok, akik idegesek lehetnek ./configure :)
Ennél több. Napjainkban a harci szervernek jó hangot ad, hogy nem tartja meg a fejlesztési alrendszert. Így ./configure egy termelés egyszerűen nem működik :)
Hallott már a forrásalapú terjesztésekről? Jól képzett, kiváló információs rendszerek kerülnek rájuk.
És még mindig vannak ilyen emberek fejlesztők. És van Linux is.
Ezenkívül nyílt forráskód, amely úgy tűnik, hogy egy tipp. Ez néha egy forrásból készült összeállítás.
Úgy értem, hogy soha nem elavult és sok ember használja a csapatot.
Ez nem említi azt a tényt, hogy én vagyok a fejlesztő, és a Linux az elmúlt évig volt a fő rendszer :) Csak most, ahogy a Gentoo elhalványul, átállok a Windows asztalra.
Úgy értem, hogy soha nem elavult és sok ember használja a csapatot.
Nos, a holivár felfedezésére vagyok, egy ellentmondásos darabot kihagyok a pogányok kihalásáról.
És mi akadályozza meg a megfelelő kapacitással rendelkező személy számára a szerver megütését, mielőtt helyi hozzáférést kap, és ugyanazon összeszerelési környezetbe kerül?
És a tapasztaltabb elvtársak megváltoztatták az opciókat a csomagolás nginx'a csomagjának építéséhez a CI-ben, ahol a saját Mirrorjához jut, ahol békésen kúszik yum / apt'ami a szerveren.
Azt már régóta egy kérdés: miért annyira szereti nginx tudott (ami véleményem, enyhén görbe és kissé megzavarja), és ugyanabban az időben, kevés ember tud a lighttpd, amely képes gyakorlatilag azonos (vagy még több), csak a közvetlen és logikus?
Ráadásul a legtöbb olyan kiszolgáló, amelyet a lighttpd segítségével emelsz, egyáltalán nem kell apache-nak lennie, mert a lighttpd egy egyszerű, de nagyon alkalmas fastcgi folyamatkezelővel rendelkezik.
És igen, ő is korlátozhatja a sebességet IP-n keresztül.
nginx furcsa teljesítmény és minimálisan elfogyasztott erőforrások
Az én gyakorlatomban azt mondhatom, hogy ha a lighttpd lemarad a teljesítményben, akkor nagyon elhanyagolható. Ebben az esetben az apache elutasítása szintén bizonyos előnyt jelent.
Igen, elutasította a apache nem adnak ingyen (ez szükséges, például sugárzott .htaccess-k lighttpd konfigurációs direktíva), de ha meg kell tenni a gyors hosting egy pár helyek korábban ismert motorok, ez elég lehet menni.
Lásd, Nginx korlátozza a sebességet minden egyes kérelem nagyjából így (az én találgatás):
r-> main-> limit_rate = $ limit_rate; (vagyis a megadott hely vagy állomás konfigurációjában meghatározott $ limit_rate)
A cikkben bemutatott modul szintén korlátozza az egyes kérelmek (kapcsolat) sebességét, de kissé eltérően, itt egy kivonat közvetlenül a modulkódból:
sebesség = lscf-> sebesség; r-> main-> limit_rate = sebesség / ls-> conn; (nevezetesen a megadott helyre vagy állomáson beállított zónára meghatározott limit_speed)
azaz a sebességet a kiszolgálóval meglévő aktuális kapcsolatok száma osztja el. Amint látod, mindent rendkívül egyszerű.
Ráadásul, mivel zónákat használnak, a $ binary_remote_addr helyett bármit használhat a korlátozások szükséges zónájának létrehozásához. Beállíthat korlátozásokat a domainre, országra (geoip), igen akár a böngésző nevére vagy a Googlebot sebességének levágására.
Megfelelően értem, hogy ha teljes limitet határoznod meg a 100k sebességre, és a lélek kedvességével 100 összekapcsolást engedélyezhetsz, akkor minden csatlakozásnál kemény határértéke 1k. Ennek megfelelően, ha a felhasználó csak egy kapcsolatot használ, akkor mindig csak 1 k, nem 100 k sebességgel pumpálja. Vagy ls-> conn - ez a kapcsolatok aktuális száma?
Igen, ez is zavaros :)
bár nem, persze ez a kapcsolatok jelenlegi száma, de az algoritmus még mindig túlságosan egyszerű.
Ha több különböző kérést teszünk fel, akkor a korlátozás mindig kevésbé lesz lehetséges, mert a kapcsolatok nincsenek teljesen kihasználva
Olyan érzés, hogy Sysoyev személyes ismerősök mellett senki nem tud hozzáadni semmit. Nos, vagy ennek valószínűsége nagyon kicsi.
Forge nginx és támogatja a nginx-ng-et. Ha tudsz, természetesen.
Az adminisztratív szempontból azt mondhatom, hogy a harmadik féltől származó modulok túlnyomó többsége csirke mancsként van írva. Segfolty, szivárgó memória, nem világos, hogy hol a fék és más illatok kapnak ingyen.
A Nginx nem általános célú webszerver, nincs benne sok funkció, mert nem ez a feladat. Senki se siklik, hogy nincs benne mod_php.
És mégis - hogyan lehet a NAT-felhasználók a modul telepítése után a kiszolgálón? Egy ügyfél fog pontszámozni az egész csatornát, a többi nem fog betörni a szerverbe?
Bármely oka lehet a vékony csatorna (olcsó vagy akár ingyenes VPS például)
vékony csatorna - ez minden rossz, nos, 1000 felhasználó tölti le a 1 kb / s-ot, mindannyian köpni és megtörni a letöltést ...
a GoogleBot, a YandexBot és más szkennerek vagy pókok behatolása
néhány Delirium tremens egyenes ...
DDoS
valószínűtlen, hogy többé-kevésbé súlyos támadással a moduljánál olyan alacsony határértéket kell felállítanod az IP-re, hogy a webhely nem szűnik meg.
Ez a modul korlátozza az egyes kapcsolatokat, pl. az első felhasználónak nincs előnye a későbbiekben
Ami a vékony csatornát illeti - feltételezzem, hogy van Gbod a szerveren, valaki Vasya gigabit kapcsolattal rendelkezik, és eltömíti az egész csatornát ...
Minimális medence szolgáltatást keresek be. egyenlő számlára, 256 ügyfelet ... korlátozza a 4Mbodot, és a csatorna csak akkor érhető el, ha több mint 256 ügyfél érkezik egyszerre ...
Általában a logika annyira ...