it-swarm.com.de

Macht HTTP / 2 Websockets überflüssig?

Ich lerne etwas über das HTTP/2-Protokoll. Es ist ein binäres Protokoll mit kleinen Telegrammen. Es ermöglicht Stream-Multiplexing über eine einzelne TCP Verbindung. Konzeptionell scheint es WebSockets sehr ähnlich zu sein.

Gibt es Pläne, Websockets zu veralten und durch eine Art von HTTP/2-Anfragen ohne Header und serverinitiierten Push-Nachrichten zu ersetzen? Oder wird WebSockets HTTP/2 ergänzen?

212
vbezhenar

Nach meinem Verständnis ist HTTP/2 kein Ersatz für Websocket, sondern zielt darauf ab, das SPDY-Protokoll zu standardisieren.

In HTTP/2 wird Server-Push im Hintergrund verwendet, um das Laden von Ressourcen durch den Client über den Browser zu verbessern. Als Entwickler interessiert es Sie während Ihrer Entwicklung nicht wirklich. Mit Websocket kann der Entwickler jedoch eine API verwenden, die in der Lage ist, Push-Nachrichten mit einer eindeutigen Vollduplex-Verbindung zu verarbeiten.

Dies sind nicht die gleichen Dinge, und sie sollten sich ergänzen.

132
Guillaume D.

Nachdem ich gerade mit dem Lesen der HTTP/2-Spezifikation fertig bin, denke ich, dass HTTP/2 für die meisten Anwendungsfälle veraltete Websockets bereitstellt, aber vielleicht nicht für alle.

Push_PROMISE (umgangssprachlich als Server-Push bezeichnet) ist hier nicht das Problem. Das ist nur eine Leistungsoptimierung.

Der Hauptanwendungsfall für Websockets in einem Browser besteht darin, das bidirektionale Streaming von Daten zu ermöglichen. Ich denke also, dass die Frage des OP lautet, ob HTTP/2 das bidirektionale Streaming im Browser besser ermöglicht, und ich denke, dass dies der Fall ist.

Zuallererst ist es is bi-di. Lesen Sie einfach die Einführung in den Abschnitt Streams :

Ein "Stream" ist eine unabhängige, bidirektionale Folge von Frames, die innerhalb einer HTTP/2-Verbindung zwischen Client und Server ausgetauscht werden. Streams haben mehrere wichtige Eigenschaften:

Eine einzelne HTTP/2-Verbindung kann mehrere gleichzeitig geöffnete Streams enthalten, wobei jeder Endpunkt Frames aus mehreren Streams verschachtelt.

Streams können einseitig erstellt und verwendet oder vom Client oder Server gemeinsam genutzt werden.

Streams können von jedem Endpunkt geschlossen werden.

Artikel wie this (in einer anderen Antwort verlinkt) sind in Bezug auf diesen Aspekt von HTTP/2 falsch. Sie sagen, es ist kein Bidi. Es gibt eine Sache, die mit HTTP/2 nicht passieren kann: Nachdem die Verbindung geöffnet wurde, kann der Server keinen regulären Stream initiieren, sondern nur einen Push-Stream. Sobald der Client einen Stream durch Senden einer Anfrage öffnet, können beide Seiten jederzeit DATA-Frames über einen persistenten Socket senden - Full Bidi.

Das ist nicht viel anders als bei Websockets: Der Client muss eine Websocket-Aktualisierungsanforderung initiieren, bevor der Server auch Daten übermitteln kann.

Der größte Unterschied besteht darin, dass HTTP/2 im Gegensatz zu Websockets seine eigene Multiplex-Semantik definiert: Wie Streams Bezeichner erhalten und wie Frames die ID des Streams tragen, auf dem sie sich befinden. HTTP/2 definiert auch die Flusssteuerungssemantik für die Priorisierung von Streams. Dies ist in den meisten realen Bidi-Anwendungen wichtig.

