Vertieftes Verständnis der Websocket-Prinzipien

Dieser Artikel vermittelt Ihnen ein tiefgreifendes Verständnis der Prinzipien von Websocket. Ich hoffe, er kann Freunden in Not helfen. 

1. Websocket und http

WebSocket ist ein von HTML5 eingeführtes Ding (Protokoll), was bedeutet, dass sich das HTTP-Protokoll nicht geändert hat oder es keine Rolle spielt, aber HTTP nicht unterstützt persistente Verbindungen (lange Verbindungen, zirkuläre Verbindungen werden nicht gezählt)

Erstens verfügt HTTP über 1.1 und 1.0 , die sogenannten keep-alive , die mehrere HTTP-Anfragen zu einer zusammenführen. aber Websocket ist eigentlich ein neues Protokoll, das nichts mit dem HTTP-Protokoll zu tun hat. Es dient nur der Kompatibilität mit den Handshake-Spezifikationen bestehender Browser. Mit anderen Worten, es ist eine Ergänzung zum HTTP-Protokoll So ein Bild

Es gibt Kreuzungen, aber nicht alle.

Darüber hinaus bezieht sich Html5 auf eine Reihe neuer APIs bzw. neuer Spezifikationen und neuer Technologien. Das HTTP-Protokoll selbst hat nur 1.0 und 1.1 und hat keine direkte Beziehung zu HTML selbst. . Laienhaft ausgedrückt: Sie können das HTTP-Protokoll verwenden, um Nicht-HTML-Daten zu übertragen, das ist alles =. =

Vereinfacht ausgedrückt sind die Level unterschiedlich.

2. Was für ein Protokoll ist Websocket und was sind seine spezifischen Vorteile?

Erstens ist Websocket im Vergleich zu nicht-persistenten Protokollen wie HTTP ein persistentes Protokoll. Lassen Sie uns ein einfaches Beispiel geben und den derzeit weit verbreiteten PHP-Lebenszyklus zur Erklärung verwenden.

Der Lebenszyklus von HTTP wird durch Request definiert, d. h. eins Request und eins Response. Dann endet diese HTTP-Anfrage in HTTP1.0.

In HTTP 1.1 wurden Verbesserungen vorgenommen, so dass es ein Keep-Alive gibt, d. h. in einer HTTP-Verbindung können mehrere Anfragen gesendet und mehrere Antworten empfangen werden. Aber bitte bedenken Sie Request = Response, dass dies bei HTTP immer der Fall ist, was bedeutet, dass eine Anfrage nur eine Antwort haben kann. Darüber hinaus ist diese Reaktion ebenfalls passiv und kann nicht aktiv initiiert werden.

Trainer, Sie haben so viel getan, was hat das mit Websocket zu tun? _(:з　∠)_Okay, ich wollte gerade über Websocket sprechen. .

Zuallererst basiert Websocket auf dem HTTP-Protokoll oder leiht sich das HTTP-Protokoll aus, um einen Teil des Handshakes abzuschließen.

Schauen wir uns zunächst einen typischen WebsocketHandshake an (aus Wikipedia entlehnt...)

GET /chat HTTP/1.1Host: server.example.comUpgrade: websocketConnection: UpgradeSec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==Sec-WebSocket-Protocol: chat, superchatSec-WebSocket-Version: 13Origin: http://example.com

Kinder, die mit HTTP vertraut sind, haben möglicherweise bemerkt, dass diese Handshake-Anfrage dem HTTP-Protokoll ähnelt , es gibt viele Habe ein paar Dinge. Die Funktion erkläre ich übrigens.

Upgrade: websocketConnection: Upgrade

Das ist der Kern von Websocket, Apache und anderen Servern: Achtung, ich habe das Websocket-Protokoll initiiert – nicht so altmodisch ein HTTP. Nginx

Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==Sec-WebSocket-Protocol: chat, superchatSec-WebSocket-Version: 13

Zuallererst ist

ein Sec-WebSocket-Key-Wert, der vom Browser zufällig generiert wird und dem Server mitteilt: Torf, mach mir nichts vor, ich möchte überprüfen, ob du wirklich ein bist Websocket-Assistent. Base64 encode

Dann ist

