Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
WebSocket wird von Application Gateway nativ für alle Gatewaygrößen unterstützt. Die WebSocket-Unterstützung kann von Benutzern nicht selektiv aktiviert oder deaktiviert werden.
Das in RFC6455 standardisierte WebSocket-Protokoll ermöglicht die Vollduplexkommunikation zwischen einem Server und einem Client über eine TCP-Verbindung mit langer Laufzeit. Dieses Feature ermöglicht wiederum mehr Interaktivität bei der Kommunikation zwischen dem Webserver und dem Client, da die Kommunikation auch ohne die bei HTTP-basierten Implementierungen erforderlichen Abfragen bidirektional sein kann. Im Vergleich zu HTTP zeichnet sich WebSocket durch einen geringen Mehraufwand aus. Außerdem können sie die gleiche TCP-Verbindung für mehrere Anforderungen/Antworten verwenden, was eine effizientere Ressourcennutzung zur Folge hat. WebSocket-Protokolle sind für die Nutzung der herkömmlichen HTTP-Ports 80 und 443 konzipiert. Das Anwendungsgateway unterstützt bis zu 30.000 gleichzeitige WS-Verbindungen und 13.500 WSS-Verbindungen pro Instanz.
Sie können weiterhin einen standardmäßigen HTTP-Listener auf Port 80 oder 443 verwenden, um WebSocket-Datenverkehr zu empfangen. Der empfangene WebSocket-Datenverkehr wird dann unter Verwendung des entsprechenden Back-End-Pools (gemäß Angabe in Anwendungsgatewayregeln) an den WebSocket-fähigen Back-End-Server weitergeleitet. Der Backendserver muss auf die Sonden von Application Gateway reagieren, die im Abschnitt Übersicht über Integritätstests beschrieben werden. Application Gateway-Integritätstests sind auf HTTP/HTTPS beschränkt. Jeder Backendserver muss auf HTTP-Sonden antworten, damit das Application Gateway den WebSocket-Datenverkehr an den Server weiterleiten kann.
Es wird in Apps verwendet, die von schneller Kommunikation in Echtzeit profitieren, z.B. Chats, Dashboards und Spiele-Apps.
Funktionsweise von WebSocket
Um eine WebSocket-Verbindung einzurichten, wird ein spezifischer HTTP-basierter Handshake zwischen dem Client und dem Server ausgetauscht. Im Erfolgsfall wird mithilfe der zuvor hergestellten TCP-Verbindung ein „Upgrade“ des Protokolls der Anwendungsschicht von HTTP auf WebSockets ausgeführt. Sobald dies erfolgt ist, spielt HTTP keinerlei Rolle mehr. Daten können von beiden Endpunkten mithilfe des WebSocket-Protokolls gesendet oder empfangen werden, bis die WebSocket-Verbindung geschlossen wird.
Hinweis
Nachdem eine Verbindung auf WebSocket aktualisiert wurde, sendet Das Anwendungsgateway als Zwischen-/Endproxy einfach die vom Frontend empfangenen Daten an das Back-End und umgekehrt, ohne dass eine Inspektions- oder Manipulationsfunktion erforderlich ist. Daher kann der Web Application Firewall (WAF) keine Inhalte analysieren und führt keine Inspektionen zu solchen Daten durch. Ebenso gelten manipulationen wie Header Rewrites, URL Rewrites oder Overriding Hostname in den Back-End-Einstellungen nicht, nachdem eine WebSocket-Verbindung hergestellt wurde.
Listenerkonfigurationselement
Zur Unterstützung von WebSocket-Datenverkehr kann ein vorhandener HTTP-Listener verwendet werden. Der folgende Codeausschnitt zeigt ein httpListeners Element aus einer Beispielvorlagendatei. Sie benötigen SOWOHL HTTP- als auch HTTPS-Listener, um WebSocket und sicheren WebSocket-Datenverkehr zu unterstützen. Ebenso können Sie das Portal oder Azure PowerShell verwenden, um ein Anwendungsgateway mit Listenern am Port 80 und 443 zu erstellen, um WebSocket-Datenverkehr zu unterstützen.
"httpListeners": [
{
"name": "appGatewayHttpsListener",
"properties": {
"FrontendIPConfiguration": {
"Id": "/subscriptions/{subscriptionId/resourceGroups/{resourceGroupName/providers/Microsoft.Network/applicationGateways/{applicationGatewayName/frontendIPConfigurations/DefaultFrontendPublicIP"
},
"FrontendPort": {
"Id": "/subscriptions/{subscriptionId/resourceGroups/{resourceGroupName/providers/Microsoft.Network/applicationGateways/{applicationGatewayName/frontendPorts/appGatewayFrontendPort443'"
},
"Protocol": "Https",
"SslCertificate": {
"Id": "/subscriptions/{subscriptionId/resourceGroups/{resourceGroupName/providers/Microsoft.Network/applicationGateways/{applicationGatewayName/sslCertificates/appGatewaySslCert1'"
},
}
},
{
"name": "appGatewayHttpListener",
"properties": {
"FrontendIPConfiguration": {
"Id": "/subscriptions/{subscriptionId/resourceGroups/{resourceGroupName/providers/Microsoft.Network/applicationGateways/{applicationGatewayName/frontendIPConfigurations/appGatewayFrontendIP'"
},
"FrontendPort": {
"Id": "/subscriptions/{subscriptionId/resourceGroups/{resourceGroupName/providers/Microsoft.Network/applicationGateways/{applicationGatewayName/frontendPorts/appGatewayFrontendPort80'"
},
"Protocol": "Http",
}
}
],
Konfiguration von BackendAddressPool, BackendHttpSetting und Routingregel
Verwenden Sie einen Back-EndAddressPool, um einen Back-End-Pool mit WebSocket-fähigen Servern zu definieren. Definieren Sie die backendHttpSetting mit den Backendports 80 und 443. Der Wert für das Anforderungstimeout in den HTTP-Einstellungen gilt auch für die WebSocket-Sitzung. Sie müssen die Routingregel nicht ändern, die den entsprechenden Listener mit dem entsprechenden Back-End-Adresspool verknüpft.
"requestRoutingRules": [{
"name": "<ruleName1>",
"properties": {
"RuleType": "Basic",
"httpListener": {
"id": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/applicationGateways/{applicationGatewayName}/httpListeners/appGatewayHttpsListener')]"
},
"backendAddressPool": {
"id": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/applicationGateways/{applicationGatewayName}/backendAddressPools/ContosoServerPool')]"
},
"backendHttpSettings": {
"id": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/applicationGateways/{applicationGatewayName}/backendHttpSettingsCollection/appGatewayBackendHttpSettings')]"
}
}
}, {
"name": "<ruleName2>",
"properties": {
"RuleType": "Basic",
"httpListener": {
"id": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/applicationGateways/{applicationGatewayName}/httpListeners/appGatewayHttpListener')]"
},
"backendAddressPool": {
"id": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/applicationGateways/{applicationGatewayName}/backendAddressPools/ContosoServerPool')]"
},
"backendHttpSettings": {
"id": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/applicationGateways/{applicationGatewayName}/backendHttpSettingsCollection/appGatewayBackendHttpSettings')]"
}
}
}]
Hinweis
Stellen Sie sicher, dass Ihr Timeoutwert größer als das serverseitig definierte Ping-/Pong-Intervall ist, um Timeoutfehler zu vermeiden, bevor ein Ping vom Client gesendet wird. Ein typischer Wert für ein WebSocket beträgt 20 Sekunden, sodass beispielsweise ein Timeoutwert von 40 Sekunden sicherstellt, dass das Gateway keinen Timeoutfehler sendet, bevor der Client einen Ping sendet. Andernfalls löst diese Bedingung einen 1006-Fehler auf der Clientseite aus.
WebSocket-fähiges Back-End
Ihr Back-End muss über einen HTTP/HTTPS-Webserver verfügen, der auf dem konfigurierten Port (in der Regel 80 oder 443) ausgeführt wird, damit WebSocket funktioniert. Diese Anforderung besteht, weil das WebSocket-Protokoll verlangt, dass der initiale Handshake über HTTP erfolgt und das Upgrade auf das WebSocket-Protokoll über ein Header-Feld angefordert wird. Das folgende Beispiel zeigt eine Kopfzeile:
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: https://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Ein weiterer Grund für diese Anforderung ist, dass der Back-End-Integritätstest des Anwendungsgateways nur HTTP- und HTTPS-Protokolle unterstützt. Wenn der Back-End-Server nicht auf HTTP- oder HTTPS-Prüfpunkte reagiert, entfernt das Gateway ihn aus dem Back-End-Pool.
Nächste Schritte
Nachdem Sie mehr über die WebSocket-Unterstützung erfahren haben, erstellen Sie ein Anwendungsgateway , um mit einer WebSocket-fähigen Webanwendung zu beginnen.