A sebességkorlátozás az NGINX-ben kulcsfontosságú funkció a szerver által kezelt forgalom mennyiségének szabályozásában. Segít megvédeni a szervert attól, hogy túl sok kérés túlterhelje rövid időn belül, amit rosszindulatú támadások, például DDoS vagy nagy forgalmi kiugrások okozhatnak. A sebességkorlátozás megvalósítása biztosítja az erőforrások hatékony felhasználását, és a legitimate felhasználók megszakítás nélkül hozzáférhetnek szolgáltatásaihoz.
Ez az útmutató bemutatja, hogyan konfigurálhatja a sebességkorlátozást az NGINX-ben, egyértelmű utasításokat adva a bejövő forgalom hatékony kezeléséhez és szabályozásához.
Az NGINX díjkorlátozási irányelveinek megértése
Az NGINX kulcsfontosságú díjkorlátozási irányelvei
Az NGINX specifikus direktívák segítségével konfigurálja a sebességkorlátozást, amelyek mindegyike egyedi funkciót lát el:
- limit_req_zone: Az NGINX limit_req_zone direktívája egy megosztott memóriazónát állít be a sebességkorlátozási információk tárolására. A http kontextusban elhelyezve meghatározza a kérések megengedett arányát, hatékonyan meghatározva a sebességkorlátok alapértékét.
- limit_req: A helykontextusban használt limit_req direktíva a limit_req_zone által beállított sebességkorlátot kényszeríti ki. Ezeket a korlátozásokat bizonyos helyekre vagy URL-ekre alkalmazza, így szabályozza az ezekhez a végpontokhoz való hozzáférés gyakoriságát.
- limit_req_status: A helykörnyezetben elhelyezett limit_req_status direktíva határozza meg a HTTP állapotkódot, amelyet akkor ad vissza, ha a kérési sebesség meghaladja a határértéket. Ez a visszacsatolási mechanizmus kulcsfontosságú a felhasználók vagy az automatizált rendszerek tájékoztatásában, ha túllépik a megengedett kérési gyakoriságot.
Dóziskorlátozó konfiguráció létrehozása
A sebességkorlátozás NGINX-ben való megvalósításához illessze be a megfelelő direktívákat az NGINX konfigurációs fájljába. Tekintsük ezt az alapvető példát:
http {
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;
server {
...
location / {
limit_req zone=mylimit burst=10;
...
}
}
}Ebben a konfigurációban a limit_req_zone direktíva létrehoz egy 'mylimit' nevű memóriazónát, amely másodpercenként 5 kérést (5r/s) engedélyez minden ügyfél IP-címéről ($binary_remote_addr). A limit_req direktíva ezután ezt a sebességkorlátot a gyökér helyre (/) alkalmazza, 10 kérés sorozatfelvételi kapacitásával, egyensúlyt kínálva a szigorú sebességkorlátozás és a rugalmasság között a legitimate forgalmi kiugrások esetén.
Rate Limit in NGINX: gyakorlati példák
Alap Dózis-korlátozó konfiguráció
Ez a rész az NGINX-ben az egész szerveren alkalmazott alapvető sebességkorlátozó konfigurációt tárgyalja. A cél a felhasználói kérések korlátozása a szerver felé, stabil teljesítmény biztosítása és a túlterhelés kockázatának csökkentése.
Példa: Szerverszintű sebességkorlát
Vegye figyelembe a következő NGINX konfigurációt:
http {
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=2r/s;
server {
listen 80;
server_name example.com;
location / {
limit_req zone=mylimit burst=5;
proxy_pass http://backend;
}
}
}
Ez a konfiguráció másodpercenként 2 kérés korlátját állítja be minden kliens számára, az IP-címük alapján ($binary_remote_addr). Bontsuk fel a legfontosabb összetevőket:
- limit_req_zone: Meghatároz egy memóriazónát (mylimit) a sebességkorlátozási állapotok tárolására 10 megabájt méretben. A sebességkorlátot másodpercenként 2 kérésre (2r/s) állítja be.
- szerver blokk: A 80-as porton figyeli az example.com bejövő forgalmat.
- hely blokk: A sebességkorlátozást a gyökér URL-re (/) alkalmazza. A sorozat-paraméter akár 5 kérésből álló sorozatfelvételt tesz lehetővé, rugalmasságot biztosítva a rövid forgalomcsúcsok esetén. A proxy_pass direktíva továbbítja a kérést a megadott háttérkiszolgálóhoz.
- Burst paraméter: A limit_req direktíva burst=5 beállítása lehetővé teszi a kérések rövid távú növekedését, akár 5 további kéréssel a beállított sebesség felett. Ez a funkció kulcsfontosságú a hirtelen, legitimate forgalomnövekedés kezelésében a felhasználói élmény befolyásolása nélkül.
- Proxy Pass: A proxy_pass http://backend; direktíva továbbítja a forgalmat egy háttérkiszolgálóhoz. Ezt általában terheléselosztási forgatókönyvekben használják, vagy amikor az NGINX fordított proxyként működik.
Speciális díjkorlátozási példák
Különböző helyeken eltérő díjkorlátok
Előfordulhat, hogy összetettebb forgatókönyvekben eltérő sebességkorlátokat kell alkalmaznia a különböző alkalmazásrészekre. Ez különösen akkor hasznos, ha bizonyos végpontok erőforrásigényesebbek vagy visszaélésre hajlamosak.
Vegye figyelembe a következő konfigurációt:
http {
limit_req_zone $binary_remote_addr zone=low:10m rate=1r/s;
limit_req_zone $binary_remote_addr zone=high:10m rate=10r/s;
server {
listen 80;
server_name example.com;
location /api/low {
limit_req zone=low burst=3;
proxy_pass http://backend;
}
location /api/high {
limit_req zone=high burst=20;
proxy_pass http://backend;
}
}
}
Ez a konfiguráció alacsonyabb sebességkorlátot (másodpercenként 1 kérés) alkalmaz az /api/low helyre, és magasabb sebességkorlátot (10 kérés másodpercenként) az /api/high helyre.
További Nginx sebességkorlátozási példák
Díjkorlátozás a kérelem típusa alapján
A sebességkorlátozást konkrét kérések, például GET, POST vagy PUT kérések alapján konfigurálhatja. Ez különösen akkor hasznos, ha bizonyos végpontokat szeretne megvédeni, amelyek sebezhetőbbek a visszaélésekkel szemben, vagy amelyek nagyobb hatással vannak a kiszolgáló erőforrásaira.
Használhatja az if direktívát és az $request_method változót a sebességkorlátozás alkalmazására adott kéréstípusokra. Íme egy példa:
http {
limit_req_zone $binary_remote_addr zone=get_limit:10m rate=5r/s;
limit_req_zone $binary_remote_addr zone=post_limit:10m rate=2r/s;
server {
listen 80;
server_name example.com;
location / {
if ($request_method = GET) {
limit_req zone=get_limit burst=10;
}
if ($request_method = POST) {
limit_req zone=post_limit burst=5;
}
proxy_pass http://backend;
}
}
}
Ebben a konfigurációban két külön sebességkorlátot állítottunk be: egyet a GET-kérésekhez (5 kérés másodpercenként) és egyet a POST-kérésekhez (2 kérés másodpercenként).
Díjkorlátozás User-Agent alapján
Egy másik hasznos technika a díjkorlátozás alkalmazása az ügyfelek által küldött User-Agent fejléc alapján. Ez segíthet megvédeni szolgáltatásait a problémákat okozó robotoktól vagy bejáróktól.
A User-Agenten alapuló sebességkorlátozás megvalósításához használhatja a map direktívát és az $http_user_agent változót.
Íme egy példa:
http {
map $http_user_agent $limit_bots {
default 0;
~*(Googlebot|Bingbot) 1;
}
limit_req_zone $binary_remote_addr zone=bot_limit:10m rate=1r/s;
server {
listen 80;
server_name example.com;
location / {
if ($limit_bots) {
limit_req zone=bot_limit burst=2;
}
proxy_pass http://backend;
}
}
}
Ebben a példában definiáltunk egy leképezési direktívát, amely az $limit_bots változót 1-re állítja, ha a User-Agent fejléc egyezik a „Googlebot” vagy a „Bingbot” kifejezéssel. Ezután az ezektől a robotoktól érkező kérésekre másodpercenként 1 kérés sebességkorlátozást alkalmazunk.
IP-címek engedélyezése a Rate Limiting szolgáltatásból
Néha előfordulhat, hogy bizonyos IP-címeket, például megbízható partnereket vagy belső szolgáltatásokat szeretne mentesíteni a sebességkorlátozás alól. Ennek eléréséhez használhatja a geo direktívát, valamint a if irányelv.
Íme egy példa:
http {
geo $rate_limit {
default 1;
192.168.0.0/24 0;
10.0.0.0/8 0;
}
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;
server {
listen 80;
server_name example.com;
location / {
if ($rate_limit) {
limit_req zone=mylimit burst=10;
}
proxy_pass http://backend;
}
}
}
Méretezési sebesség korlátozása elosztott környezetben
Ha több Nginx-példány fut egy elosztott környezetben, érdemes megbizonyosodni arról, hogy a sebességkorlátozás minden példányban konzisztens. Ennek eléréséhez használhat egy központi adattárat, például a Redis-t, hogy kezelje a sebességkorlátokat. Ezzel lehetővé válik az összes Nginx példány között megosztott globális sebességkorlát fenntartása.
A sebességkorlátozás Redis segítségével történő beállításához telepítenie és konfigurálnia kell az nginx-module-redis modult. Miután telepítette a modult, frissítheti az Nginx konfigurációját, hogy a Redis-t használja a sebességkorlátozáshoz.
Íme egy példa:
load_module modules/ngx_http_redis_module.so;
http {
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;
upstream redis_server {
server 127.0.0.1:6379;
keepalive 32;
}
server {
listen 80;
server_name example.com;
location / {
limit_req_redis zone=mylimit burst=10 redis_server=redis_server;
proxy_pass http://backend;
}
}
}
Ebben a példában definiáltunk egy upstream blokkot a Redis kiszolgálóhoz, és frissítettük a helyblokkot úgy, hogy a limit_req_redis direktívát használja a szokásos limit_req direktíva helyett. Ez a konfiguráció biztosítja, hogy a sebességkorlátokat a megosztott Redis-adattár segítségével kényszerítsék ki, így több Nginx-példányon is egységes sebességkorlátozást biztosítanak.
Dinamikus sebességkorlátozás
Bizonyos helyzetekben érdemes lehet dinamikusan módosítani a sebességkorlátokat bizonyos feltételek vagy a szerver aktuális terhelése alapján. Például érdemes szigorúbb díjkorlátokat alkalmazni a csúcsforgalom idején a szervererőforrások jobb kezelése érdekében.
A dinamikus sebességkorlátozás megvalósításához használhatja a map irányelvet a díjhatárok meghatározott feltételek alapján történő meghatározására.
Íme egy példa:
http {
map $http_x_traffic $dynamic_rate {
default "5r/s";
high "2r/s";
}
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=$dynamic_rate;
server {
listen 80;
server_name example.com;
location / {
limit_req zone=mylimit burst=10;
proxy_pass http://backend;
}
}
}
Ebben a konfigurációban az $http_x_traffic változót használjuk, amely egy egyéni X-Traffic fejlécből származik. Ennek a fejlécnek az értéke alapján dinamikusan beállítjuk a sebességkorlátot. Ha a fejléc értéke „magas”, szigorúbb, másodpercenkénti 2 kérés gyakorisági korlátot alkalmazunk. Ellenkező esetben az alapértelmezett, másodpercenkénti 5 kérés arányt használjuk.
Vegye figyelembe, hogy ez a példa azt feltételezi, hogy a háttérkiszolgáló vagy az infrastruktúra egy másik összetevője beállítja az X-Traffic fejlécet a kívánt feltételek alapján.
A díjkorlát tesztelése az NGINX konfigurációban
A sebességkorlátozás ellenőrzése göndörítéssel
Curl használata az egyszerű kérés teszteléséhez
Az NGINX sebességkorlátozó beállításai hatékonyságának ellenőrzéséhez a curl, a HTTP-kérések küldésére szolgáló parancssori eszköz rendkívül hasznosnak bizonyul. Gyorsan több kérést is el tud küldeni a szervernek, így segít felmérni, hogy a sebességkorlátok aktívak-e.
for i in {1..10}; do curl -I http://example.com; done- Ez a parancs 10 HEAD-kérést küld a szervernek, a http://example.com címet célozva.
- Elemezze az ezekből a kérésekből származó HTTP-válaszfejléceket, hogy ellenőrizze a sebességkorlátozást.
- Az NGINX-nek 429 túl sok kérés állapotkódot kell visszaadnia, ha a kérések aránya meghaladja a megadott korlátot.
Tesztelés Apache Bench (ab) segítségével
Szerverválaszok összehasonlítása az Apache Bench segítségével
Az Apache Bench (ab) egy hatékony benchmarking eszköz, amely ideális a sebességhatárok tesztelésére a nagy forgalmi viszonyok szimulálásával. Segít megérteni, hogyan viselkedik az NGINX-kiszolgáló a kérések hulláma alatt.
ab -n 100 -c 10 http://example.com/- Ez a parancs arra utasítja az ab-t, hogy 100 kérést küldjön a http://example.com címre 10-es párhuzamossági szinttel.
- Az ab kimenete betekintést nyújt a sebességkorlátozó hatékonyságba.
- Koncentráljon a sikertelen kérések számára a kimenetben, amelyeknek meg kell egyeznie az NGINX sebességkorlátozó konfiguráció beállításaival.
Az NGINX konfiguráció tesztelésének legjobb módszereinek alkalmazása biztosítja, hogy a sebességkorlátozó szabályok a kívánt módon működjenek.
Következtetés
A sebességkorlátozás konfigurálásával az NGINX-ben megvédheti szerverét a túlzott forgalomtól és az esetleges visszaélésektől. Ez segít fenntartani a szolgáltatások teljesítményét és elérhetőségét, jobb élményt biztosítva a legitimate felhasználók számára. Rendszeresen figyelje és módosítsa a sebességkorlátozás beállításait a biztonság és a hozzáférhetőség egyensúlya érdekében. Ezen vezérlők végrehajtása létfontosságú a szerver erőforrásainak hatékony kezeléséhez.
