In ons laatste artikel, dat deel uitmaakt van onze serie NGINX-verkeersbeheer, hebben we besproken hoe we de aantal verbindingen in NGINX. In deze gids zullen we bekijken hoe we het aantal verzoeken in NGINX.
Snelheidsbeperking is een verkeersmanagementtechniek die wordt gebruikt om het aantal HTTP verzoeken die een klant in een bepaalde periode kan doen - tarieflimieten worden berekend in Verzoeken per seconde (of RPS).
Een voorbeeld van een verzoek is een KRIJGEN verzoek om de inlogpagina van een applicatie of a NA aanvraag op een inlogformulier of a NA op een API eindpunt.
Er zijn veel redenen om het aantal verzoeken naar uw webapplicaties of API-services te beperken, waaronder beveiliging: bescherming tegen misbruik van snelle verzoeken.
Begin met het definiëren van de parameters voor snelheidsbeperking met behulp van de limit_req_zone
richtlijn. De vereiste parameters zijn een sleutel voor het identificeren van clients, een zone met gedeeld geheugen waarin de status van de sleutel wordt opgeslagen en hoe vaak deze toegang heeft gekregen tot een URL met beperkte aanvraag, en de snelheid.
De limit_req_zone
richtlijn is geldig binnen de HTTP-context.
limit_req_zone $binary_remote_addr zone=limitreqsbyaddr: 20m rate=10r/s;
Stel ook een antwoordstatuscode in die wordt geretourneerd aan afgewezen verzoeken, met behulp van de limit_req_status
richtlijn die geldig is binnen de HTTP-, server- en locatiecontexten.
limit_req_status 429;
Nu kunt u de limitt_conn
richtlijn om verzoeksnelheidsbeperking in te schakelen binnen de HTTP-, server- en locatiecontexten. Het heeft een geheugenzone als parameter en andere optionele parameters.
limit_req zone=limitreqsbyaddr;
In het volgende configuratievoorbeeld ziet u het beperken van de aanvraagsnelheid tot een webtoepassings-API. De grootte van het gedeelde geheugen is 20 MB en de limiet voor de verzoeksnelheid is 10 verzoeken per seconde.
upstream api_service {server 127.0.0.1:9051; server 10.1.1.77:9052; } limit_req_zone $binary_remote_addr zone=limitreqsbyaddr: 20m rate=10r/s;limit_req_status 429; server { luister 80; servernaam testapp.tecmint.com; root /var/www/html/testapp.tecmint.com/build; indexindex.html; #include snippets/error_pages.conf; proxy_read_timeout 600; proxy_connect_timeout 600; proxy_send_timeout 600; locatie / {try_files $uri $uri/ /index.html =404 =403 =500; } locatie /api { limit_req zone=limitregsbyaddr;proxy_pass http://api_service; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_http_versie 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Verbinding "upgrade"; } }
Sla uw configuratiebestand op en sluit het.
Controleer dan of de NGINX configuratiesyntaxis correct is met de volgende opdracht:
$ sudo nginx -t.
Laad daarna de opnieuw NGINX service pas de laatste wijzigingen toe:
$ sudo systemctl herlaad nginx.
Zodra de snelheidslimiet van 10 verzoeken per seconde wordt overschreden door een enkele client toegang /api/
, NGINX retourneert een "429 Te veel verzoeken” fout aan de klant.
Het registreert het incident ook in het foutenlogboek.
2022/04/29 00:30:38 [fout] 3145846#0: *131039 limietverzoeken, overschot: 0.990 per zone "limitreqsbyaddr", client: 192.168.1.10, server: testapp.tecmint.com, aanvraag: "GET /api/v1/app/meta-data HTTP/1.1", host: "testapp.tecmint.com", verwijzer: " https://testapp.tecmint.com/"
Soms, afhankelijk van de aard van uw toepassing of API, moet een klant veel verzoeken tegelijk doen, en vervolgens het tarief voor een bepaalde periode verlagen voordat hij er meer doet. NGINX kan ook overtollige verzoeken in een wachtrij bufferen en deze onmiddellijk verwerken.
U kunt dit gedrag bij snelheidsbeperking inschakelen met behulp van de uitbarsting
parameter met de limit_req
richtlijn. Om wachtrijen zonder vertraging mogelijk te maken, voegt u de geen vertraging
parameter.
limit_req zone=limitregsbyaddr burst=20 nodelay;
Er is een probleem met snelheidsbeperking op basis van het IP-adres van een client, met name voor gebruikers die toegang hebben tot uw toepassing vanaf hetzelfde netwerk en die achter een NAT werken. In dit geval zullen al hun verzoeken afkomstig zijn van hetzelfde IP-adres. In een dergelijk scenario kunt u andere variabelen gebruiken om clients te identificeren, zoals een sessiecookie.
Bekijk dit voor meer informatie over het beperken van het aantal verzoeken: NGINX-snelheidsbeperking op de NGINX-website. Vervolgens zullen we bespreken hoe u het bandbreedtegebruik kunt beperken in NGINX.