WebSockets-Protokoll gegen HTTP

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

Zum Beispiel (Argumente von Websocket-Liebhabern):

HTML5-Web-Sockets stellen die nächste Entwicklung der Webkommunikation dar - einen bidirektionalen Vollduplex-Kommunikationskanal, der über einen einzigen Socket über das Web betrieben wird. ( http://www.websocket.org/quantum.html )

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

Während der Verbindung mit WebSocket tauschen Client und Server Daten pro Frame aus, die jeweils 2 Byte betragen, verglichen mit 8 Kilo HTTP-Header bei kontinuierlicher Abfrage.

Warum enthalten diese 2 Bytes nicht TCP und unter TCP-Protokollen Overhead?

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

Dies ist ~ 48 Bytes http-Header.

http chunked encoding - https://en.wikipedia.org/wiki/Chunked_transfer_encoding :

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

• Der Overhead pro Block ist also nicht groß.

Außerdem funktionieren beide Protokolle über TCP, sodass alle TCP-Probleme mit langlebigen Verbindungen weiterhin bestehen.

Fragen:

1. Warum ist das Websockets-Protokoll besser?
2. Warum wurde es implementiert, anstatt das http-Protokoll zu aktualisieren?

1) Warum ist das WebSockets-Protokoll besser?

WebSockets ist besser für Situationen geeignet, in denen Kommunikation mit geringer Latenz erforderlich ist, insbesondere für Situationen mit geringer Latenz für Client-Server-Nachrichten. Bei Server-zu-Client-Daten kann die Latenz durch lang anhaltende Verbindungen und Chunked-Übertragung relativ gering sein. Dies hilft jedoch nicht bei der Latenz von Client zu Server, bei der für jede Client-zu-Server-Nachricht eine neue Verbindung hergestellt werden muss.

Ihr 48-Byte-HTTP-Handshake ist für reale HTTP-Browserverbindungen nicht realistisch, bei denen häufig mehrere Kilobyte Daten als Teil der Anforderung gesendet werden (in beide Richtungen), einschließlich vieler Header und Cookie-Daten. Hier ist ein Beispiel für eine Anfrage / Antwort auf die Verwendung von Chrome:

Beispielanforderung (2800 Bytes einschließlich 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 Handshakes für die anfängliche Verbindung gleicher Größe. Bei einer WebSocket-Verbindung wird der anfängliche Handshake jedoch einmal ausgeführt, und kleine Nachrichten haben nur 6 Byte Overhead (2 für den Header und 4 für den Maskenwert). Der Latenzaufwand hängt nicht so sehr von der Größe der Header ab, sondern von der Logik zum Parsen / Behandeln / Speichern dieser Header. Darüber hinaus ist die Latenz beim Einrichten der TCP-Verbindung wahrscheinlich ein größerer Faktor als die Größe oder Verarbeitungszeit für jede Anforderung.

2) Warum wurde es implementiert, anstatt das HTTP-Protokoll zu aktualisieren?

Es wird versucht, das HTTP-Protokoll neu zu entwickeln, um eine bessere Leistung und eine geringere Latenz wie SPDY , HTTP 2.0 und QUIC zu erzielen . Dies verbessert die Situation für normale HTTP-Anforderungen, aber es ist wahrscheinlich, dass WebSockets und / oder WebRTC DataChannel immer noch eine geringere Latenz für die Datenübertragung von Client zu Server aufweisen als das HTTP-Protokoll (oder es wird in einem Modus verwendet, der WebSockets sehr ähnlich sieht Sowieso).

Update :

Hier ist ein Rahmen zum Nachdenken über Webprotokolle:

