So halten Sie eine lange Verbindung aufrecht, wenn Sie den Nginx-Reverse-Proxy verwenden

· 【Szenenbeschreibung】

Nach HTTP1.1 unterstützt das HTTP-Protokoll dauerhafte Verbindungen, auch als lange Verbindungen bezeichnet. Der Vorteil besteht darin, dass mehrere HTTP-Anfragen und -Antworten über eine TCP-Verbindung übertragen werden können, wodurch der Verbrauch und die Verzögerung beim Herstellen und Schließen von Verbindungen verringert werden.

Wenn wir nginx als Reverse-Proxy oder Load Balancer verwenden, wird die lange Verbindungsanforderung vom Client in eine kurze Verbindung umgewandelt und an den Server gesendet.

Um lange Verbindungen zu unterstützen, müssen wir einige Konfigurationen auf dem Nginx-Server vornehmen.

·【Erfordern】

Wenn Sie bei Verwendung von nginx lange Verbindungen erreichen möchten, müssen wir die folgenden zwei Dinge tun:

• Vom Client zu Nginx ist eine lange Verbindung
• Von Nginx zum Server ist eine lange Verbindung
  

Für den Client übernimmt nginx tatsächlich die Rolle eines Servers. Umgekehrt ist nginx für den Server ein Client.

[Eine lange Verbindung mit dem Kunden aufrechterhalten]

Wenn wir eine lange Verbindung zwischen Client und Nginx aufrechterhalten möchten, müssen wir:

• Die vom Client gesendete Anfrage trägt den „Keep-Alive“-Header.
• Nginx-Einstellungen unterstützen Keep-Alive
  

HTTP-Konfiguration

Standardmäßig hat nginx die Keepalive-Unterstützung für Clientverbindungen aktiviert. Für spezielle Szenarien können relevante Parameter angepasst werden.

http {

keepalive_timeout 120s; #Timeout der Clientverbindung. Wenn der Wert 0 ist, sind lange Verbindungen deaktiviert.

keepalive_requests 10000; #Die maximale Anzahl von Anfragen, die über eine lange Verbindung bedient werden können.

                         #Wenn die maximale Anzahl an Anfragen erreicht ist und alle bestehenden Anfragen abgeschlossen sind, wird die Verbindung geschlossen.

                         #Der Standardwert ist 100

}

In den meisten Fällen ist „keepalive_requests = 100“ ausreichend, aber für Szenarien mit hohem QPS ist es notwendig, diesen Parameter zu erhöhen, um zu vermeiden, dass eine große Anzahl von Verbindungen hergestellt und dann abgebrochen wird, und um TIME_WAIT zu reduzieren.

Wenn QPS = 10000 ist, sendet der Client 10.000 Anfragen pro Sekunde (normalerweise werden mehrere lange Verbindungen hergestellt) und jede Verbindung kann maximal 100 Anfragen ausführen, was bedeutet, dass nginx im Durchschnitt 100 lange Verbindungen pro Sekunde schließt.

Dies bedeutet auch, dass der Client zur Aufrechterhaltung der QPS 100 Verbindungen pro Sekunde neu herstellen muss.

Wenn Sie daher den Befehl netstat zum Anzeigen des Client-Computers verwenden, werden Sie eine große Anzahl von TIME_WAIT-Socket-Verbindungen vorfinden (auch wenn zwischen dem Client und NGINX bereits Keep-Alive aktiviert ist).

[Eine lange Verbindung mit dem Server aufrechterhalten]

Um eine dauerhafte Verbindung zwischen Nginx und dem Server aufrechtzuerhalten, sind die einfachsten Einstellungen wie folgt:

http {

Upstream-Backend {

  Server 192.168.0.1:8080 Gewicht=1 max_fails=2 Fail_Timeout=30s;

  Server 192.168.0.2:8080 Gewicht=1 max_fails=2 Fail_Timeout=30s;

  keepalive 300; // Das ist wichtig!

}

   Server {

hören Sie 8080 Standardserver;

Servername "";



   Standort / {

Proxy-Passwort http://backend;

proxy_http_version 1.1; # Setze die HTTP-Version auf 1.1

proxy_set_header Connection ""; # Setze Verbindung auf lange Verbindung (Standard ist nein)}

}

}

}

【Upstream-Konfiguration】

