So verwenden Sie die Ratenbegrenzung in NGINX

Die Ratenbegrenzung in NGINX ist eine wichtige Funktion zur Kontrolle der Datenverkehrsmenge, die Ihr Server verarbeitet. Sie schützt Ihren Server vor einer Überlastung durch zu viele Anfragen in kurzer Zeit, die durch böswillige Angriffe wie DDoS oder hohe Datenverkehrsspitzen verursacht werden kann. Durch die Implementierung der Ratenbegrenzung wird sichergestellt, dass Ihre Ressourcen effizient genutzt werden und legitime Benutzer ohne Unterbrechung auf Ihre Dienste zugreifen können.

In diesem Handbuch wird gezeigt, wie Sie die Ratenbegrenzung in NGINX konfigurieren. Es enthält klare Anweisungen, die Ihnen dabei helfen, eingehenden Datenverkehr effektiv zu verwalten und zu kontrollieren.

Grundlegendes zu Rate Limit-Richtlinien in NGINX

Wichtige NGINX-Richtlinien zur Ratenbegrenzung

NGINX konfiguriert die Ratenbegrenzung mithilfe spezifischer Anweisungen, von denen jede eine einzigartige Funktion erfüllt:

  • limit_req_zone: Die Direktive limit_req_zone in NGINX richtet eine gemeinsam genutzte Speicherzone zum Speichern von Informationen zur Ratenbegrenzung ein. Im HTTP-Kontext positioniert, bestimmt sie die zulässige Anfragerate und legt damit effektiv die Basis für Ratenbegrenzungen fest.
  • Grenzwert_Anforderung: Die im Standortkontext verwendete Direktive limit_req erzwingt die von limit_req_zone festgelegte Ratenbegrenzung. Sie wendet diese Beschränkungen auf bestimmte Standorte oder URLs an und steuert so die Zugriffshäufigkeit auf diese Endpunkte.
  • limit_req_status: Im Standortkontext positioniert, gibt die Direktive limit_req_status den HTTP-Statuscode an, der zurückgegeben wird, wenn die Anforderungsrate den Grenzwert überschreitet. Dieser Feedback-Mechanismus ist entscheidend, um Benutzer oder automatisierte Systeme zu informieren, wenn sie die zulässige Anforderungshäufigkeit überschreiten.

Erstellen einer Ratenbegrenzungskonfiguration

Um die Ratenbegrenzung in NGINX zu implementieren, fügen Sie die entsprechenden Anweisungen in die NGINX-Konfigurationsdatei ein. Betrachten Sie dieses einfache Beispiel:

http {
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;

    server {
        ...
        location / {
            limit_req zone=mylimit burst=10;
            ...
        }
    }
}

In dieser Konfiguration richtet die Direktive limit_req_zone eine Speicherzone namens „mylimit“ ein, die 5 Anfragen pro Sekunde (5r/s) von jeder Client-IP-Adresse ($binary_remote_addr) zulässt. Die Direktive limit_req wendet diese Ratenbegrenzung dann auf den Stammspeicherort (/) an, mit einer Burst-Kapazität von 10 Anfragen, und bietet so ein Gleichgewicht zwischen strikter Ratenbegrenzung und Flexibilität für legitime Verkehrsspitzen.

Rate Limit in NGINX: Praktische Beispiele

Grundlegende Konfiguration der Ratenbegrenzung

In diesem Abschnitt wird eine grundlegende Ratenbegrenzungskonfiguration erläutert, die serverweit in NGINX angewendet wird. Ziel ist es, Benutzeranforderungen an den Server zu begrenzen, eine stabile Leistung sicherzustellen und das Risiko einer Überlastung zu verringern.

Beispiel: Serverweite Ratenbegrenzung

Betrachten Sie die folgende 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;
        }
    }
}

Diese Konfiguration legt ein Limit von 2 Anfragen pro Sekunde für jeden Client fest, wie durch seine IP-Adresse definiert ($binary_remote_addr). Lassen Sie uns die wichtigsten Komponenten aufschlüsseln:

  • limit_req_zone: Definiert eine Speicherzone (mylimit) zum Speichern der Ratenbegrenzungszustände mit einer Größe von 10 Megabyte. Es legt die Ratenbegrenzung auf 2 Anfragen pro Sekunde (2r/s) fest.
  • Serverblock: Lauscht auf Port 80 auf eingehenden Datenverkehr zu example.com.
  • Standortblock: Wendet die Ratenbegrenzung auf die Stamm-URL (/) an. Der Burst-Parameter ermöglicht einen Burst von bis zu 5 Anfragen und bietet so Flexibilität für kurze Verkehrsspitzen. Die Proxy_pass-Direktive leitet die Anfrage an den angegebenen Backend-Server weiter.
  • Burst-Parameter: Die Einstellung „burst=5“ in der Direktive „limit_req“ ermöglicht eine kurzfristige Erhöhung der Anfragen um bis zu 5 zusätzliche Anfragen über der festgelegten Rate. Diese Funktion ist entscheidend für die Handhabung plötzlicher, legitimer Verkehrsanstiege ohne Beeinträchtigung der Benutzererfahrung.
  • Proxy-Pass: Die Direktive proxy_pass http://backend; leitet den Datenverkehr an einen Backend-Server weiter. Dies wird häufig in Lastausgleichsszenarien verwendet oder wenn NGINX als Reverse-Proxy fungiert.