• TCP : Low-Level-, bidirektionale, Vollduplex- und garantierte Auftragstransportschicht. Keine Browserunterstützung (außer über Plugin / Flash).
• HTTP 1.0 : Auf TCP geschichtetes Request-Response-Transportprotokoll. Der Client stellt eine vollständige Anfrage, der Server gibt eine vollständige Antwort und dann wird die Verbindung geschlossen. Die Anforderungsmethoden (GET, POST, HEAD) haben eine spezifische Transaktionsbedeutung für Ressourcen auf dem Server.
• HTTP 1.1 : Behält die Anforderungs-Antwort-Natur von HTTP 1.0 bei, ermöglicht jedoch, dass die Verbindung für mehrere vollständige Anforderungen / vollständige Antworten (eine Antwort pro Anforderung) offen bleibt. Die Anforderung und Antwort enthält weiterhin vollständige Header, die Verbindung wird jedoch wiederverwendet und nicht geschlossen. HTTP 1.1 hat auch einige zusätzliche Anforderungsmethoden (OPTIONS, PUT, DELETE, TRACE, CONNECT) hinzugefügt, die ebenfalls spezifische Transaktionsbedeutungen haben. Wie in der Einführung zum Entwurf des HTTP 2.0-Entwurfs erwähnt, ist das HTTP 1.1-Pipelining jedoch nicht weit verbreitet, sodass der Nutzen von HTTP 1.1 zur Lösung der Latenz zwischen Browsern und Servern stark eingeschränkt wird.
• Lange Umfrage : Eine Art "Hack" auf HTTP (entweder 1.0 oder 1.1), bei dem der Server nicht sofort (oder nur teilweise mit Headern) auf die Clientanforderung reagiert. Nach einer Serverantwort sendet der Client sofort eine neue Anforderung (über HTTP 1.1 wird dieselbe Verbindung verwendet).
• HTTP-Streaming : Eine Vielzahl von Techniken (mehrteilige / blockierte Antwort), mit denen der Server mehr als eine Antwort auf eine einzelne Clientanforderung senden kann. Das W3C standardisiert dies als vom Server gesendete Ereignisse unter Verwendung eines text/event-streamMIME-Typs. Die Browser-API (die der WebSocket-API ziemlich ähnlich ist) wird als EventSource-API bezeichnet.
• Comet / Server Push : Dies ist ein Überbegriff, der sowohl Long-Poll- als auch HTTP-Streaming umfasst. Comet-Bibliotheken unterstützen normalerweise mehrere Techniken, um die browser- und serverübergreifende Unterstützung zu maximieren.
• WebSockets : Eine auf TCP basierende Transportschicht, die einen HTTP-freundlichen Upgrade-Handshake verwendet. Im Gegensatz zu TCP, einem Streaming-Transport, handelt es sich bei WebSockets um einen nachrichtenbasierten Transport: Nachrichten werden auf der Leitung begrenzt und vor der Übermittlung an die Anwendung vollständig neu zusammengestellt. WebSocket-Verbindungen sind bidirektional, Vollduplex und langlebig. Nach der ersten Handshake-Anforderung / Antwort gibt es keine Transaktionssemantik und nur sehr wenig Overhead pro Nachricht. Der Client und der Server können jederzeit Nachrichten senden und müssen den Nachrichtenempfang asynchron behandeln.
• SPDY : Ein von Google initiierter Vorschlag zur Erweiterung von HTTP mithilfe eines effizienteren Kabelprotokolls unter Beibehaltung der gesamten HTTP-Semantik (Anforderung / Antwort, Cookies, Codierung). SPDY führt ein neues Rahmenformat (mit Rahmen mit Längenpräfix) ein und gibt eine Möglichkeit an, HTTP-Anforderungs- / Antwortpaare auf die neue Rahmenebene zu schichten. Header können komprimiert und neue Header gesendet werden, nachdem die Verbindung hergestellt wurde. Es gibt reale Implementierungen von SPDY in Browsern und Servern.
• HTTP 2.0 : hat ähnliche Ziele wie SPDY: Reduzierung der HTTP-Latenz und des Overheads unter Beibehaltung der HTTP-Semantik. Der aktuelle Entwurf ist von SPDY abgeleitet und definiert ein Upgrade-Handshake und Datenframing, das dem WebSocket-Standard für Handshake und Framing sehr ähnlich ist. Ein alternativer HTTP 2.0-Entwurfsvorschlag (httpbis-speed-mobility) verwendet tatsächlich WebSockets für die Transportschicht und fügt das SPDY-Multiplexing und die HTTP-Zuordnung als WebSocket-Erweiterung hinzu (WebSocket-Erweiterungen werden während des Handshakes ausgehandelt).
• WebRTC / CU-WebRTC : Vorschläge zur Ermöglichung der Peer-to-Peer-Konnektivität zwischen Browsern. Dies kann eine Kommunikation mit niedrigerer durchschnittlicher und maximaler Latenz ermöglichen, da der zugrunde liegende Transport eher SDP / Datagramm als TCP ist. Dies ermöglicht die Zustellung von Paketen / Nachrichten außerhalb der Reihenfolge, wodurch das TCP-Problem von Latenzspitzen vermieden wird, die durch verworfene Pakete verursacht werden und die Zustellung aller nachfolgenden Pakete verzögern (um die Zustellung in der Reihenfolge zu gewährleisten).
• QUIC : ist ein experimentelles Protokoll zur Reduzierung der Weblatenz gegenüber TCP. An der Oberfläche ist QUIC TCP + TLS + SPDY sehr ähnlich, das auf UDP implementiert ist. QUIC bietet Multiplexing und Flusskontrolle, die HTTP / 2 entsprechen, Sicherheit, die TLS entspricht, sowie Verbindungssemantik, Zuverlässigkeit und Überlastungskontrolle, die TCP entsprechen. Da TCP in Betriebssystemkernen und in der Middlebox-Firmware implementiert ist, ist es nahezu unmöglich, wesentliche Änderungen an TCP vorzunehmen. Da QUIC jedoch auf UDP aufbaut, unterliegt es keinen solchen Einschränkungen. QUIC wurde für die HTTP / 2-Semantik entwickelt und optimiert.

