WebSockets-Protokoll gegenüber HTTP

Question

Es gibt viele Blogs und Diskussionen über WebSocket und HTTP, und viele Entwickler und Websites befürworten WebSockets nachdrücklich, aber ich kann immer noch nicht verstehen, warum.

Zum Beispiel (Argumente von WebSocket-Liebhabern):

HTML5 Web Sockets stellt die nächste Evolution der Webkommunikation dar - ein bidirektionaler Vollduplex-Kommunikationskanal, der über einen einzigen Socket über das Web funktioniert. - websocket.org

HTTP unterstützt Streaming: Request Body Streaming (Sie verwenden es beim Hochladen großer Dateien) und Response Body Streaming.

Während des Verbindungsaufbaus mit WebSocket tauschen Client und Server Daten pro Frame aus, die jeweils 2 Byte betragen, im Vergleich zu 8 Kilobyte des HTTP-Headers bei kontinuierlichem Polling.

Warum enthalten diese 2 Bytes nicht den TCP- und Unter-TCP-Protokoll-Overhead?

GET /about.html HTTP/1.1
Host: example.org

Dies sind ~48 Bytes HTTP-Header.

HTTP chunked encoding - Chunked Transfer Kodierung :

23
This is the data in the first chunk
1A
and this is the second one
3
con
8
sequence
0

• Der Aufwand für jeden einzelnen Chunk ist also nicht groß.

Außerdem arbeiten beide Protokolle über TCP, so dass alle TCP-Probleme mit langlebigen Verbindungen bestehen bleiben.

Fragen:

1. Warum ist das WebSockets-Protokoll besser?
2. Warum wurde sie eingeführt, anstatt das HTTP-Protokoll zu aktualisieren?

Answer 1

1) Warum ist das WebSockets-Protokoll besser?

WebSockets eignen sich besser für Situationen, in denen eine Kommunikation mit geringer Latenz erforderlich ist, insbesondere für eine geringe Latenz bei Nachrichten zwischen Client und Server. Für Server-zu-Client-Daten können Sie eine ziemlich niedrige Latenzzeit erreichen, wenn Sie lange gehaltene Verbindungen und Chunked-Transfer verwenden. Dies hilft jedoch nicht bei der Latenz von Client zu Server, da für jede Client zu Server Nachricht eine neue Verbindung aufgebaut werden muss.

Ihr 48-Byte-HTTP-Handshake ist nicht realistisch für reale HTTP-Browserverbindungen, bei denen oft mehrere Kilobyte an Daten als Teil der Anfrage (in beide Richtungen) gesendet werden, einschließlich vieler Kopfzeilen und Cookie-Daten. Hier ist ein Beispiel für eine Anfrage/Antwort mit Chrome:

Beispielanfrage (2800 Bytes mit Cookie-Daten, 490 Bytes ohne Cookie-Daten):

GET / HTTP/1.1
Host: www.cnn.com
Connection: keep-alive
Cache-Control: no-cache
Pragma: no-cache
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.68 Safari/537.17
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: [[[2428 byte of cookie data]]]

Beispielantwort (355 Bytes):

HTTP/1.1 200 OK
Server: nginx
Date: Wed, 13 Feb 2013 18:56:27 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: CG=US:TX:Arlington; path=/
Last-Modified: Wed, 13 Feb 2013 18:55:22 GMT
Vary: Accept-Encoding
Cache-Control: max-age=60, private
Expires: Wed, 13 Feb 2013 18:56:54 GMT
Content-Encoding: gzip

Sowohl HTTP als auch WebSockets haben gleich große anfängliche Verbindungs-Handshakes, aber bei einer WebSocket-Verbindung wird der anfängliche Handshake nur einmal durchgeführt, und dann haben kleine Nachrichten nur 6 Bytes Overhead (2 für den Header und 4 für den Maskenwert). Der Latenz-Overhead entsteht nicht so sehr durch die Größe der Header, sondern durch die Logik zum Parsen/Handling/Speichern dieser Header. Darüber hinaus ist die Latenzzeit für den Aufbau der TCP-Verbindung wahrscheinlich ein größerer Faktor als die Größe oder die Verarbeitungszeit für jede Anfrage.

2) Warum wurde es anstelle einer Aktualisierung des HTTP-Protokolls eingeführt?

