it-swarm.com.de

WebSockets-Protokoll vs HTTP

Es gibt viele Blogs und Diskussionen über Websocket und HTTP, und viele Entwickler und Websites plädieren nachdrücklich für 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 - ein bidirektionaler Vollduplex-Kommunikationskanal, der über einen einzelnen Socket über das Web betrieben wird. ( http://www.websocket.org/quantum.html )

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

Während der Verbindungsherstellung mit WebSocket tauschen Client und Server Daten pro Frame aus, die jeweils 2 Byte betragen, verglichen mit 8 Kilobyte HTTP-Header, wenn Sie fortlaufende Abfragen durchführen.

Warum beinhalten diese 2 Bytes nicht den Overhead von TCP und unter TCP-Protokollen?

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

Dies ist ~ 48 Bytes http-Header.

http chunked encoding - http://ru.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.

Frage:

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

1) Warum ist das WebSockets-Protokoll besser?

WebSockets eignet sich besser für Situationen, in denen eine Kommunikation mit geringer Latenz erforderlich ist, insbesondere für Nachrichten zwischen Client und Server mit geringer Latenz. Bei Server-zu-Client-Daten kann die Latenz bei Verwendung von Verbindungen mit langer Lebensdauer und unterbrochener Übertragung relativ gering sein. Dies hilft jedoch nicht bei Client-zu-Server-Wartezeiten, bei denen 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 im Rahmen der Anforderung (in beide Richtungen) gesendet werden, einschließlich vieler Header- und Cookie-Daten. Hier ist ein Beispiel für eine Anfrage/Antwort zur 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 anfängliche Verbindungs-Handshakes gleicher Größe. Bei einer WebSocket-Verbindung wird der anfängliche Handshake jedoch einmal ausgeführt und kleine Nachrichten haben nur einen Overhead von 6 Byte (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 TCP - Verbindungsaufbau-Latenz 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 gibt Bemühungen, das HTTP-Protokoll neu zu entwickeln, um eine bessere Leistung und geringere Latenz zu erzielen, z. B. SPDY , HTTP 2. und - QUIC . Dies verbessert die Situation für normale HTTP-Anforderungen, aber es ist wahrscheinlich, dass WebSockets und/oder WebRTC DataChannel weiterhin eine geringere Latenz für die Datenübertragung vom Client zum Server als das HTTP-Protokoll aufweisen (oder in einem Modus verwendet werden, der WebSockets sehr ähnlich sieht Sowieso).

Update :

Hier ist ein Framework 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 Anforderung, der Server eine vollständige Antwort, und dann wird die Verbindung geschlossen. Die Anforderungsmethoden (GET, POST, HEAD) haben eine bestimmte Transaktionsbedeutung für Ressourcen auf dem Server.
  • HTTP 1.1 : Behält den Anforderungs-Antwort-Charakter von HTTP 1.0 bei, ermöglicht jedoch, dass die Verbindung für mehrere vollständige Anforderungen/vollständige Antworten geöffnet bleibt (eine Antwort pro Anforderung) ). Die Anfrage und Antwort enthält noch vollständige Header, die Verbindung wird jedoch erneut verwendet und nicht geschlossen. HTTP 1.1 fügte auch einige zusätzliche Anforderungsmethoden hinzu (OPTIONS, PUT, DELETE, TRACE, CONNECT), die ebenfalls spezifische Transaktionsbedeutungen haben. Wie in der Einführung zum HTTP 2.0-Entwurfsvorschlag erwähnt, wird HTTP 1.1-Pipelining jedoch nicht in großem Umfang eingesetzt, sodass der Nutzen von HTTP 1.1 zur Behebung der Latenz zwischen Browsern und Servern stark eingeschränkt ist.
  • Long-Poll : Eine Art "Hack" zu HTTP (entweder 1.0 oder 1.1), bei dem der Server nicht sofort antwortet (oder nur teilweise mit Headern antwortet) ) zur Kundenanfrage. Nach einer Serverantwort sendet der Client sofort eine neue Anforderung (bei Verwendung der gleichen Verbindung über HTTP 1.1).
  • HTTP-Streaming : Verschiedene Techniken (mehrteilige/geteilte Antwort), mit denen der Server mehr als eine Antwort auf eine einzelne Clientanforderung senden kann. Das W3C standardisiert dies als Server-Sent Events unter Verwendung eines text/event-stream - MIME-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. Kometenbibliotheken unterstützen normalerweise mehrere Techniken, um die browser- und serverübergreifende Unterstützung zu maximieren.
  • WebSockets : Eine auf TCP aufgebaute Transportschicht, die einen HTTP-freundlichen Upgrade-Handshake verwendet. Im Gegensatz zu TCP, bei dem es sich um einen Streaming-Transport handelt, handelt es sich bei WebSockets um einen nachrichtenbasierten Transport: Nachrichten werden auf der Leitung abgegrenzt 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 mehr und es entsteht nur ein sehr geringer Overhead pro Nachricht. Der Client und der Server können jederzeit Nachrichten senden und müssen den Nachrichtenempfang asynchron bearbeiten.
  • [~ # ~] spdy [~ # ~] : Ein von Google initiierter Vorschlag, HTTP mithilfe eines effizienteren Wire-Protokolls zu erweitern, wobei jedoch die gesamte HTTP-Semantik beibehalten wird (Anfrage)/Antwort, Cookies, Codierung). SPDY führt ein neues Framing-Format (mit Frames mit Längenpräfix) ein und gibt eine Möglichkeit an, HTTP-Request/Response-Paare auf die neue Framing-Ebene 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 für 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, um Peer-to-Peer-Konnektivität zwischen Browsern zu ermöglichen. Dies kann eine Kommunikation mit geringerer durchschnittlicher und maximaler Latenz ermöglichen, da der zugrunde liegende Transport SDP/Datagramm und nicht 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 Web-Latenz 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 mit HTTP/2, Sicherheit mit TLS und Verbindungssemantik, Zuverlässigkeit und Überlastungskontrolle mit TCP vergleichbar sind. Da TCP in Betriebssystemkernen und in der Middlebox-Firmware implementiert ist, ist es so gut wie unmöglich, signifikante Änderungen an TCP vorzunehmen. Da QUIC jedoch auf UDP aufbaut, unterliegt es keinen derartigen Einschränkungen. QUIC wurde für die HTTP/2-Semantik entwickelt und optimiert.

Referenzen :

447
kanaka

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, mit der Javascript-Anwendungen mit einem Server interagieren konnten, 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 es, browserbasierte Spiele mit einer viel geringeren Latenz zu implementieren, 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, den Client-Anforderungs- und -Antworttext nur asynchron zu streamen.

Tatsächlich sind WebSockets im Grunde genommen das. Der Versuch, eine WebSocket-Verbindung vom Client aus zu öffnen, sieht zunächst wie eine HTTP-Anforderung aus, aber eine spezielle Anweisung im Header (Upgrade: websocket) weist den Server an, in diesem asynchronen Modus mit der Kommunikation zu beginnen. Erste Entwürfe des WebSocket-Protokolls waren nicht viel mehr als das und ein gewisses Handshaking, um sicherzustellen, dass der Server tatsächlich versteht, dass der Client asynchron kommunizieren möchte. Dann wurde jedoch klar, dass Proxy-Server dadurch verwirrt werden würden, da sie an das übliche Anforderungs-/Antwortmodell von HTTP gewöhnt sind. Ein potenzielles Angriffsszenario gegen Proxy-Server wurde entdeckt. Um dies zu verhindern, musste sichergestellt werden, dass der WebSocket-Datenverkehr nicht wie normaler HTTP-Datenverkehr aussieht. Aus diesem Grund wurden die Maskierungsschlüssel in der endgültigen Version des Protokolls eingeführt.

116
Philipp

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

  1. WebSockets bietet gegenüber HTTP die folgenden Vorteile:

    • Dauerhafte zustandsbehaftete Verbindung für die Dauer der Verbindung
    • Geringe Latenz: Nahezu Echtzeit-Kommunikation zwischen Server/Client, da für jede Anforderung kein zusätzlicher Aufwand für die Wiederherstellung von Verbindungen erforderlich ist.
    • Vollduplex: Server und Client können gleichzeitig senden/empfangen
  2. WebSocket und das HTTP-Protokoll wurden entwickelt, um verschiedene Probleme zu lösen, z. WebSocket wurde entwickelt, um die bidirektionale Kommunikation zu verbessern, während HTTP so konzipiert wurde, dass es zustandslos ist und mithilfe eines Anforderungs-/Antwortmodells verteilt wird. Abgesehen von der gemeinsamen Nutzung der Ports aus älteren Gründen (Firewall-/Proxy-Durchdringung) gibt es kaum Gemeinsamkeiten, um sie in einem Protokoll zu kombinieren.

18
Devy

Warum ist das Websockets-Protokoll besser?

Ich denke 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 sein, als würde man Äpfel mit Orangen vergleichen. Sie sind anders.

[~ # ~] http [~ # ~] ist ein Anforderungs-Antwort-Protokoll. Client (Browser) will etwas, Server gibt es. Das ist. Wenn der Datenclient große Anforderungen hat, sendet der Server möglicherweise Streaming-Daten, um unerwünschte Pufferprobleme zu vermeiden. Hier besteht die Hauptanforderung oder das Hauptproblem darin, wie die Anforderung von Clients zu stellen ist und wie die angeforderten Ressourcen (Hybertext) zu beantworten sind. Hier erstrahlt HTTP.

In HTTP nur Clientanforderung. Server antwortet nur.

WebSocket ist kein Anforderungs-Antwort-Protokoll, das nur vom Client angefordert werden kann. Es ist ein Socket (sehr ähnlich zu TCP Socket). In der Zwischenzeit kann jede Seite, sobald die Verbindung offen ist, Daten senden, bis die Unterstreichung TCP Verbindung geschlossen wird. Es ist wie ein normaler Socket. Der einzige Unterschied zu TCP Socket ist, dass 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 Proxy-Server und Vermittler werden ebenfalls problematisch sein. Um die Bereitstellung des Protokolls auf dem Websocket für vorhandene Infrastrukturen zu vereinfachen, verwenden Sie HTTP-Handshake für das Upgrade. Das bedeutet, wenn die erste Verbindung geöffnet wird, sendet der Client eine HTTP-Anfrage Um dem Server mitzuteilen, dass dies keine HTTP-Anforderung ist, aktualisieren Sie bitte 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 das HTTP-Protokoll nicht 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 auch alles unter dem Namen [~ # ~] http [~ # ~] machen. Aber sollen wir? Wenn es sich um zwei verschiedene Dinge handelt, bevorzuge ich zwei verschiedene Namen. So auch Hickson und Michael Carter .

11
FranXho

Die anderen Antworten scheinen einen wichtigen Aspekt hier nicht zu berühren, und das heißt, Sie erwähnen nicht, dass Sie einen Webbrowser als Client benötigen. Die meisten der oben genannten Einschränkungen von normalem HTTP setzen voraus, dass Sie mit Browser-/JS-Implementierungen arbeiten.

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

Wenn Sie also nur nach Vollduplex suchen, sowohl Client als auch Server steuern und nicht an zusätzlichen Framing-/Features 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 unterscheiden.

5
parity3

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

http

Mit WebSockets wird die Kommunikation zwar immer noch als anfänglicher HTTP-Handshake gestartet, es sind jedoch weitere Upgrades erforderlich, um dem WebSockets-Protokoll zu folgen (dh, wenn sowohl der Server als auch der Client dem Protokoll entsprechen, da nicht alle Entitäten dies unterstützen das WebSockets-Protokoll).

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 offen bleibt, wie die Anwendung ausgeführt wird (dh sie besteht fort). 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.

websockets

Das WebSockets -Protokoll ist statusbehaftet und ermöglicht Ihnen die Implementierung des Publish-Subscribe-Nachrichtenmusters (oder Pub/Sub-Nachrichtenmusters), das das primäre Konzept in Echtzeittechnologien darstellt, in denen Sie neue Aktualisierungen erhalten können die Form des Server-Pushs, ohne dass der Client wiederholt nachfragen (die Seite aktualisieren) muss. Beispiele für solche Anwendungen sind die Standortverfolgung von Uber-Fahrzeugen, Push-Benachrichtigungen, Börsenkursaktualisierungen in Echtzeit, Chat, Multiplayer-Spiele, Tools für die Online-Live-Zusammenarbeit usw.

Sie können einen ausführlichen Tauchartikel ü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 von 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 beim Daten-Streaming