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

Artykuł
10/17/2024

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 porównuje klienta wchodzącego w interakcję z serwerem internetowym, łącząc się dwa razy, aby uzyskać dwie odpowiedzi, z interakcją protokołu WebSocket, gdzie klient łączy się z serwerem raz, aby uzyskać wiele odpowiedzi.

Uwaga

Po uaktualnieniu połączenia do protokołu WebSocket jako pośredni/kończący serwer proxy usługa Application Gateway po prostu wyśle dane odebrane z frontonu do zaplecza i na odwrót bez możliwości inspekcji ani manipulowania. W związku z tym zapora aplikacji internetowej (WAF) nie może przeanalizować żadnej zawartości i nie wykonuje żadnych inspekcji na 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

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 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 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.

Udostępnij za pośrednictwem