Build real-time Web apps with HTML5 WebSocket

Original address: http://www.ibm.com/developerworks/cn/web/1112_huangxa_websocket/

HTML5 WebSocket Introduction and practical Walkthrough

This article mainly introduces the principle of HTML5 WebSocket and its revolutionary innovation to real-time WEB development, and demonstrates the powerful and easy-to-use of WebSocket through a case of WebSocket server and client.

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. Web developers can easily use WebSocket to build real-time web applications, and in the hands of developers there is a more powerful weapon of divine soldiers. This paper first introduces the basic concept of HTML5 WebSocket and the problem that this specification tries to solve, then introduces the basic principle and programming interface of WebSocket. The next step is to demonstrate how to implement a WebSocket application in a simple case, and to demonstrate how WebSocket is perfectly unified in both powerful and easy-to-use programming. Finally, this paper introduces the current situation, limitations and future prospects of mainstream browsers for WebSocket support.

The dilemma of real-time WEB applications

The 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 application can still be peaceful, But for applications with high real-time requirements, such as online games, online securities, device monitoring, news online, RSS feeds, etc., when the client browser prepares to present this information, the 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, while Comet technology was actually an improvement in polling technology and could be subdivided into two implementations, One is the long polling mechanism, which is called the 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.

In 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 each HTTP Both the request and the response have full HTTP header information, which increases the amount of data per transmission, and the programmatic implementation of the client and server side of these scenarios is more complex, in real-world applications, in order to simulate more 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.

The Salvation of WebSocket

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. Because the WebSocket connection is essentially a TCP connection, in terms of the stability of the data transmission and the size of the data transfer volume, the comparison with polling and Comet technology has a great performance advantage. websocket.org Web site to the traditional polling method and Websocket call way to make a detailed test and comparison, a simple WEB application by polling and Websocket way to achieve, here reference their test result diagram:

Figure 1. Network Load comparison diagram for polling and WebSocket implementations

With this graph, it is clear that the WebSocket scheme has a great performance advantage over the traditional Ajax polling scheme in the case of increased traffic and load. That's why we think WebSocket is the preferred solution for future real-time WEB applications.

WebSocket specification

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, with the additional header information "Upgrade:websocket" Indicates that this is an application protocol upgrade HTTP request, the server side to resolve these additional header information and then generate the response information returned to the client, the client and server side of the 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.

Let us introduce in detail the WebSocket specification, as this specification is still in the draft stage, the version changes relatively fast, we choose the draft-hixie-thewebsocketprotocol-76 version to describe WebSocket protocol. Because this version is currently in some major browsers such as Chrome, FireFox, Opera on the better support, if you are referring to the new version of the words, the content may be slightly different.

An example of a typical WebSocket initiating request and getting a response looks like this:

Listing 1. WebSocket Handshake Protocol

client-to-server: Service-to-client: http/1.1 101 WebSocket Protocol handshake upgrade:websocket Connection:upgrade websocket-origin:http://example.com Web Socket-location:ws://example.com/demo [16-byte Hash response]

These requests are similar to the usual HTTP requests, but some of them are closely related to the WebSocket protocol. We need a brief introduction to these requests and responses, "Upgrade:websocket" means 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. The information from the client-to-server request contains header information such as "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 side, the server side resolves the header information, generates a 16-bit security key and returns it to the client during the handshake, to indicate that the server has obtained the client's request and agrees to create a WebSocket connection. Once the connection is established, the client and server can transmit data in both 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 implementation of the WebSocket specification of the server, server-side implementation is not limited by the platform and development language, only need to comply with WebSocket specifications, There have been some more mature WebSocket server-side implementations, such as:

• Kaazing WebSocket gateway-A Java-implemented WebSocket Server
• Mod_pywebsocket-a Python-implemented WebSocket Server
• netty-a Java-implemented network framework that includes support for WebSocket
• node.js-a Server-side JavaScript Framework provides support for WebSocket

If the above WebSocket service implementations do not meet your business needs, developers can implement a server themselves according to the WebSocket specification. In the "WebSocket Combat" section, we will use the C # language on the Microsoft. NET platform to build a simple WebSocket server and build a simple live chat system.