eine benutzerdefinierte Zeichenfolge, die zur Unterscheidung der Protokolle verwendet wird, die von verschiedenen Diensten unter derselben URL benötigt werden. Einfaches Verständnis: Ich möchte heute Abend A bedienen, machen Sie keinen Fehler ~Sec_WebSocket-Protocol

Abschließend teilt

dem Server mit, welches Sec-WebSocket-Version (Protokollversion) verwendet wurde. Zu Beginn war das Websocket-Protokoll noch Websocket Draft In dieser Phase gibt es alle möglichen seltsamen Protokolle, und es gibt auch viele seltsame und unterschiedliche Dinge. Zu Beginn gab es zu viele Websocket-Protokolle, was ein großes Problem war. . Aber jetzt ist alles in Ordnung, es ist geklärt ~ eine Sache, die jeder benutzt ~ Dehydrierung: Draft Kellner, ich möchte einen 13-Jährigen →_→

Dann wird der Server die folgenden Dinge zurückgeben: Zeigt an, dass die Anfrage angenommen wurde und der Websocket erfolgreich eingerichtet wurde!

HTTP/1.1 101 Switching ProtocolsUpgrade: websocketConnection: UpgradeSec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=Sec-WebSocket-Protocol: chat

Dies ist der letzte Bereich, der für HTTP verantwortlich ist. Teilen Sie dem Client mit, dass ich das Protokoll erfolgreich umgestellt habe. ~

Upgrade: websocketConnection: Upgrade

ist immer noch behoben und teilt dem Client mit, dass das bevorstehende Upgrade der

ist Protokoll, nicht Mozillasocket, Lurnarsocket oder Shitsocket. Websocket

Dann

wird dies vom Server bestätigt und verschlüsselt Sec-WebSocket-Accept . Server: Okay, okay, ich verstehe. Lassen Sie mich Ihnen meinen Personalausweis zeigen, um es zu beweisen. . Nach Sec-WebSocket-Key

stellt

das endgültige verwendete Protokoll dar. Sec-WebSocket-Protocol

Zu diesem Zeitpunkt hat HTTP seine gesamte Arbeit abgeschlossen und der nächste Schritt besteht darin, vollständig in Übereinstimmung mit dem Websocket-Protokoll vorzugehen. Auf die konkrete Vereinbarung wird hier nicht näher eingegangen.

————Teil der technischen Analyse abgeschlossen——————

Sie haben so lange BBBing, also was nützt Websocket http long poll oder ajax轮询 kann keine Echtzeit-Informationsübertragung realisieren?

Okay, junge Leute, lasst uns über die Verwendung von Websocket sprechen. Lassen Sie mich Ihnen ein paar Karotten (rot) geben

3. Die Rolle von Websocket

Bevor ich über Websocket spreche, werde ich übrigens darüber reden die Prinzipien von long poll und ajax轮询.

Ajax-Polling

Das Prinzip des Ajax-Pollings ist sehr einfach. Lassen Sie den Browser alle paar Sekunden eine Anfrage senden, um den Server zu fragen, ob neue Informationen vorliegen.

Szenenwiedergabe:

Kunde: La la la, gibt es neue Informationen (Anfrage)

Server: Nein (Antwort)

Kunde: La la la, gibt es neue Informationen (Anfrage)

Server: Nein. . (Antwort)

Kunde: La la la, gibt es neue Informationen (Anfrage)

Server: Du bist so genervt, es gibt keine. . (Antwort)

Kunde: La la la, gibt es eine neue Nachricht? (Anfrage)

Server: Okay, okay, ich habe sie für dich. (Antwort)

Kunde: La la la, gibt es neue Nachrichten? (Anfrage)

Server:. . . . . ohne. . . . ohne. . . Nein (Antwort) – Schleife

lange Umfrage

