HTML5 WebSocket: The next revolution in Web communications unveiled

Let's take a look at the changes to the current web traffic in HTML 5. The HTML 5 Web socket defines a full-duplex communication channel through a single socket on the Web, which brings significant improvements to WEB traffic.

HTML5 WebSocket: The next revolution in Web communications unveiled

"51CTO" a variety of cutting-edge technologies for HTML 5 have been reported in 51CTO, such as the HTML 5 video audio element, HTML 5 Web SQL Database, the HTML5 File API, and how to build an HTML 5 page from scratch, and so on. These are HTML 5 upgrades or extensions to the current Web development standard technology. Today, 51CTO takes you through the other side of HTML 5, the--html 5 Web Socket, and its changes to the current web traffic.

The recent rumors about the HTML 5 Web socket have been flying through a single socket on the web that defines a full-duplex communication channel, and theHTML 5 Web socket is not an enhanced version of normal HTTP communication, it represents a huge improvement, Especially for real-time, event-driven Web applications .

"The number of bytes in the data is drastically reduced to 2 bytes, and the latency is reduced from 150 milliseconds to 50 milliseconds, in fact, these two factors are enough to interest Google," said Google's engineer Ian Hickson. By simulating a full-duplex connection in one browser, the HTML 5 Web socket provides significant improvements to web traffic.

Let's look at how HTML 5 Web sockets reduce unnecessary network traffic and latency compared to traditional solutions.

Current Web Communication--The poll of headaches (Polling)

Typically, when a browser accesses a Web page, an HTTP request is sent to the Web server hosting the page, and the Web server recognizes the request and returns a response. For example, stock prices, news reports, ticket sales, traffic patterns, medical device readings, etc., when the browser renders the page, the response may expire, and if you want to get the latest "real-time" information, you can constantly refresh the page manually, but obviously this is not the best approach.

The real-time web programs currently available are mainly around polling and other server-side push technologies, most notably ComNet, which delays the end of HTTP responses, and ComNet-based push is usually combined with JavaScript long polling (longer Polling) Or a streaming connection policy is implemented.

When using polling, the browser sends HTTP requests periodically and receives immediate responses, a technique that is the first attempt to deliver real-time information, and obviously, if you know the time interval for message delivery, this is a good idea because you can synchronize client requests when the information on the server is available, but real-time data is often unpredictable. Inevitably there are unnecessary requests that cause many connections to be turned on, and some connections that do not have to be closed are closed.

When using long polling, the browser sends a request to the server, the server keeps the request open for a given period of time, if it receives a notification during this period, sends a response to the client that contains the message, and if no message is received during this period, the server sends a response to terminate the open request. It is important to understand that long polling does not provide any performance improvement over traditional polling when your information capacity is high. In fact, it may be worse because long polling may get out of control into a dead loop.

When a stream is used, the browser sends a complete request, but the server sends a response and saves the open state, then keeps it open (or remains open for a period of time), whenever the message is ready to be sent, the response is updated, but the server does not send an end response. As a result, the connection remains open, and subsequent messages can continue to use the connection. However, the flow is still encapsulated in HTTP, blocking the firewall and proxy server selection buffer content in response, so the time for message delivery is extended. Many streaming ComNet solutions have turned to long polling, and TLS (SSL) connections can be used to mask responses from buffers, but in this case each connection consumes more server resources.

Ultimately, all of these methods provide real-time data, including HTTP requests and response headers, which contain many additional, unnecessary header data, and most importantly, full-duplex connections require more than just a downstream connection from the server to the client. To emulate full-duplex communication on half-duplex http, many of today's solutions use two connections: one downstream connection and one upstream connection. Maintaining and reconciling these two connections requires a lot of overhead and adds complexity. In short, HTTP is not designed for real-time, full-duplex communication, as shown in 1, which shows the complexity of building a comnet Web application that uses the Publish/subscribe mode from the back-end data source to display real-time data based on half-duplex http.

Figure 1:comnet Complexity of the program

When you try to scale out those comet solutions, the situation gets worse, simulating HTTP-based bidirectional communication error-prone, even if the end user feels something looks like a real-time web application, the cost of this "real-time" experience is very high and requires more latency to wait. Unnecessary network traffic and a drag on CPU performance.

