WebSocket

from Wikipedia, the free encyclopedia
WebSocket protocol
Family: Internet protocol family
Operation area: bidirectional connection between
a web application and a WebSocket server
Port: 80 / TCP, 443 / TCP
WebSocket in the TCP / IP protocol stack :
application WebSocket
transport TCP
Internet IP ( IPv4 , IPv6 )
Network access Ethernet Token
bus
Token
ring
FDDI ...
Standards: RFC 6455 (The WebSocket Protocol Version 13, 2011)

The WebSocket protocol is a TCP- based network protocol that was designed to establish a bidirectional connection between a web application and a WebSocket server or a web server that also supports WebSockets.

Advantages over pure HTTP

While with a pure HTTP connection every action by the server requires a previous request from the client, with the WebSocket protocol it is sufficient for the client to open the connection. The server can then actively use this open connection and deliver new information to the client without waiting for a new connection from the client. With a pure HTTP connection, a transmission initiated by the server is only possible through delayed responses to a request initiated by the client ( long polling ). Since HTTP / 2 the server can also send push notifications. In addition, with WebSockets, the additional data caused by the HTTP header, which can be a few hundred bytes for each request, is not required. From a technical point of view, with WebSocket, as with HTTP, the client starts a request, with the difference that after the data has been transmitted to establish the connection, the underlying TCP connection remains and enables asynchronous transmissions in both directions.

Url scheme

The WebSocket Protocol Specification defines two new URI schemes, ws: for unencrypted connections, and wss: for encrypted connections.

The WebSocket protocol handshake

At the beginning of every connection, the server and client carry out a so-called handshake. This is similar to the HTTP header and is fully backwards compatible with it, which enables the use of the standard HTTP port "80" for normal HTTP communication as well as for web socket use. The handshake also contains further information (e.g. the protocol version used).

Request from the client

An example handshake of the seventeenth draft protocol ( draft-ietf-hybi-thewebsocketprotocol-17 ) is shown and explained below:

Caution: Older protocol drafts can differ greatly from this version of the protocol, as it has been redesigned due to security concerns. This applies in particular to the drafts before 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

As in the HTTP protocol , the client specifies which resource (here: / chat ) and which host (here: server.example.com ) it wants to access. The client also requests an upgrade to the websocket protocol. The randomly generated "Sec-WebSocket-Key" is used to check whether the server has actually read and understood the request ( see section Response from the server ). Under "Sec-WebSocket-Protocol", the client has the option of specifying protocols based on the Websocket protocol that the client application supports (here: a chat protocol). The protocol version used should be specified under "Sec-WebSocket-Version".

Response from the server

For example, a websocket server could respond to the example query above as follows:

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

With the HTTP status code 101 and the following two lines, the server declares that it agrees to the protocol change. From then on, both of them use a binary protocol that is no longer HTTP compatible. It is broken down into packets marked as binary or text, as ping or pong, or as the end of the connection, specifying the length of the content.

The key sent back under "Sec-WebSocket-Accept" is used to verify that the server has read the client's request. It is created as follows: The globally unique identifier is appended to the above-mentioned Base64- encoded string that the client sends (“Sec-WebSocket-Key”) . A SHA1 hash of the resulting key is then created and Base64-encoded. It should be noted here that the originally received key is Base64-encoded, but is not decoded at any time. 258EAFA5-E914-47DA-95CA-C5AB0DC85B11

In this example, the server also indicates that it knows the requested protocol "chat" ("Sec-WebSocket-Protocol").

example

WebSocket Client in JavaScript

 1 var socket = new WebSocket(urlToWebsocketServer);
 2 
 3 // callback-Funktion wird gerufen, wenn die Verbindung erfolgreich aufgebaut werden konnte
 4 socket.onopen = function () {
 5     console.log("Verbindung wurde erfolgreich aufgebaut");
 6 };
 7 
 8 // callback-Funktion wird gerufen, wenn eine neue Websocket-Nachricht eintrifft
 9 socket.onmessage = function (messageEvent) {
10     console.log(messageEvent.data);
11 };
12 
13 // callback-Funktion wird gerufen, wenn ein Fehler auftritt
14 socket.onerror = function (errorEvent) {
15     console.log("Error! Die Verbindung wurde unerwartet geschlossen");
16 };
17 
18 socket.onclose = function (closeEvent) {
19     console.log('Die Verbindung wurde geschlossen --- Code: ' + closeEvent.code + ' --- Grund: ' + closeEvent.reason);
20 };

Extensions

The specification allows the websocket protocol to be expanded through defined "extensions". These are negotiated between client and server. Examples:

Browser support

literature

  • Peter Leo Gorski, Luigi Lo Iacono, Hoai Viet Nguyen: WebSockets - Developing Modern HTML5 Real-Time Applications , Hanser, Munich and Vienna 2015, ISBN 978-3-446-44371-6

Web links

Individual evidence

  1. This example handshake comes from the seventeenth version of the WebSocket Protocol Draft of the IETF
  2. Base Framing Protocol in RFC 6455
  3. https://developer.mozilla.org/de/docs/WebSockets