Es gibt Bestrebungen, das HTTP-Protokoll umzugestalten, um eine bessere Leistung und geringere Latenzzeiten zu erreichen, z. B. SPDY , HTTP 2.0 y QUIC . Dies wird die Situation für normale HTTP-Anfragen verbessern, aber es ist wahrscheinlich, dass WebSockets und/oder WebRTC DataChannel immer noch eine geringere Latenz für die Datenübertragung zwischen Client und Server haben als das HTTP-Protokoll (oder es wird in einem Modus verwendet, der ohnehin sehr wie WebSockets aussieht).

Update :

Hier ist ein Rahmen, um über Webprotokolle nachzudenken:

• TCP Low-Level-, bidirektionale, Vollduplex- und garantierte Auftrags-Transportschicht. Keine Browser-Unterstützung (außer über Plugin/Flash).

• HTTP 1.0 : Anfrage-Antwort-Transportprotokoll, das auf TCP aufbaut. Der Client stellt eine vollständige Anfrage, der Server gibt eine vollständige Antwort, und dann wird die Verbindung geschlossen. Die Anfragemethoden (GET, POST, HEAD) haben eine spezifische transaktionale Bedeutung für die Ressourcen des Servers.

• HTTP 1.1 HTTP 1.0: Behält den Anfrage-Antwort-Charakter von HTTP 1.0 bei, erlaubt aber, dass die Verbindung für mehrere vollständige Anfragen/Antworten offen bleibt (eine Antwort pro Anfrage). Die Anfrage und die Antwort enthalten weiterhin vollständige Kopfzeilen, aber die Verbindung wird wiederverwendet und nicht geschlossen. HTTP 1.1 fügte auch einige zusätzliche Anfragemethoden hinzu (OPTIONS, PUT, DELETE, TRACE, CONNECT), die ebenfalls spezifische transaktionale Bedeutungen haben. Wie jedoch im Abschnitt Einführung Im Vergleich zum HTTP-2.0-Entwurf ist das HTTP-1.1-Pipelining nicht weit verbreitet, so dass der Nutzen von HTTP 1.1 zur Lösung von Latenzproblemen zwischen Browsern und Servern stark eingeschränkt ist.

• Lange Abfrage Eine Art "Hack" für HTTP (entweder 1.0 oder 1.1), bei dem der Server nicht sofort (oder nur teilweise mit Headern) auf die Client-Anfrage antwortet. Nach einer Antwort des Servers sendet der Client sofort eine neue Anfrage (über dieselbe Verbindung, falls HTTP 1.1).

• HTTP-Streaming eine Vielzahl von Techniken (Multipart/Chunked Response), die es dem Server ermöglichen, mehr als eine Antwort auf eine einzige Client-Anfrage zu senden. Das W3C standardisiert dies als Server-gesendete Ereignisse unter Verwendung einer text/event-stream MIME-Typ. Die Browser-API (die der WebSocket-API recht ähnlich ist) wird EventSource-API genannt.

• Comet/Server Push : Dies ist ein Oberbegriff, der sowohl Long-Poll als auch HTTP-Streaming umfasst. Comet-Bibliotheken unterstützen in der Regel mehrere Techniken, um die Browser- und Server-übergreifende Unterstützung zu maximieren.

• WebSockets eine auf TCP aufbauende Transportschicht, die ein HTTP-freundliches Upgrade-Handshake verwendet. Im Gegensatz zu TCP, das ein Streaming-Transport ist, ist WebSockets ein nachrichtenbasierter Transport: Nachrichten werden auf der Leitung abgegrenzt und vor der Zustellung an die Anwendung wieder vollständig zusammengesetzt. WebSocket-Verbindungen sind bidirektional, voll-duplex und langlebig. Nach dem anfänglichen Handshake Anfrage/Antwort gibt es keine transaktionale Semantik und es fällt nur sehr wenig Overhead pro Nachricht an. Der Client und der Server können jederzeit Nachrichten senden und müssen den Empfang von Nachrichten asynchron verarbeiten.

