Introducción a la compatibilidad de WebSocket en Application Gateway

Application Gateway proporciona una compatibilidad nativa con WebSocket en todas las puertas de enlace, con independencia de su tamaño. No hay ninguna opción de configuración que permita al usuario habilitar o deshabilitar la compatibilidad con WebSocket.

El protocolo WebSocket, estándar en RFC6455 , permite una comunicación dúplex completa entre un servidor y un cliente a través de una conexión TCP de larga duración. Esta característica permite una comunicación más interactiva entre el servidor web y el cliente, que puede ser bidireccional sin necesidad de realizar sondeos como en las implementaciones basadas en HTTP. A diferencia de HTTP, WebSocket tiene poca sobrecarga y puede reutilizar la misma conexión TCP para varias solicitudes y respuestas, lo que conlleva un uso más eficaz de los recursos. Los protocolos WebSocket están diseñados para utilizarse a través de los puertos HTTP tradicionales 80 y 443. Application Gateway admite hasta 30 000 conexiones WS simultáneas y 13 500 conexiones WSS por instancia.

Puede seguir usando un receptor HTTP estándar en el puerto 80 o 443 para recibir tráfico WebSocket. Después, el tráfico de WebSocket se dirige al servidor back-end habilitado para WebSocket utilizando el grupo de back-end adecuado, según se especifica en las reglas de la puerta de enlace de aplicaciones. El servidor de back-end debe responder a los sondeos de Application Gateway, que se describen en la sección descripción general de los sondeos de estado. Los sondeos de estado de Application Gateway solo pueden ser HTTP o HTTPS. Cada servidor de back-end debe responder a los sondeos HTTP de Application Gateway para enrutar el tráfico de WebSocket al servidor.

Se usa en aplicaciones que sacan partido de comunicaciones rápidas y en tiempo real, como las aplicaciones de chat, panel y juegos.

Cómo funciona WebSocket

Para establecer una conexión de WebSocket, se intercambia un protocolo de enlace específico basado en HTTP entre el cliente y el servidor. Si se realiza correctamente, el protocolo de capa de aplicación se "actualiza" de HTTP a WebSockets, mediante la conexión TCP establecida previamente. Una vez que esto ocurre, HTTP queda completamente fuera de juego. Los dos puntos de conexión pueden enviar o recibir los datos mediante el protocolo WebSocket, hasta que se cierra la conexión de WebSocket.

En el diagrama, se compara un cliente que interactúa con un servidor web y que se conecta dos veces para obtener dos respuestas con una interacción de WebSocket en la que un cliente se conecta una sola vez a un servidor para obtener varias respuestas.

Nota:

Después de actualizar una conexión a WebSocket, como proxy intermediario o terminado, Application Gateway simplemente envía los datos recibidos del front-end al back-end y viceversa, sin ninguna funcionalidad de inspección o manipulación. Por lo tanto, el Web Application Firewall (WAF) no puede analizar ningún contenido y no realiza ninguna inspección de dichos datos. Del mismo modo, cualquier modificación, como las reescrituras de encabezados, las reescrituras de URL o la sobrescritura del nombre de host en la configuración del backend, no se aplica una vez establecida una conexión WebSocket.

Elemento de configuración de escucha

Se puede utilizar un receptor HTTP existente para soportar tráfico de WebSocket. El fragmento de código siguiente muestra un httpListeners elemento de un archivo de plantilla de ejemplo. Se necesitan receptores HTTP y HTTPS para admitir tráfico WebSocket y WebSocket seguro. Del mismo modo, puede usar el portal o Azure PowerShell para crear una puerta de enlace de aplicaciones con agentes de escucha en el puerto 80 y 443 para admitir el tráfico de 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 y configuración de reglas de enrutamiento

Use un backendAddressPool para definir un grupo de back-end con servidores habilitados para WebSocket. Defina backendHttpSetting con los puertos de back-end 80 y 443. El valor de tiempo de espera de la solicitud en la configuración de HTTP también se aplica a la sesión de WebSocket. No es necesario cambiar la regla de enrutamiento, que vincula el agente de escucha adecuado al grupo de direcciones de back-end correspondiente.

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

    }
}]

Nota:

Asegúrese de que el valor de tiempo de espera sea mayor que el intervalo de ping/pong definido por el servidor para evitar que se produzcan errores de tiempo de espera antes de enviar un ping desde el cliente. Un valor típico de WebSocket es de 20 segundos, por lo que, por ejemplo, un valor de tiempo de espera de 40 segundos garantiza que la puerta de enlace no envíe un error de tiempo de espera antes de que el cliente envíe un ping. De lo contrario, esta condición produce un error 1006 en el lado cliente.

Back-end habilitado para WebSocket

El back-end debe tener un servidor web HTTP/HTTPS que se ejecute en el puerto configurado (normalmente 80 o 443) para que WebSocket funcione. Este requisito existe porque el protocolo WebSocket requiere que el intercambio inicial sea HTTP, con una actualización al protocolo WebSocket mediante un campo de cabecera. En el ejemplo siguiente se muestra un encabezado:

    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

Otro motivo para este requisito es que el sondeo de estado de back-end de Application Gateway solo admite protocolos HTTP y HTTPS. Si el servidor back-end no responde a sondas HTTP o HTTPS, la puerta de enlace lo quita del grupo de servidores back-end.

Pasos siguientes

Después de obtener más información sobre la compatibilidad con WebSocket, vaya a crear una puerta de enlace de aplicación para empezar a usar una aplicación web con WebSocket habilitado.

  • Last updated on