Im Upstream gibt es einen besonders wichtigen Parameter: Keepalive.

Dieser Parameter unterscheidet sich vom Keepalive_Timeout im vorherigen HTTP.

Die Bedeutung dieses Parameters ist die maximale Anzahl inaktiver Verbindungen im Verbindungspool.

Nicht verstanden? Das ist egal, nehmen wir ein Beispiel:

Szenario:

Es gibt einen HTTP-Dienst, der als Upstream-Server Anfragen mit einer Antwortzeit von 100 Millisekunden entgegennimmt.

Um eine Leistung von 10.000 QPS zu erreichen, müssen wir ungefähr 1.000 HTTP-Anfragen zwischen nginx und dem Upstream-Server herstellen. (1000/0,1 s = 10000)

Bester Fall:

Vorausgesetzt, die Anforderungen sind sehr gleichmäßig und stabil, dauert jede Anforderung 100 ms, und die Anforderung wird sofort in den Verbindungspool gestellt und in den Leerlaufzustand versetzt.

Wir verwenden 0,1s als Einheit:

1. Wir setzen nun den Keepalive-Wert auf 10, mit 1000 Verbindungen alle 0,1s

2. Innerhalb von 0,1 s haben wir insgesamt 1.000 Anfragen erhalten und freigegeben

3. Nach 0,2 s erhielten wir weitere 1.000 Anfragen, die nach Ablauf der 0,2 s freigegeben wurden.

Die Anforderungen und Antworten sind relativ gleichmäßig, die alle 0,1 s freigegebene Verbindung ist gerade ausreichend, es muss keine neue Verbindung hergestellt werden und es gibt keine inaktiven Verbindungen im Verbindungspool.

Erster Fall:

Die Antwort ist sehr stabil, aber die Anfrage ist nicht stabil

4. In 0,3 Sekunden haben wir nur 500 Anfragen erhalten, und 500 Anfragen gingen aufgrund von Netzwerkverzögerungen und anderen Gründen nicht ein

Zu diesem Zeitpunkt erkennt Nginx, dass sich im Verbindungspool 500 inaktive Verbindungen befinden, und schließt daher direkt (500-10) Verbindungen.

5. Nach 0,4 s haben wir 1500 Anfragen erhalten, aber es gibt nur (500+10) Verbindungen im Pool, sodass Nginx (1500-510) Verbindungen erneut herstellen muss.

Wenn die 490 Verbindungen in Schritt 4 nicht geschlossen werden, müssen nur 500 Verbindungen neu hergestellt werden.

Zweiter Fall:

Wenn die Anfrage sehr stabil ist, die Antwort jedoch nicht stabil ist

4. In 0,3 Sekunden erhielten wir insgesamt 1500 Anfragen

Es gibt jedoch nur 1000 Verbindungen im Pool. Zu diesem Zeitpunkt erstellt Nginx weitere 500 Verbindungen, insgesamt 1500 Verbindungen

5. Nach 0,3 s wurden alle Verbindungen freigegeben und wir erhielten 500 Anfragen

Nginx hat festgestellt, dass sich im Pool 1000 inaktive Verbindungen befanden, und musste daher (1000-10) Verbindungen freigeben.

Ein Grund dafür, dass die Verbindungsanzahl immer wieder schwankt, ist die durch Keepalive festgelegte maximale Anzahl an Leerlaufverbindungen.

Bei den beiden oben genannten Situationen handelt es sich um unangemessene Keepalive-Einstellungen, die dazu führen, dass Nginx Verbindungen mehrmals freigibt und aufbaut, was zu einer Ressourcenverschwendung führt.

Seien Sie beim Festlegen des Keepalive-Parameters vorsichtig, insbesondere in Szenarien mit hohen QPS-Anforderungen oder instabilen Netzwerkumgebungen. Im Allgemeinen kann die Anzahl der erforderlichen langen Verbindungen anhand des QPS-Werts und der durchschnittlichen Antwortzeit grob geschätzt werden.

Stellen Sie dann den Keepalive-Wert auf 10 % bis 30 % der Anzahl der dauerhaften Verbindungen ein.

【Standortkonfiguration】

http {

Server {

Standort / {

Proxy-Passwort http://backend;

proxy_http_version 1.1; # Setze die HTTP-Version auf 1.1

proxy_set_header Connection ""; # Setze Verbindung auf lange Verbindung (Standard ist nein)

}

}

}