Beispiele für erweiterte Ratenbegrenzungen

Unterschiedliche Ratenbegrenzungen für unterschiedliche Standorte

In komplexeren Szenarien müssen Sie möglicherweise unterschiedliche Ratenbegrenzungen auf unterschiedliche Anwendungsteile anwenden. Dies ist insbesondere dann nützlich, wenn bestimmte Endpunkte ressourcenintensiver oder anfälliger für Missbrauch sind.

Betrachten Sie die folgende 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;
        }
    }
}

Diese Konfiguration wendet eine niedrigere Ratenbegrenzung (1 Anforderung pro Sekunde) auf den Standort /api/low und eine höhere Ratenbegrenzung (10 Anforderungen pro Sekunde) auf den Standort /api/high an.

Weitere Beispiele zur Ratenbegrenzung bei Nginx

Ratenbegrenzung basierend auf Anforderungstypen

Sie können die Ratenbegrenzung basierend auf bestimmten Anfragen konfigurieren, z. B. GET-, POST- oder PUT-Anfragen. Dies ist besonders nützlich, wenn Sie bestimmte Endpunkte schützen möchten, die anfälliger für Missbrauch sind oder einen größeren Einfluss auf Ihre Serverressourcen haben.

Sie können die if-Direktive und die Variable $request_method verwenden, um die Ratenbegrenzung auf bestimmte Anfragetypen anzuwenden. Hier ist ein Beispiel:

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 dieser Konfiguration haben wir zwei separate Ratenlimits eingerichtet: eines für GET-Anfragen (5 Anfragen pro Sekunde) und eines für POST-Anfragen (2 Anfragen pro Sekunde).

Ratenbegrenzung basierend auf User-Agent

Eine weitere hilfreiche Technik ist die Anwendung einer Ratenbegrenzung basierend auf dem von den Clients gesendeten User-Agent-Header. Dies kann dazu beitragen, Ihre Dienste vor bestimmten Bots oder Crawlern zu schützen, die Probleme verursachen.

Um eine auf dem User-Agent basierende Ratenbegrenzung zu implementieren, können Sie die Map-Direktive und die Variable $http_user_agent verwenden.

Hier ist ein Beispiel:

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 diesem Beispiel haben wir eine Map-Direktive definiert, die die Variable $limit_bots auf 1 setzt, wenn der User-Agent-Header mit „Googlebot“ oder „Bingbot“ übereinstimmt. Wir wenden dann ein Ratenlimit von 1 Anfrage pro Sekunde auf Anfragen von diesen Bots an.

Whitelist für IPs zur Ratenbegrenzung

Manchmal möchten Sie vielleicht bestimmte IP-Adressen, wie vertrauenswürdige Partner oder interne Dienste, von der Ratenbegrenzung ausnehmen. Um dies zu erreichen, können Sie die Geo-Direktive zusammen mit der if Richtlinie.

Hier ist ein Beispiel:

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;
        }
    }
}

Skalierungsratenbegrenzung in einer verteilten Umgebung

Wenn mehrere Nginx-Instanzen in einer verteilten Umgebung ausgeführt werden, möchten Sie möglicherweise sicherstellen, dass die Ratenbegrenzung für alle Instanzen einheitlich ist. Sie können einen zentralisierten Datenspeicher wie Redis verwenden, um die Ratenbegrenzungen zu verwalten und dies zu erreichen. Auf diese Weise können Sie eine globale Ratenbegrenzung verwalten, die von allen Nginx-Instanzen gemeinsam genutzt wird.

Um die Ratenbegrenzung mit Redis einzurichten, müssen Sie das Modul nginx-module-redis installieren und konfigurieren. Nachdem Sie das Modul installiert haben, können Sie Ihre Nginx-Konfiguration aktualisieren, um Redis zur Ratenbegrenzung zu verwenden.

