NGINX als WebSocket-Proxy

Das WebSocket -Protokoll bietet eine Möglichkeit zum Erstellen von Webanwendungen, die eine bidirektionale Echtzeitkommunikation zwischen Clients und Servern unterstützen. Als Teil von HTML5 erleichtert WebSocket die Entwicklung dieser Art von Anwendungen erheblich im Vergleich zu den bisher verfügbaren Methoden. Die meisten modernen Browser unterstützen WebSocket, darunter Chrome, Firefox, Internet Explorer, Opera und Safari, und auch immer mehr Server-Anwendungs-Frameworks unterstützen mittlerweile WebSocket.

Für den Produktionseinsatz in Unternehmen, wo mehrere WebSocket-Server für Leistung und hohe Verfügbarkeit benötigt werden, ist eine Lastausgleichsschicht erforderlich, die das WebSocket-Protokoll versteht. NGINX unterstützt WebSocket seit Version 1.3 und kann als Reverse-Proxy fungieren und den Lastausgleich von WebSocket-Anwendungen durchführen. (Alle Versionen von NGINX Plus unterstützen auch WebSocket.)

Sehen Sie sich die neuesten Leistungstests zur Skalierbarkeit von NGINX zum Lastenausgleich von WebSocket-Verbindungen an.

Das WebSocket-Protokoll unterscheidet sich vom HTTP-Protokoll, aber der WebSocket-Handshake ist mit HTTP kompatibel und verwendet die HTTP-Upgrade-Funktion, um die Verbindung von HTTP auf WebSocket zu aktualisieren. Dadurch lassen sich WebSocket-Anwendungen einfacher in vorhandene Infrastrukturen integrieren. Beispielsweise können WebSocket-Anwendungen die Standard-HTTP-Ports 80 und 443 verwenden und so die Verwendung vorhandener Firewall-Regeln ermöglichen.

Eine WebSocket-Anwendung hält eine dauerhafte Verbindung zwischen dem Client und dem Server aufrecht und erleichtert so die Entwicklung von Echtzeitanwendungen. Der HTTP-Upgrade-Mechanismus zum Upgrade der Verbindung von HTTP auf WebSocket verwendet die Upgrade- und Connection- Header. Bei der Unterstützung von WebSocket steht ein Reverse-Proxy-Server vor einigen Herausforderungen. Einer davon ist, dass WebSocket ein Hop-by-Hop-Protokoll ist. Wenn also ein Proxyserver eine Upgrade-Anforderung von einem Client abfängt, muss er seine eigene Upgrade-Anforderung einschließlich der entsprechenden Header an den Backend-Server senden. Da WebSocket-Verbindungen im Gegensatz zu den typischen kurzlebigen Verbindungen, die von HTTP verwendet werden, langlebig sind, muss der Reverse-Proxy diese Verbindungen offen lassen, anstatt sie zu schließen, weil sie inaktiv zu sein scheinen.

NGINX unterstützt WebSocket, indem es die Einrichtung eines Tunnels zwischen einem Client und einem Backend-Server ermöglicht. Damit NGINX die Upgrade-Anforderung vom Client an den Backend-Server senden kann, müssen die Upgrade- und Connection- Header explizit festgelegt werden, wie in diesem Beispiel:

Standort /wsapp/ { Proxy-Passwort http://wsbackend;
Proxy-http_Version 1.1;
Proxy-Set-Header Upgrade $http_upgrade;
Proxy-Set-Header Verbindung „Upgrade“;
Proxy-Set-Header Host $host;
}

Sobald dies erledigt ist, behandelt NGINX dies als eine WebSocket-Verbindung.

NGINX WebSocket-Beispiel

Hier ist ein Livebeispiel, das zeigt, wie NGINX als WebSocket-Proxy funktioniert. Dieses Beispiel verwendet ws , eine auf Node.js basierende WebSocket-Implementierung. NGINX fungiert als Reverse-Proxy für eine einfache WebSocket-Anwendung, die ws und Node.js nutzt. Diese Anweisungen wurden mit Ubuntu 13.10 und CentOS 6.5 getestet, müssen aber möglicherweise für andere Betriebssysteme und Versionen angepasst werden. In diesem Beispiel lautet die IP-Adresse des WebSocket-Servers 192.168.100.10 und die IP-Adresse des NGINX-Servers 192.168.100.20.

1. Wenn Sie Node.js und npm noch nicht installiert haben, führen Sie den folgenden Befehl aus:

   • Für Debian und Ubuntu:

     $ sudo apt-get installiere nodejs npm

   • Für RHEL und CentOS:

     $ sudo yum installiere nodejs npm

2. Node.js wird unter Ubuntu als Node.js und unter CentOS als Node installiert. Das Beispiel verwendet node , daher müssen wir unter Ubuntu einen symbolischen Link von nodejs zu node erstellen:

   $ ln -s /usr/bin/nodejs /usr/local/bin/node

