Hastighedsbegrænsning i NGINX er en afgørende funktion til at kontrollere mængden af trafik, som din server håndterer. Det hjælper med at beskytte din server mod at blive overvældet af for mange anmodninger i en kort periode, hvilket ondsindede angreb som DDoS eller høje trafikstigninger kan forårsage. Implementering af hastighedsbegrænsning sikrer, at dine ressourcer bruges effektivt, og at legitime brugere kan få adgang til dine tjenester uden afbrydelser.
Denne guide vil demonstrere, hvordan du konfigurerer hastighedsbegrænsning i NGINX, og giver klare instruktioner til at hjælpe dig med at administrere og kontrollere indgående trafik effektivt.
Forståelse af satsgrænsedirektiver i NGINX
Vigtige NGINX satsbegrænsende direktiver
NGINX konfigurerer hastighedsbegrænsning ved hjælp af specifikke direktiver, der hver har en unik funktion:
- limit_req_zone: Limit_req_zone-direktivet i NGINX opsætter en delt hukommelseszone til lagring af hastighedsbegrænsende information. Placeret i http-konteksten bestemmer den den tilladte frekvens af anmodninger, og sætter faktisk basislinjen for hastighedsgrænser.
- limit_req: Limit_req-direktivet, der anvendes i lokalitetskonteksten, håndhæver den hastighedsgrænse, der er angivet af limit_req_zone. Den anvender disse begrænsninger på specifikke placeringer eller URL'er og kontrollerer dermed hyppigheden af adgang til disse slutpunkter.
- limit_req_status: Placeret i lokationskonteksten specificerer direktivet limit_req_status den HTTP-statuskode, der returneres, når anmodningshastigheden overskrider grænsen. Denne feedbackmekanisme er afgørende for at informere brugere eller automatiserede systemer, når de overskrider den tilladte anmodningsfrekvens.
Oprettelse af en hastighedsbegrænsende konfiguration
For at implementere hastighedsbegrænsning i NGINX skal du indsætte de relevante direktiver i NGINX-konfigurationsfilen. Overvej dette grundlæggende eksempel:
http {
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;
server {
...
location / {
limit_req zone=mylimit burst=10;
...
}
}
}I denne konfiguration etablerer limit_req_zone-direktivet en hukommelseszone ved navn 'mylimit', der tillader 5 anmodninger pr. sekund (5r/s) fra hver klient-IP-adresse ($binary_remote_addr). Limit_req-direktivet anvender derefter denne hastighedsgrænse på rodplaceringen (/), med en burstkapacitet på 10 anmodninger, hvilket tilbyder en balance mellem streng hastighedsbegrænsning og fleksibilitet for lovlige trafikstigninger.
Satsgrænse i NGINX: Praktiske eksempler
Grundlæggende hastighedsbegrænsende konfiguration
Dette afsnit vil udforske en grundlæggende hastighedsbegrænsende konfiguration, der anvendes på hele serveren i NGINX. Målet er at begrænse brugeranmodninger til serveren, sikre stabil ydeevne og mindske risikoen for overbelastning.
Eksempel: Server-Wide Rate Limit
Overvej følgende NGINX-konfiguration:
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;
}
}
}
Denne konfiguration sætter en grænse på 2 anmodninger pr. sekund for hver klient, som defineret af deres IP-adresse ($binary_remote_addr). Lad os nedbryde nøglekomponenterne:
- limit_req_zone: Definerer en hukommelseszone (mylimit) til lagring af hastighedsgrænsetilstande med en størrelse på 10 megabyte. Den indstiller hastighedsgrænsen til 2 anmodninger pr. sekund (2r/s).
- server blok: Lytter på port 80 for indgående trafik til example.com.
- lokationsblok: Anvender hastighedsgrænsen på rod-URL'en (/). Burst-parameteren tillader et burst på op til 5 anmodninger, hvilket giver fleksibilitet til korte stigninger i trafikken. Proxy_pass-direktivet videresender anmodningen til den angivne backend-server.
- Burst-parameter: Burst=5-indstillingen i limit_req-direktivet tillader en kortvarig stigning i anmodninger, op til 5 yderligere anmodninger over den indstillede hastighed. Denne funktion er afgørende for at håndtere pludselige, legitime stigninger i trafik uden at påvirke brugeroplevelsen.
- Proxy Pass: Proxy_pass http://backend; direktiv videresender trafikken til en backend-server. Dette bruges almindeligvis i belastningsbalancerende scenarier, eller når NGINX fungerer som en omvendt proxy.
Eksempler på avanceret satsbegrænsning
Forskellige takstgrænser for forskellige lokationer
Du skal muligvis anvende forskellige hastighedsgrænser på forskellige applikationsdele i mere komplekse scenarier. Dette er især nyttigt, når specifikke endepunkter er mere ressourcekrævende eller tilbøjelige til at blive misbrugt.
Overvej følgende konfiguration:
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;
}
}
}
Denne konfiguration anvender en lavere hastighedsgrænse (1 anmodning pr. sekund) til /api/low-lokationen og en højere hastighedsgrænse (10 anmodninger pr. sekund) til /api/high-placeringen.
Yderligere eksempler på Nginx-hastighedsbegrænsende
Takstbegrænsning baseret på anmodningstyper
Du kan konfigurere hastighedsbegrænsning baseret på specifikke anmodninger, såsom GET-, POST- eller PUT-anmodninger. Dette er især nyttigt, når du ønsker at beskytte specifikke endepunkter, der er mere sårbare over for misbrug eller har en større indvirkning på dine serverressourcer.
Du kan bruge if-direktivet og $request_method-variablen til at anvende hastighedsbegrænsning på specifikke anmodningstyper. Her er et eksempel:
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;
}
}
}
I denne konfiguration har vi opsat to separate hastighedsgrænser: en for GET-anmodninger (5 anmodninger pr. sekund) og en for POST-anmodninger (2 anmodninger pr. sekund).
Satsbegrænsning baseret på User-Agent
En anden nyttig teknik er at anvende hastighedsbegrænsning baseret på User-Agent-headeren sendt af klienter. Dette kan hjælpe med at beskytte dine tjenester mod specifikke bots eller crawlere, der forårsager problemer.
For at implementere hastighedsbegrænsning baseret på User-Agent kan du bruge kortdirektivet og $http_user_agent-variablen.
Her er et eksempel:
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;
}
}
}
I dette eksempel har vi defineret et kortdirektiv, der sætter variablen $limit_bots til 1, hvis User-Agent-headeren matcher "Googlebot" eller "Bingbot". Vi anvender derefter en hastighedsgrænse på 1 anmodning i sekundet på anmodninger fra disse bots.
Hvidliste IP'er fra Rate Limiting
Nogle gange vil du måske undtage specifikke IP-adresser, såsom betroede partnere eller interne tjenester, fra takstbegrænsning. For at opnå dette kan du bruge geo-direktivet sammen med if direktiv.
Her er et eksempel:
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;
}
}
}
Skaleringshastighedsbegrænsning i et distribueret miljø
Når flere Nginx-forekomster kører i et distribueret miljø, vil du måske sikre dig, at hastighedsbegrænsningen er konsistent på tværs af alle forekomster. Du kan bruge et centraliseret datalager såsom Redis til at administrere hastighedsgrænser for at opnå dette. Hvis du gør det, kan du opretholde en global satsgrænse, der deles mellem alle Nginx-forekomster.
For at opsætte hastighedsbegrænsning med Redis skal du installere og konfigurere nginx-module-redis-modulet. Når du har installeret modulet, kan du opdatere din Nginx-konfiguration til at bruge Redis til hastighedsbegrænsning.
Her er et eksempel:
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;
}
}
}
I dette eksempel har vi defineret en opstrømsblok for Redis-serveren og opdateret lokationsblokken til at bruge limit_req_redis-direktivet i stedet for standard limit_req-direktivet. Denne konfiguration sikrer, at hastighedsgrænser håndhæves ved hjælp af det delte Redis-datalager, hvilket giver ensartet hastighedsbegrænsning på tværs af flere Nginx-instanser.
Dynamisk hastighedsbegrænsning
I nogle situationer vil du måske justere hastighedsgrænserne dynamisk baseret på visse forhold eller den aktuelle belastning på din server. For eksempel vil du måske anvende strengere hastighedsgrænser under spidsbelastningstider for at administrere serverressourcer bedre.
For at implementere dynamisk hastighedsbegrænsning kan du bruge map direktiv om at definere satsgrænser baseret på specifikke forhold.
Her er et eksempel:
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;
}
}
}
I denne konfiguration bruger vi $http_x_traffic-variablen afledt af en tilpasset header X-Traffic. Baseret på denne overskrifts værdi indstiller vi hastighedsgrænsen dynamisk. Når overskriftsværdien er "høj", anvender vi en strengere hastighedsgrænse på 2 anmodninger pr. sekund. Ellers bruger vi standardhastigheden på 5 anmodninger i sekundet.
Bemærk, at dette eksempel antager, at din backend-server eller en anden komponent i din infrastruktur indstiller X-Traffic-headeren baseret på dine ønskede betingelser.
Test af din hastighedsgrænse i NGINX-konfiguration
Bekræftelse af hastighedsbegrænsning med krølle
Brug af curl til Simple Request Testing
For at validere effektiviteten af din hastighedsbegrænsende opsætning i NGINX, viser curl, et kommandolinjeværktøj til at sende HTTP-anmodninger, sig meget nyttigt. Det kan hurtigt sende flere anmodninger til din server, hvilket hjælper dig med at vurdere, om hastighedsgrænserne er aktive.
for i in {1..10}; do curl -I http://example.com; done- Denne kommando sender 10 HEAD-anmodninger til din server, målrettet mod http://example.com.
- Analyser HTTP-svar-headerne fra disse anmodninger for at verificere hastighedsbegrænsende funktionalitet.
- NGINX skulle returnere en 429 Too Many Requests statuskode, når antallet af anmodninger overstiger din specificerede grænse.
Test med Apache Bench (ab)
Benchmarking af serversvar med Apache Bench
Apache Bench (ab) er et effektivt benchmarkingværktøj, der er ideelt til at teste hastighedsgrænser ved at simulere forhold med høj trafik. Det hjælper med at forstå, hvordan din NGINX-server opfører sig under en bølge af anmodninger.
ab -n 100 -c 10 http://example.com/- Denne kommando instruerer ab til at sende 100 anmodninger til http://example.com med et samtidighedsniveau 10.
- Outputtet fra ab giver indsigt i den hastighedsbegrænsende effektivitet.
- Fokuser på antallet af mislykkede anmodninger i outputtet, som bør stemme overens med indstillingerne for din NGINX hastighedsbegrænsende konfiguration.
Anvendelse af de bedste metoder til at teste din NGINX-konfiguration sikrer, at dine hastighedsbegrænsende regler fungerer efter hensigten.
Konklusion
Ved at konfigurere hastighedsbegrænsning i NGINX kan du beskytte din server mod overdreven trafik og potentielt misbrug. Dette hjælper med at opretholde ydeevnen og tilgængeligheden af dine tjenester, hvilket sikrer en bedre oplevelse for legitime brugere. Overvåg og juster dine hastighedsbegrænsende indstillinger regelmæssigt for at balancere sikkerhed og tilgængelighed. Implementering af disse kontroller er afgørende for effektiv styring af din servers ressourcer.
