WikiDer > WebSocket

WebSocket ist ein Netzwerkprotokoll Welche Vollduplex bietet Kommunikation über eine einzige TCP-Verknüpfung. Das WebSocket-Protokoll ist von der by Internettechnik-Arbeitsgruppe im Jahr 2011 als RFC 6455 und die WebSocketAPI erstellt in Web-IDL ist standardisiert durch die World Wide Web Konsortium.

WebSocket ist für die Verwendung in Internetbrowser und Webserver. Das WebSocket-Protokoll ist eine eigenständige Op TCP basierendes Protokoll. WebSocket hat eine gewisse Ähnlichkeit mit HTTP, weil die Händedruck des WebSocket-Protokolls von HTTPServer wird als Upgrade Request interpretiert. Das WebSocket-Protokoll ermöglicht den bidirektionalen Datenverkehr zwischen Webbrowsern und Webservern. Dies ist möglich, weil das Protokoll einen Standardweg des Datenverkehrs bereitstellt, ohne dass eine Anfrage des Webbrowsers erforderlich ist, um Daten vom Server an den Browser zu senden. Darüber hinaus ermöglicht das Protokoll, Nachrichten hin und her zu senden, während die Verbindung zwischenzeitlich offen gehalten wird. Auf diese Weise findet eine fortlaufende bidirektionale Konversation zwischen Webserver und Webbrowser statt. Die Kommunikation erfolgt über TCP-Port 80 (oder TCP-Port 443, wenn die Kommunikation über TLS-verschlüsselte Verbindungen erfolgt), was in Netzwerkumgebungen von Vorteil ist, in denen Ports, die nicht für das Web gedacht sind (andere TCP-Ports als 80 und 443) von einer Firewall blockiert werden . Ähnlicher bidirektionaler Datenverkehr wurde auf andere nicht standardisierte Weise mit Notlösungstechnologien wie z Komet.

Das WebSocket-Protokoll wird derzeit von den meisten gängigen Browsern unterstützt, darunter: Google Chrome, Microsoft Edge, Internet Explorer, Feuerfuchs, Safari und Oper. WebSocket hat auch Web Applikationen auf dem Server, um es zu unterstützen.

Überblick

Im Gegensatz zu HTTP bietet WebSocket Vollduplex-Kommunikation. Darüber hinaus bietet WebSocket die Möglichkeit, zusätzlich zu einer TCP-Verbindung einen Nachrichtenstrom zu senden. TCP selbst steuert nur einen Strom von Bytes und hat kein Nachrichtenkonzept. Vor WebSocket war Vollduplex-Kommunikation über Port 80 mit Comet-Kanälen möglich. Die Comet-Implementierung war jedoch nicht Standard. Außerdem war die Comet-Implementierung schwerer, da sie auf HTTP funktionierte und für kleine Nachrichten ineffizient war. Das WebSocket-Protokoll zielt darauf ab, diese Probleme zu überwinden, ohne die Websicherheit zu beeinträchtigen.

Die WebSocket-Spezifikation definiert ws und wss wie zwei neue URISchemata, die für unverschlüsselte bzw. verschlüsselte Verbindungen verwendet werden können. Abgesehen von Fragmenten und Schemanamen ist der Rest des Vans URIKomponenten definiert nach URI-generische Syntax.

Mit den Entwicklungstools des Browsers können Entwickler WebSocket-Handshakes und WebSocket-Frames überprüfen.

Geschichte

WebSocket war der erste TCPVerbindung erwähnt im HTML5Spezifikation als Ersatz für eine op TCP basierter Sockel-API. Im Juni 2008 wurden die Diskussionen von Michael Carter geleitet, die zur ersten Version des jetzt WebSocket führten.

Im Anschluss an diese Diskussionen, Zusammenarbeit zwischen Ian Hickson und Michael Carter im #whatwg IRC-Chatraum kam auf den Namen WebSocket. Es folgte die Ergänzung zum HTML5Spezifikation von Ian Hickson und die Ergänzung wurde auf der Comettäglich-Blog von Michael Carter. Im Dezember 2009 Google Chrome 4 der erste große Webbrowser, der den vollständigen Standard mit standardmäßig aktiviertem WebSocket unterstützt. Die Entwicklung des WebSocket-Protokolls wurde anschließend W3C und die whatwg-Gruppe ist dorthin gezogen IETF im Februar 2010 mit zwei Revisionen unter der Kontrolle von Ian Hickson.

