Visão geral do suporte para WebSocket no Gateway de Aplicativo

O Gateway de Aplicativo fornece suporte nativo a WebSocket em todos os tamanhos de gateway. Não há nenhuma configuração configurável pelo usuário para habilitar ou desabilitar seletivamente o suporte ao WebSocket.

O protocolo WebSocket padronizado na RFC6455 permite uma comunicação full-duplex entre um servidor e um cliente em uma conexão TCP de execução longa. Esse recurso permite uma comunicação mais interativa entre o servidor Web e o cliente, que pode ser bidirecional sem a necessidade de sondagem, necessária nas implementações baseadas em HTTP. O WebSocket tem baixa sobrecarga, ao contrário do HTTP e pode reutilizar a mesma conexão TCP para várias solicitações/respostas, resultando em uma utilização mais eficiente de recursos. Os protocolos WebSocket são projetados para funcionar em portas HTTP tradicionais de 80 e 443. O Gateway de Aplicativo dá suporte a até 30.000 conexões WS simultâneas e 13.500 conexões WSS por instância.

Você pode continuar usando um ouvinte HTTP padrão na porta 80 ou 443 para receber o tráfego do WebSocket. O tráfego WebSocket será direcionado para o servidor de back-end habilitado para WebSocket usando o pool de back-end apropriado conforme especificado nas regras do gateway de aplicativo. O servidor back-end precisa responder às investigações do gateway de aplicativo, descritas na seção Visão geral da investigação de integridade. As investigações de integridade do gateway de aplicativo se destinam apenas a HTTP/HTTPS. Cada servidor back-end precisa responder às investigações de HTTP do gateway de aplicativo para encaminhar o tráfego do WebSocket para o servidor.

Ele é usado em aplicativos que se beneficiam de comunicação rápida e em tempo real, como chat, painel e aplicativos de jogos.

Como o WebSocket funciona

Para estabelecer uma conexão WebSocket, um handshake baseado em HTTP é trocado entre o cliente e o servidor. Em caso de êxito, o protocolo de camada de aplicativo é "atualizado" de HTTP para WebSockets usando a conexão TCP estabelecida anteriormente. Assim que isso ocorre, o HTTP fica totalmente fora de cogitação. Os dados podem ser enviados ou recebidos usando o protocolo WebSocket por ambos os pontos de extremidade até o encerramento da conexão com o WebSocket.

O diagrama compara um cliente que interage com um servidor Web, conectando duas vezes para obter duas respostas através de uma interação WebSocket, em que um cliente se conecta a um servidor uma única vez para obter várias respostas.

Observação

Depois que uma conexão é atualizada para usar WebSocket, como um proxy intermediário/de terminação, o Application Gateway simplesmente envia os dados recebidos do frontend para o backend e vice-versa, sem qualquer capacidade de inspecionar ou manipular os dados. Portanto, o WAF (Firewall de Aplicativo Web) não pode analisar nenhum conteúdo e não realiza nenhuma inspeção nesses dados. Da mesma forma, quaisquer alterações, como reescrita de cabeçalhos, reescrita de URL ou substituição do nome do host nas configurações de back-end, não se aplicam após o estabelecimento de uma conexão WebSocket.

Elemento de configuração do ouvinte

Um ouvinte HTTP existente pode ser usado para dar suporte ao tráfego do WebSocket. O snippet a seguir mostra um httpListeners elemento de um arquivo de modelo de exemplo. Você precisa de ouvintes HTTP e HTTPS para dar suporte ao WebSocket e ao tráfego seguro do WebSocket. Da mesma forma, você pode usar o portal ou Azure PowerShell para criar um gateway de aplicativo com ouvintes nas portas 80 e 443 para dar suporte ao tráfego do 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 e configuração da regra de roteamento

Use um BackendAddressPool para definir um pool de back-end com servidores habilitados para WebSocket. Defina a backendHttpSetting com as portas de back-end 80 e 443. O valor do tempo limite da solicitação nas Configurações de HTTP também se aplica à sessão do WebSocket. Você não precisa alterar a regra de roteamento, que vincula o ouvinte apropriado ao pool de endereços de back-end correspondente.

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

    }
}]

Observação

Verifique se o valor de tempo limite é maior do que o intervalo de ping/pong definido pelo servidor para evitar erros de tempo limite antes que um ping seja enviado do cliente. Um valor típico para um WebSocket é de 20 segundos, portanto, por exemplo, um valor de tempo limite de 40 segundos garante que o gateway não envie um erro de tempo limite antes que o cliente envie um ping. Caso contrário, essa condição gerará um erro 1006 no lado do cliente.

Back-end habilitado para WebSocket

Seu back-end deve ter um servidor Web HTTP/HTTPS em execução na porta configurada (geralmente 80 ou 443) para que o WebSocket funcione. Esse requisito existe porque o protocolo WebSocket exige que o handshake inicial seja HTTP com uma atualização para o protocolo WebSocket como um campo de cabeçalho. O exemplo a seguir mostra um cabeçalho:

    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

Outro motivo para esse requisito é que a investigação de integridade de back-end do gateway de aplicativo dá suporte apenas aos protocolos HTTP e HTTPS. Se o servidor de back-end não responder a investigações HTTP ou HTTPS, o gateway o removerá do pool de back-end.

Próximas etapas

Depois de saber mais sobre o suporte do WebSocket, vá para criar um gateway de aplicativo para começar a usar um aplicativo Web habilitado para WebSocket.