Detaillierte Erläuterung der Nginx Reverse Proxy WebSocket-Konfiguration

Kürzlich habe ich bei der Arbeit an einem Projekt das WebSocket-Protokoll verwendet und WebSocket im WeChat-Applet verwendet. Bei Verwendung des WSS-Protokolls im WeChat-Applet kann der Port nicht festgelegt werden und es kann nur der Standardport 443 verwendet werden. Verdammt, mein https lauscht bereits auf Port 443 und webSocket lauscht auch auf 443, das wird definitiv nicht funktionieren. Um eine Lösung zu finden, gab mir der Chef dieses Problem und ich nahm diese Aufgabe freudig (manuell verwirrt) an. Mir sind zwei Lösungen eingefallen. Eine Lösung besteht darin, WebSocket auf einem anderen Server bereitzustellen, aber das ist zu teuer. Eine andere Möglichkeit ist die Verwendung des Reverse-Proxys von Nginx.

Da das WebSocket-Protokoll ein auf dem HTTP-Protokoll basierendes Upgrade ist (siehe Abbildung unten), können Sie Nginx zum Reverse-Proxy-WebSocket verwenden.

webSocket

Wie aus diesem Bild ersichtlich ist, basiert der Aufbau der WebSocket-Verbindung auf dem http-Protokoll.

GET /chat HTTP/1.1
Host: server.example.com
Aktualisierung: WebSocket
Verbindung: Upgrade
Sec-WebSocket-Schlüssel: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protokoll: Chat, Superchat
Sec-WebSocket-Version: 13
Herkunft: http://example.com

Wer mit HTTP vertraut ist, hat möglicherweise festgestellt, dass diese Handshake-Anforderung dem HTTP-Protokoll ähnelt, jedoch einige zusätzliche Dinge enthält.

Aktualisierung: WebSocket
Verbindung: Upgrade
Dies ist der Kern von Websocket, der Servern wie Apache und Nginx mitteilt: Ich initiiere das Websocket-Protokoll.
Sec-WebSocket-Schlüssel: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protokoll: Chat, Superchat
Sec-WebSocket-Version: 13

Erstens ist Sec-WebSocket-Key ein Base64-codierter Wert, der vom Browser zufällig generiert wird und dem Server mitteilt: Machen Sie mir nichts vor, ich möchte überprüfen, ob Sie wirklich ein Websocket-Assistent sind.

Schließlich teilt Sec-WebSocket-Version dem Server den verwendeten Websocket-Entwurf (Protokollversion) mit. Am Anfang befand sich das Websocket-Protokoll noch im Entwurfsstadium. Es gab alle möglichen seltsamen Protokolle, und in verschiedenen Zeiträumen gab es viele seltsame und unterschiedliche Dinge, beispielsweise verwendeten Firefox und Chrome unterschiedliche Versionen. Am Anfang waren zu viele Websocket-Protokolle ein großes Problem. . Aber jetzt ist es ok, es ist geregelt und jeder nutzt es.

Der Server gibt dann Folgendes zurück und zeigt damit an, dass die Anfrage empfangen und der Websocket erfolgreich eingerichtet wurde!

HTTP/1.1 101 Protokolle wechseln
Aktualisierung: WebSocket
Verbindung: Upgrade
Sec-WebSocket-Akzeptieren: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protokoll: Chat

Dies ist der letzte Bereich, für den HTTP verantwortlich ist, und teilt dem Client mit, dass ich das Protokoll erfolgreich gewechselt habe~

Aktualisierung: WebSocket
Verbindung: Upgrade

Es ist immer noch behoben und teilt dem Client mit, dass das Websocket-Protokoll bald aktualisiert wird. An diesem Punkt hat HTTP seine gesamte Arbeit abgeschlossen und der nächste Schritt besteht darin, vollständig gemäß dem Websocket-Protokoll fortzufahren.

Sobald Sie die Prinzipien des Protokolls verstanden haben, können Sie mit dem nächsten Schritt fortfahren.

Zunächst konfiguriert nginx das https-Zertifikat

Das Serverzertifikat wurde vom Chef konfiguriert, daher habe ich es direkt verwendet. Überprüfen Sie es selbst, wenn Sie es brauchen. 0,0

Fügen Sie service in der Nginx-Konfigurationsdatei die folgende Konfiguration hinzu

Standort /wss
    {
         Proxy-Passwort http://127.0.0.1:8888;
         Proxy_http_Version 1.1;
         Proxy_Set_Header-Upgrade $http_upgrade;
         proxy_set_header Verbindung "Upgrade";
        Proxy_Set_Header X-Real-IP $Remote_Addr;
     }

