WebSocket Series: A Brief introduction

First Order

In reading <<netty authoritative guide >> 11th chapter WebSocket The development of the agreement, I think the author of this section is relatively simple, for the relevant knowledge is unfamiliar, not suitable to use Netty to achieve websocket. The plan is divided into three steps: 1websocket Introductory introduction. 2.Tomcat implements WebSocket. 3.netty Implementation WebSocket

Mainly consists of two parts: 1websocket protocol Introduction, 2 Tomcat implementation simple websocket. two WebSocket 2.1 Background

For historical reasons, when creating a Web application with a two-way communication mechanism, you need to take advantage of the way HTTP polling is used. "Short polling" and "long polling" are generated around polling. At a certain time interval (for example, 1 seconds) by the browser automatically make the request, the server's message pull back actively, in this case, we need to constantly send requests to the server, however, the HTTP request header is very long, the data contained in it may be just a small value, This can consume a lot of bandwidth and server resources.

And the most new technology to do polling effect is comet– using AJAX. However, although this technique can achieve full-duplex communication, it still needs to make a request (Reuqest). 2.2 WebSocket Introduction

WebSocket is a protocol specification proposed by HTML5, referring to rfc6455.

WebSocket the specification of a communication, through a handshake mechanism, between the client (browser) and the server (webserver) can establish a TCP-like connection, so as to facilitate communication between the c-s. Before the advent of WebSocket, web interaction was generally a short or long connection based on the HTTP protocol.

WebSocket is the technology that is generated to address real-time communication between the client and the server. The WebSocket protocol is essentially a TCP-based protocol that creates a TCP connection for exchanging data after a special HTTP request is initiated through the HTTP/HTTPS protocol, after which the server communicates with the client in real time over this TCP connection.

WebSocket protocol See https://tools.ietf.org/html/rfc6455 2.3 Protocol Overview

Open handshake data transfer close handshake

In the development of the WebSocket protocol, there are several versions of the handshake protocol, which are listed here.

Flash-based handshake protocol

The usage scenario is the majority version of IE, because most versions of IE do not support the WebSocket protocol, as well as the low version of the FF, Chrome and other browsers, there is no native support WebSocket. Here, the only thing the server has to do is prepare a websocket-location domain for the client, no encryption, and poor reliability. handshake protocol based on MD5 encryption method

Client Request:

Get/demo http/1.1
Host:example.com
Connection:upgrade
Sec-websocket-key2:
Upgrade:websocket
Sec-websocket-key1:
Origin:http://www.qixing318.com
[8-byte security key]

Service side return:

http/1.1 101 WebSocket Protocol handshake
upgrade:websocket
connection:upgrade
websocket-origin:http:/ /www.qixing318.com
Websocket-location:ws://example.com/demo
[16-byte Hash response]

where Sec-websocket-key1,sec-websocket-key2 and [8-byte security key] These headers are the sources that Web server uses to generate the response information, based on Definition of draft draft-hixie-thewebsocketprotocol-76.

