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 WebSocket jest następnie kierowany do serwera zaplecza obsługującego WebSocket, przy użyciu odpowiedniej puli zaplecza określonej w zasadach bramy aplikacji. Serwer zaplecza musi odpowiadać na sondy bramy aplikacji, które opisano w sekcji Przegląd sond kondycji. Sondy kondycji usługi Application Gateway działają wyłącznie z protokołami HTTP/HTTPS. Każdy serwer zaplecza musi odpowiadać na sondy HTTP, aby brama aplikacyjna mogła kierować ruch 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 protokół WebSocket

Aby ustanowić połączenie WebSocket, określone uzgadnianie oparte na protokole HTTP wymienia się 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.

Uwaga

Po uaktualnieniu połączenia do protokołu WebSocket, jako serwer proxy działający jako pośrednik lub końcowy, usługa Application Gateway po prostu przekazuje dane otrzymane z warstwy frontowej do warstwy zaplecza i z powrotem, bez możliwości inspekcji ani manipulowania. W związku z tym zapora aplikacji internetowej (WAF) nie może przeanalizować żadnej treści i nie wykonuje żadnych inspekcji takich danych. Podobnie wszelkie manipulacje, takie jak ponowne zapisywanie nagłówków, ponowne zapisywanie adresów URL lub zastępowanie nazwy hosta w ustawieniach zaplecza, nie będą stosowane po nawiązaniu połączenia protokołu WebSocket.

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

Zasób BackendAddressPool służy do definiowania puli zaplecza z serwerami obsługującymi protokół WebSocket. Element backendHttpSetting jest zdefiniowany z portami zaplecza 80 i 443. Wartość limitu czasu żądania w ustawieniach protokołu 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 połączenia HTTP z przekształceniem 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 zapytania HTTP lub HTTPS, zostanie on usunięty z puli serwerów zaplecza.

Następne kroki

Po zapoznaniu się z obsługą protokołu WebSocket, przejdź do utworzenia bramy aplikacji, aby rozpocząć pracę z aplikacją internetową obsługującą protokół WebSocket.