So lösen Sie die Falle des Nginx-Proxy-Socket.io-Dienstes

nginx fungiert als Proxy für zwei socket.io-Server. Der Arbeitsmodus von socket.io ist das Abfragen und Aktualisieren auf Websocket

Phänomen

Beim Anfordern von Diensten über Nginx wird eine große Anzahl von 400 Fehlern angezeigt. Manchmal kann ein Upgrade auf Websocket durchgeführt werden, und manchmal werden weiterhin Fehler gemeldet. Wenn Sie jedoch direkt über ip+端口 darauf zugreifen, ist dies zu 100 % erfolgreich.

Analyse

sid

sid ist der Schlüssel zu unserem Problem. Beim ersten Herstellen einer Verbindung (der Polling-Modus simuliert eine lange Verbindung) initiiert der Client eine solche Anfrage:

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

Vom Server An empfangen Das Objekt wird erstellt, an die Verbindung gebunden und eine SID (Sitzungs-ID) wird zurückgegeben, um die Sitzung zu markieren. Was bedeutet eine Sitzung? Eine Sitzung ist eine Reihe von Interaktionen, und wenn in unserem Szenario die nächste http-Anfrage eintrifft, muss ich die lange Verbindung finden, die zuvor an die Theorie gebunden war (noch nicht hier). Websocket, also theoretisch). Wir wissen, dass HTTP-Anfragen zustandslos sind und jede Anfrage unabhängig ist. Deshalb hat socket.io Sid eingeführt, um dies zu erreichen. Nach Erhalt der Anfrage generiert der Server eine SID. Schauen Sie sich die Antwort an:

Code kopieren Der Code lautet wie folgt:

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

Jede nachfolgende Anfrage muss diese Seite mitbringen, und das Herstellen einer Verbindung für Websocket-Anfragen ist keine Ausnahme. Daher ist Sid der Schlüssel zum Polling und zum Upgrade des Pollings auf Websocket. Die Anfrage danach ist ähnlich wie:

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

or

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

Dann stellt sich die Frage, was passiert, wenn die SID in der Anfrage nicht vom Server generiert wird? Der Server wird es nicht erkennen und Ihnen eine 400 zurücksenden und Ihnen sagen:

invalid sid

Das ist das Problem, auf das wir gestoßen sind. Die Standardlastausgleichsstrategie von Nginx ist Polling, sodass die Anfrage möglicherweise den Computer trifft, der die SID nicht generiert hat. Wenn wir nach oben gehen, erhalten wir zu diesem Zeitpunkt eine 400. Wenn wir Glück haben, können wir sogar bestehen bleiben, bis die Websocket-Verbindung hergestellt ist.

Lösung

Hier werden zwei Lösungen vorgeschlagen

1. nginx Load Balancing verwendet ip_hash, was sicherstellen kann, dass alle Anfragen von einem Client an einen Server gehen

2. Verwenden Sie keinen Polling-Modus, sondern nur WebSocket

Beide Optionen haben ihre eigenen Vor- und Nachteile. Der zweite offensichtliche Grund ist, dass ältere Browser und Clients, die keine WebSockets unterstützen, nicht funktionieren. Die erste Art von Problem liegt tiefer. Stellen Sie sich vor, was passiert, wenn Sie Maschinen hinzufügen oder entfernen. Zu diesem Zeitpunkt ändert sich der Modus der ip_hash-Richtlinie und alle vorherigen Verbindungen sind ungültig Bei häufigem Betrieb (insbesondere wenn sich das Produkt in der Entwicklungsphase befindet) ist diese Art der verlustbehafteten Expansion und Kontraktion höchstwahrscheinlich inakzeptabel.

Das obige ist der detaillierte Inhalt vonSo lösen Sie die Falle des Nginx-Proxy-Socket.io-Dienstes. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!