(Dieser falsche Artikel besagt auch, dass der Websocket-Standard Multiplexing enthält. Nein, das ist nicht der Fall. Es ist nicht wirklich schwierig, dies herauszufinden. Öffnen Sie einfach den Websocket RFC 6455 und drücken Sie ⌘-F und geben Sie Folgendes ein "Multiplex" Nachdem Sie gelesen haben

Das Protokoll soll erweiterbar sein. Zukünftige Versionen werden wahrscheinlich zusätzliche Konzepte wie Multiplexing einführen.

Sie werden feststellen, dass es 2013 Draft Extension für Websocket-Multiplexing gibt. Aber ich weiß nicht, welche Browser das unterstützen. Ich würde nicht versuchen, meine SPA-Webanwendung auf der Rückseite dieser Erweiterung zu erstellen, insbesondere wenn HTTP/2 kommt, wird der Support möglicherweise nie eintreffen.

Multiplexing ist genau das, was Sie normalerweise selbst tun müssen, wenn Sie beispielsweise einen Websocket für Bidi öffnen, um eine reaktiv aktualisierte App für einzelne Seiten zu betreiben. Ich bin froh, dass es in der HTTP/2-Spezifikation ist, die ein für alle Mal erledigt wurde.

Wenn Sie wissen möchten, was HTTP/2 kann, schauen Sie sich gRPC an. gRPC ist in HTTP/2 implementiert. Sehen Sie sich insbesondere die von gRPC angebotenen Halb- und Vollduplex-Streaming-Optionen an. (Beachten Sie, dass gRPC derzeit nicht in Browsern funktioniert. Dies liegt jedoch daran, dass Browser (1) den HTTP/2-Frame nicht für das JavaScript des Clients verfügbar machen und (2) im Allgemeinen keine Trailer unterstützen, die in verwendet werden die gRPC-Spezifikation.)

Wo könnten Websockets noch einen Platz haben? Wenn Sie nicht keine der zusätzlichen Bits benötigen, die HTTP/2 ausgibt (es ist eine riesige, komplizierte Spezifikation), sind Websockets möglicherweise besser. Ich bin zuversichtlich, dass die Einhaltung des Websocket-Protokolls immer weniger rechenintensiv ist als HTTP/2 - HTTP/2 erfordert lediglich, dass Sie mehr tun.

Die Größe der Frames ist sehr vergleichbar. Websocket-Frames sind etwas kleiner, 2-14 Bytes Overhead pro Frame im Vergleich zu HTTP/2's Fixed 9. Da sich Websocket für einen Header variabler Länge entschieden hat, kann es größere Frames codieren (bis zu 2 ^ 64-1 Bits pro Frame vs HTTP/2 2 ^ 24-1 Bits pro Frame). Wenn Sie also eine Steckdose brauchen, um etwas Fettiges ohne viel Zeremonie abzusaugen, wie zum Beispiel, ich weiß nicht, vielleicht Videobilder, dann sind Websockets möglicherweise immer noch sinnvoll. Für die meisten Anwendungsfälle, insbesondere im Zusammenhang mit Webseiten, scheint HTTP/2 der richtige Weg zu sein.

101
masonk

Ich sage Nein (Websockets sind nicht veraltet).

Das erste und am häufigsten ignorierte Problem ist das HTTP/2-Push ist nicht durchsetzbar und wird möglicherweise ignoriert von Proxies, Routern, anderen Vermittlern oder sogar dem Browser.

d.h. (aus dem HTTP2-Entwurf):

Ein Vermittler kann Pushs vom Server empfangen und diese nicht an den Client weiterleiten. Mit anderen Worten, wie die gepushten Informationen verwendet werden, liegt bei diesem Vermittler. Ebenso kann der Vermittler entscheiden, zusätzliche Pushs an den Client durchzuführen, ohne dass der Server etwas unternimmt.

Außerdem werden HTTP/2-Verbindungen nach einer Weile geschlossen.

Es ist wahr, dass der Standard besagt, dass:

HTTP/2-Verbindungen sind dauerhaft. Für eine optimale Leistung wird erwartet, dass Clients keine Verbindungen schließen, bis festgestellt wird, dass keine weitere Kommunikation mit einem Server erforderlich ist (z. B. wenn ein Benutzer von einer bestimmten Webseite weg navigiert) oder bis der Server die Verbindung beendet.

Aber...

Server werden aufgefordert, offene Verbindungen so lange wie möglich aufrechtzuerhalten es ist jedoch zulässig, inaktive Verbindungen zu beenden falls erforderlich. Wenn einer der Endpunkte die Transportschicht TCP) schließt, MUSS der terminierende Endpunkt zuerst einen GOAWAY-Frame (Abschnitt 6.8) senden, damit beide Endpunkte zuverlässig feststellen können, ob zuvor gesendete Frames verarbeitet wurden und Schließen Sie erforderliche verbleibende Aufgaben ordnungsgemäß ab oder beenden Sie sie.