HTML 5 Web Socket -- Rescue

The HTML 5 Web socket is defined in the communication section of the HTML 5 specification, which represents the next evolution of Web traffic: Implementing a full-duplex, two-way communication channel through a single socket. The HTML 5 Web socket provides a true standard that you can use to build extensible, real-time web applications. In addition, because it provides a browser-delivered socket that eliminates many of the problems with the comet solution, the WEB socket significantly reduces overhead and complexity.

In order to establish a Web socket connection, the client and server are upgraded from the HTTP protocol to the WEBSOCKET protocol during the initial handshake, as in the following example:

Example 1:websocket handshake (browser request, server response)

1. Get/text http/1.1/r/n
2. upgrade:websocket/r/n
3. connection:upgrade/r/n
4. host:www.websocket.org/r/n
5. .../r/n
6. http/1.1 101 WebSocket Protocol handshake/r/n
7. upgrade:websocket/r/n
8. connection:upgrade/r/n
9. .../r/n

Once the connection is established, the WebSocket data frame can be transferred in full duplex mode between the client and the server, and in any direction at the same time, the text and binary frames can be sent at full duplex, with a minimum frame of only 2 bytes. In a text frame, each frame starts with 0x00 directly, ending at 0xFF bytes, and the data is encoded using UTF-8. WebSocket text frames use finalizers, while binary frames use a length prefix.

Note: Although the WebSocket protocol can already support multiple clients, it is not possible to pass the raw data to JavaScript because JavaScript does not support byte types, so if the client is JavaScript, the binary data is ignored. However, it can be passed to clients that support byte types.

Duel between Comet and HTML 5 WEB sockets

What people are most concerned about is how HTML 5 Web sockets reduce unnecessary network traffic and latency, and we compare a polling application with a Web socket application.

For the polling example, I created a simple Web application that uses the traditional publish/subscribe model to request real-time stock data from the RABBITMQ message broker, which is implemented by polling a Java servlet hosted on a Web server. The RABBITMQ message agent receives data from a fictitious, constantly updated price source of a stock price, connects to and subscribes to a specific stock channel (a topic on the message agent), and polls with XMLHttpRequest updates per second. When an update is received, some calculations are performed, and the stock data is displayed in the table shown in Figure 2.

Figure 2: A JavaScript stock quotes app

Note: The back-end stock source actually generates a lot of stock price updates per second, so it's better to use polling per second than long polling, which results in many successive polls, and polling is more effective at blocking incoming updates.

It all looks good, but when you look closely, you'll see that there are serious problems with the application, such as using Firefox's Firebug plugin (which allows you to debug Web pages and monitor page loading and script execution time), and you can expect a GET request to hit the server every second. Turning on live http Headers (another Firefox plugin that shows real-time HTTP message header traffic) reveals that the number of header overhead associated with each request is quite alarming. The following two examples show the HTTP message header data for a request and response.

Example 2:http request Header