Die Unterstützung für dauerhafte Verbindungen im HTTP-Protokoll ist erst seit Version 1.1 verfügbar, daher ist es am besten, die Direktive proxy_http_version auf 1.1 zu setzen.

HTTP1.0 unterstützt die Keepalive-Funktion nicht. Wenn HTTP1.1 nicht verwendet wird, gibt der Backend-Dienst einen 101-Fehler zurück und trennt dann die Verbindung.

Der Header „Connection“ kann bereinigt werden, sodass auch bei einer kurzen Verbindung zwischen Client und Nginx eine lange Verbindung zwischen Nginx und Upstream geöffnet werden kann.

[Eine weitere fortgeschrittene Methode]

http {

Karte $http_upgrade $connection_upgrade {

Standard-Upgrade;

'' schließen;

}

   Upstream-Backend {

Server 192.168.0.1:8080 Gewicht=1 max_fails=2 Fail_Timeout=30s;

Server 192.168.0.2:8080 Gewicht=1 max_fails=2 Fail_Timeout=30s;

Keepalive 300;

}

   Server {

hören Sie 8080 Standardserver;

Servername "";

Standort / {

Proxy-Passwort http://backend;



   proxy_connect_timeout 15; #Verbindungstimeout mit Upstream-Server (keine Einheit, Maximum darf 75 s nicht überschreiten)

proxy_read_timeout 60s; #Wie lange wartet nginx auf eine Antwort auf eine Anfrage proxy_send_timeout 12s; #Timeout für das Senden einer Anfrage an einen Upstream-Server

   Proxy_http_Version 1.1;

Proxy_Set_Header-Upgrade $http_upgrade;

proxy_set_header Verbindung $connection_upgrade;

}

}

}

Die Funktion von map in http ist:

Machen Sie den Wert des an den Proxy-Server weitergeleiteten Header-Felds „Verbindung“ vom Wert des Felds „Upgrade“ im Client-Anforderungsheader abhängig.

Wenn $http_upgrade nicht übereinstimmt, lautet der Wert des Header-Felds „Connection“ „Upgrade“.

Wenn $http_upgrade eine leere Zeichenfolge ist, ist der Wert des Header-Felds „Connection“ nahe dran.

【Auffüllen】

NGINX unterstützt WebSocket.

Damit NGINX die Upgrade-Anforderung vom Client an den Backend-Server senden kann, müssen die Upgrade- und Connection-Header explizit festgelegt werden.

Dies ist auch in der obigen Situation ein sehr häufiges Szenario.

Der HTTP-Upgrade-Protokollheadermechanismus wird verwendet, um die Verbindung von einer HTTP-Verbindung auf eine WebSocket-Verbindung zu aktualisieren. Der Upgrade-Mechanismus verwendet den Upgrade-Protokollheader und den Connection-Protokollheader.

Damit Nginx die Upgrade-Anforderung vom Client an den Backend-Server senden kann, müssen die Upgrade- und Connection-Header explizit festgelegt werden.

【Beachten】

Wenn in der Nginx-Konfigurationsdatei im aktuellen Modul keine Proxy_set_header-Einstellung vorhanden ist, wird die Konfiguration von der höheren Ebene übernommen.

Die Vererbungsreihenfolge ist: http, Server, Standort.

Wenn der Header-Wert mithilfe von proxy_set_header in der nächsten Ebene geändert wird, können sich alle Header-Werte ändern und alle zuvor übernommenen Konfigurationen werden verworfen.

Versuchen Sie daher, proxy_set_header an derselben Stelle auszuführen, da sonst möglicherweise weitere Probleme auftreten.

· 【siehe】

Offizielle chinesische Nginx-Dokumentation: http://www.nginx.cn/doc/

Testreferenzdokument: https://www.lijiaocn.com/问题/2019/05/08/nginx-ingress-keep-alive-not-work.html

Keep-Alive-Referenzdokument: https://wglee.org/2018/12/02/nginx-keepalive/

Oben finden Sie Einzelheiten dazu, wie Sie bei Verwendung des Nginx-Reverse-Proxys eine lange Verbindung aufrechterhalten. Weitere Informationen dazu, wie Sie mit Nginx eine lange Verbindung aufrechterhalten, finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!