Referenzen :

• HTTP :
  • Wikipedia HTTP Seite
  • W3C Liste der HTTP-bezogenen Entwürfe / Protokolle
  • Liste der IETF-HTTP / 1.1- und HTTP / 2.0-Entwürfe
• Vom Server gesendetes Ereignis :
  • Vom W3C-Server gesendete Ereignisse / EventSource-Kandidatenempfehlung
  • Vom W3C-Server gesendete Ereignisse / EventSource-Entwurf
• WebSockets :
  • IETF RFC 6455 WebSockets-Protokoll
  • IETF RFC 6455 WebSocket Errata
• SPDY :
  • IETF SPDY Entwurf
• HTTP 2.0 :
  • IETF HTTP 2.0 httpbis-http2 Draft
  • IETF HTTP 2.0 httpbis-speed-Mobility Draft
  • IETF httpbis-netzwerkfreundlicher Entwurf - ein älterer HTTP 2.0-Vorschlag
• WebRTC :
  • W3C WebRTC API Draft
  • Liste der IETF-WebRTC-Entwürfe
  • IETF WebRTC Übersichtsentwurf
  • IETF WebRTC DataChannel Draft
  • Startseite des Microsoft CU-WebRTC-Vorschlags
• QUIC :
  • QUIC Chrominum Projekt
  • IETF QUIC Entwurf

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

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

Vor WebSockets war die einzige Methode für Javascript-Anwendungen, mit einem Server zu interagieren, "Through" XmlHttpRequest. Diese haben jedoch einen großen Nachteil: Der Server kann keine Daten senden, es sei denn, der Client hat dies ausdrücklich angefordert.

Mit der neuen WebSocket-Funktion kann der Server jedoch jederzeit Daten senden. Dies ermöglicht die Implementierung von browserbasierten Spielen mit einer viel geringeren Latenz und ohne hässliche Hacks wie AJAX Long-Polling oder Browser-Plugins.

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 Antworttext nur asynchron zu streamen.

