Comment résoudre le piège du service proxy nginx socket.io

nginx agit comme proxy pour deux serveurs socket.io. Le mode de fonctionnement de socket.io consiste à interroger et à mettre à niveau vers websocket

Phénomène

Lors de la demande de services via nginx, un grand nombre de 400 erreurs apparaissent Parfois, il peut être mis à niveau vers websocket, et parfois il continue de signaler des erreurs. Mais en accédant directement via ip+端口, ce sera un succès à 100%.

Analyse

sid

sid est la clé de notre problème. Lors de la création initiale d'une connexion (le mode d'interrogation simule une longue connexion), le client lancera une telle requête :

https://***/?eio=3&transport=polling&t=1540820717277-0

Reçu par le serveur An L'objet sera créé, lié à la connexion, et un sid (identifiant de session) sera renvoyé pour marquer la session. Que signifie une session ? Une session est une série d'interactions, et ces interactions sont liées. Dans notre scénario, lorsque la prochaine requête http arrive, je dois trouver la longue connexion qui était auparavant liée à la théorie (pas encore ici). websocket, donc théoriquement). Nous savons que les requêtes http sont sans état et que chaque requête est indépendante, donc socket.io a introduit sid pour ce faire. Après avoir reçu la requête, le serveur générera un sid. Jetez un œil à la réponse :

Copier le code Le code est le suivant :

{"sid":"eogal3frqlptoalp5est","upgrades":["websocket"], "pinginterval":8000," pingtimeout":10000}

Chaque requête ultérieure doit apporter ce sid, et la connexion pour établir une requête websocket ne fait pas exception. Par conséquent, sid est la clé pour l'interrogation et la mise à niveau de l'interrogation vers Websocket. La requête suivante est similaire à :

https://***/?eio=3&transport=polling&t=1540820717314-1&sid=eogal3frqlptoalp5est

or

wss://***/?eio=3&transport=websocket&t=1540820717314-1&sid=eogal3frqlptoalp5est

Alors la question est, que se passe-t-il si le sid dans la requête n'est pas généré par le serveur ? Le serveur ne le reconnaîtra pas et vous renverra un 400 et vous dira

invalid sid

C'est le problème que nous avons rencontré. La stratégie d'équilibrage de charge par défaut de nginx est l'interrogation, donc la requête peut toucher la machine qui n'a pas généré le SID. Montez et nous recevrons un 400 à ce moment-là. Si nous avons de la chance, il pourra être envoyé à la machine d'origine. Si nous avons de la chance, nous pouvons même persister jusqu'à ce que la connexion websocket soit établie.

Solution

Voici deux solutions proposées

1. l'équilibrage de charge nginx utilise ip_hash, qui peut garantir que toutes les requêtes d'un client vont vers un seul serveur

2. N'utilisez pas le mode d'interrogation, utilisez uniquement websocket

Les deux options ont leurs propres avantages et inconvénients. La deuxième évidence est que les anciens navigateurs et clients qui ne prennent pas en charge les websockets ne fonctionneront pas. Le premier type de problème est caché plus profondément. Imaginez ce qui se passera si vous ajoutez ou supprimez des machines à ce moment-là, le mode de la politique ip_hash changera et toutes les connexions précédentes seront très invalides. opérations fréquentes (surtout lorsque le produit est en phase de développement), ce type d’expansion et de contraction avec perte est très probablement inacceptable.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!