HTML5 WebSocket protocol < A > based on building real-time Web applications

Preface

As a next-generation WEB standard, HTML5 has a number of compelling new features, such as Canvas, local storage, multimedia programming interfaces, WebSocket, and more. The WebSocket, which has the "Web TCP" , is particularly appealing to developers. The advent of WebSocket makes it possible for the browser to provide support for sockets, providing a two-way, TCP-based connection between the browser and the server. WebSocket is a new communication protocol added by HTML5, which is supported by popular browsers, and Web developers can easily build real-time Web applications using WebSocket.

Why introduce the WebSocket protocolThe WEB application's information interaction process is usually the client sends a request through the browser, the server side receives and approves the request after the processing and returns the result to the client, then the client browser presents the information, this mechanism for the information change is not particularly frequent applications can still be peaceful, but for those Real-time demanding applications such as online games, online securities, device monitoring, news online, RSS feeds , and so on, when the client browser is ready to present this information, may be outdated on the server side. So keeping information synchronization between client and server is a key element of real-time web applications, and is a challenge for web developers. Before the WebSocket specification came out, developers wanted to implement these real-time Web applications and had to adopt a few tradeoffs, the most common being polling (Polling) and comet technology , and comet technology was actually an improvement in polling technology, Can be subdivided into two ways of implementation, one is the long polling mechanism, a kind of called flow technology . Here's a brief introduction to these technologies:
Polling :This is one of the first scenarios for implementing real-time WEB applications. The client makes a request to the server at a certain time interval to maintain client-side synchronization in a frequently requested manner . The biggest problem with this synchronization scenario is that when the client initiates a request to the server at a fixed frequency, the server-side data may not be updated, which can result in a lot of unnecessary network transmissions , so this is a very inefficient real-time scenario.
Long Polling:Long polling is the improvement and enhancement of timed polling to reduce invalid network transmission . When there is no data update on the server side, the connection is maintained for a period of time until the data or state changes or time expires, which reduces the interaction between invalid client and server. Of course, if the data on the server is changed very frequently, there is no intrinsic performance improvement in this mechanism compared with timed polling.
Flow:

A streaming solution is usually a request to send a long connection to the server using a hidden window on the client's page. The server responds to this request and constantly updates the connection status to ensure that the client and server connections are not in the same period. This mechanism allows the server-side information to be continuously pushed to the client. This mechanism has a bit of a problem with the user experience, it is necessary to design different scenarios for different browsers to improve the user experience , and this mechanism in the concurrency is relatively large, the server-side resources is a great test .

SummaryIn combination with these scenarios, you will find that the so-called real-time technologies we use today are not real real-time technologies, they are just using Ajax to simulate real-time effects , and each time the client interacts with the server, it is an HTTP request and response process, and every HTTP request and reply with full HTTP header information, which increases the amount of data per transmission , and these scenarios in the client and server-side programming is more complex, in the actual application, in order to simulate more real real-time effects, developers often need to construct two HTTP Connection to simulate the two-way communication between the client and the server, a connection to handle the client-to-server data transfer, a connection to handle server-to-client data transmission, which inevitably increases the complexity of programming implementation, but also increases the server-side load, restricting the scalability of the application system.

HTML5 WebSocket designed to replace polling and Comet technology, so that the client browser has a desktop system like the C/s architecture of real-time communication capabilities. The browser sends a request to the server to establish a WebSocket connection through JavaScript, and after the connection is established, the client and server can exchange data directly via a TCP connection.

WebSocket Protocol Specification

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.

The WebSocket protocol is essentially a TCP-based protocol. In order to establish a WebSocket connection, the client browser first initiates an HTTP request to the server, which differs from the usual HTTP request and contains additional header information, where the additional header information "Upgrade:websocket" indicates that it is an application protocol upgrade The HTTP request, the server side resolves these additional header information and then produces the reply message returns to the client, the client and the server side WebSocket connection is established, the two sides can pass through this connection channel free information, And the connection persists until either the client or the server side actively closes the connection.

websocket vs. TCP, HTTP

WebSocket is TCP-based like the HTTP protocol, so they are all reliable protocols, and the WebSocket send function that the web developer invokes is ultimately transmitted through the TCP system interface in the implementation of the browser. WebSocket and the HTTP protocol belong to the application layer protocol, so what is the relationship between them? The answer is yes, websocket in the handshake connection, the data is transmitted through the HTTP protocol, as we saw in the previous section of the "Get/chat http/1.1", where the use of only the HTTP protocol some simple fields. However, after the connection is established, the actual data transfer phase is not required to participate in the HTTP protocol.

HTML5 WebSocket protocol < A > based on building real-time Web applications