So begrenzen Sie die Netzwerkbandbreite im NGINX-Webserver
Zuvor haben wir in unserer Reihe zu NGINX-Datenverkehrsmanagement und Sicherheitskontrollen erläutert, wie Sie die Anzahl der Verbindungen, die ein und derselbe Client mit Ihren Webressourcen herstellen kann, mithilfe von Client-Identifikationsparametern wie der IP-Adresse begrenzen können. Wir haben auch behandelt, wie Sie die Rate der Anfragen für Ihre Webressourcen begrenzen (begrenzen Sie die Rate, mit der ein Client Anfragen stellen kann).
Um sicherzustellen, dass die Bandbreite Ihrer Anwendungsnutzung nicht von einem einzelnen Client verbraucht wird, müssen Sie die Upload- und Download-Geschwindigkeiten pro Client steuern. Dies ist eine gängige NGINX-Sicherheitskontrolle gegen DoS-Angriffe (Denial of Service) von böswilligen Benutzern, die nur versuchen, die Leistung der Website zu missbrauchen.
In diesem dritten Teil der Serie erklären wir, wie Sie die Netzwerkbandbreite auf dem NGINX-Webserver begrenzen können.
Begrenzung der Bandbreite in NGINX
Um die Bandbreite in NGINX zu begrenzen, verwenden Sie die Direktive limit_rate, die die Rate der Antwortübertragung an einen Client begrenzt. Sie ist in der HTTP-, server-, location- und if-Anweisung innerhalb eines location-Blocks gültig und gibt standardmäßig die Ratenbegrenzung für einen bestimmten Kontext in Byte pro Sekunde an. Sie können auch m für Megabyte oder g für Gigabyte verwenden.
limit_rate 20k;
Eine weitere verwandte Direktive ist limit_rate_after, die angibt, dass die Verbindung erst nach der Übertragung einer bestimmten Datenmenge ratenbegrenzt werden soll. Diese Direktive kann in der HTTP-, server-, location- und "if-Anweisung innerhalb eines location-Blocks " festgelegt werden.
limit_rate_after 500k;
Im Folgenden finden Sie eine Beispielkonfiguration, um einen Client auf das Herunterladen von Inhalten über eine einzelne Verbindung mit einer maximalen Geschwindigkeit von 20 Kilobyte pro Sekunde zu beschränken.
upstream api_service {
server 10.1.1.10:9051;
server 10.1.1.77:9052;
}
server {
listen 80;
server_name testapp.linux-console.net;
root /var/www/html/testapp.linux-console.net/build;
index index.html;
location / {
try_files $uri $uri/ /index.html =404 =403 =500;
}
location /api {
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_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
location /documents {
limit_rate 20k;
limit_rate_after 500k;
}
}
Nachdem Sie die oben beschriebenen erforderlichen Einstellungen vorgenommen haben, speichern Sie die Änderungen und schließen Sie die Datei. Überprüfen Sie anschließend, ob die NGINX-Konfigurationssyntax korrekt ist, wie folgt:
$ sudo nginx -t
Wenn alles in Ordnung ist, laden Sie den NGINX-Dienst neu, um die neuesten Änderungen vorzunehmen:
$ sudo systemctl reload nginx
Begrenzung der Bandbreite und der Anzahl der Verbindungen in NGINX
Mit der obigen Konfiguration kann der Client mehrere Verbindungen öffnen, um die Bandbreite zu erhöhen. Daher können Sie zusätzlich auch Verbindungen pro Client mithilfe eines Parameters wie einer IP-Adresse begrenzen, wie wir uns zuvor angesehen haben.
Sie können z. B. eine Verbindung pro IP-Adresse begrenzen.
upstream api_service {
server 127.0.0.1:9051;
server 10.1.1.77:9052;
}
limit_conn_zone $binary_remote_addr zone=limitconnbyaddr:20m;
limit_conn_status 429;
server {
listen 80;
server_name testapp.linux-console.net;
root /var/www/html/testapp.linux-console.net/build;
index index.html;
location / {
try_files $uri $uri/ /index.html =404 =403 =500;
}
location /api {
limit_conn limitconnbyaddr 5;
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_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
location /documents {
limit_rate 50k;
limit_rate_after 500k;
limit_conn limitconnbyaddr 1;
}
}
Dynamisches Begrenzen der Bandbreite in NGINX
Als Parameterwert für die Direktive limit_rate können Sie Variablen angeben, um die Bandbreite dynamisch zu begrenzen. Dies ist besonders nützlich in Situationen, in denen der Tarif in Abhängigkeit von einer bestimmten Bedingung begrenzt werden soll.
In diesem Beispiel verwenden wir den Map-Block. Damit konnten Sie eine neue Variable erstellen, deren Wert von den Werten einer oder mehrerer der ursprünglichen Variablen ($slow und $limit_rate) abhängt, die im ersten Parameter angegeben wurden.
upstream api_service {
server 10.1.1.10:9051;
server 10.1.1.77:9052;
}
map $slow $limit_rate {
1 20k;
2 30k;
}
server {
listen 80;
server_name testapp.linux-console.net;
root /var/www/html/testapp.linux-console.net/build;
index index.html;
location / {
try_files $uri $uri/ /index.html =404 =403 =500;
}
location /api {
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_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
location /documents {
limit_rate $limit_rate;
limit_rate_after 500k;
}
}
Hier ist ein weiteres Beispielkonfigurationsbeispiel, um die dynamische Begrenzung der Bandbreite in NGINX zu veranschaulichen. Diese Konfiguration ermöglicht es NGINX, die Bandbreite basierend auf der TLS-Version zu begrenzen. Die Direktive limit_rate_after 512 impliziert die Grenzwertrate nach dem Senden von Headern.
upstream api_service {
server 10.1.1.10:9051;
server 10.1.1.77:9052;
}
map $ssl_protocol $response_rate {
"TLSv1.1" 50k;
"TLSv1.2" 100k;
"TLSv1.3" 500k;
}
server {
listen 443 ssl;
ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3;
ssl_certificate /etc/ssl/testapp.crt;
ssl_certificate_key /etc/ssl/testapp.key;
location / {
limit_rate $response_rate; # Limit bandwidth based on TLS version
limit_rate_after 512;
proxy_pass http://api_service;
}
}
Das war alles, was wir in diesem Teil der Serie für euch hatten. Wir werden weitere Themen rund um das NGINX-Verkehrsmanagement und die Sicherheitskontrollen behandeln. Aber wie üblich können Sie über das untenstehende Feedback-Formular Fragen stellen oder Ihre Gedanken zu diesem Leitfaden teilen.