WebSocket--Why the introduction of WebSocket protocol

Browser already supports the HTTP protocol, why develop a new websocket protocol? We know that the HTTP protocol is a one-way network protocol, and after the connection is established, it only allows Browser/ua (useragent) to send the requested resource to webserver, webserver to return the corresponding data. and webserver can not actively push data to Browser/ua, originally so design HTTP protocol also has reason, assuming webserver can actively push data to Browser/ua, that Browser/ua is too vulnerable to attack, Some advertisers will also take the initiative to send some advertising information inadvertently forcibly transferred to the client, this can not be said to be a disaster. So what is the problem with a one-way HTTP protocol for today's web site or Web application development?

Let's take a look at a case, now suppose we want to develop a Web-based application to get the real-time data of the current Web server, such as the real-time stock market, the ticket number of tickets and so on, which requires the Browser/ua and webserver end of the repeated HTTP communication, Browser constantly sends a GET request to get the current real-time data. Here are a few common ways:

1. Polling

This way is through Browser/ua timed to send HTTP to the Web server get request, the server received the request, the latest data sent back to the client (Browser/ua), Browser/ua get the data, it is displayed, Then repeat the process on a regular basis. Although this can meet the requirements, but there are still some problems, such as the Web server in a certain period of time there is no updated data, but Browser/ua still need to send a regular GET request to ask, then the Web server will transfer the old data back, browser/ The UA shows the unchanged data, which obviously wastes network bandwidth and wastes CPU utilization. This can be mitigated if the period of the browser send GET request is larger, but it does not guarantee the real-time nature of the data in the Web application if the data is updated very quickly on the Web server side.

2. Long Polling

The above describes the problems encountered by polling, and now introduce longpolling, it is an improvement to polling.

Browser/ua send a GET request to the Web server, the Web server can do two things, first, if the server side has new data needs to be transmitted, immediately send the data back to the Browser/ua,browser/ua received data, immediately sent a GET request to the Web server; second, if there is no new data to be sent on the server side, unlike the polling method, the server does not send a response to Browser/ua immediately, but keeps the request in response to the request when new data arrives, and, of course, If the server's data is not updated for a long period of time, the GET request will time out, Browser/ua receive a timeout message, and then immediately send a new GET request to the server. Then loop through the process in turn.

This approach, although to some extent, reduces the network bandwidth and CPU utilization problems, but there are still defects, such as the assumption that the server side of the data update rate is faster, the server after transmitting a packet to browser must wait for the next get request of browser arrival, In order to pass the second updated packet to browser, so that the browser display real-time data the fastest time is 2xRTT (round-trip time), and in the case of network congestion, this should not be acceptable to the user. In addition, because HTTP packet header data is often large (usually more than 400 bytes), but the actual data required by the server is very small (sometimes only 10 bytes or so), such a packet on the network periodic transmission, it is inevitable that network bandwidth is a waste.

The above analysis shows that if the browser can have a new network protocol, can support the client and server side of the two-way communication, and the Protocol's head is not so large. WebSocket is on the stage with such a mission.

The WebSocket protocol is a two-way communication protocol that is based on TCP and transmits data over TCP as HTTP, but it differs from HTTP by a maximum of two points: 1. WebSocket is a two-way communication protocol, after establishing a connection, the WebSocket server and Browser/ua can actively send or receive data to each other, just like a socket, The difference is that WebSocket is a simple analog socket protocol based on Web, 2. WebSocket need to be connected via a handshake, similar to TCP It also requires a handshake connection between the client and server to communicate with each other after the connection is successful.

Here is a simple timing diagram to build the handshake:

Here is a brief explanation of the WebSocket handshake process.

When the Web application calls the new WebSocket (URL) interface, browser begins the process of establishing a handshake connection with the Webserver address as a URL.

1. Browser with the WebSocket server through a TCP three handshake to establish a connection, if the connection fails, then the subsequent procedure will not be executed, the Web application will receive an error message notification.

2. After TCP establishes the connection successfully, BROWSER/UA transmits the WebSocket supported version number through the HTTP protocol, the Word version number of the Protocol, the original address, the host address and so on some column fields to the server side.

For example:

[HTML]View PlainCopy

1. Get/chat http/1.1
2. Host:server.example.com
3. Upgrade:websocket
4. Connection:upgrade
5. sec-websocket-key:dghlihnhbxbszsbub25jzq==
6. Origin:http://example.com
7. Sec-websocket-protocol:chat,superchat
8. Sec-websocket-version:13

3. After the WebSocket server receives the handshake request sent by Browser/ua, if the packet data and format are correct, the client and server side protocol version number matches, and so on, accepts this handshake connection, and gives the corresponding data reply, the same reply packet is also transmitted using HTTP protocol.

[HTML]View PlainCopy

1. http/1.1 101 Switching protocols
2. Upgrade:websocket
3. Connection:upgrade
4. sec-websocket-accept:s3pplmbitxaq9kygzzhzrbk+xoo=
5. Sec-websocket-protocol:chat

4. Browser received the server reply to the packet, if the packet content, format is not a problem, it means that the connection is successful, triggering the OnOpen message, the web developer can at this time through the send interface to the server to send data. Otherwise, the handshake connection fails, and the Web application receives the ONERROR message and knows why the connection failed.

WebSocket--Why the introduction of WebSocket protocol