The Handshake protocol based on SHA encryption method
is also the most current way to see, here the version number is currently required more than 13 version. Where the server is the client escalated a key to a GUID ("258eafa5-e914-47da-95ca-c5ab0dc85b11″), take this string to do SHA-1 hash calculation, and then the results obtained by Base64 encryption, Finally, it is returned to the client.

The client sends a handshake message similar to the following:

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

Handshake information for the service-side response type:

http/1.1 101 Switching Protocols
upgrade:websocket
connection:upgrade
sec-websocket-accept: s3pplmbitxaq9kygzzhzrbk+xoo=

Sec-websocket-protocol:chat

The client's handshake request starts with the request line (Request-line). The response of the client is initiated by the status line (Status-line). The production of request lines and status lines is shown in RFC2616.

The sections after the first line are HTTP Headers that are not ordered.

Once both the client and the server send their handshake information, the handshake process is complete, and then the data transfer section begins. Because this is a two-way communication, both the client and the server can send the message first.

At the time of data transmission, both the client and the server use the concept of "message messages" to represent a unit of data, and the message is made up of "frame frames". The frames here do not correspond to the frames on the specific network layer.

and the relationship between TCP and HTTP

WebSocket is a standalone TCP-based protocol, and its only relationship to HTTP is that its handshake request can be interpreted as an upgrade request (Upgrade requests) via an HTTP server (that is, you can use Nginx reverse proxy for a WebSocket.

2.4 Handshake Process

The handshake part is designed to be compatible with existing HTTP-based service-side components (Web server Software) or middleware (proxy Server software). Such a port can accept a normal HTTP request at the same time or WebSocket request. For this purpose, the WebSocket client handshake is an HTTP Upgrade request (HTTP Upgrade requests): The server name in the Host header can let the client identify which site it needs to access, and also make the server know which site is the client needs The request. Upgrade:websocket
Indicates that this is a special HTTP request, and the purpose of the request is to upgrade the client and server-side communication protocols from the HTTP protocol to the WebSocket protocol. Source identity origin can prevent scripts that run in the browser and send cross-domain requests to them without the WebSocket server's permission.
Sec-websocket-key
is a browser base64 encrypted key, the server side will need to extract sec-websocket-key information, and then encrypt.

Sec-websocket-accept
The server side appends a magical string "258eafa5-e914-47da-95ca-c5ab0dc85b11" to the received Sec-websocket-key key, and the result is Sha-1 hashed. The base64 encryption is then returned to the client (that is, Sec-websocket-key). If the encryption algorithm is wrong, the client will make a direct error when the test is performed. If the handshake succeeds, the client side will start the OnOpen event.

function Encry ($req)
{
    $key = $this->getkey ($req);
    $mask = "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"; 
    # SHA-1 encrypted string once again base64 encrypted
    return Base64_encode (SHA1 ($key. ' 258eafa5-e914-47da-95ca-c5ab0dc85b11 ', true));
}

Sec-websocket-protocol
Represents the optional sub-protocol provided by the client request, and the supported sub-protocols that are selected on the server side. Sec-websocket-version:13
The client carries in the handshake request, such a version ID, indicating that this is an upgrade version, now the browser is the use of this version.

http/1.1 101 Switching protocols
101 Status codes returned by the server, all non-101 status codes indicate that handshake is not completed.

The initial state of the connection is defined as "Connecting in connection".

Once the client's handshake request has been sent, the client must wait for the service-side handshake response, during which time no data can be transmitted to the server.

The client must also be generated on a server-side basis | Sec-websocket-accept| The method of the header field value also generates a string that is compared to the service-side callbacks, and if different, marks the connection as failed.

If the server response conforms to the above description, then the WebSocket connection is established and the status of the connection becomes "open state".
2.5 Data Frames

The WebSocket protocol transmits data through serialized data frames. Fields such as opcode, payload length, payload data are defined in the packet protocol. It requires that the data frames that the client transmits to the server must be masked: If the server receives a data frame that is not masked, it must actively close the connection. The data frames that the server transmits to the client must not be masked. If a client receives a masked data frame, it must actively close the connection.

For the situation, the party that found the error can send a close frame to the other (the status code is 1002, which indicates a protocol error) to close the connection.
The exact data frame format is shown in the following figure:

FIN
Identifies whether the last packet for this message, accounting for 1 bit RSV1, RSV2, RSV3: Used for expansion protocols, typically 0, each accounting for 1bit Opcode
Packet type (frame type), accounting for 4bits
0x0: Identifies an intermediate packet
0x1: Identifies a text type packet
0x2: Identifies a binary type packet
0x3-7: Reserved
0x8: Identifies a disconnect type packet
0x9: Identifies a ping type packet
0xA: Represents a Pong type packet
0xb-f: Reserved MASK: 1bits
Used to identify whether the payloaddata is masked. If the data for the 1,masking-key domain is a masked key, it is used to decode the payloaddata. The data frame emitted by the client needs to be masked, so this bit is 1. Payload length
The length of Payload data, which is 7bits,7+16bits,7+64bits: if its value is 0-125, it is the true length of Payload. If the value is 126, then the value of the number of 16bits unsigned integers formed by the subsequent 2 bytes is the true length of the payload. Note that the network byte order needs to be converted. If the value is 127, then the value of the number of 64bits unsigned integers formed by the subsequent 8 bytes is the true length of the payload. Note that the network byte order needs to be converted.

The length here means following a principle, with a minimum of bytes representing the length (minimizing unnecessary transmission). For example, the true length of the payload is 124, between 0-125, must be represented by the first 7 bits, the length 1 is 126 or 127, and the length 2 is 124, which violates the principle.

Payload data
Application-tier data server resolves client-side data

The parsing rules after receiving the client data are as follows: 1byte 1bit:frame-fin,x0 indicates that the message is followed by a frame;x1 that is the last frame 3bit of the message: FRAME-RSV1, Frame-rsv2 and Frame-rsv3, usually x0 4bit:frame-opcode,x0 is a continuation frame;x1 indicates that the text frame;x2 indicates that the binary frame;x3-7 is reserved to the non-control frame;x8 for closing the connection X9 means that PING;XA represents pong;xb-f reserved to control frame 2byte 1bit:mask,1 indicates that the frame contains a mask, 0 means no mask 7bit, 7bit+2byte, 7bit+8byte:7bit rounding values, If between 0-125, is the load data length, if 126 indicates that the latter two bytes take unsigned 16-bit integer value, is the payload length, 127 means the post 8 byte, take 64-bit unsigned integer value, is the payload length 3-6byte: Here assumes the load length between 0-125, and mask is 1, then these 4 byte is the mask 7-end byte: length is the load length taken out above, including extended data and application data two parts, usually no extended data, if mask is 1, then this data needs decoding, decoding rule is- 1-4byte mask loop and data byte do xor or manipulate. 2.6 Turn off handshake

It's also easy to turn off the handshake. At either end, you can choose to close the handshake process. The active closed party sends a closed type of packet to the other, and after the other party receives the packet, it replies to a packet of the same type, closing the completion. The shutdown type packet complies with the packet protocol, opcode for 0x8,payload data can be used to carry the shutdown reason or message.

event response for 2.7websocket

The above opening handshake, Data Framing, Closing handshake Three steps are actually corresponding to the WebSocket three events:

OnOpen response when the interface is open onmessage response when the message is received onclose when the interface is closed

The WebSocket API for any programming language must provide at least the API interface for the above three events, and some may also provide a mechanism for handling onerror events.

WebSocket will be in one of the following 4 states at any time: connecting (0): Indicates that a connection has not been established, OPEN (1): A connection has been established, communication can be made, CLOSING (2): The connection is being closed by closing the handshake; CLOSED (3) : The connection is closed or unable to open; Next we will use Tomcat to implement the WebSocket demo.

Reference:

http://www.jianshu.com/p/867274a5e054

Https://www.cnblogs.com/lizhenghn/p/5155933.html

Https://www.cnblogs.com/tinywan/p/5894403.html