Vue d’ensemble de la prise en charge de WebSocket dans Application Gateway

Application Gateway prend en charge WebSocket de manière native, quelle que soit la taille de la passerelle. Il n’existe aucun paramètre configurable par l’utilisateur permettant d’activer ou de désactiver de manière sélective la prise en charge de WebSocket.

Le protocole WebSocket normalisé dans RFC6455 permet une communication en duplex intégral entre un serveur et un client via une connexion TCP durable. Il assure une communication plus interactive entre le serveur web et le client, qui peut être bidirectionnelle sans nécessiter d’interrogations, comme c’est le cas pour les implémentations basées sur le protocole HTTP. Contrairement au protocole HTTP, WebSocket génère une faible surcharge et peut réutiliser la même connexion TCP pour plusieurs requêtes/réponses, ce qui entraîne une utilisation plus efficace des ressources. Les protocoles WebSocket sont conçus pour fonctionner sur les ports HTTP traditionnels (80 et 443). Application Gateway prend en charge jusqu’à 30 000 connexions WS simultanées et 13 500 connexions WSS par instance.

Vous pouvez continuer d’utiliser un élément écouteur HTTP standard sur le port 80 ou 443 pour recevoir le trafic WebSocket. Le trafic WebSocket est ensuite dirigé vers le serveur principal compatible WebSocket à l’aide du pool principal approprié tel que spécifié dans les règles Application Gateway. Le serveur principal doit répondre aux sondes de la passerelle Application Gateway, qui sont décrites dans la section Vue d’ensemble de la sonde d’intégrité . Les sondes d’intégrité d’Application Gateway n’utilisent que les protocoles HTTP/HTTPS. Chaque serveur principal doit répondre aux sondes HTTP de la passerelle Application Gateway pour acheminer le trafic WebSocket au serveur.

Son utilisation profite aux applications qui tirent parti d’une communication rapide et en temps réel, par exemple les applications de conversation, de tableau de bord et de jeu.

Comment fonctionne WebSocket

Pour établir une connexion WebSocket, un établissement d’une liaison spécifique basée sur HTTP est échangée entre le client et le serveur. En cas de réussite, le protocole de la couche Application est « mis à niveau » de HTTP vers WebSockets, à l’aide de la connexion TCP établie. Une fois que cela s’est produit, le protocole HTTP disparaît du paysage. Les données peuvent être envoyées ou reçues aux deux points de terminaison via le protocole WebSocket, jusqu’à la fermeture de la connexion WebSocket.

Le diagramme compare un client qui interagit avec un serveur web, en se connectant deux fois pour obtenir deux réponses, avec une interaction WebSocket, où un client se connecte une fois à un serveur pour obtenir plusieurs réponses.

Remarque

Une fois qu’une connexion est mise à niveau vers WebSocket, en tant que proxy intermédiaire/de fin, Application Gateway envoie simplement les données reçues du serveur frontal au back-end et vice versa, sans aucune fonctionnalité d’inspection ou de manipulation. Par conséquent, le Web Application Firewall (WAF) ne peut pas analyser de contenu et n'effectue aucune inspection sur ces données. De même, toutes les manipulations telles que les réécritures d’en-tête, les réécritures d’URL ou la substitution du nom d’hôte dans les paramètres principaux ne s’appliquent pas après l’établissement d’une connexion WebSocket.

Élément de configuration d’écouteur

Un écouteur HTTP permet de prendre en charge le trafic WebSocket. L’extrait de code suivant montre un httpListeners élément à partir d’un exemple de fichier de modèle. Vous avez besoin à la fois des écouteurs HTTP et HTTPS pour prendre en charge le trafic WebSocket et le trafic WebSocket sécurisé. De même, vous pouvez utiliser le portail ou Azure PowerShell pour créer une passerelle d’application avec des écouteurs sur le port 80 et 443 pour prendre en charge le trafic 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",
            }
        }
    ],

Configuration des règles d’acheminement, BackendHttpSetting et BackendAddressPool

Utilisez un BackendAddressPool pour définir un pool principal avec des serveurs compatibles WebSocket. Définissez le backendHttpSetting avec les ports principaux 80 et 443. Le délai d’expiration de la requête défini dans les paramètres HTTP s’applique également à la session WebSocket. Vous n’avez pas besoin de modifier la règle de routage, qui lie l’écouteur approprié au pool d’adresses back-end correspondant.

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

    }
}]

Remarque

Assurez-vous que votre valeur de délai d'expiration est supérieure à l'intervalle ping/pong défini par votre serveur pour éviter de rencontrer des erreurs de délai d'expiration avant qu'un ping ne soit envoyé par le client. Une valeur classique pour un WebSocket est de 20 secondes. Par exemple, une valeur de délai d’expiration de 40 secondes garantit que la passerelle n’envoie pas d’erreur de délai d’attente avant que le client n’envoie un test ping. Sinon, cette condition lève une erreur 1006 côté client.

Serveur principal compatible WebSocket

Votre serveur web HTTP/HTTPS doit être exécuté sur le port configuré (généralement 80 ou 443) pour que WebSocket fonctionne. Cette exigence existe, car le protocole WebSocket exige que l’établissement d’une liaison initiale soit HTTP avec une mise à niveau vers le protocole WebSocket en tant que champ d’en-tête. L’exemple suivant montre un en-tête :

    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

Une autre raison de cette exigence est que la sonde d’intégrité du serveur principal application gateway prend uniquement en charge les protocoles HTTP et HTTPS. Si le serveur principal ne répond pas aux sondes HTTP ou HTTPS, la passerelle la supprime du pool principal.

Étapes suivantes

Après avoir appris la prise en charge de WebSocket, accédez à la création d’une passerelle d’application pour commencer à utiliser une application web prenant en charge WebSocket.

  • Last updated on