Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Les connexions WebSocket, définies dans le document RFC6455, permettent la communication bidirectionnelle entre un client et un serveur. Contrairement à une requête HTTP ou HTTPS classique, WebSocket permet au navigateur d’établir une connexion, et de recevoir des données en continu de la part d’un serveur, sans avoir à interroger constamment le serveur distant, ou à établir plusieurs connexions dans les deux sens (du client vers le serveur et du serveur vers le client).
Avantages de WebSocket
Le protocole WebSocket présente plusieurs avantages par rapport aux requêtes HTTP classiques, notamment :
- Compatibilité du navigateur : presque tous les navigateurs web modernes prennent en charge les connexions WebSocket.
- Données en temps réel : les connexions WebSocket permettent le transfert de données en temps réel entre le client et le serveur.
- Efficacité : les connexions WebSocket évitent d’interroger en permanence les serveurs pour rechercher des mises à jour.
- Sécurité : les connexions WebSocket peuvent être chiffrées à l’aide de TLS, et utiliser les ports HTTP standard, par exemple les ports 80 et 443.
- Flexibilité : les connexions WebSocket peuvent être utilisées pour divers types d’applications, notamment les plateformes de conversation, de gaming et de transactions financières.
Fonctionnement du protocole WebSocket
Pour établir une connexion WebSocket, une liaison HTTP spécifique est établie 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 se produit, le protocole est remplacé par WebSocket, et le trafic ne circule plus via HTTP. Les données sont envoyées ou reçues à l’aide du protocole WebSocket par les deux points de terminaison jusqu’à ce que la connexion WebSocket soit fermée.
Remarque
Une fois qu’une connexion est mise à niveau vers WebSocket, en tant que proxy intermédiaire/de fin, la solution Passerelle d’application pour conteneurs envoie les données reçues du front-end au back-end, et vice-versa, sans aucune fonctionnalité d’inspection ou de manipulation. Ainsi, les manipulations telles que les réécritures d’en-tête, les réécritures d’URL ou la substitution du nom d’hôte ne s’appliquent pas après l’établissement d’une connexion WebSocket.
Les connexions WebSocket peuvent être en texte brut ou chiffrées via TLS. Quand une connexion est établie via du texte brut, elle est établie au format ws://<fqdn>/chemin_accès. Quand une connexion est établie via TLS, elle est établie au format wss://<fqdn>/chemin_accès.
Sondes d’intégrité
Aucune configuration n’est nécessaire pour tirer parti d’une requête WebSocket dans Passerelle d’application pour conteneurs. Toutefois, vous devez veiller à configurer correctement les sondes d’intégrité pour garantir que le back-end est sain.
Par défaut, Passerelle d’application pour conteneurs tente l’établissement d’une liaison HTTP avec le port du back-end qui exécute le service WebSocket. Dans de nombreux cas, le back-end est étiqueté à tort comme étant non sain. Une stratégie HealthCheckPolicy doit donc être définie pour garantir la prise en compte de l’utilisation d’une sonde TCP par la sonde d’intégrité.
Voici un exemple de stratégie HealthCheckPolicy pour un back-end WebSocket.
kubectl apply -f - <<EOF
apiVersion: alb.networking.azure.io/v1
kind: HealthCheckPolicy
metadata:
name: websockets-health-check-policy
namespace: test-infra
spec:
targetRef:
group: ""
kind: Service
name: websockets-backend
namespace: test-infra
default:
interval: 5s
timeout: 3s
healthyThreshold: 1
unhealthyThreshold: 1
http:
path: /health
EOF
Remarque
Les extensions WebSocket sont prises en charge uniquement quand vous utilisez l’API de passerelle correspondant à la solution Passerelle d’application pour conteneurs.
Métriques et monitoring
Journaux de diagnostic :
Les connexions WebSocket utilisent un protocole distinct. Au moment de l’établissement de la connexion, le navigateur reçoit un code d’état HTTP 101, indiquant le passage de HTTP vers WebSocket. Ce code est reflété dans le journal des accès.
Les détails de la connexion WebSocket sont enregistrés uniquement à la fermeture de la connexion. Cela permet de mesurer avec exactitude la durée de chaque connexion.
Étapes suivantes
En savoir plus sur les connexions WebSocket et l’API de passerelle