long poll Tatsächlich ähnelt das Prinzip dem von ajax轮询, beide verwenden Abfragen, verwenden jedoch ein Blockierungsmodell (rufen Sie weiter an, tun Sie es Legen Sie den Hörer nicht auf, wenn er nicht empfangen wird. Das heißt, nachdem der Client die Verbindung initiiert hat und keine Nachricht vorliegt, wird die Antwort nicht an den Client zurückgegeben. Die Rückkehr erfolgt erst, wenn eine Nachricht vorliegt. Nach der Rückkehr stellt der Client die Verbindung erneut her und der Zyklus beginnt von neuem.

Szenenreproduktion:

Kunde: La la la, gibt es neue Informationen? Wenn nicht, warten Sie einfach, bis sie verfügbar sind, bevor Sie sie an mich zurücksenden (Anfrage)

Server: Stirn. . Warten Sie, bis es Neuigkeiten gibt. . Kommen Sie zu Ihnen (Antwort)

Kunde: La la la, gibt es neue Informationen? Wenn nicht, warten Sie einfach, bis sie verfügbar sind, bevor Sie sie an mich zurücksenden (Anfrage) - Schleife

Sie Sie können es von oben sehen. Tatsächlich stellen diese beiden Methoden ständig HTTP-Verbindungen her und warten dann darauf, dass der Server sie verarbeitet, was ein weiteres Merkmal des HTTP-Protokolls widerspiegeln kann: Passivität.

Was ist Passivität? Tatsächlich kann der Server den Client nicht aktiv kontaktieren, sondern nur vom Client initiiert werden.

Um es einfach auszudrücken: Der Server ist ein sehr fauler Kühlschrank (das ist ein Witz) (er kann und kann nicht aktiv eine Verbindung herstellen), aber der Chef hat einen Auftrag. Wenn ein Kunde kommt, muss er ihn erhalten Es ist egal, wie müde er ist.

Nachdem wir darüber gesprochen haben, lassen Sie uns über die oben genannten Mängel sprechen (verzeihen Sie mir, dass ich so viel OAQ rede)

Aus dem oben Gesagten ist leicht zu erkennen, egal was passiert, die beiden oben genannten sind sehr Ressourcen verbrauchend.

Ajax-Polling erfordert, dass der Server über eine hohe Verarbeitungsgeschwindigkeit und Ressourcen verfügt. (Geschwindigkeit) Lange Umfragen erfordern eine hohe Parallelität, was bedeutet, dass Kunden gleichzeitig empfangen werden können. (Größe des Veranstaltungsortes)

Das kann also sowohl bei ajax轮询 als auch bei long poll passieren.

Kunde: La la la la, gibt es neue Informationen?

Server: Die monatliche Leitung ist ausgelastet, bitte versuchen Sie es später noch einmal (503 Server nicht verfügbar)

Client:. . . . Okay, la la la, irgendwelche neuen Informationen?

Server: Die monatliche Leitung ist ausgelastet, bitte versuchen Sie es später noch einmal (503 Server nicht verfügbar)

Client: Dann ist der Server nebenbei sehr ausgelastet: Kühlschrank, ich möchte mehr Kühlschränke! Mehr. . Mehr. . (Ich habe mich geirrt... Das ist ein weiterer Witz...)

Kehren wir zum Thema zurück, sprechen wir über Websocket

Anhand des obigen Beispiels können wir erkennen, dass keines von beiden der Fall ist Zwei Methoden sind die beste Methode, die viele Ressourcen erfordert.

Man braucht höhere Geschwindigkeiten, man braucht mehr „Telefone“. Beides wird zu einer steigenden Nachfrage nach „Telefonen“ führen.

Ach übrigens, ich habe vergessen zu erwähnen, dass HTTP immer noch ein zustandsbehaftetes Protokoll ist.

Laienhaft ausgedrückt: Der Kellner hat jeden Tag mit zu vielen Kunden zu tun und ist ein vergesslicher Mensch. Sobald Sie auflegen, vergisst er alle Ihre Sachen und wirft sie weg. Beim zweiten Mal müssen Sie es dem Server erneut mitteilen.

In diesem Fall erschien also Websocket. Er hat diese Probleme von HTTP gelöst. Erstens: Passivität Nachdem der Server das Protokoll-Upgrade abgeschlossen hat (HTTP->Websocket), kann der Server aktiv Informationen an den Client übertragen. Das obige Szenario kann also wie folgt geändert werden.

Client: la la la, ich möchte das Websocket-Protokoll einrichten, erforderliche Dienste: Chat, Websocket-Protokollversion: 17 (HTTP-Anfrage)

Server: ok, bestätigt, auf Websocket-Protokoll aktualisiert ( HTTP-Protokolle umgestellt)

Kunde: Bitte leiten Sie es mir weiter, wenn Sie Informationen haben. .

Server: Ok, ich werde es dir manchmal sagen.

Server: balabalabalabala

Server: balabalabalabala

Serverseite: Hahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahaha hahahahahahaha

Es wird so, dass nur eine HTTP-Anfrage erforderlich ist. Es wird ein stetiger Informationsstrom übertragen. (In der Programmierung wird diese Art von Design als Rückruf bezeichnet, das heißt: Benachrichtigen Sie mich, wenn Sie Informationen haben, anstatt dass ich Sie jedes Mal dumm frage.)

Diese Art von Protokoll löst die oben genannte Synchronisationsverzögerung ist zudem sehr ressourcenintensiv. Warum löst er also das Problem des Ressourcenverbrauchs auf dem Server?

Tatsächlich durchläuft das von uns verwendete Programm zwei Proxy-Ebenen, das heißt, das HTTP-Protokoll wird von Servern wie Nginx analysiert und dann zur Verarbeitung an den entsprechenden Handler (PHP usw.) übertragen. Einfach ausgedrückt: Wir haben einen sehr schnellen

, der für die Weiterleitung von Problemen an die entsprechenden

verantwortlich ist. 接线员（Nginx）客服（Handler）Der Operator selbst ist grundsätzlich schnell genug, aber jedes Mal, wenn ich im Kundenservice (Handler) stecken bleibe, ist die Bearbeitungsgeschwindigkeit des Kundenservice immer zu langsam. , was zu einem unzureichenden Kundenservice führte. Websocket löst ein solches Problem, indem Sie direkt eine dauerhafte Verbindung mit dem Betreiber herstellen. Wenn Informationen vorliegen, findet der Kundendienst eine Möglichkeit, den Betreiber zu benachrichtigen, und der Betreiber leitet sie dann an den Kunden weiter.

Dies kann das Problem der langsamen Bearbeitungsgeschwindigkeit des Kundendienstes lösen.

Gleichzeitig müssen Sie auf herkömmliche Weise das HTTP-Protokoll ständig etablieren und schließen. Da HTTP nicht zustandsbehaftet ist, müssen Sie

(Identifikationsinformationen) jedes Mal erneut übertragen Server, dass du wer bist.

identity infoObwohl der Operator sehr schnell ist, verringert sich die Effizienz, wenn er sich jedes Mal so viel anhören muss. Gleichzeitig muss er diese Informationen ständig an den Kundendienst weiterleiten, was nicht nur Zeitverschwendung ist Die Verarbeitungszeit des Kundendienstes wird beeinträchtigt, es wird aber auch übermäßig viel Datenverkehr/Zeit bei der Netzwerkübertragung verbraucht.

Websocket erfordert jedoch nur einen HTTP-Handshake, sodass der gesamte Kommunikationsprozess in einer Verbindung/einem einzigen Status hergestellt wird, wodurch die Zustandslosigkeit von HTTP vermieden wird. Der Server kennt Ihre Informationen immer, bis Sie sie schließen Das Problem besteht darin, dass der Betreiber das HTTP-Protokoll wiederholt analysieren und die Identitätsinformationen überprüfen muss.

Gleichzeitig ergreift der Client die Initiative, um nachzufragen, und der Server (Push) sendet sie, wenn Informationen vorliegen (natürlich wartet der Client immer noch auf die Initiative, Informationen zu senden ...), und wenn keine Informationen vorhanden sind, werden sie an den Betreiber (Nginx) übergeben, ohne dass der Kundendienst (Handler) in Anspruch genommen werden muss, der von Natur aus langsam ist

Was die Verwendung von Websocket auf einem Client betrifft, der dies nicht tut unterstützt Websocket. . Die Antwort lautet:

kann nicht

, aber Sie können ähnliche Effekte durch die oben genannten

und

long pollajax 轮询Verwandte Empfehlungen simulieren:

HTML-Imitation der Baidu-Homepage

Die Rolle von Meta in der HTML-Seite und die Analyse der Cache- und Nicht-Caching-Einstellungen der Seite

Das obige ist der detaillierte Inhalt vonVertieftes Verständnis der Websocket-Prinzipien. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!