Nachdem das Protokoll von mehreren Browsern unterstützt und standardmäßig aktiviert war, RFC endete im Dezember 2011 unter Ian Fette.

Protokoll-Handshake

Um eine WebSocket-Verbindung zu initiieren, sendet der Browser eine WebSocket-Handshake-Anforderung an den Server. Darauf antwortet der Server mit einer Antwort, wie in der folgenden Abbildung dargestellt.

WebSockethandshakerequest (wie bei HTTP muss jede Zeile mit enden und am Ende sollte eine Leerzeile stehen)

ERHALTEN/PlaudernHTTP/1.1Gastgeber:server.beispiel.comAktualisierung:Web-SocketVerbindung:AktualisierungSek-WebSocket-Schlüssel:x3JJHMbDL1EzLkh9GBhXDw==Sec-WebSocket-Protokoll:chatten, super chattenSek-WebSocket-Version:13Ursprung:http://beispiel.com

Serverantwort:

HTTP/1.1101Umschalten von ProtokollenAktualisierung:Web-SocketVerbindung:AktualisierungSek-WebSocket-Akzeptieren:Hsmrc0sMlYUkAGmm5OPpG2HaGWk=Sec-WebSocket-Protokoll:Plaudern

Der WebSockethandshake ähnelt einem HTTP-Anfrage, sodass Webserver sowohl HTTP-Verbindungen als auch WebSocket-Verbindungen auf demselben Port verarbeiten können. Sobald die Verbindung über den WebSockethandshake hergestellt wurde, wechselt die Kommunikation auf a bidirektionalbinär Protokoll, das nicht mehr dem HTTP-Protokoll entspricht.

Zusätzlich zu den Upgrade-Headern sendet der Webbrowser auch die Sek-WebSocket-SchlüsselKopfzeile entlang. Dieser Header enthält base64-verschlüsselte zufällige Bytes, die als Schlüssel fungieren, der Server antwortet mit a hash des Schlüssels im Sec-WebSocket-AkzeptierenHeader. Dies geschieht, um ein ZwischenspeicherStellvertreter eine zuvor gesendete Konversation erneut senden. Dieser Mechanismus gewährleistet keine Art von Privatsphäre, Authentifizierung oder Integrität. Die Funktion, die die hash erstellt, fügt den folgenden Text hinzu: 258EAFA5-E914-47DA-95CA-C5AB0DC85B11(das Universell eindeutige Kennung des Webservers) zu den Inhalten von Sek-WebSocket-Schlüssel-header (ohne die Sek-WebSocket-SchlüsselHeader, der von base64 entschlüsselt werden soll), geben Sie hier die SHA-1-Hashing-Funktion aus und das Ergebnis wird mit . codiert base64.

Wenn die Verbindung hergestellt ist, können Webbrowser und Server Daten oder Textrahmen hin und her senden VollduplexModus. Den Daten geht ein kleiner Header voraus, dem die Nutzdaten folgen. WebSocket-Übertragungen werden als "Nachrichten" bezeichnet, wobei jede Nachricht in mehrere Textrahmen unterteilt werden kann. Dies ermöglicht das Senden von Nachrichten, deren Gesamtlänge unbekannt ist, aber die ersten Daten bereits vorhanden sind (es sendet einen Datenrahmen nach dem anderen bis das Ende erreicht ist und wird mit dem FLOSSE bisschen). Mit Erweiterungen des Protokolls können damit auch mehrere Datenströme gleichzeitig gesendet und empfangen werden, auch genannt Multiplexen erwähnt.

Aus Sicherheitsgründen ist es wichtig, UrsprungHeader während der Verbindung vom Server. Dies verhindert Cross-Site WebSocket Hijacking-Angriffe, die möglich sind, wenn die Verbindung mit geprüft wird Kekse oder HTTP-Authentifizierung. Es ist besser, Schlüssel oder ähnliche Mechanismen zu verwenden, um die Zuverlässigkeit einer WebSocket-Verbindung sicherzustellen, wenn sensible Informationen über die Verbindung gesendet werden.