Omówienie obsługi protokołu WebSocket w usłudze Application Gateway

Usługa Application Gateway zapewnia natywną obsługę protokołu WebSocket w bramach każdego rozmiaru. Nie ma żadnych ustawień konfigurowanych przez użytkownika umożliwiających selektywne włączenie lub wyłączenie obsługi protokołu WebSocket.

Protokół WebSocket ustandaryzowany w RFC6455 umożliwia pełną dwukierunkową komunikację między serwerem a klientem przez długotrwałe połączenie TCP. Ta funkcja umożliwia bardziej interaktywną komunikację między serwerem internetowym a klientem, który może być dwukierunkowy bez konieczności sondowania zgodnie z wymaganiami w implementacjach opartych na protokole HTTP. Protokół WebSocket ma niewielkie obciążenie w przeciwieństwie do protokołu HTTP i może ponownie używać tego samego połączenia TCP dla wielu żądań/odpowiedzi, co skutkuje bardziej wydajnym wykorzystaniem zasobów. Protokoły Protokołu WebSocket zostały zaprojektowane tak, aby działały na tradycyjnych portach HTTP 80 i 443.

Możesz nadal używać standardowego odbiornika HTTP na porcie 80 lub 443 w celu odbierania ruchu protokołu WebSocket. Ruch protokołu WebSocket jest następnie kierowany do serwera zaplecza z obsługą protokołu WebSocket przy użyciu odpowiedniej puli zaplecza określonej w regułach bramy aplikacji. Serwer zaplecza musi odpowiadać na sondy bramy aplikacji, które opisano w sekcji Przegląd sondy kondycji. Sondy kondycji usługi Application Gateway są tylko protokołem HTTP/HTTPS. Każdy serwer zaplecza musi odpowiadać na sondy HTTP dla bramy aplikacji w celu kierowania ruchu protokołu WebSocket do serwera.

Jest ona używana w aplikacjach, które korzystają z szybkiej komunikacji w czasie rzeczywistym, takiej jak czat, pulpit nawigacyjny i aplikacje gier.

Jak działa składnik WebSocket

Aby ustanowić połączenie protokołu WebSocket, określony uzgadnianie oparte na protokole HTTP jest wymieniane między klientem a serwerem. W przypadku powodzenia protokół warstwy aplikacji jest "uaktualniony" z protokołu HTTP do protokołu WebSockets przy użyciu wcześniej ustanowionego połączenia TCP. Gdy tak się dzieje, protokół HTTP jest całkowicie poza obrazem; dane mogą być wysyłane lub odbierane przy użyciu protokołu WebSocket przez oba punkty końcowe do momentu zamknięcia połączenia protokołu WebSocket.

Diagram compares a client interacting with a web server, connecting twice to get two replies, with a WebSocket interaction, where a client connects to a server once to get multiple replies.

Uwaga

Zgodnie z opisem protokół HTTP jest używany tylko do wykonywania uzgadniania podczas nawiązywania połączenia protokołu WebSocket. Po zakończeniu uzgadniania zostanie otwarte połączenie protokołu WebSocket na potrzeby przesyłania danych, a zapora aplikacji internetowej (WAF) nie może przeanalizować żadnej zawartości. W związku z tym zapora aplikacji internetowej nie wykonuje żadnych inspekcji na takich danych.

Element konfiguracji odbiornika

Istniejący odbiornik HTTP może służyć do obsługi ruchu protokołu WebSocket. Poniżej znajduje się fragment kodu elementu httpListeners z przykładowego pliku szablonu. Odbiorniki HTTP i HTTPS będą potrzebne do obsługi protokołu WebSocket i bezpiecznego ruchu protokołu WebSocket. Podobnie można użyć portalu lub programu Azure PowerShell, aby utworzyć bramę aplikacji z odbiornikami na porcie 80/443 w celu obsługi ruchu protokołu WebSocket.

"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",
            }
        }
    ],

BackendAddressPool, BackendHttpSetting i Konfiguracja reguły routingu

Pula BackendAddressPool służy do definiowania puli zaplecza z serwerami z obsługą protokołu WebSocket. Element backendHttpSetting jest definiowany z portem zaplecza 80 i 443. Wartość limitu czasu żądania w Ustawienia HTTP ma również zastosowanie do sesji protokołu WebSocket. W regule routingu nie jest wymagana żadna zmiana, która służy do wiązania odpowiedniego odbiornika z odpowiednią pulą adresów zaplecza.

"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')]"
        }

    }
}]

Uwaga

Upewnij się, że wartość limitu czasu jest większa niż interwał ping/pong zdefiniowany przez serwer, aby uniknąć wystąpienia błędów przekroczenia limitu czasu przed wysłaniem polecenia ping z klienta. Typowa wartość protokołu WebSocket wynosi 20 sekund, więc na przykład wartość limitu czasu 40 sekund gwarantuje, że brama nie wyśle błędu przekroczenia limitu czasu, zanim klient wyśle polecenie ping; w przeciwnym razie spowoduje to zgłoszenie błędu 1006 po stronie klienta.

Zaplecze z obsługą protokołu WebSocket

Zaplecze musi mieć serwer internetowy HTTP/HTTPS uruchomiony na skonfigurowanym porcie (zazwyczaj 80/443), aby usługa WebSocket działała. Jest to wymagane, ponieważ protokół WebSocket wymaga początkowego uzgadniania http z uaktualnieniem do protokołu WebSocket jako pola nagłówka. Oto przykład nagłówka:

    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

Innym powodem jest to, że sonda kondycji zaplecza usługi Application Gateway obsługuje tylko protokoły HTTP i HTTPS. Jeśli serwer zaplecza nie odpowiada na sondy HTTP lub HTTPS, zostanie on wyjęty z puli zaplecza.

Następne kroki

Po zapoznaniu się z obsługą protokołu WebSocket przejdź do tematu tworzenia bramy aplikacji, aby rozpocząć pracę z aplikacją internetową z obsługą protokołu WebSocket.