WebSocket (2)--Why the introduction of the WebSocket protocol

[This article is original, if reproduced, please indicate the source http://blog.csdn.net/yl02520/article/]

Browser has supported the HTTP protocol, so why develop a new websocket protocol? We know that the HTTP protocol is a one-way network protocol, after the connection is established, it only allows Browser/ua (useragent) to send webserver request resources, webserver can return the appropriate data. And webserver can not take the initiative to push data to Browser/ua, the original design HTTP protocol is also a reason, assuming webserver can actively push data to Browser/ua, that Browser/ua is too vulnerable to attack, Some advertisers will also actively put some advertising information inadvertently forcibly transmitted to the client, which can not but say is a disaster. So what is the problem with a one-way HTTP protocol for today's web sites or Web application development?

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

1. Polling

This way is through Browser/ua timed to the Web server to send HTTP GET request, the server received the request, the latest data sent back to the client (Browser/ua), Browser/ua get the data, it will be displayed, Then repeat the process periodically. 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 come over to ask, then the Web server will send the old data back, browser/ UA shows these unchanged data again, which obviously wastes both network bandwidth and CPU utilization. If the cycle of browser send get Requests is larger, this can be mitigated, but if the data on the Web server is updated quickly, it does not guarantee the real-time nature of the data being retrieved by the Web application.

2. Long Polling

The above introduces the problem that polling encounters, now introduce longpolling, it is an improvement to polling.

Browser/ua send get requests to the Web server, when the Web server can do two things, first, if the server side has new data need to transfer, immediately send the data back to Browser/ua,browser/ua after receiving the data, immediately resend GET request to the Web server; second, if there is no new data to be sent on the servers, here, unlike the polling method, the server does not send a response immediately to Browser/ua, but rather holds the request and waits for new data to come in response to the request; of course, If the server's data has not been updated for a long period of time, the GET request times out, Browser/ua receives the timeout message, and sends a new GET request to the server immediately. Then loop through the process in turn.

This approach, while reducing network bandwidth and CPU utilization to some extent, still has drawbacks, such as assuming that the server-side data update rate is faster, and the server must wait for browser's next get request to arrive after sending a packet to browser. In order to pass the second updated packet to browser, then, browser display real-time data the fastest time is 2xRTT (round trip time), in addition to network congestion, this should not allow users to accept. In addition, because the HTTP packet header data volume is often very large (usually more than 400 bytes), but the real server needs the data is very little (sometimes only 10 bytes), such packets on the network periodically transmission, it is inevitable to network bandwidth is a waste.

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