2. Get/pollingstock//pollingstock http/1.1
4. host:localhost:8080
6. user-agent:mozilla/5.0 (Windows; U Windows NT 5.1; En-us; rv:1.9.1.5) gecko/20091102 firefox/3.5.5
8. Accept:text/html,application/xhtml+xml,application/xml; q = 0.9,*/*; q = 0.8
10. Accept-language:en-us
12. Accept-encoding:gzip,deflate
14. Accept-charset:iso-8859-1,utf-8; q = 0.7,*; q = 0.7
16. keep-alive:300
18. Connection:keep-alive
20. referer:http://www.example.com/pollingstock/
21. cookie:  showinheritedconstant = false;  
    showinheritedprotectedconstant = false;  
    showinheritedproperty = false;  
    false;  
    false;
      showinheritedprotectedmethod = false;
      showinheritedevent = false;  
    showinheritedstyle = false;  
    false  

Example 3:http response header

1. http/1.x OK
2. x-powered-by:servlet/2.5
3. Server:sun Java System Application Server 9.1_02
4. content-type:text/html; charset = UTF-8
5. Content-length:21
6. Date:sat, 00:32:46 GMT

The cost of the HTTP request and response header information includes a total of 871 bytes, and does not include any data, of course, this is only an example, your message header data may be less than 871 bytes, but I also saw the message header data more than 2000 bytes. In this example, the stock topic message data is about 20 characters.

What happens when you deploy such a program to users on a large scale? We use three different use cases to observe the network throughput required for the HTTP request and response header data associated with this polling application.

Use case a:1000 client, polling once per second
Network throughput (871x1000) = 871000 bytes =6968000 bits per second (6.6Mbps)

Use case b:10000 client, polling once per second
Network throughput (871x10000) = 8710000 bytes =69680000 bits per second (66Mbps)

Use case c:100000 client, polling once per second
Network throughput (871x100000) = 87100000 bytes =696800000 bits per second (665Mbps)

This is an unnecessary huge network throughput, when we can use the HTML 5 Web socket, I reconstructed the application using the HTML 5 Web socket, added an event handler to the Web page, and listened synchronously to the stock update message from the message agent. Each message is a Web socket frame, with a cost of only 2 bytes (not 871 bytes), and then a look at the impact on network throughput.

Use case a:1000 client, polling once per second
Network throughput (2x1000) = 2000 bytes =16000 bits per second (0.015Mbps)

Use case b:10000 client, polling once per second
Network throughput (2x10000) = 20000 bytes =160000 bits per second (0.153Mbps)

Use case c:100000 client, polling once per second
Network throughput (2x100000) = 200000 bytes =1600000 bits per second (1.526Mbps)

As you can see in Figure 3, the HTML 5 WEB socket reduces unnecessary network traffic compared to a polling solution.

Figure 3: Compare network throughput between polling and WebSocket applications

What about the reduction in latency? Looking at Figure 4, the upper part of the figure shows the delay of the half-duplex polling scheme, where we assume that the message is transferred from the server to the browser for 50 milliseconds, and the polling method introduces many additional delays, because when the response is complete, a new request is sent to the server, and the new request takes 50 milliseconds. During this time, the server cannot send any messages to the browser, resulting in additional server memory consumption.

The lower half of Figure 4 shows the latency generated by the web socket, and once the connection is upgraded to a Web socket, the message is transferred more timely, and it still takes 50 milliseconds to transfer from the server to the browser, but the web socket connection remains open, and then no more requests are sent to the server.

Figure 4: Latency comparison between polling and web Socket applications

HTML5 Web sockets and kaazing WebSocket gateways

Currently, only Google Chrome browser natively supports HTML 5 WEB sockets, but other browsers will also provide support to address this limitation, Kaazing WEB socket gateway for all old browsers (IE 5.5+,firefox 1.5+, Safari 3.0+ and Opera 9.5+ provide a complete web socket emulation, so you can now use the HTML 5 Web socket API.

Web sockets are great, but what can you do with a full-duplex socket connection in your browser? To take full advantage of the full functionality of the HTML 5 Web socket, Kaazing provides a bytesocket library for binary communications, providing more advanced libraries for protocols such as Stomp, AMQP, XMPP, and IRC, all built on top of the web socket.

For example, if you use a more advanced library for the Stomp or AMQP protocol, then you can communicate directly with the backend message broker, such as RABBITMQ, by directly connecting to the service, eliminating the need for additional application service logic to convert these bidirectional, full-duplex TCP back-end protocols to non-bidirectional, Half-Duplex HTTP connection, because the browser itself can understand these protocols.

Figure 5:kaazing Web Socket Gateway extends TCP-based messages with better performance

Summarize

The HTML 5 Web socket is a big step forward in the extensibility of real-time Web applications, as you can see in this article, with HTML 5 Web sockets providing 5,000:1 or – depending on the HTTP header size – A 1000:1 reduction in the amount of unnecessary HTTP header traffic and a 3:1 reduction in communication latency is not a gradual improvement, but a revolutionary leap.

The Kaazing Web socket gateway allows HTML 5 Web socket code to run in all browsers, while providing an Additional Protocol library that allows you to leverage the full-duplex socket connection provided by the HTML 5 Web socket to communicate directly with the backend service.

HTML5 WebSocket: The next revolution in Web communications unveiled