Nous avons la configuration suivante pour l'équilibreur de charge Google HTTPS.
Deux Frontends : 1. Trafic HTTP vers une IP statique 2. Trafic HTTPS vers la même IP statique (DNS configuré sur un nom de domaine)
Règles relatives aux hôtes et aux chemins Tout va vers le backend
Un seul backend : Avec le protocole HTTP et l'affinité de session définie sur l'IP du client.
L'instance dorsale a une application MEAN fonctionnant sur le port 3000.
Depuis notre application côté client, nous pouvons accéder à l'application backend en utilisant le nom de domaine du loadbalancer. Mais nous avons aussi une fonction de chat avec socket.io.
Pour la connexion au socket, nous n'avons pas pu utiliser le nom de domaine du loadbalancer. Il y a une erreur 400.
Si nous essayons d'utiliser l'IP du backend directement pour la connexion au socket, cela fonctionne mais si le client est en HTTPS, cela crée un autre problème car le backend est en http.
La documentation de Google indique que le loadbalancer prend en charge les websockets par défaut. Je ne suis donc pas sûr de ce qui se passe. Tous les autres exemples que je vois sont relativement anciens et non pertinents, je pense. Toute aide est appréciée. Merci.
0 votes
Comme socket.io démarre la connexion par quelques requêtes http, la connexion échouera régulièrement si vous ne disposez pas d'un équilibrage de charge efficace. Vous pouvez donc soit activer l'équilibrage de charge collant dans l'équilibreur de charge (si cette option est prise en charge), soit configurer le client socket.io pour qu'il se connecte directement avec webSocket et n'utilise pas de sondage http au début de la connexion.
1 votes
Comme j'ai essayé de l'expliquer, la documentation de Google indique clairement que l'équilibrage de charge HTTP(S) prend en charge les websockets sans support supplémentaire. Et je ne pense pas qu'il y ait une option de collage disponible sur GCE. Cependant, il existe une affinité de session et je l'ai essayée.
1 votes
Apparemment, vous n'avez pas compris mon commentaire. Une connexion socket.io commence par plusieurs requêtes http avant de passer à une connexion webSocket. Si ces requêtes http ne sont pas collantes et vont au même hôte à chaque fois, alors la connexion socket.io échouera. Vous pouvez forcer le client à se connecter directement avec une webSocket comme transport pour éviter cela ou vous pouvez configurer l'équilibreur de charge pour qu'il soit collant. Vous avez BESOIN de l'une de ces options pour qu'une connexion socket.io fonctionne à travers un équilibreur de charge, même s'il prend en charge les webSockets. socket.io n'est PAS une simple webSocket, il y a des choses par-dessus.
0 votes
Voir Socket.io pour utiliser uniquement webSocket pour savoir comment forcer le transport par webSocket dès le début.
0 votes
Suite au commentaire ci-dessus, veuillez noter qu'en vertu du Documentation sur les BPC Si vous avez configuré l'affinité de session de l'IP du client ou du cookie généré pour votre LB HTTP(S), toutes les connexions WebSocket d'un client sont envoyées à la même instance de backend, à condition que l'instance continue à passer les contrôles de santé.