Web socket

To establish a WebSocket connection, the client and server use a protocol similar to HTTP . The client generates a special HTTP request to which the server responds in a certain way.

Protocol 75

Prior to editing draft protocol number 75 inclusive, a WebSocket connection was established as follows. Customer Request:

  GET / demo HTTP / 1.1
 Upgrade: WebSocket
 Connection: Upgrade
 Host: example.com
 Origin: http://example.com
 WebSocket-Protocol: sample

Server response confirming transition to WebSocket:

  HTTP / 1.1 101 Web Socket Protocol Handshake
 Upgrade: WebSocket
 Connection: Upgrade
 WebSocket-Origin: http://example.com
 WebSocket-Location: ws: //example.com/demo
 WebSocket-Protocol: sample

Immediately after sending the response, the WebSocket connection is considered established, the client and server can begin bidirectional messaging over the same TCP connection. To send a text message (in UTF-8 encoding), it is necessary to transmit a zero byte before it, and after that - a byte with a value of 255.

Protocol 76

On June 2, 2010, the WebSocket protocol was amended to change the procedure for establishing a WebSocket connection without maintaining backward compatibility. The 76th edition of the draft WebSocket protocol adds protection against fake requests. A client supporting the new schema sends the following request:

  GET / demo HTTP / 1.1
 Upgrade: WebSocket
 Connection: Upgrade
 Sec-WebSocket-Key2: 4 @ 1 46546xW% 0l 1 5
 Host: example.com
 Sec-WebSocket-Key1: 12998 5 Y3 1 .P00
 Origin: http://example.com
 WebSocket-Protocol: sample

 ^ n: ds [4U

New “Sec-WebSocket-Key1” and “Sec-WebSocket-Key2” headers and an 8-byte request body have been added to the request. All of them are randomly generated by the client.

Server response confirming transition to WebSocket:

  HTTP / 1.1 101 Web Socket Protocol Handshake
 Upgrade: WebSocket
 Connection: Upgrade
 Sec-WebSocket-Origin: http://example.com
 Sec-WebSocket-Location: ws: //example.com/demo
 Sec-WebSocket-Protocol: sample

 8jKS'y: G * Co, Wxa-

The response contains new header names ("Sec-WebSocket-Origin", "Sec-WebSocket-Location", "Sec-WebSocket-Protocol" instead of "WebSocket-Origin", "WebSocket-Location", "WebSocket-Protocol") and 16 byte response body, calculated as follows:

1. exclude from the string with the value of the Sec-WebSocket-Key1 request header value all non-digit characters (not falling into the range '0' .. '9');
2. convert the resulting string into a 64-bit integer (for the example above, we get 1299853100);
3. divide the resulting number by integer division by the number of spaces in the original line with the header value;
4. represent the resulting number as a 4-byte 32-bit number in the big endian format: the high byte is stored at zero offset;
5. do the same with the Sec-WebSocket-Key2 header;
6. interpreting the numbers from points 4) and 5) as 4-byte strings, concatenate them (add them to one line) and add the request body as a string;
7. calculate the MD5 value from the received 16-byte string and write this value to the response body "as is", without conversion to any representation;

Notes.

Despite the "similarity" of new requests and responses to requests and responses of the HTTP protocol , they are not. For example, the request has a body, but the “Content-Length” field is absent in the headers (which violates the HTTP conventions).

The server side should support both types of clients and distinguish them by the presence or absence of Sec-WebSocket-Key1 and Sec-WebSocket-Key2 headers in the request.

Protocol 07

Changes were made to version 07 of the draft protocol of April 22, 2011.

Unlike protocol 76, according to which data is transmitted without encryption ^[1] , each byte transferred from the client (browser) to the data server in this version of the protocol is necessarily masked by a 4-byte mask ^[2] . It is re-created for each message.

The transmitted message now has a header that contains data such as:

• Is the message fragmented?
• type of data transmitted;
• whether the message was disguised;
• data size;
• mask;
• other control data (ping, pong ...).

The interaction between the client and the server begins with a request from the client:

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

The server response is as follows:

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

The response contains the Sec-WebSocket-Protocol header with the only protocol selected by the server (chat) from all supported by the client (chat, superchat). The Sec-WebSocket-Accept header is formed as follows:

1. take the string value from the Sec-WebSocket-Key header and combine with the string 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 (in the example, we get dGhlIHNhbXBsZSBub25jZQ == 258EAFA5-E914-47DA-95CA-C5AB0DCB11511)
2. calculate the SHA-1 binary hash (a binary string of 20 characters) from the string received in the first paragraph
3. encode the hash in Base64 (s3pPLMBiTxaQ9kYGzzhZRbK + xOo =)

An example implementation of the above algorithm in PHP :

  <? php
   echo base64_encode ( SHA1 ( "dGhlIHNhbXBsZSBub25jZQ == 258EAFA5-E914-47DA-95CA-C5AB0DC85B11" , true ));
 ?> 

RFC 6455 (hereinafter data is transmitted in frames using this protocol)

On December 11, 2011, the protocol acquired RFC status.

Instead of the Sec-WebSocket-Origin header, just Origin is now used.

The Web Socket protocol defines two URI schemes, ws: (unencrypted connection) and wss: (encrypted connection).

To establish a connection, the client script creates a WebSocket object, into the constructor of which it passes the WebSocket URI parameter, and defines callback functions when connecting, receiving a message, and disconnecting.

  < html >
     < head >
         < script >
             const webSocket = new WebSocket ( 'ws: // localhost / echo' );

             webSocket .  onopen = event => {
                 alert ( 'onopen' );
                 webSocket .  send ( "Hello Web Socket!" );
             };

             webSocket .  onmessage = event => {
                 alert ( 'onmessage,' + event . data );
             };

             webSocket .  onclose = event => {
                 alert ( 'onclose' );
             };
         </ script >
     </ head >
     < body >
     </ body >
 </ html >

WebSocket is currently supported in the following browsers:

• Google Chrome (since version 4.0.249.0);
• Apple Safari (since version 5.0.7533.16);
• Mozilla Firefox (since version 4);
• Opera (since version 10.70 9067);
• Internet Explorer (since version 10);

You can check WebSocket browser support by clicking on the link: http://caniuse.com/#feat=websockets .

At the end of November 2010 Adam Barth published the results of a study of the reliability of the protocol used ^[3] . According to its results, it turned out that in the case of using transparent proxies, it is possible to replace the cache of transmitted data so that users instead of real data will receive a version of the data from the attacker. The problem turned out to be serious enough for the developers of Firefox and Opera to announce that in future versions of their browsers the support for web sockets will be disabled by default until the insecurity of this protocol is fixed (although it remains possible to enable them).

• RFC 6455 - The WebSocket protocol , protocol standard
• HTML5 WebSocket API draft W3C specification
• WebSockets.org WebSocket website (supports WebSocket test echo server)
• WebSocketsTest.org site that checks the operation of WebSockets and Comet in your browser