Erklären Sie die Parameter

/wss ist ein zufälliger Name, der Nginx die URL zum Proxy mitteilt. Meiner ist jetzt auf wss eingestellt. Wenn ich meinen Server https://abc.com/wss besuche, wird Nginx meine Anfrage auf Port 8888 dieser Maschine abbilden.

proxy_pass ist die URL, zu der der Proxy geleitet werden soll. Mein Proxy ist Port 8888 des lokalen Computers.

proxy_http_version Die beim Proxying verwendete HTTP-Version.

Hier kommt der Punkt:

Schlüsselparameter für das Proxying von WebSocket

proxy_set_header Upgrade setzt Upgrade des HTTP-Anforderungsheaders beim Proxying auf den Anforderungsheader der ursprünglichen HTTP-Anforderung, und der Anforderungsheader des WSS-Protokolls ist websocket
proxy_set_header Connection Da der Proxy das WSS-Protokoll verwendet, wird Connection im HTTP-Anforderungsheader auf Upgrade gesetzt.

proxy_set_header X-Real-IP setzt die originale HTTP-Anforderungs-IP für den Proxy, füllen Sie einfach $remote_addr aus

Um die Antwortparameter des WebSocket-Protokolls müssen Sie sich bei der Verwendung eines Reverse-Proxys keine Gedanken machen.

An diesem Punkt ist die Konfiguration des Nginx Reverse Proxy WebSocket abgeschlossen. Starten Sie Nginx neu, versuchen Sie eine Verbindung mit WebSocket herzustellen und geben Sie wss://abc.com/wss anstelle der ursprünglichen WSS-Adresse ein. Wenn die Verbindung zum WebSocket erfolgreich hergestellt wurde, bedeutet dies, dass der Nginx-Reverse-Proxy-WebSocket erfolgreich war.

Zusammenfassen

Die aktuelle Konfiguration ist nur für Reverse-Proxying zum lokalen Rechner gedacht. Wenn Sie Reverse-Proxying zu einem anderen Host verwenden möchten, kann es beim Proxying zu domänenübergreifenden Problemen kommen. Sie müssen eine domänenübergreifende Konfiguration im Reverse-Proxy von Nginx vornehmen.

denken

Sie können diesen Abschnitt in der Nginx-Konfigurationsdatei sehen

Standort ~ .php$ {
   Stamm-HTML;
   fastcgi_pass 127.0.0.1:9000;
   fastcgi_index index.php;
   fastcgi_param SCRIPT_FILENAME $Dokumentstammsatz$fastcgi_script_name;
   fastcgi_params einschließen;
}

Dies ist die Konfigurationsdatei von PHP in Nginx. Verdammt, warum kommt sie mir so bekannt vor? Diese Konfigurationsliste ist dem Reverse-Proxy von WebSocket gerade so ähnlich. Durch Online-Recherche habe ich herausgefunden, dass Nginx, wenn es PHP-Anfragen verarbeitet, die Anfragen zur Verarbeitung an den FastCGI-Verwaltungsprozess sendet. Der FastCGI-Verwaltungsprozess wählt den CGI-Unterprozess zur Verarbeitung der Ergebnisse aus und gibt sie an Nginx zurück. PHP-FPM ist jedoch ein PHP-FastCGI-Manager. Nginx selbst kann PHP nicht verarbeiten. Es ist nur ein Webserver. Wenn es eine Anfrage empfängt, wird diese, sofern es sich um eine PHP-Anfrage handelt, zur Verarbeitung an den PHP-Interpreter gesendet und die Ergebnisse werden an den Client zurückgegeben. Wenn Nginx Anforderungen vom Typ PHP verarbeitet, wird dies daher im Wesentlichen über die Reverse-Proxy-Funktion implementiert.

Wir können unseren Horizont erweitern und den Reverse-Proxy von Nginx verwenden, um weitere Funktionen zu erreichen, wie z. B. das Proxying von Tomcat

Standort /Tomcat
    {
         Proxy-Passwort http://127.0.0.1:8080;
         Proxy_http_Version 1.1;
        Proxy_Set_Header X-Real-IP $Remote_Addr;
     }

Natürlich können Sie auch den Nginx-Reverse-Proxy verwenden, um Lastenausgleich zu erreichen. Ich habe das noch nicht ausprobiert. Ich werde mehr hinzufügen, wenn ich es später verwende.

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.