Echtzeit-Webanwendungen mit WebSocket und NGINX
Im Blogbeitrag „NGINX als WebSocket-Proxy“ haben wir die Verwendung von NGINX zum Proxying von WebSocket- Anwendungsservern besprochen. In diesem Beitrag besprechen wir einige Architektur- und Infrastrukturaspekte, die bei der Erstellung von Echtzeitanwendungen mit WebSocket zu berücksichtigen sind, darunter die benötigten Komponenten und wie Sie Ihre Systeme strukturieren können.
WebSocket fügt HTTP Interaktivität hinzu
HTTP eignet sich gut für Webanwendungen, die auf Anfragen/Antworten basieren. Dabei geht der Kommunikationsfluss immer davon aus, dass der Client die Anfrage initiiert, auf die ein Backend-Server antwortet. Webanwendungen mit einer interaktiveren, nachrichtenbasierten Interaktion zwischen Client und Server erfordern mehr als einfaches HTTP. Frühere Versuche, die Vollduplex-Kommunikation über HTTP zu simulieren, waren kompliziert und hatten viele Nachteile. Das WebSocket-Protokoll bietet zusammen mit der WebSocket-JavaScript-Schnittstelle eine viel einfachere Möglichkeit zum Erstellen dieser Art von Anwendungen und reduziert gleichzeitig die übertragene Datenmenge und die Latenz.
Die Möglichkeit, eine Vollduplex-Socket-Verbindung zwischen Client und Server herzustellen, ermöglicht die Entwicklung ereignisgesteuerter Webanwendungen in Echtzeit, die Push-, Poll- oder Streaming-Kommunikation nutzen. Mithilfe von WebSocket kann entweder der Client oder der Server die Kommunikation initiieren, nachdem die Verbindung hergestellt wurde. Dies ermöglicht viele Arten von Webanwendungen, darunter Online-Spiele, Chat, Aktienverfolgung und Echtzeitberichte von Sportergebnissen.
Ein weiterer Anwendungsfall für WebSocket ist die Entwicklung von WebRTC -basierten Anwendungen. WebRTC wird zum Erstellen von Anwendungen verwendet, die Browser-zu-Browser-Kommunikation ermöglichen. Für die Einrichtung der Kommunikation ist ein separater Signalkanal erforderlich. WebSocket ist hierfür ein gutes Protokoll.
Technische Voraussetzungen für eine WebSocket-Anwendung
Die für eine WebSocket-Webanwendung erforderliche Mindestinfrastruktur ist ein Client-Browser, der eine WebSocket-JavaScript-Anwendung ausführt und mit einem WebSocket-Server kommuniziert. Die aktuellen Versionen aller gängigen Browser unterstützen mittlerweile WebSocket. Es muss jedoch sichergestellt werden, dass die Clients über einen Browser mit WebSocket-Unterstützung verfügen. Es gibt viele Optionen für WebSocket-Server. Hier sind einige Beispiele für unterschiedliche Umgebungen (diese Liste dient Ihrer Bequemlichkeit und stellt keine Billigung durch NGINX, Inc. dar):
Skalieren von WebSocket für hohe Datenverkehrsmengen
Es ist möglich, einen einzelnen WebSocket-Server zu verwenden, aber die Anwendungsleistung wird durch die Kapazität des Servers begrenzt, der auch einen einzelnen Ausfallpunkt darstellt. Viele Echtzeitanwendungen werden in der Hoffnung entwickelt, eine breite Akzeptanz zu finden. Allerdings ist die Wachstumsrate schwer vorherzusagen. Um die zunehmende Beliebtheit von Echtzeitanwendungen zu unterstützen, muss die Infrastruktur Folgendes können:
- Skalieren Sie, um eine große Anzahl gleichzeitiger Benutzer zu unterstützen
- Sorgen Sie für geringe Latenzzeiten bei der Kommunikation zwischen Client und Server
- Unterstützt hohe Verfügbarkeit (was bedeutet, dass es keinen einzelnen Ausfallpunkt gibt)
- Ermöglichen Sie eine einfache Änderung der Konfiguration und passen Sie sie an veränderte Bedingungen an
Dies kann erreicht werden, indem NGINX vor die WebSocket-Server und HTTP-Server gesetzt wird (da die meisten WebSocket-Anwendungen auch HTTP verwenden), um als WebSocket-fähiger Reverse-Proxy und Load Balancer zu fungieren. Nicht alle Reverse-Proxys bieten direkte Unterstützung für WebSocket. Einige, wie etwa Elastic Load Balancing (ELB) in der Amazon Web Services (AWS)-Umgebung, müssen im TCP-Modus ausgeführt werden, was bedeutet, dass sie nicht mit HTTP-Headern umgehen können. Das Proxy-Protokoll wurde entwickelt, um diese Einschränkung zu umgehen, und NGINX unterstützt es ebenfalls, was bedeutet, dass WebSocket in AWS vollständig unterstützt wird. Die Verwendung von NGINX als WebSocket-Reverse-Proxy bietet zusätzliche Vorteile, beispielsweise Routing-Flexibilität und die Möglichkeit, SSL-Verbindungen über NGINX beenden zu lassen.
Eine typische WebSocket-Konfiguration mit NGINX könnte ungefähr so aussehen:
Hier zeigen wir eine Vielzahl von Desktop- und Mobilclients, die eine Verbindung zu einem hochverfügbaren Paar von NGINX-Servern herstellen, die den Lastenausgleich für eine Reihe von HTTP- und WebSocket-Servern durchführen. Diese Art der Konfiguration kann dem Ausfall eines WebSocket-Servers oder eines NGINX-Servers standhalten und Sie können WebSocket-Server problemlos hinzufügen oder entfernen. Darüber hinaus sind alle Routing-Details zur Verbindung mit den WebSocket-Servern vor den Clients verborgen, wodurch eine robuste und skalierbare WebSocket-Anwendungsinfrastruktur entsteht. Die Webleistung und Zuverlässigkeit für Echtzeit-Webanwendungen sind von entscheidender Bedeutung. Kontaktieren Sie uns noch heute, um zu erfahren, wie NGINX Plus Ihnen dabei helfen kann, die Leistung, Zuverlässigkeit und Verfügbarkeit Ihrer Anwendungen zu verbessern.
Weitere Informationen finden Sie unter:
„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."