WebSocket JavaScript Interface

The previous section describes the WebSocket specification, which mainly describes the WebSocket handshake protocol. The handshake protocol is often an issue we need to consider when building the WebSocket server-side implementation and providing WebSocket support for the browser, while the WebSocket JavaScript client interface for WEB developers is very simple, and the following is WebSocket J Definition of the Avascript interface:

Listing 2. WebSocket JavaScript Definition

[Constructor (in Domstring URL, in optional domstring protocol)]  Interface WebSocket {    readonly attribute domstring URL;         Ready state    Const unsigned short connecting = 0;    Const unsigned short OPEN = 1;    Const unsigned short CLOSED = 2;    ReadOnly attribute unsigned short readyState;    ReadOnly attribute unsigned long bufferedamount;    Networking    attribute Function OnOpen;    Attribute Function onmessage;    Attribute Function OnClose;    Boolean send (in domstring data);    void Close ();  };  WebSocket implements Eventtarget;

Where the URL property represents the network address of the WebSocket server, the protocol is usually "WS", and the Send method sends the data to the server side, and the Close method is to close the connection. In addition to these methods, there are some very important events: Onopen,onmessage,onerror and OnClose. We use a picture on the Nettuts website to visualize the WebSocket interface:

Figure 2. WebSocket JavaScript Interface

Here's a simple JavaScript code that shows how to establish a WebSocket connection and get data:

Listing 3. Creating an instance of the WebSocket connection JavaScript code