In der Tat sind WebSockets im Grunde das. Ein Versuch, eine WebSocket-Verbindung vom Client aus zu öffnen, sieht zunächst wie eine HTTP-Anforderung aus. Eine spezielle Anweisung im Header (Upgrade: Websocket) weist den Server jedoch an, in diesem asynchronen Modus mit der Kommunikation zu beginnen. Erste Entwürfe des WebSocket-Protokolls waren nicht viel mehr als das und einige Handshakes, um sicherzustellen, dass der Server tatsächlich versteht, dass der Client asynchron kommunizieren möchte. Dann wurde jedoch klar, dass Proxyserver dadurch verwirrt würden, da sie an das übliche Anforderungs- / Antwortmodell von HTTP gewöhnt sind. Ein potenzielles Angriffsszenario gegen Proxyserver wurde entdeckt. Um dies zu verhindern, musste der WebSocket-Verkehr anders aussehen als der normale HTTP-Verkehr. Deshalb wurden die Maskierungsschlüssel in eingeführtdie endgültige Version des Protokolls .

Eine reguläre REST-API verwendet HTTP als zugrunde liegendes Kommunikationsprotokoll, das dem Anforderungs- und Antwortparadigma folgt. Dies bedeutet, dass der Client Daten oder Ressourcen von einem Server anfordert und der Server auf diesen Client antwortet. HTTP ist jedoch ein zustandsloses Protokoll, sodass bei jedem Anforderungs- / Antwortzyklus die Header- und Metadateninformationen wiederholt werden müssen. Dies führt zu einer zusätzlichen Latenz bei häufig wiederholten Anforderungs- / Antwortzyklen.

Bei WebSockets werden, obwohl die Kommunikation immer noch als anfänglicher HTTP-Handshake beginnt, weitere Upgrades durchgeführt, um dem WebSockets-Protokoll zu folgen (dh wenn sowohl der Server als auch der Client mit dem Protokoll kompatibel sind, da nicht alle Entitäten das WebSockets-Protokoll unterstützen).

Mit WebSockets ist es jetzt möglich, eine Vollduplex- und dauerhafte Verbindung zwischen dem Client und einem Server herzustellen. Dies bedeutet, dass im Gegensatz zu einer Anforderung und einer Antwort die Verbindung so lange geöffnet bleibt, wie die Anwendung ausgeführt wird (dh dauerhaft ist). Da es sich um Vollduplex handelt, ist eine gleichzeitige bidirektionale Kommunikation möglich, dh der Server kann jetzt initiieren eine Kommunikation und "Push" einiger Daten an den Client, wenn neue Daten (an denen der Client interessiert ist) verfügbar werden.

Das WebSockets-Protokoll ist statusbehaftet und ermöglicht die Implementierung des Publish-Subscribe- (oder Pub / Sub-) Messaging-Musters. Dies ist das primäre Konzept, das in Echtzeittechnologien verwendet wird, bei denen Sie neue Updates in Form von Server-Push ohne das erhalten können Client muss wiederholt anfordern (Seite aktualisieren). Beispiele für solche Anwendungen sind die Standortverfolgung von Uber Car, Push-Benachrichtigungen, Aktualisierung der Börsenkurse in Echtzeit, Chat, Multiplayer-Spiele, Live-Tools für die Online-Zusammenarbeit usw.

Sie können einen ausführlichen Artikel über Websockets lesen, in dem die Geschichte dieses Protokolls erläutert wird, 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 gemacht habe und wie sie sich von der Verwendung der regulären REST-APIs unterscheiden: Standardisierung und Nutzung des exponentiellen Anstiegs des Daten-Streamings

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

1. WebSockets bietet diese Vorteile gegenüber HTTP:

   • Dauerhafte zustandsbehaftete Verbindung für die Dauer der Verbindung
   • Geringe Latenz: Nahezu Echtzeitkommunikation zwischen Server / Client, da kein Aufwand für die Wiederherstellung von Verbindungen für jede Anforderung nach HTTP erforderlich ist.
   • Vollduplex: Sowohl Server als auch Client können gleichzeitig senden / empfangen

