Snelheidsbeperking in NGINX is een cruciale functie voor het controleren van de hoeveelheid verkeer die uw server afhandelt. Het helpt voorkomen dat uw server in korte tijd wordt overweldigd door te veel verzoeken, die kwaadaardige aanvallen zoals DDoS of hoge verkeerspieken kunnen veroorzaken. Het implementeren van snelheidsbeperking zorgt ervoor dat uw bronnen efficiënt worden gebruikt en dat legitieme gebruikers zonder onderbreking toegang hebben tot uw services.
Deze handleiding demonstreert hoe u snelheidsbeperking in NGINX configureert en geeft duidelijke instructies om u te helpen inkomend verkeer effectief te beheren en te controleren.
Tarieflimietrichtlijnen in NGINX begrijpen
Belangrijke NGINX-richtlijnen voor snelheidsbeperking
NGINX configureert snelheidsbeperking met behulp van specifieke richtlijnen, die elk een unieke functie vervullen:
- limit_req_zone: De limit_req_zone richtlijn in NGINX stelt een gedeelde geheugenzone in voor het opslaan van snelheidsbeperkende informatie. Gepositioneerd in de http-context, bepaalt het het toegestane aantal verzoeken, waarmee feitelijk de basis voor snelheidslimieten wordt vastgelegd.
- limit_req: De limit_req richtlijn, gebruikt in de locatiecontext, dwingt de snelheidslimiet af die is ingesteld door limit_req_zone. Het past deze beperkingen toe op specifieke locaties of URL's, waardoor de frequentie van toegang tot deze eindpunten wordt gecontroleerd.
- limit_req_status: De limit_req_status richtlijn, geplaatst in de locatiecontext, specificeert de HTTP-statuscode die wordt geretourneerd wanneer de verzoeksnelheid de limiet overschrijdt. Dit feedbackmechanisme is cruciaal voor het informeren van gebruikers of geautomatiseerde systemen wanneer deze de toegestane verzoekfrequentie overschrijden.
Een snelheidsbeperkende configuratie creëren
Om snelheidsbeperking in NGINX te implementeren, voegt u de juiste richtlijnen in het NGINX-configuratiebestand in. Beschouw dit eenvoudige voorbeeld:
http {
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;
server {
...
location / {
limit_req zone=mylimit burst=10;
...
}
}
}In deze configuratie stelt de limit_req_zone-richtlijn een geheugenzone in met de naam 'mylimit', waardoor 5 verzoeken per seconde (5r/s) van elk client-IP-adres ($binary_remote_addr) worden toegestaan. De limit_req-richtlijn past deze snelheidslimiet vervolgens toe op de hoofdlocatie (/), met een burst-capaciteit van 10 verzoeken, wat een evenwicht biedt tussen strikte snelheidsbeperking en flexibiliteit voor legitieme verkeerspieken.
Tarieflimiet in NGINX: praktische voorbeelden
Basisconfiguratie voor snelheidsbeperking
In deze sectie wordt een basissnelheidsbeperkende configuratie onderzocht die serverbreed in NGINX wordt toegepast. Het doel is om gebruikersverzoeken aan de server te beperken, stabiele prestaties te garanderen en het risico op overbelasting te beperken.
Voorbeeld: snelheidslimiet voor de hele server
Overweeg de volgende NGINX-configuratie:
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;
}
}
}
Deze configuratie stelt een limiet in van 2 verzoeken per seconde voor elke client, zoals gedefinieerd door hun IP-adres ($binary_remote_addr). Laten we de belangrijkste componenten opsplitsen:
- limit_req_zone: Definieert een geheugenzone (mylimit) voor het opslaan van de snelheidslimietstatussen met een grootte van 10 megabytes. Het stelt de snelheidslimiet in op 2 verzoeken per seconde (2r/s).
- serverblok: Luistert op poort 80 naar inkomend verkeer naar example.com.
- locatie blok: past de snelheidslimiet toe op de hoofd-URL (/). De burst-parameter maakt een burst van maximaal vijf verzoeken mogelijk, wat flexibiliteit biedt voor korte pieken in het verkeer. De proxy_pass-instructie stuurt het verzoek door naar de opgegeven backend-server.
- Burst-parameter: De instelling burst=5 in de limit_req-richtlijn maakt een korte termijn toename van het aantal verzoeken mogelijk, tot maximaal 5 extra verzoeken boven de ingestelde snelheid. Deze functie is cruciaal bij het verwerken van plotselinge, legitieme toenames in verkeer zonder de gebruikerservaring te beïnvloeden.
- Proxypas: De proxy_pass http://backend; richtlijn stuurt het verkeer door naar een backend-server. Dit wordt vaak gebruikt in scenario's voor taakverdeling of wanneer NGINX fungeert als een omgekeerde proxy.
Geavanceerde voorbeelden van snelheidsbeperking
Verschillende tarieflimieten voor verschillende locaties
In complexere scenario's moet u mogelijk verschillende tarieflimieten toepassen op verschillende toepassingsonderdelen. Dit is met name handig wanneer specifieke eindpunten meer middelen vereisen of vatbaar zijn voor misbruik.
Overweeg de volgende configuratie:
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;
}
}
}
Deze configuratie past een lagere snelheidslimiet (1 verzoek per seconde) toe op de /api/low locatie en een hogere snelheidslimiet (10 verzoeken per seconde) op de /api/high locatie.
Aanvullende Nginx-snelheidsbeperkende voorbeelden
Tariefbeperking op basis van verzoektypen
U kunt snelheidsbeperkingen configureren op basis van specifieke verzoeken, zoals GET-, POST- of PUT-verzoeken. Dit is met name handig als u specifieke eindpunten wilt beschermen die kwetsbaarder zijn voor misbruik of een grotere impact hebben op uw serverbronnen.
U kunt de if-richtlijn en de variabele $request_method gebruiken om snelheidsbeperkingen toe te passen op specifieke verzoektypen. Hier is een voorbeeld:
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;
}
}
}
In deze configuratie hebben we twee afzonderlijke tarieflimieten ingesteld: één voor GET-verzoeken (5 verzoeken per seconde) en één voor POST-verzoeken (2 verzoeken per seconde).
Tariefbeperking op basis van user-agent
Een andere nuttige techniek is het toepassen van snelheidslimieten op basis van de User-Agent-header die door clients wordt verzonden. Dit kan u helpen uw services te beschermen tegen specifieke bots of crawlers die problemen veroorzaken.
Om snelheidsbeperking op basis van User-Agent te implementeren, kunt u de kaartrichtlijn en de variabele $http_user_agent gebruiken.
Hier is een voorbeeld:
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;
}
}
}
In dit voorbeeld hebben we een kaartrichtlijn gedefinieerd die de variabele $limit_bots instelt op 1 als de User-Agent-header overeenkomt met 'Googlebot' of 'Bingbot'. Op verzoeken van deze bots hanteren wij dan een snelheidslimiet van 1 verzoek per seconde.
IP's op de witte lijst zetten via Rate Limiting
Soms wilt u specifieke IP-adressen, zoals vertrouwde partners of interne services, uitsluiten van snelheidsbeperking. Om dit te bereiken, kunt u de geo-richtlijn gebruiken, samen met de if richtlijn.
Hier is een voorbeeld:
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;
}
}
}
Schaalsnelheidslimiet in een gedistribueerde omgeving
Wanneer meerdere Nginx-instanties in een gedistribueerde omgeving worden uitgevoerd, wilt u er mogelijk voor zorgen dat de snelheidsbeperking consistent is voor alle instanties. U kunt een gecentraliseerde gegevensopslag zoals Redis gebruiken om snelheidslimieten te beheren om dit te bereiken. Als u dit doet, kunt u een globale snelheidslimiet handhaven die wordt gedeeld door alle Nginx-instanties.
Om snelheidsbeperking in te stellen met Redis, moet u de nginx-module-redis-module installeren en configureren. Nadat u de module hebt geïnstalleerd, kunt u uw Nginx-configuratie bijwerken om Redis te gebruiken voor snelheidsbeperking.
Hier is een voorbeeld:
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;
}
}
}
In dit voorbeeld hebben we een upstream-blok voor de Redis-server gedefinieerd en het locatieblok bijgewerkt om de limit_req_redis-richtlijn te gebruiken in plaats van de standaard limit_req-richtlijn. Deze configuratie zorgt ervoor dat snelheidslimieten worden afgedwongen met behulp van de gedeelde Redis-gegevensopslag, waardoor een consistente snelheidslimiet voor meerdere Nginx-instanties wordt geboden.
Dynamische snelheidsbeperking
In sommige situaties wilt u mogelijk de tarieflimieten dynamisch aanpassen op basis van bepaalde omstandigheden of de huidige belasting van uw server. U wilt bijvoorbeeld wellicht strengere tarieflimieten toepassen tijdens piekmomenten om de serverbronnen beter te beheren.
Om dynamische snelheidsbeperking te implementeren, kunt u de map richtlijn om tarieflimieten te definiëren op basis van specifieke voorwaarden.
Hier is een voorbeeld:
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;
}
}
}
In deze configuratie gebruiken we de variabele $http_x_traffic die is afgeleid van een aangepaste header X-Traffic. Op basis van de waarde van deze header stellen we de snelheidslimiet dynamisch in. Wanneer de headerwaarde ‘hoog’ is, hanteren we een strengere snelheidslimiet van 2 verzoeken per seconde. Anders hanteren wij het standaardtarief van 5 verzoeken per seconde.
Houd er rekening mee dat in dit voorbeeld wordt aangenomen dat uw backend-server of een ander onderdeel in uw infrastructuur de X-Traffic-header instelt op basis van uw gewenste omstandigheden.
Uw snelheidslimiet testen in NGINX-configuratie
Snelheidslimiet verifiëren met krul
Curl gebruiken voor het testen van eenvoudige verzoeken
Om de effectiviteit van uw snelheidsbeperkende instellingen in NGINX te valideren, blijkt curl, een opdrachtregelprogramma voor het verzenden van HTTP-verzoeken, zeer nuttig. Het kan snel meerdere verzoeken naar uw server sturen, zodat u kunt beoordelen of de tarieflimieten actief zijn.
for i in {1..10}; do curl -I http://example.com; done- Deze opdracht verzendt 10 HEAD-verzoeken naar uw server, gericht op http://example.com.
- Analyseer de HTTP-antwoordheaders van deze verzoeken om de snelheidsbeperkende functionaliteit te verifiëren.
- NGINX zou de statuscode 429 Too Many Requests moeten retourneren wanneer het aantal verzoeken de door u opgegeven limiet overschrijdt.
Testen met Apache Bench (ab)
Benchmarking van serverreacties met Apache Bench
Apache Bench (ab) is een effectieve benchmarkingtool die ideaal is voor het testen van snelheidslimieten door omstandigheden met veel verkeer te simuleren. Het helpt begrijpen hoe uw NGINX-server zich gedraagt onder een golf van verzoeken.
ab -n 100 -c 10 http://example.com/- Deze opdracht instrueert ab om 100 verzoeken naar http://example.com te sturen met een gelijktijdigheidsniveau 10.
- De output van ab geeft inzicht in de snelheidsbeperkende effectiviteit.
- Concentreer u op het aantal mislukte verzoeken in de uitvoer, dat moet overeenkomen met de instellingen van uw NGINX-snelheidsbeperkende configuratie.
Door de beste methoden te gebruiken om uw NGINX-configuratie te testen, zorgt u ervoor dat uw snelheidsbeperkende regels functioneren zoals bedoeld.
Conclusie
Door snelheidsbeperking in NGINX te configureren, kunt u uw server beschermen tegen overmatig verkeer en mogelijk misbruik. Dit helpt de prestaties en beschikbaarheid van uw services te behouden, waardoor een betere ervaring voor legitieme gebruikers wordt gegarandeerd. Controleer regelmatig uw snelheidsbeperkende instellingen en pas deze aan om de beveiliging en toegankelijkheid in evenwicht te brengen. Het implementeren van deze controles is essentieel voor het efficiënt beheren van de bronnen van uw server.