3. Um ws zu installieren, führen Sie den folgenden Befehl aus:

   $ sudo npm installiere ws

   Notiz: Wenn Sie die Fehlermeldung erhalten: „Fehler: Abrufen aus Registrierung fehlgeschlagen: ws“, führen Sie den folgenden Befehl aus, um das Problem zu beheben:

   $ sudo npm config set registry http://registry.npmjs.org/

   Führen Sie dann den Befehl „sudo npm install ws“ erneut aus.

4. ws wird mit dem Programm /root/node_modules/ws/bin/wscat geliefert, das wir für unseren Client verwenden werden, aber wir müssen ein Programm erstellen, das als Server fungiert. Erstellen Sie eine Datei namens server.js mit folgendem Inhalt:

   console.log("Server gestartet");
   var Msg = '';
   var WebSocketServer = require('ws').Server
   , wss = neuer WebSocketServer({port: 8010});
   wss.on('Verbindung', Funktion(ws) {
   ws.on('Nachricht', Funktion(Nachricht) {
   console.log('Vom Client empfangen: %s', Nachricht);
   ws.send('Server hat vom Client empfangen: ' + Nachricht);
   });
   });

5. Um das Serverprogramm auszuführen, führen Sie den folgenden Befehl aus:

   $ Knoten server.js

6. Der Server gibt zunächst die Meldung „Server gestartet“ aus und lauscht dann auf Port 8010, während er darauf wartet, dass sich ein Client mit ihm verbindet. Wenn es eine Client-Anforderung empfängt, gibt es diese wieder und sendet eine Nachricht mit der empfangenen Nachricht an den Client zurück. Damit NGINX diese Anfragen als Proxy verwendet, erstellen wir die folgende Konfiguration. Wir fügen den Map- Block hinzu, damit der Verbindungsheader korrekt so eingestellt ist, dass er geschlossen wird, wenn der Upgrade- Header in der Anforderung auf „“ gesetzt ist.

   http {
   map $http_upgrade $connection_upgrade {
   Standard-Upgrade;
   '' schließen;
   }
   
   Upstream-Websocket {
   Server 192.168.100.10:8010;
   }
   
   Server {
   listen 8020;
   Standort / {
   Proxy-Passwort http://Websocket;
   Proxy-http_Version 1.1;
   Proxy-Set-Header Upgrade $http_upgrade;
   Proxy-Set-Header Verbindung $connection_upgrade;
   Proxy-Set-Header Host $host;
   }
   }
   }

   NGINX lauscht auf Port 8020 und leitet Anfragen per Proxy an den Backend-WebSocket-Server weiter. Die proxy_set_header- Direktiven ermöglichen NGINX, das WebSocket-Protokoll ordnungsgemäß zu verarbeiten.

7. Um den Server zu testen, führen wir wscat als unseren Client aus:

   $ /root/node_modules/ws/bin/wscat --connect ws://192.168.100.20:8020

   wscat stellt über den NGINX-Proxy eine Verbindung zum WebSocket-Server her. Wenn Sie eine Nachricht eingeben, die wscat an den Server senden soll, wird diese auf dem Server als Echo angezeigt und anschließend erscheint eine Nachricht vom Server auf dem Client. Hier ist eine Beispielinteraktion:

   Server:	Kunde:
   $ Knoten server.js Server gestartet
   	wscat --connect ws://192.168.100.20:8020 Verbunden (zum Beenden STRG+C drücken) > Hallo
   Vom Kunden erhalten: Hallo
   	<Server hat vom Client empfangen: Hallo

   Hier sehen wir, dass Client und Server über NGINX kommunizieren können, das als Proxy fungiert, und dass weiterhin Nachrichten hin und her gesendet werden können, bis entweder der Client oder der Server die Verbindung trennt. Damit NGINX WebSocket ordnungsgemäß verarbeiten kann, müssen lediglich die Header richtig eingestellt werden, um die Upgrade-Anforderung zu verarbeiten, die die Verbindung von HTTP auf WebSocket aktualisiert.

Weitere Informationen

• WebSocket-Proxying bei nginx.org
• Funktionsvergleich von NGINX und NGINX Plus
• Technische Daten zu NGINX Plus

• Konfigurieren des Proxys für WebSocket-Datenverkehr in:

  • Lastenausgleich für Apache Tomcat-Server mit NGINX Open Source und NGINX Plus
  • Lastenausgleich für Node.js-Anwendungsserver mit NGINX Open Source und NGINX Plus
  • Lastenausgleich für Oracle WebLogic Server mit NGINX Open Source und NGINX Plus
  • Lastausgleich für Wildfly- und JBoss-Anwendungsserver mit NGINX Open Source und NGINX Plus