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

Die anderen Antworten scheinen einen wichtigen Aspekt nicht zu berühren, nämlich dass Sie nicht erwähnen, dass ein Webbrowser als Client unterstützt werden muss. Die meisten der oben genannten Einschränkungen von einfachem HTTP gehen davon aus, dass Sie mit Browser-/JS-Implementierungen arbeiten würden.

Das HTTP-Protokoll ist vollduplex-fähig; es ist zulässig, dass ein Client eine POST-Übertragung mit einer Chunked-Codierung durchführt und ein Server eine Antwort mit einem Chunked-Codierungstext zurückgibt. Dadurch würde der Header-Overhead nur zur Init-Zeit entfallen.

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