Comprehensive Analysis of webkit HTML5 WebSocket 1

Csdn lidp http://blog.csdn.net/perfectpdl
 
As the next-generation Web standard, HTML5 has many notable new features, such as Canvas, local storage, multimedia programming interfaces, WebSocket, and so on. Specifically, WebSocket, called "Web TCP", attracts the attention of developers. The emergence of WebSocket makes it possible for the browser to provide support for Socket, thus providing a two-way channel based on TCP connection between the browser and the server, webkit, a popular open-source browser engine, also supports this heavyweight html5 feature.
 
 
 
 
 
 
Real-time Web application dilemma
 
The information interaction process of a Web application is usually when a client sends a request through a browser. After receiving and reviewing the request, the server processes the request and returns the result to the client. Then, the client browser displays the information, this mechanism is still safe for applications with less frequent information changes, but for applications with high real-time requirements, for example, online games, online securities, device monitoring, online news broadcast, and RSS subscription push. When the client browser prepares to present the information, the information may be outdated on the server. Therefore, keeping the client and server information synchronized is a key element of real-time Web applications, which is also a challenge for Web developers. Before the WebSocket specification came out, developers had to adopt some compromise solutions to implement these real-time Web applications. The most common ones were Polling and Comet technologies, the Comet technology is actually an improvement of the polling technology. It can be subdivided into two implementation methods: Long polling mechanism and stream technology. Below we will briefly introduce these technologies:
 
Round robin:
 
This is the earliest solution to implement real-time Web applications. The client sends a request to the server at a certain interval, and maintains the synchronization between the client and the server in the form of frequent requests. The biggest problem with this synchronization solution is that when the client initiates a request to the server at a fixed frequency, the data on the server may not be updated, which will lead to a lot of unnecessary network transmission, therefore, this is a very inefficient real-time solution.
 
Long polling:
 
Long round robin improves and improves regular round robin to reduce invalid network transmission. When no data is updated on the server, the connection will be retained for a period of time until the data or status changes or the time expires. This mechanism can be used to reduce the interaction between invalid clients and servers. Of course, if the data on the server is frequently changed, this mechanism does not substantially improve performance compared with regular polling.
 
Stream:
 
The stream technology solution usually sends a persistent connection request to the server using a hidden window on the client page. The server responds to this request and constantly updates the connection status to ensure that the connection between the client and the server does not expire. This mechanism can continuously push server information to the client. This mechanism has a problem in user experience. You need to design different solutions for different browsers to improve the user experience. At the same time, when the concurrency is large, it is a great test for server resources.
 
Based on these solutions, you will find that the so-called real-time technologies we are currently using are not real-time technologies. They are just simulating real-time effects using Ajax, each interaction between the client and the server is an HTTP request and response process, and each HTTP request and response carries the complete HTTP header information, this increases the amount of data transmitted each time, and the client and server programming implementations in these solutions are complicated. In actual applications, in order to simulate real-time results, developers often need to construct two HTTP connections to simulate two-way communication between the client and the server. One connection is used to process data transmission from the client to the server, A connection is used to process data transmission from the server to the client, which increases programming complexity and server load, and restricts the scalability of the application system.
 
 
 
 
 
 
WebSocket rescue
 
HTML5 WebSocket is designed to replace the polling and Comet technologies so that the client browser can communicate with the desktop system in real time in a C/S architecture. The browser sends a WebSocket connection request to the server through JavaScript. After the connection is established, the client and the server can directly exchange data through the TCP connection. WebSocket connection is essentially a TCP connection. Therefore, compared with polling and Comet technologies, it has great performance advantages in terms of data transmission stability and data transmission volume.
 
 
 
WebSocket Specification
 
The WebSocket protocol is essentially a TCP-based protocol. To establish a WebSocket connection, the client browser must first initiate an HTTP request to the server. This request is different from the common HTTP request and contains some additional header information, with the additional header information "Upgrade: webSocket indicates that this is an HTTP request for protocol upgrade. The server parses the additional header information and generates the response information and returns it to the client. The WebSocket connection between the client and the server is established, both parties can transmit information freely through this connection channel, and the connection will continue until a client or a server actively closes the connection.
 
Below we will introduce the WebSocket specification in detail, because this specification is still in the draft stage, version changes faster, we choose the draft-hixie-thewebsocketprotocol-76 version to describe the WebSocket protocol. This version is currently well supported in some mainstream browsers such as Chrome, FireFox, and Opera. If you are referring to a new version, the content may be slightly different.
 
The following is an example of a typical WebSocket request and response:
 
 
View plaincopy to clipboardprint?
List 1. WebSocket handshake protocol
Client to server:
GET/demohttp/1.1
Host: example.com
Connection: Upgrade
Sec-WebSocket-Key2: 12998 5 Y3 1. P00
Upgrade: WebSocket
Sec-WebSocket-Key1: 4 @ 1 46546xW % 0l 1 5
Origin: http://example.com
[8-byte security key]
 
Server to client:
HTTP/1.1 101 WebSocket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
WebSocket-Origin: http://example.com
WebSocket-Location: ws: // example.com/demo
[16-byte hash response]
List 1. WebSocket handshake protocol
Client to server:
GET/demohttp/1.1
Host: example.com
Connection: Upgrade
Sec-WebSocket-Key2: 12998 5 Y3 1. P00
Upgrade: WebSocket
Sec-WebSocket-Key1: 4 @ 1 46546xW % 0l 1 5
Origin: http://example.com
[8-byte security key]
 
Server to client:
HTTP/1.1 101 WebSocket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
WebSocket-Origin: http://www.bkjia.com
WebSocket-Location: ws: // example.com/demo
[16-byte hash response]
 
 
These requests are similar to common HTTP requests, but some of them are closely related to the WebSocket protocol. We need to briefly introduce these requests and response information. "Upgrade: WebSocket" indicates that this is a special HTTP request, the purpose of the request is to upgrade the communication protocol between the client and the server from HTTP to WebSocket. The information requested from the client to the server contains header information such as the Sec-WebSocket-Key1, Sec-WebSocket-Key2, and [8-byte securitykey. This is the handshake information that the client browser needs to provide to the server. The server parses the header information and generates a 16-bit security key based on the handshake information and returns it to the client, to indicate that the server obtains the client request and agrees to create a WebSocket connection. Once the connection is established, the client and server can transmit data in two directions through this channel.
 
In the actual development process, in order to use the WebSocket interface to build a Web application, we first need to build a server that implements the WebSocket specification. The server implementation is not limited by the platform and development language, you only need to comply with the WebSocket specifications. For example, JWebSoket adopts the java language to implement the websocket server protocol and provides the client to develop js interfaces.
 
The next article analyzes the websocket js interface on webkit.