WebSocket

The WebSocket protocol is based on TCP 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.

  • 4.1 browser implementations

Advantages over pure HTTP

While in a pure HTTP connection every action of the server requires a previous request from the client, it is sufficient when WebSocket protocol when the client opens the connection. The then open connection can be used in the following active from the server. This means that the server does not wait for more requests from the client, but can deliver new information without having to wait for a new connection from the client.

A server-initiated transfer is in a pure HTTP connection only by delayed responses to a client-initiated request (long polling).

Moreover, in the Web Sockets caused by the HTTP header additional data, which may include several hundreds of bytes for each request omitted.

Technically starts the WebSocket protocol as a request from the client, with the difference that after the transfer of data to establish the connection, the underlying TCP connection remains, allowing transfers in both directions.

URL scheme

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

The WebSocket protocol handshake

At the beginning of each compound run server and client by a so-called handshake. This is similar in structure to the HTTP header and is fully backward- compatible with it, which allows the use of standard HTTP ports "80" at the same time for normal HTTP communication as well as for the websocket usage. The handshake also includes additional information (eg the protocol version used ).

Client request

The following is an example of the seventeenth handshake protocol design is ( draft-ietf - hybi - thewebsocketprotocol -17) illustrated and explained:

Warning: Mature protocol designs can be very different from this version of the protocol, since it was remodeled because of safety concerns. This concerns in particular the draft before draft-ietf - hybi - thewebsocketprotocol - 04th

GET / HTTP/1.1 chat   Host: server.example.com   Upgrade: websocket   Connection: Upgrade   Sec - WebSocket -Key: dGhlIHNhbXBsZSBub25jZQ ==   Origin: http://example.com   Sec - WebSocket - Protocol: chat, super chat   Sec - WebSocket - Version: 13 As in the HTTP protocol, the client on to which resource ( here: / chat ) and which host ( here: server.example.com ) he wants to access. In addition, the client requests an upgrade to the websocket protocol. The randomly generated " Sec - WebSocket -Key " is used to check whether the server has read and understood the request actually (see response from the server ). Under " Sec - WebSocket - Protocol", the client has the ability to specify the websocket protocol -building protocols that the client application supports ( here: a chat transcript ). Self-explanatory, the protocol version used should be specified under " Sec - WebSocket - Version".

Response from the server

In the above example request a websocket server could respond, for example, as follows:

HTTP/1.1 101 Switching Protocols   Upgrade: websocket   Connection: Upgrade   Sec - WebSocket -Accept: s3pPLMBiTxaQ9kYGzzhZRbK xOo =   Sec - WebSocket - Protocol: chat Explained by the HTTP status code of 101 and the following two lines to the server that it is in agreement with the change of the protocol.

The returned key under " Sec - WebSocket -Accept " is used to verify that the server has read the client's request. It is created as follows: mentioned at the top, base64-encoded string that the client sends ( " Sec - WebSocket -Key " ) is the Globally Unique Identifier 258EAFA5 - E914 - 47DA - 95cA - C5AB0DC85B11 appended. Then, a SHA1 hash of the resulting key is created and Base64-encoded. It should be noted here is that the originally received key is indeed Base64 - encoded, but is decoded at any time.

In this example, the server returns in addition to that he the requested protocol "chat" knows ( " Sec - WebSocket - Protocol" ).

Extensions

The specification allows for the expansion of the websocket protocol defined by "Extensions". These are negotiated between client and server. Examples:

  • WebSocket Per- frame Compression
  • A Multiplexing Extension for WebSockets
  • The Message Broker WebSocket subprotocol

Browser implementations

  • On WebKit based browsers (eg Google Chrome, Safari)
  • Opera, version 10.70
  • Mozilla Firefox, Version 4.0
  • Internet Explorer, version 10.0
815179
de