Echtzeit-Webanwendungen mit WebSocket und NGINX

Rick NelsonRegional Vice President, Solution Engineering

Im Blogbeitrag „NGINX als WebSocket-Proxy“ haben wir erläutert, wie NGINX als Proxy für WebSocket-Anwendungsserver eingesetzt werden kann. In diesem Beitrag befassen wir uns mit einigen Aspekten der Architektur und Infrastruktur, die bei der Entwicklung von Echtzeitanwendungen mit WebSocket zu berücksichtigen sind. Dazu gehören die benötigten Komponenten und die mögliche Strukturierung Ihrer Systeme.

WebSocket macht HTTP interaktiv

HTTP eignet sich gut für Webanwendungen, die auf dem Anfrage-Antwort-Prinzip basieren und bei denen der Kommunikationsfluss stets damit beginnt, dass der Client eine Anfrage sendet, auf die ein Backend-Server antwortet. Webanwendungen mit einer interaktiveren, nachrichtenbasierten Kommunikation zwischen Client und Server benötigen mehr als einfaches HTTP. Frühere Versuche, eine Vollduplexkommunikation über HTTP zu simulieren, waren kompliziert und mit zahlreichen Nachteilen verbunden. Das WebSocket-Protokoll bietet zusammen mit der WebSocket-JavaScript-Schnittstelle eine wesentlich einfachere Möglichkeit, solche Anwendungen zu entwickeln und gleichzeitig die übertragene Datenmenge sowie die Latenz zu reduzieren.

Die Möglichkeit, eine Vollduplex-Socket-Verbindung zwischen Client und Server herzustellen, erlaubt die Entwicklung ereignisgesteuerter Echtzeit-Webanwendungen, die Push-, Polling- oder Streaming-Kommunikation nutzen. Mit WebSocket kann nach dem Verbindungsaufbau sowohl der Client als auch der Server die Kommunikation initiieren. Dies ermöglicht zahlreiche Arten von Webanwendungen, darunter Onlinespiele, Chats, die Verfolgung von Aktienkursen und die Echtzeitübertragung von Sportergebnissen.

Ein weiterer Anwendungsfall für WebSocket ist die Entwicklung von WebRTC-basierten Anwendungen. WebRTC wird zur Entwicklung von Anwendungen verwendet, die eine direkte Kommunikation zwischen Browsern ermöglichen. Für den Verbindungsaufbau ist ein separater Signalisierungskanal erforderlich, für den sich WebSocket gut als Protokoll eignet.

Technische Anforderungen an eine WebSocket-Anwendung

Die für eine WebSocket-Webanwendung erforderliche Mindestinfrastruktur besteht aus einem Client-Browser, in dem eine WebSocket-JavaScript-Anwendung ausgeführt wird und der mit einem WebSocket-Server kommuniziert. Die aktuellen Versionen aller gängigen Browser unterstützen inzwischen WebSocket. Dennoch muss sichergestellt werden, dass die Clients über einen Browser mit WebSocket-Unterstützung verfügen. Für WebSocket-Server gibt es zahlreiche Optionen. Nachfolgend finden Sie einige Beispiele für verschiedene Umgebungen (diese Liste dient lediglich Ihrer Orientierung und stellt keine Empfehlung durch NGINX, Inc. dar):

WebSocket für hohe Datenverkehrsvolumen skalieren

Es ist möglich, einen einzelnen WebSocket-Server zu verwenden, doch die Anwendungsleistung wird durch dessen Kapazität begrenzt. Zudem stellt er einen Single Point of Failure dar. Viele Echtzeitanwendungen werden in der Hoffnung entwickelt, eine breite Akzeptanz zu finden, doch die Wachstumsrate lässt sich nur schwer vorhersagen. Um die zunehmende Beliebtheit einer Echtzeitanwendung zu unterstützen, muss die Infrastruktur Folgendes leisten können:

• Skalierbar sein, um eine große Anzahl gleichzeitiger Benutzer zu unterstützen
• Eine geringe Latenz bei der Kommunikation zwischen Client und Server gewährleisten
• Hohe Verfügbarkeit unterstützen (d. h., es gibt keinen Single Point of Failure)
• Ermöglichen, dass die Konfiguration einfach geändert und an veränderte Bedingungen angepasst werden kann

Dies lässt sich erreichen, indem NGINX den WebSocket-Servern und HTTP-Servern vorgeschaltet wird (da die meisten WebSocket-Anwendungen auch HTTP verwenden), sodass NGINX als WebSocket-fähiger Reverse-Proxy und Load-Balancer fungiert. Nicht alle Reverse-Proxys bieten direkte Unterstützung für WebSocket. Einige, wie Elastic Load Balancing (ELB) in der Amazon-Web-Services-(AWS)-Umgebung, müssen im TCP-Modus ausgeführt werden und können daher keine HTTP-Header verarbeiten. Das Proxy Protocol wurde entwickelt, um diese Einschränkung zu umgehen, und wird auch von NGINX unterstützt. Somit wird WebSocket in AWS vollständig unterstützt. Der Einsatz von NGINX als WebSocket-Reverse-Proxy bietet weitere Vorteile, darunter flexible Routing-Möglichkeiten und die Option, SSL-Verbindungen durch NGINX terminieren zu lassen.

Eine typische WebSocket-Konfiguration mit NGINX könnte etwa so aussehen:

Hier zeigen wir verschiedene Desktop- und Mobil-Clients, die eine Verbindung zu einem hochverfügbaren Paar von NGINX-Servern herstellen, das den Datenverkehr auf mehrere HTTP- und WebSocket-Server verteilt. Diese Art der Konfiguration verkraftet den Ausfall eines WebSocket- oder NGINX-Servers, und WebSocket-Server lassen sich problemlos hinzufügen oder entfernen. Darüber hinaus bleiben sämtliche Routing-Details für die Verbindung mit den WebSocket-Servern vor den Clients verborgen. So entsteht eine robuste und skalierbare WebSocket-Anwendungsinfrastruktur. Für Echtzeit-Webanwendungen sind Web-Performance und Zuverlässigkeit von entscheidender Bedeutung. Kontaktieren Sie uns noch heute, um zu erfahren, wie NGINX Plus die Performance, Zuverlässigkeit und Verfügbarkeit Ihrer Anwendungen verbessern kann.

Weitere Informationen finden Sie unter:

• NGINX als WebSocket-Proxy
• NGINX-WebSocket-Leistung
• WebSocket-Proxying auf nginx.org
• Funktionsvergleich zwischen NGINX und NGINX Plus
• Technische Spezifikationen für NGINX Plus

Über den Autor

Rick NelsonRegional Vice President, Solution Engineering

Weitere Blogbeiträge von Rick Nelson