Hier ist ein Beispiel:

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 diesem Beispiel haben wir einen Upstream-Block für den Redis-Server definiert und den Standortblock aktualisiert, um die Direktive limit_req_redis anstelle der Standarddirektive limit_req zu verwenden. Diese Konfiguration stellt sicher, dass Ratenbegrenzungen mithilfe des gemeinsam genutzten Redis-Datenspeichers durchgesetzt werden, wodurch eine konsistente Ratenbegrenzung über mehrere Nginx-Instanzen hinweg gewährleistet wird.

Dynamische Ratenbegrenzung

In manchen Situationen möchten Sie die Ratenbegrenzungen möglicherweise dynamisch an bestimmte Bedingungen oder die aktuelle Belastung Ihres Servers anpassen. Beispielsweise möchten Sie möglicherweise während der Spitzenverkehrszeiten strengere Ratenbegrenzungen anwenden, um die Serverressourcen besser zu verwalten.

Zur Implementierung einer dynamischen Ratenbegrenzung können Sie den map Richtlinie zum Definieren von Ratenbegrenzungen basierend auf bestimmten Bedingungen.

Hier ist ein Beispiel:

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 dieser Konfiguration verwenden wir die Variable $http_x_traffic, die aus einem benutzerdefinierten Header X-Traffic abgeleitet ist. Basierend auf dem Wert dieses Headers legen wir die Ratenbegrenzung dynamisch fest. Wenn der Header-Wert „hoch“ ist, wenden wir eine strengere Ratenbegrenzung von 2 Anfragen pro Sekunde an. Andernfalls verwenden wir die Standardrate von 5 Anfragen pro Sekunde.

Beachten Sie, dass in diesem Beispiel davon ausgegangen wird, dass Ihr Backend-Server oder eine andere Komponente in Ihrer Infrastruktur den X-Traffic-Header basierend auf Ihren gewünschten Bedingungen festlegt.

Testen Ihrer Ratenbegrenzung in der NGINX-Konfiguration

Überprüfen der Ratenbegrenzung mit curl

Verwenden von curl zum Testen einfacher Anfragen

Um die Wirksamkeit Ihrer Ratenbegrenzungskonfiguration in NGINX zu überprüfen, erweist sich curl, ein Befehlszeilentool zum Senden von HTTP-Anfragen, als äußerst nützlich. Es kann schnell mehrere Anfragen an Ihren Server senden und Ihnen so dabei helfen, festzustellen, ob die Ratenbegrenzungen aktiv sind.

for i in {1..10}; do curl -I http://example.com; done
  • Dieser Befehl sendet 10 HEAD-Anfragen an Ihren Server, die auf http://example.com abzielen.
  • Analysieren Sie die HTTP-Antwortheader dieser Anfragen, um die Funktion zur Ratenbegrenzung zu überprüfen.
  • NGINX sollte den Statuscode 429 „Zu viele Anfragen“ zurückgeben, wenn die Anzahl der Anfragen den von Ihnen angegebenen Grenzwert überschreitet.

Testen mit Apache Bench (ab)

Benchmarking von Serverantworten mit Apache Bench

Apache Bench (ab) ist ein effektives Benchmarking-Tool, das sich ideal zum Testen von Ratenbegrenzungen durch Simulation von Bedingungen mit hohem Datenverkehr eignet. Es hilft zu verstehen, wie sich Ihr NGINX-Server bei einer Flut von Anfragen verhält.

ab -n 100 -c 10 http://example.com/
  • Dieser Befehl weist ab an, 100 Anfragen mit einem Parallelitätsgrad von 10 an http://example.com zu senden.
  • Die Ausgabe von ab bietet Einblicke in die geschwindigkeitsbegrenzende Wirksamkeit.
  • Konzentrieren Sie sich auf die Anzahl der fehlgeschlagenen Anfragen in der Ausgabe. Diese sollte mit den Einstellungen Ihrer NGINX-Ratenbegrenzungskonfiguration übereinstimmen.

Durch den Einsatz der besten Methoden zum Testen Ihrer NGINX-Konfiguration wird sichergestellt, dass Ihre Ratenbegrenzungsregeln wie vorgesehen funktionieren.

Abschluss

Durch die Konfiguration einer Ratenbegrenzung in NGINX können Sie Ihren Server vor übermäßigem Datenverkehr und potenziellem Missbrauch schützen. Dies trägt dazu bei, die Leistung und Verfügbarkeit Ihrer Dienste aufrechtzuerhalten und ein besseres Erlebnis für legitime Benutzer zu gewährleisten. Überwachen und passen Sie Ihre Ratenbegrenzungseinstellungen regelmäßig an, um Sicherheit und Zugänglichkeit in Einklang zu bringen. Die Implementierung dieser Kontrollen ist für die effiziente Verwaltung der Ressourcen Ihres Servers von entscheidender Bedeutung.

Joshua James
Folgen Sie mir
Letzte Artikel von Joshua James (Alle anzeigen)

Hinterlasse einen Kommentar