WebSocket

Das WebSocket-Protokoll ist ein auf TCP basierendes Netzwerkprotokoll, das entworfen wurde, um eine bidirektionale Verbindung zwischen einer Webanwendung und einem WebSocket-Server bzw. einem Web-Server, der auch WebSockets unterstützt, herzustellen.

Vorteile gegenüber reinem HTTP

Während bei einer reinen HTTP-Verbindung jede Aktion des Servers eine vorhergehende Anfrage des Clients erfordert, reicht es beim WebSocket-Protokoll, wenn der Client die Verbindung öffnet. Die dann offene Verbindung kann im folgenden aktiv vom Server verwendet werden. Der Server muss also nicht mehr Anfragen vom Client abwarten, sondern kann neue Informationen ohne Zeitverzug ausliefern.

Ein sogenannter Server-Push ist bei einer reinen HTTP-Connection nur durch verzögerte Antworten und Polling des Clients möglich.

Zudem entfällt bei WebSockets der HTTP-Overhead, der bei jeder Anfrage einige Hundert Byte umfassen kann.

Technisch betrachtet startet das WebSocket-Protokoll wie ein „normaler“ http-Request/Response-Zyklus, nur, dass nach der Übertragung der HTTP-Request- und Response-Header die zugrundeliegende TCP-Verbindung bestehen bleibt und dadurch für binäre bzw. Zeichenketten-Übertragung in beide Richtungen frei wird.

URL-Schema

Die WebSocket-Protokoll-Spezifikation definiert zwei neue URI-Schemen, ws: und wss:, für unverschlüsselte und verschlüsselte Verbindungen.

Der WebSocket-Protokoll-Handshake

Zu Beginn einer jeden Verbindung führen Server und Client einen sogenannten Handshake durch. Dieser ähnelt vom Aufbau her dem HTTP-Header und ist vollständig abwärtskompatibel zu diesem, was die Nutzung des Standard-HTTP-Ports „80“ zugleich für normale HTTP-Kommunikation als auch für die Websocket-Nutzung ermöglicht. Der Handshake beinhaltet außerdem weitere Informationen (z. B. die verwendete Protokollversion).

Anfrage des Clients

Im Folgenden ist ein Beispielhandshake des siebzehnten Protokollentwurfs (draft-ietf-hybi-thewebsocketprotocol-17) dargestellt und erläutert:^[1]

Achtung: Ältere Protokollentwürfe können sehr stark von dieser Version des Protokolls abweichen, da es aufgrund von Sicherheitsbedenken umgestaltet wurde. Dies betrifft insbesondere die Entwürfe vor draft-ietf-hybi-thewebsocketprotocol-04.

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

Wie auch im HTTP-Protokoll gibt der Client an, auf welche Ressource (hier: /chat) und auf welchen Host (hier: server.example.com) er zugreifen möchte. Außerdem fordert der Client ein Upgrade auf das Websocket-Protokoll. Der zufällig generierte „Sec-WebSocket-Key“ dient zur Überprüfung, ob der Server die Anfrage tatsächlich gelesen und verstanden hat (siehe Abschnitt Antwort des Servers). Unter „Sec-WebSocket-Protocol“ hat der Client die Möglichkeit, auf das Websocket-Protokoll aufbauende Protokolle anzugeben, die die Clientanwendung unterstützt (hier: ein Chat-Protokoll). Selbsterklärend sollte unter „Sec-WebSocket-Version“ die verwendete Protokollversion angegeben werden.

Antwort des Servers

Auf die obige Beispielanfrage könnte ein Websocket-Server beispielsweise wie folgt antworten:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat

Durch den HTTP-Statuscode 101 und die folgenden zwei Zeilen erklärt der Server, dass er mit dem Wechsel des Protokolls einverstanden ist.

Der zurückgesendete Schlüssel unter „Sec-WebSocket-Accept“ dient der Verifikation, dass der Server die Anfrage des Clients gelesen hat. Er wird wie folgt erstellt: An den oben erwähnten, Base64-kodierten String, den der Client sendet („Sec-WebSocket-Key“) wird der Globally Unique Identifier 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 angehängt. Daraufhin wird ein SHA1-Hash des entstandenen Schlüssels erstellt und Base64-kodiert. Anzumerken ist hierbei, dass der ursprünglich empfangene Schlüssel zwar Base64-kodiert ist, jedoch zu keinem Zeitpunkt dekodiert wird.

In diesem Beispiel gibt der Server zusätzlich an, dass er das angeforderte Protokoll „chat“ kennt („Sec-WebSocket-Protocol“).

Unterstützung des Protokolls

Browser-Implementierungen

• Auf WebKit basierende Browser (Google Chrome, Safari)
• Opera, ab Version 10.70
• Firefox, ab Version 4.0 beta 7^[2]

Client-Implementierungen

• weberknecht, Java-Client
• jWebSocket JavaScript, Java und Java ME Client, Open Source
• ArduinoWebsocketClient C++ for AVR Microcontroller, Open Source

Server-Implementierungen

• Jetty, HTTP-Server und Servlet-Container, der WebSockets seit Version 7.0.1 unterstützt.
• phpwebsocket, einer der ersten WebSocket-Server in PHP
• jWebSocket High-Speed Kommunikationsserver inkl. Web, Java und Mobile Clients, Open Source
• xLightweb HTTP-Bibliothek inkl. HttpClient und HttpServer, welche WebSocket und ServerSentEvent unterstützt
• Mojolicious – Web Framework in Perl
• GlassFish ab Version 3.1
• PyWebsocket Python Websocket Server (Apache Modul oder Standalone)
• gevent-websocket Bibliothek in Python
• JBoss Netty – Java NIO Netzwerkbibliothek mit WebSocket-Unterstützung

Weblinks

• The WebSocket API – W3C Entwurf für die API-Spezifikation
• The WebSocket protocol – WebSocket Protocol Draft der IETF
• HTML5 Server-Push Technologies, Part 2 – Einführung in WebSockets
• „WebSocket: Annäherung an Echtzeit im Web“ – Artikel über Websocket bei heise Developer

Einzelnachweise

1. ↑ Der vorliegende Beispielhandshake entstammt der siebzehnten Version des WebSocket Protocol Draft der IETF
2. ↑ Blizzard, Christopher: disabling websockets for firefox 4. http://www.0xdeadbeef.com/weblog/2010/12/disabling-websockets-for-firefox-4/ (2010-12-08T01:14:39+00:00, abgerufen 2010-12-09T13:51:03+01:00).