• SPDY SPDY ist ein von Google initiierter Vorschlag zur Erweiterung von HTTP durch ein effizienteres Leitungsprotokoll unter Beibehaltung aller HTTP-Semantiken (Anfrage/Antwort, Cookies, Kodierung). SPDY führt ein neues Framing-Format ein (mit längenpräfixierten Frames) und spezifiziert einen Weg, HTTP-Anfrage/Antwort-Paare auf die neue Framing-Schicht zu schichten. Kopfzeilen können komprimiert werden und neue Kopfzeilen können nach dem Verbindungsaufbau gesendet werden. SPDY wird in der Praxis in Browsern und Servern implementiert.

• HTTP 2.0 : hat ähnliche Ziele wie SPDY: Verringerung der HTTP-Latenz und des Overheads unter Beibehaltung der HTTP-Semantik. Der aktuelle Entwurf ist von SPDY abgeleitet und definiert ein Upgrade-Handshake und ein Daten-Framing, das dem WebSocket-Standard für Handshake und Framing sehr ähnlich ist. Ein alternativer HTTP-2.0-Entwurf (httpbis-speed-mobility) verwendet WebSockets für die Transportschicht und fügt das SPDY-Multiplexing und HTTP-Mapping als WebSocket-Erweiterung hinzu (WebSocket-Erweiterungen werden während des Handshakes ausgehandelt).

• WebRTC/CU-WebRTC : Vorschläge zur Ermöglichung von Peer-to-Peer-Verbindungen zwischen Browsern. Dies kann niedrigere durchschnittliche und maximale Latenzzeiten für die Kommunikation ermöglichen, da der zugrunde liegende Transport SDP/Datagramm und nicht TCP ist. Dies ermöglicht eine ungeordnete Zustellung von Paketen/Nachrichten, wodurch das TCP-Problem von Latenzspitzen vermieden wird, die durch verworfene Pakete verursacht werden, die die Zustellung aller nachfolgenden Pakete verzögern (um eine ordnungsgemäße Zustellung zu gewährleisten).

• QUIC QUIC: ist ein experimentelles Protokoll, das die Latenzzeit im Internet gegenüber TCP verringern soll. Oberflächlich betrachtet ist QUIC sehr ähnlich wie TCP+TLS+SPDY auf UDP-Basis. QUIC bietet Multiplexing und Flusskontrolle wie HTTP/2, Sicherheit wie TLS und Verbindungssemantik, Zuverlässigkeit und Staukontrolle wie TCP. Da TCP in Betriebssystem-Kernels und Middlebox-Firmware implementiert ist, ist es nahezu unmöglich, wesentliche Änderungen an TCP vorzunehmen. Da QUIC jedoch auf UDP aufbaut, unterliegt es keinen derartigen Beschränkungen. QUIC wurde für die Semantik von HTTP/2 entwickelt und optimiert.

Referenzen :

HTTP :

• Wikipedia HTTP-Seite
• W3C-Liste von HTTP-bezogenen Entwürfen/Protokollen
• Liste der IETF-Entwürfe für HTTP/1.1 und HTTP/2.0

Server-gesendetes Ereignis :

• W3C Server-Sent Events/EventSource-Kandidatenempfehlung
• W3C-Entwurf für servergesendete Ereignisse/Ereignisquellen

WebSockets :

• IETF RFC 6455 WebSockets-Protokoll
• IETF RFC 6455 WebSocket Errata

SPDY :

• IETF SPDY-Entwurf

HTTP 2.0 :

• IETF HTTP 2.0 httpbis-http2-Entwurf
• IETF HTTP 2.0 httpbis-speed-mobility Entwurf
• IETF httpbis-network-friendly-Entwurf - ein älterer Vorschlag zu HTTP 2.0

WebRTC :

• W3C WebRTC API-Entwurf
• Liste der IETF WebRTC-Entwürfe
• IETF WebRTC Übersichtsentwurf
• IETF WebRTC DataChannel-Entwurf
• Microsoft CU-WebRTC-Vorschlag-Startseite

QUIC :

• QUIC Chrominum Projekt
• IETF QUIC-Entwurf

Answer 2

Sie scheinen anzunehmen, dass WebSocket ein Ersatz für HTTP ist. Das ist es nicht. Es ist eine Erweiterung.

Der Hauptanwendungsfall von WebSockets sind Javascript-Anwendungen, die im Webbrowser laufen und Echtzeitdaten von einem Server empfangen. Spiele sind ein gutes Beispiel.