2. WebSocket und HTTP-Protokoll wurden entwickelt, um verschiedene Probleme zu lösen. IE WebSocket wurde entwickelt, um die bidirektionale Kommunikation zu verbessern, während HTTP zustandslos und unter Verwendung eines Anforderungs- / Antwortmodells verteilt wurde. Abgesehen von der gemeinsamen Nutzung der Ports aus früheren Gründen (Firewall- / Proxy-Penetration) gibt es nicht viele Gemeinsamkeiten, um sie in einem Protokoll zu kombinieren.

Warum ist das Websockets-Protokoll besser?

Ich glaube nicht, dass wir sie nebeneinander vergleichen können, wie wer besser ist. Das ist kein fairer Vergleich, nur weil sie zwei verschiedene Probleme lösen . Ihre Anforderungen sind unterschiedlich. Es wird so sein, als würde man Äpfel mit Orangen vergleichen. Sie sind anders.

HTTP ist ein Request-Response-Protokoll. Client (Browser) will etwas, Server gibt es. Das ist. Wenn der vom Client gewünschte Datenwert groß ist, sendet der Server möglicherweise Streaming-Daten, um unerwünschte Pufferprobleme zu beseitigen. Hier besteht die Hauptanforderung oder das Hauptproblem darin, wie die Anforderung von Clients gestellt und die von ihnen angeforderten Ressourcen (Hybertext) beantwortet werden. Hier strahlt HTTP.

In HTTP nur Client-Anfrage. Der Server antwortet nur.

WebSocket ist kein Anforderungs-Antwort-Protokoll, das nur der Client anfordern kann. Es ist ein Socket (sehr ähnlich dem TCP-Socket). Sobald die Verbindung geöffnet ist, kann jede Seite Daten senden, bis die unterstreichende TCP-Verbindung geschlossen ist. Es ist wie eine normale Steckdose. Der einzige Unterschied zum TCP-Socket besteht darin, dass der Websocket im Web verwendet werden kann. Im Web haben wir viele Einschränkungen für einen normalen Socket. Die meisten Firewalls blockieren andere Ports als 80 und 433, die HTTP verwendet. Proxies und Vermittler sind ebenfalls problematisch. Um die Bereitstellung des Protokolls auf vorhandenen Infrastrukturen zu vereinfachen, verwenden Sie HTTP-Handshake zum Aktualisieren. Das heißt, wenn die Verbindung zum ersten Mal geöffnet wird, hat der Client eine HTTP-Anfrage gesendet, um dem Server mitzuteilen, dass dies keine HTTP-Anfrage ist. Bitte aktualisieren Sie auf das Websocket-Protokoll.

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

Sobald der Server die Anforderung verstanden und auf das Websocket-Protokoll aktualisiert hat, wird keines der HTTP-Protokolle mehr angewendet.

Meine Antwort lautet also: Keiner ist besser als der andere. Sie sind völlig anders.

Warum wurde es implementiert, anstatt das http-Protokoll zu aktualisieren?

Nun, wir können alles auch unter dem Namen HTTP machen . Aber sollen wir? Wenn es zwei verschiedene Dinge sind, werde ich zwei verschiedene Namen bevorzugen. Hickson und Michael Carter auch .

Die anderen Antworten scheinen hier keinen Schlüsselaspekt zu berühren, und das heißt, Sie erwähnen nicht, dass Sie einen Webbrowser als Client unterstützen müssen. Die meisten der oben genannten Einschränkungen von einfachem HTTP setzen voraus, dass Sie mit Browser / JS-Implementierungen arbeiten.

Das HTTP-Protokoll ist vollständig zur Vollduplex-Kommunikation fähig. Es ist legal, dass ein Client einen POST mit Chunked-Coding-Übertragung durchführt und ein Server eine Antwort mit einem Chunked-Coding-Body zurückgibt. Dies würde den Header-Overhead auf nur zur Init-Zeit entfernen.

Wenn Sie also nur Vollduplex suchen, sowohl Client als auch Server steuern und nicht an zusätzlichen Frames / Funktionen von Websockets interessiert sind, würde ich argumentieren, dass HTTP ein einfacherer Ansatz mit geringerer Latenz / CPU ist (obwohl die Latenz würde sich wirklich nur in Mikrosekunden oder weniger für beide unterscheiden).