Verwendung von NGINX und NGINX Plus mit Node.js und Socket.IO, der WebSocket-API

In diesem Beitrag sprechen wir über die Verwendung von NGINX und NGINX Plus mit Node.js und Socket.IO. Unser Beitrag zum Erstellen von Echtzeit-Webanwendungen mit WebSocket und NGINX hat große Popularität erlangt, daher fahren wir in diesem Beitrag mit der Dokumentation und den Best Practices zur Verwendung von Socket.IO fort.

Warum NGINX mit Node.js und Socket.IO verwenden?

Socket.IO ist eine WebSocket-API, die mit dem Aufkommen von Node.js-Anwendungen recht populär geworden ist. Die API ist bekannt, weil sie die Erstellung von Echtzeit-Apps, etwa Online-Spielen oder Chats, vereinfacht. NGINX 1.3.13 und höher und alle NGINX Plus-Versionen unterstützen das Proxying von WebSocket-Verbindungen, wodurch Sie Socket.IO nutzen können. Das WebSocket-Protokoll ermöglicht Vollduplex- oder bidirektionale Kommunikation über eine einzelne TCP-Verbindung.

In der Produktion ausgeführte Anwendungen müssen normalerweise auf Port 80 (HTTP), Port 443 (HTTPS) oder beiden ausgeführt werden. Dies kann eine Herausforderung darstellen, wenn mehrere Komponenten Ihrer Anwendung mit dem Benutzer interagieren oder Sie einen Webserver auf Port 80 verwenden, um andere Assets bereitzustellen. Dies macht eine Proxy-Verbindung zum Socket.IO-Server erforderlich und NGINX ist hierfür die beste Möglichkeit. Unabhängig davon, ob Sie über eine oder Hunderte Instanzen Ihrer Backend-Anwendung verfügen, kann NGINX bei Verwendung mehrerer Knoten auch die Last Ihrer Upstreams ausgleichen.

Socket.IO-Konfiguration

Um Node.js zu installieren, laden Sie die entsprechende Distribution herunter (oder installieren Sie sie mit einem Paketmanager ). Führen Sie den Befehl npm install socket.io aus, um Socket.IO zu installieren.

Für dieses Beispiel gehen wir davon aus, dass der Socket.IO-Server für Ihre Echtzeit-App auf Port 5000 läuft. Das Folgende ist eine Vorlage für eine server.js- Node-Anwendungsdatei. Es handelt sich dabei um ein Basisprogramm, das als Server fungiert und eingehende Anfragen an den entsprechenden Port weiterleitet, auf dem der Socket.IO-Server ausgeführt wird.

var io = require('socket.io').listen(5000); 
io.sockets.on('connection', function (socket) {
socket.on('set nickname', function (name) {
socket.set('nickname', name, function () {
socket.emit('ready');
});
});

socket.on('msg', function () {
socket.get('nickname', function (err, name) {
console.log('Chat-Nachricht von ', name);
});
});
});

Fügen Sie der Datei, die an Ihren Client übermittelt wird, JavaScript-Code wie den folgenden hinzu, zum Beispiel index.html . Dieses Beispiel fordert eine Verbindung zu Ihrer Anwendung an, um einen WebSocket mit dem Browser Ihres Benutzers zu erstellen.

<script src="/socket.io/socket.io.js"></script>
<script>
var socket = io(); // hier Ihr Initialisierungscode.
</script>

NGINX-Konfiguration

Upstream-Erklärung

NGINX und NGINX Plus können die Last ausgleichen und Benutzersitzungen auf mehrere Knoten verteilen, wenn Ihre Anwendung über mehrere Instanzen verfügt. Fügen Sie im HTTP- Kontext Ihrer NGINX- oder NGINX Plus-Konfiguration einen Upstream- Block ein, um die Knoten in einer Upstream-Gruppe zu definieren.

Wie im folgenden Beispiel gezeigt, können Sie den Gewichtsparameter in eine Serverdirektive aufnehmen, um den Anteil des an sie geleiteten Datenverkehrs festzulegen. Hier empfängt srv1.app.com fünfmal mehr Sitzungen als die anderen Server. NGINX Plus erweitert die Reverse-Proxy-Funktionen von NGINX um verbesserte Methoden zum Lastenausgleich und durch Hinzufügen von Sitzungspersistenz, Integritätsprüfungen, erweiterten Statusberichten und einer sofortigen Neukonfiguration von Servergruppen mit Lastenausgleich.

# im http{}-Konfigurationsblock
upstream socket_nodes {
ip_hash;
server srv1.app.com:5000 weight=5;
server srv2.app.com:5000;
server srv3.app.com:5000;
server srv4.app.com:5000;
}

Konfiguration des virtuellen Hosts

Nachdem die Upstream-Servergruppe deklariert wurde, muss ein virtueller Server konfiguriert werden, um den Datenverkehr dorthin zu leiten. Schließen Sie mindestens die Direktive „proxy_pass“ ein und benennen Sie die Upstream-Gruppe. Da das WebSocket-Protokoll den in HTTP/1.1 eingeführten Upgrade- Header verwendet, schließen wir die Direktive proxy_http_version ein.

Server {
Servername app.domain.com;
Standort / {
Proxy_Set_Header Upgrade $http_upgrade;
Proxy_Set_Header Verbindung „Upgrade“;
Proxy_http_Version 1.1;
Proxy_Set_Header X-Forwarded-For $proxy_add_x_forwarded_for;
Proxy_Set_Header Host $host;
Proxy_Pass http://socket_nodes;
}
}

Was ist mit statischen Dateien?

Zum Übermitteln statischer Assets können Sie NGINX-Proxy-Anfragen an eine vorgelagerte Node.js-Instanz senden. In den meisten Fällen ist es jedoch effizienter, wenn diese direkt von NGINX bereitgestellt werden.

In Kombination mit der Direktive „server_name“ im Serverblock oben weist der folgende Standortblock NGINX an, auf Clientanforderungen für Inhalte in http://app.domain.com/assets/ zu reagieren, indem diese aus dem lokalen Verzeichnis „/path/to/assets“ bereitgestellt werden. Sie können die statische Dateiverwaltung weiter optimieren oder Cache-Ablaufeinstellungen festlegen, die Ihren Anforderungen entsprechen.

Standort /assets {
Alias /Pfad/zu/assets;
access_log off;
läuft max ab;
}

Fehlerbehebung

Wenn Sie den folgenden Fehler erhalten, verwenden Sie wahrscheinlich eine Version von NGINX vor 1.3. Die Verwendung von WebSocket wird in NGINX 1.3.13 und höher unterstützt.

WebSocket-Verbindung zu '...' fehlgeschlagen: Fehler beim WebSocket-Handshake: Der Header-Wert „Verbindung“ ist nicht „Upgrade“: Keep-Alive-Socket.io.js:2371

Weitere Informationen

• NGINX als WebSocket-Proxy
• Funktionsvergleich von NGINX und NGINX Plus
• Technische Daten zu NGINX Plus

Um NGINX Plus auszuprobieren, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.