Vor WebSockets war die einzige Methode für JavaScript-Anwendungen zur Interaktion mit einem Server XmlHttpRequest . Diese haben jedoch einen großen Nachteil: Der Server kann keine Daten senden, wenn der Client sie nicht ausdrücklich angefordert hat.

Aber die neue WebSocket-Funktion ermöglicht es dem Server, Daten zu senden, wann immer er will. Dies ermöglicht die Implementierung von browserbasierten Spielen mit einer viel geringeren Latenzzeit und ohne hässliche Hacks wie AJAX Long-Polling oder Browser-Plugins verwenden zu müssen.

Warum also nicht normales HTTP mit gestreamten Anfragen und Antworten verwenden?

In einem Kommentar zu einer anderen Antwort haben Sie vorgeschlagen, die Clientanforderung und den Antwortkörper asynchron zu streamen.

Im Grunde genommen sind WebSockets genau das. Der Versuch, eine WebSocket-Verbindung vom Client aus zu öffnen, sieht zunächst wie eine HTTP-Anfrage aus, aber eine spezielle Anweisung im Header ( Upgrade: websocket ) weist den Server an, die Kommunikation in diesem asynchronen Modus zu beginnen. Erste Entwürfe des WebSocket-Protokolls waren nicht viel mehr als das und etwas Handshaking, um sicherzustellen, dass der Server tatsächlich versteht, dass der Client asynchron kommunizieren will. Aber dann wurde klar, dass Proxy-Server dadurch verwirrt werden würden, weil sie an das übliche Anfrage/Antwort-Modell von HTTP gewöhnt sind. A mögliches Angriffsszenario gegen Proxy-Server entdeckt wurde. Um dies zu verhindern, war es notwendig, den WebSocket-Verkehr so zu gestalten, dass er nicht wie normaler HTTP-Verkehr aussieht. Aus diesem Grund wurden die Maskierungsschlüssel eingeführt in die endgültige Fassung des Protokolls .

Answer 3

Eine reguläre REST-API verwendet HTTP als zugrunde liegendes Protokoll für die Kommunikation, das dem Request-and-Response-Paradigma folgt, d. h. die Kommunikation beinhaltet, dass der Client Daten oder Ressourcen von einem Server anfordert und der Server dem Client antwortet. HTTP ist jedoch ein zustandsloses Protokoll, so dass bei jedem Anfrage-Antwort-Zyklus die Header- und Metadateninformationen wiederholt werden müssen. Dies führt bei häufig wiederholten Anfrage-Antwort-Zyklen zu zusätzlichen Latenzzeiten.

Bei WebSockets beginnt die Kommunikation zwar immer noch mit einem anfänglichen HTTP-Handshake, wird aber weiter ausgebaut, um dem WebSockets-Protokoll zu folgen (d. h. wenn sowohl der Server als auch der Client mit dem Protokoll konform sind, da nicht alle Einrichtungen das WebSockets-Protokoll unterstützen).

Mit WebSockets ist es nun möglich, eine vollduplexe und dauerhafte Verbindung zwischen dem Client und einem Server herzustellen. Das bedeutet, dass die Verbindung im Gegensatz zu einer Anfrage und einer Antwort so lange offen bleibt, wie die Anwendung läuft (d.h. sie ist persistent), und da sie voll-duplex ist, ist eine simultane Zwei-Wege-Kommunikation möglich, d.h. der Server ist jetzt in der Lage, die Kommunikation zu initiieren und einige Daten an den Client zu "pushen", wenn neue Daten (an denen der Client interessiert ist) verfügbar werden.

Das WebSockets-Protokoll ist zustandsbehaftet und ermöglicht die Implementierung des Publish-Subscribe- (oder Pub/Sub-) Nachrichtenmusters, das in Echtzeittechnologien verwendet wird, bei denen neue Aktualisierungen in Form eines Server-Pushs abgerufen werden können, ohne dass der Client wiederholt eine Anfrage stellen muss (Aktualisierung der Seite). Beispiele für solche Anwendungen sind die Standortverfolgung von Uber-Fahrzeugen, Push-Benachrichtigungen, die Aktualisierung von Börsenkursen in Echtzeit, Chats, Multiplayer-Spiele, Tools für die Online-Zusammenarbeit usw.

Sie können einen ausführlichen Artikel über Websockets lesen, der die Geschichte dieses Protokolls erklärt, wie es entstanden ist, wofür es verwendet wird und wie Sie es selbst implementieren können.

