Freigeben über

WebSocket in Azure Front Door

Gilt für: ✔️ Front Door Standard ✔️ Front Door Premium

Azure Front Door unterstützt WebSocket in der Dienstebene „Standard“ und „Premium“, ohne dass zusätzliche Konfigurationsschritte erforderlich sind. WebSocket ist ein TCP-basiertes Protokoll gemäß RFC6455-Standard, das die Vollduplexkommunikation zwischen einem Server und einem Client über eine TCP-Verbindung mit langer Laufzeit ermöglicht. Damit entfällt das bei HTTP erforderliche Polling, und der Mehraufwand von HTTP wird teilweise vermieden. Das Protokoll kann die gleiche TCP-Verbindung für mehrere Anforderungen oder Antworten wiederverwenden, was eine effizientere Ressourcennutzung zur Folge hat. Dies ermöglicht interaktivere Szenarien und Echtzeitszenarien.

WebSocket ist ideal für Anwendungen, die Echtzeitaktualisierungen oder fortlaufende Datenströme benötigen, z. B. Chat-Apps, Dashboards, Finanzupdates, GPS, Onlinebildungsdienste, Livestreaming und Gaming. Beispielsweise kann eine Handelswebsite WebSocket verwenden, um Preisdaten in Echtzeit zu pushen und zu aktualisieren.

Hinweis

Front Door unterstützt Server-Sent Events (SSE) nicht.

Verwenden von WebSocket in Azure Front Door

Berücksichtigen Sie bei der Verwendung von WebSocket in Azure Front Door Folgendes:

  • Sobald eine Verbindung auf WebSocket aktualisiert wurde, überträgt Azure Front Door Daten zwischen Clients und dem Ursprungsserver, ohne während der hergestellten Verbindung Überprüfungen oder Bearbeitungen durchzuführen.
  • WAF-Überprüfungen (Web Application Firewall) werden während der WebSocket-Einrichtungsphase angewendet. Nachdem die Verbindung hergestellt wurde, führt WAF keine weiteren Überprüfungen durch.
  • Integritätstests für Ursprünge werden mithilfe des HTTP-Protokolls durchgeführt.
  • Deaktivieren Sie die Zwischenspeicherung für WebSocket-Routen. Für Routen mit aktivierter Zwischenspeicherung leitet Azure Front Door den WebSocket-Upgradeheader nicht an den Ursprung weiter und behandelt ihn als HTTP-Anforderung. Cacheregeln werden dabei ignoriert. Dies führt zu einer fehlerhaften WebSocket-Upgradeanforderung.
  • Das Leerlauftimeout beträgt fünf Minuten. Wenn Azure Front Door innerhalb der letzten 5 Minuten keine Datenübertragung vom Ursprung oder Client erkennt, wird die Verbindung als inaktiv betrachtet und geschlossen.
  • Derzeit bleiben WebSocket-Verbindungen in Azure Front Door maximal 4 Stunden geöffnet. Die WebSocket-Verbindung kann aufgrund zugrunde liegender Serverupgrades oder anderer Wartungsaktivitäten verworfen werden. Es wird dringend empfohlen, eine Wiederholungslogik in der Anwendung zu implementieren.
  • Derzeit unterstützt jedes Azure Front Door-Profil bis zu 3.000 gleichzeitige globale Verbindungen. Weitere Informationen finden Sie unter Azure Front Door Standard und Premium Service Limits.

Funktionsweise des WebSocket-Protokolls

WebSocket-Protokolle verwenden Port 80 für WebSocket-Standardverbindungen und Port 443 für WebSocket-Verbindungen über TLS/SSL. Als zustandsbehaftetes Protokoll bleibt die Verbindung zwischen Clients und dem Server aktiv, bis sie von einer der beiden Parteien beendet wird. WebSocket-Verbindungen beginnen als HTTP-Upgradeanforderung mit dem Schema ws: oder wss:. Diese Verbindungen werden durch Aktualisieren einer HTTP-Anforderung/-Antwort mithilfe der Header Connection: Upgrade, Upgrade: websocket, Sec-WebSocket-Key und Sec-WebSocket-Version eingerichtet, wie in den Beispielen für den Anforderungsheader gezeigt.

Der Handshake vom Client sieht wie folgt aus:

    GET /chat HTTP/1.1
    Host: server.example.com
    Upgrade: websocket
    Connection: Upgrade
    Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
    Origin: http://example.com
    Sec-WebSocket-Protocol: chat, superchat
    Sec-WebSocket-Version: 13

Der Server antwortet mit dem Statuscode 101 Switching Protocols, um anzugeben, dass er wie vom Client angefordert zum WebSocket-Protokoll wechselt. Die Antwort enthält die Header Connection: Upgrade und Upgrade: websocket, die den Protokollwechsel bestätigen. Der Sec-WebSocket-Accept-Header wird zurückgegeben, um zu überprüfen, ob die Verbindung erfolgreich aktualisiert wurde.

Der Handshake vom Server sieht wie folgt aus:

    HTTP/1.1 101 Switching Protocols
    Upgrade: websocket
    Connection: Upgrade
    Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
    Sec-WebSocket-Protocol: chat

Nachdem der Client die Serverantwort empfangen hat, ist die WebSocket-Verbindung geöffnet, um mit der Übertragung von Daten zu beginnen. Wenn die WebSocket-Verbindung vom Client oder Server oder durch eine Netzwerkunterbrechung getrennt wird, wird erwartet, dass die Clientanwendung die Verbindung mit dem Server erneut initiiert.

Nächste Schritte

  • Last updated on