var  wsserver = ' Ws://localhost:8888/demo ';  var  websocket = new WebSocket (wsserver);  Websocket.onopen = function (evt) {OnOpen (evt)};  Websocket.onclose = function (evt) {OnClose (evt)};  Websocket.onmessage = function (evt) {onmessage (evt)};  Websocket.onerror = function (evt) {onerror (evt)};  function OnOpen (evt) {  console.log ("Connected to WebSocket server.");  function OnClose (evt) {  Console.log ("Disconnected");  }  function OnMessage (evt) {  console.log (' Retrieved data from server: ' + evt.data);  }  function OnError (evt) {  console.log (' Error occured: ' + evt.data);  }

Browser support

The following are the support scenarios for HTML5 WebSocket in mainstream browsers:

Browser	Support Situation
Chrome	Supported in version 4+
Firefox	Supported in version 4+
Internet Explorer	Supported in version
Opera	Supported in version
Safari	Supported in version 5+

WebSocket Combat

In this section we use a case to demonstrate how to use WebSocket to build a real-time WEB application. This is a simple real-time multiplayer chat system, including client and server implementations. The client initiates a request to the chat server through the browser, and the server-side resolves the handshake request from the client and generates the reply message back to the client to establish a connection channel between the client and the server. The server supports the broadcast function, the information sent by each chat user is sent to all users in real time, and when the user exits the chat room, the server needs to clean up the connection information of the corresponding user and avoid the resource leakage. Below we separately from the server side and the client to demonstrate the implementation of this Web chat system, in the implementation of the way we use the C # language to implement the WebSocket server, and the client is a running in the browser HTML file.

WebSocket Server-side implementation

The implementation of this chat server is very similar to a socket-based network application, first, the server side to start a socket to listen for connection requests from the client, the key difference is that the WebSocket server needs to parse the client's WebSocket handshake information, and according to WebSocket The requirements of the specification produce corresponding response information. Once the WebSocket connection channel is established, the client-server interaction is the same as the normal socket network application. So in the following about the WebSocket server-side implementation of the description, we mainly explain how the WebSocket server handles WebSocket handshake information, as for the establishment of the WebSocket listening port, the socket stream read and write, Are some of the common socket programming methods, we do not explain more, you can refer to the attachment source code files in this article.

As mentioned in the description of the WebSocket specification, a typical WebSocket Upgrade information is as follows:

Get/demo http/1.1 Host:example.com connection:upgrade sec-websocket-key2:12998 5 Y3 1. P00 upgrade:websocket sec-websocket-key1: [email protected] 46546xw%0l 1 5 origin:http://example.com [8-byte security ke Y

where Sec-websocket-key1,sec-websocket-key2 and [8-byte security key] These header information is the WebSocket server used to generate the source of the response information, based on draft-hixie-thewebsocketprotocol-76 The definition of draft, the WebSocket server generates the correct response information based on the following algorithm:

1. Reads the value of the Sec-websocket-key1 header information by character, connect prompt the numeric characters together into a temporary string, and counts the number of spaces;
2. Converts the number string generated in the 1th step to an integer number and then divides the resulting floating-point number into an integer by dividing the amount of space counted in the 1th step;
3. Converting the integer value generated in the 2nd step into a network byte array that conforms to the network transmission;
4. The Sec-websocket-key2 header information is also carried out in steps 1th through 3rd, resulting in another network byte array;
5. Combine [8-byte security key] and the network byte array generated in 3rd, 4th step into a 16-byte array;
6. The byte array generated for step 5th uses the MD5 algorithm to generate a hash value that is returned to the client as a security key to indicate that the server has obtained the client's request and agrees to create the WebSocket connection

At this point, the client and server WebSocket handshake is complete, the WebSocket channel is also set up. The following first describes how the server-side implementation is based on user-passed handshake information to generate a network byte array. The. NET platform provides a convenient function for string, numeric, and array manipulation, so the method of generating a byte array is very straightforward and the code is as follows:

Listing 4. Code to generate a network byte array

    Private byte[] Buildserverpartialkey (string clientkey)  {       string partialserverkey = "";      Byte[] Currentkey;      int spacesnum = 0;      char[] Keychars = Clientkey.tochararray ();      foreach (char currentchar in keychars)      {          if (char. IsDigit (Currentchar)) Partialserverkey + = Currentchar;         if (char. Iswhitespace (Currentchar)) spacesnum++;      }      Try      {               Currentkey = bitconverter.getbytes ((int) (Int64.parse (Partialserverkey)  /Spacesnum));         if (Bitconverter.islittleendian) array.reverse (Currentkey);      }      Catch      {         if (currentkey!= null) array.clear (currentkey, 0, currentkey.length);      }      return currentkey;   }

After the network byte array is obtained, the server-side generation of the 16-bit security key is as follows:

Listing 5. Code to generate a 16-bit security key

Private byte[] Buildcompleteserverkey (byte[] serverKey1, byte[] ServerKey2,  byte[] last8bytes)  {      byte[] Concatenatedkeys = new BYTE[16];     Array.copy (serverKey1, 0, Concatenatedkeys, 0, 4);     Array.copy (serverKey2, 0, Concatenatedkeys, 4, 4);     Array.copy (last8bytes, 0, Concatenatedkeys, 8, 8);     System.Security.Cryptography.MD5 Md5service =  System.Security.Cryptography.MD5.Create ();    Return Md5service.computehash (Concatenatedkeys);  }

The entire implementation is very straightforward, is to combine the generated network byte array and the client-submitted header information [8-byte security key] into a 16-bit byte array and encrypted with the MD5 algorithm, and then return the generated security key as a reply to the client, both the The Websocekt connection channel is set up. Implement the WebSocket handshake information processing logic, a basic function of the WebSocket server is completed. The entire WebSocket server consists of two core classes, one is Websocketserver, the other is socketconnection, for the sake of space, we do not introduce the properties and methods of each class, the attachment of the article will give the detailed source code, Interested readers can refer to.

When the server just started the screen is as follows:

Figure 3. WebSocket server just started the screen

The client can fill in the connection address of the chat server according to this information, when a client connects to the chat server, the server will print out the client and server handshake information, each customer's chat information will also be displayed on the server interface, the interface of the running Chat server is as follows:

Figure 4. There is a client connection to the WebSocket server.

We briefly describe the most basic elements of implementing a WebSocket server, and we will describe the implementation of the client in the next section.

Client implementation

The implementation of the client is much simpler than the server-side implementation, and we just need to visualize the HTML user interface and then call the WebSocket JavaScript interface to interact with the WebSocket server side. Of course don't forget to use a browser that supports HTML5 and WebSocket, the browser that I use when I write this article is Firefox. The client page structure is very concise, the initial run interface is as follows:

Figure 5. Chat Room Client Initial page

When the page is first loaded, it first detects whether the current browser supports WebSocket and gives the appropriate prompt information. When the user presses the Connect button, the page initializes a Websocekt connection to the chat server, and after the initialization succeeds, the page loads the corresponding WebSocket event handler, as shown in the client JavaScript code:

Listing 6. Initialize the code of the client WebSocket object

 function toggleconnectionclicked () {if (socketcreated && (ws.readystate = = 0 | | ws.readystate = = 1)) {            Ws.close ();                } else {Log ("Ready to connect to chat server ...");                  try {ws = new WebSocket ("ws://" + document.getElementById ("Connection"). Value);                Socketcreated = true;                  } catch (ex) {Log (ex, "ERROR");                Return                } document.getElementById ("Toggleconnection"). InnerHTML = "Disconnected";                Ws.onopen = Wsonopen;                Ws.onmessage = Wsonmessage;                Ws.onclose = Wsonclose;            Ws.onerror = Wsonerror;        }        }; function Wsonopen () {Log ("connection already established.            "," OK ");        $ ("#SendDataContainer"). Show ("slow");        };                    function Wsonmessage (event) {Log (event.data);        }; function Wsonclose () {Log ("connection close。            "," ERROR ");            document.getElementById ("Toggleconnection"). InnerHTML = "Connection";        $ ("#SendDataContainer"). Hide ("slow");        }; function Wsonerror () {Log ("WebSocket error.        "," ERROR "); };

When the user presses the Send button, the client calls the WebSocket object to send the message to the server, and the message is broadcast to all users, and the implementation code looks like this:

function senddataclicked () {            if (document.getElementById ("Datatosend"). Value! = "") {                ws.send ( document.getElementById ("Txtname"). Value + "say: \" "+ document.getElementById (" Datatosend "). Value +" \ "");                document.getElementById ("Datatosend"). Value = "";            }        };

If more than one user is logged on to the chat server, the client page runs as follows:

Figure 6. Chat Client Run page

At this point we have completed a complete WebSocket client implementation, the user can experience the simple and fast chat room, regardless of the page refresh and cumbersome Ajax calls, enjoy the user experience of the desktop program. WebSocket's powerful and easy-to-use visibility, you can add more features on this basis, design a more beautiful user interface, to experience the shock of WebSocket. For complete client code, see the source code provided in the attachment.

Limitations of WebSocket

The advantages of WebSocket have been enumerated a lot, but as an evolving WEB specification, we also want to see some of the risks of building applications with WebSocket today. First, the WebSocket specification is still in the draft phase, that is, its specifications and APIs are still possible, another risk is that Microsoft's IE as the largest market share of the browser, and other mainstream browser compared to the HTML5 support is relatively poor, this is our building enterprise-class A problem that must be considered in WEB applications.

Summarize

This article describes the HTML5 WebSocket's emergence and the problems it is trying to solve, then introduces the WebSocket specification and WebSocket interface, as well as its performance advantages over traditional real-time technology, and demonstrates how to use WebSocket to build a real-time WEB Application, finally we introduce the current mainstream browser support for HTML5 and WebSocket limitations. However, we should see that although HTML5 WebSocket currently has some limitations, but it is the trend, Microsoft has clearly expressed the future of HTML5 support, and these support we can see in Windows 8 and IE10, we are also on a variety of mobile devices, HTML5 and WebSocket were seen on the tablet. WebSocket will become the future development of real-time WEB application of the new force should be no suspense, as a Web developer, attention to HTML5, attention to WebSocket should also put on the agenda, otherwise we in the next wave of software innovation can only do Howard.

Click Download instance.

The original explanation of the websocket is very thorough, after looking at, know more than half. Audacity will stick to the original here, stay in the future to study slowly. If you are offended, please contact me and delete it immediately.