Hier ist ein Video aus einer Präsentation, die ich über WebSockets gehalten habe, und wie sie sich von der Verwendung der regulären REST-APIs unterscheiden: Standardisierung und Nutzung des exponentiellen Anstiegs des Datenstroms

Answer 4

Für die TL;DR, hier sind 2 Cent und eine einfachere Version für Ihre Fragen:

1. WebSockets bietet diese Vorteile gegenüber HTTP:

   • Persistente zustandsabhängige Verbindung für die Dauer der Verbindung
   • Geringe Latenz: Kommunikation zwischen Server/Client nahezu in Echtzeit, da kein Overhead für die Wiederherstellung der Verbindung bei jeder Anfrage anfällt, wie es bei HTTP der Fall ist.
   • Vollduplex: Sowohl Server als auch Client können gleichzeitig senden/empfangen
2. Das WebSocket- und das HTTP-Protokoll wurden entwickelt, um unterschiedliche Probleme zu lösen, d.h. WebSocket wurde entwickelt, um die bidirektionale Kommunikation zu verbessern, während HTTP entwickelt wurde, um zustandslos und verteilt zu sein und ein Anfrage/Antwort-Modell zu verwenden. Abgesehen von der gemeinsamen Nutzung der Ports aus Legacy-Gründen (Firewall/Proxy-Penetration) gibt es nicht viele Gemeinsamkeiten, um sie in einem Protokoll zu vereinen.

Answer 5

Warum ist das WebSockets-Protokoll besser?

Ich glaube nicht, dass wir sie nebeneinander vergleichen können, wer besser ist. Das wäre kein fairer Vergleich, einfach weil sie die Probleme lösen. zwei unterschiedliche Probleme . Ihre Anforderungen sind unterschiedlich. Es ist, als würde man Äpfel mit Birnen vergleichen. Sie sind unterschiedlich.

HTTP ist ein Anfrage-/Antwort-Protokoll. Der Client (Browser) will etwas, der Server gibt es ihm. Das heißt. Wenn die vom Client angeforderten Daten sehr groß sind, sendet der Server möglicherweise Streaming-Daten, um unerwünschte Pufferprobleme zu vermeiden. Die Hauptanforderung bzw. das Hauptproblem besteht darin, wie die Anfragen der Clients gestellt werden und wie die angeforderten Ressourcen (Hypertext) beantwortet werden. Das ist die Stärke von HTTP.

Bei HTTP nur Client-Anfragen. Der Server antwortet nur.

WebSocket ist kein Anfrage-Antwort-Protokoll, bei dem nur der Kunde eine Anfrage stellen kann. Es ist ein Socket (sehr ähnlich dem TCP-Socket). Das heißt, sobald die Verbindung geöffnet ist, können beide Seiten Daten senden, bis die darunter liegende TCP-Verbindung geschlossen wird. Es ist genau wie ein normaler Socket. Der einzige Unterschied zum TCP-Socket ist, dass WebSocket im Web verwendet werden kann. Im Web gibt es viele Einschränkungen für einen normalen Socket. Die meisten Firewalls blockieren andere Ports als 80 und 433, die HTTP verwendet. Auch Proxies und Vermittler sind problematisch. Damit das Protokoll leichter in bestehende Infrastrukturen integriert werden kann, verwendet WebSocket den HTTP-Handshake zur Aktualisierung. Das bedeutet, dass der Client beim ersten Verbindungsaufbau eine HTTP-Anfrage an den Server sendet, um ihm mitzuteilen: "Das ist keine HTTP-Anfrage, bitte wechseln Sie zum WebSocket-Protokoll".

Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

Sobald der Server die Anfrage versteht und auf das WebSocket-Protokoll umgestellt hat, gilt keines der HTTP-Protokolle mehr.

Meine Antwort lautet also Keiner von beiden ist besser als der andere. Sie sind völlig unterschiedlich.

Warum wurde sie eingeführt, anstatt das HTTP-Protokoll zu aktualisieren?

Nun, wir können alles unter dem Namen machen, der HTTP auch. Aber sollen wir? Wenn es sich um zwei verschiedene Dinge handelt, werde ich zwei verschiedene Namen vorziehen. Das tun Hickson und Michael Carter .