Selbst wenn dieselbe Verbindung das Pushen von Inhalten ermöglicht, während diese geöffnet sind, und selbst wenn HTTP/2 einige der Leistungsprobleme behebt, die durch die Keep-Alive-Funktion von HTTP/1.1 verursacht wurden ... HTTP/2-Verbindungen werden nicht auf unbestimmte Zeit geöffnet .

Eine Webseite kann auch keine HTTP/2-Verbindung wiederherstellen, wenn sie einmal geschlossen ist (es sei denn, wir sind wieder mit langem Ziehen beschäftigt).

EDIT (2017, zwei Jahre später)

Implementierungen von HTTP/2 zeigen, dass mehrere Browser-Registerkarten/-Fenster eine einzige HTTP/2-Verbindung gemeinsam nutzen, was bedeutet, dass Push nie weiß, zu welcher Registerkarte/welchem ​​Fenster es gehört, wodurch die Verwendung von Push als wegfällt ein Ersatz für Websockets.

56
Myst

Die Antwort ist nein. Das Ziel zwischen den beiden ist sehr unterschiedlich. Es gibt sogar einen RFC für WebSocket über HTTP/2, mit dem Sie mehrere WebSocket-Verbindungen über eine einzige HTTP/2-Pipe TCP herstellen können.

WS über HTTP/2 wird eine ressourcenschonende Maßnahme sein, indem die Zeit zum Öffnen neuer Verbindungen verkürzt und mehr Kommunikationskanäle ermöglicht werden, ohne dass zusätzliche Sockets, weiche IRQs und Puffer erforderlich sind.

https://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01

37
bond

Nun, um aus diesem InfoQ Artikel zu zitieren:

Nun, die Antwort lautet aus einem einfachen Grund eindeutig nein: Wie wir oben gesehen haben, führt HTTP/2 Server Push ein, mit dem der Server proaktiv Ressourcen an den Client-Cache senden kann. Es ist jedoch nicht möglich, Daten in die Clientanwendung selbst zu übertragen. Server-Pushs werden nur vom Browser verarbeitet und gelangen nicht zum Anwendungscode. Dies bedeutet, dass keine API für die Anwendung vorhanden ist, um Benachrichtigungen für diese Ereignisse abzurufen.

Und so ist HTTP2 Push wirklich etwas zwischen Ihrem Browser und dem Server, während Websockets wirklich die APIs verfügbar macht, die sowohl vom Client (Javascript, wenn es im Browser ausgeführt wird) als auch vom Anwendungscode (auf dem Server ausgeführt) zum Übertragen von Echtzeitdaten verwendet werden können.

13
Jeet Prakash

Der Nachrichtenaustausch und einfaches Streaming (kein Audio- oder Video-Streaming) kann sowohl über HTTP/2-Multiplexing als auch über WebSockets erfolgen. Es gibt also einige Überschneidungen, aber WebSockets haben ein gut etabliertes Protokoll, viele Frameworks/APIs und weniger Header-Overhead. Hier ist ein netter Artikel zum Thema .

4
Dennis R

In HTTP/2 wird WebSocket implementiert. https://tools.ietf.org/html/rfc8441

0
Dzintars