New Web Protocol Promises to Reduce Browser Latency
by George Lawton
The chatty nature of traditional HTTP communications is the main source of browser latency today. Although various techniques have emerged to reduce the number of browser method calls to the server, they come with costs in programming complexity and code size. The WebSocket protocol is a proposed IETF standard to reduce Web application latency, code size, and development complexity by enabling two-way communication between Web pages and a remote host.
"WebSockets really marks a quantum leap forward in the reduction of unnecessary network traffic," said Peter Lubbers, director of documentation and training at Kaazing, an HTML 5 training and tool vendor.
Reducing application latency could have a direct impact on businesses using even the simplest text-only websites. For example, a recent Google experiment reported that users entered 25 percent fewer new search terms when the latency rose from 400 to 900 milliseconds. A 2 percent increase in latency from adding a shopping cart icon corresponded to a 2 percent drop in site usage.
A pre-standardized version of Websockets is running now within the Chrome and Safari browsers, while Opera and Firefox are also working on implementations. The main obstacle to full standardization has been security concerns related to cache maintenance.
Simplified Web Communications
Websockets is one of the primary communication protocols introduced as part of HTML 5.It's been in development for six years, starting from a World Wide Web Consortium (W3C) working group that included representatives from leading browser providers such as Google, Apple, Mozilla, and Opera. The W3C group forwarded a rough WebSockets draft to the IETF in 2008 to create a final standard.
Ian Fette, senior product manager for Google Chrome and author of the IETF standard, said the IETF group has reached consensus on many aspects of the protocol. For example, the APIs are locked in place, making it possible to write a program once using HTML 5 and WebSockets and run it today. The group is now approaching consensus on its framing and handshake aspects as well.
"People have been trying to realize these use cases for a while — for example, using XMLHttpRequest to send data from a client to server and then using a hanging get request," said Fette. But this approach is suboptimal. "There are two open connections rather than one," he explained. "The presence of caching proxies often forces you to close one of the connections to ensure the data is sent."
In contrast, WebSockets is designed to be a simple, straightforward API. "A Web developer doesn't have to worry about multiple connections and closing connections and how the entire message has been sent," said Fette. "All of that is abstracted to 'Here is the data to send,' and 'Here is the data I want to read.'"
WebSockets Primer
HTTP was designed for static websites. It worked well in the early Web, when data was presented in sequentially transmitted pages. But today, most applications involve considerable feedback between the browser and server. Many developers have developed complex workarounds, such as Comet and Ajax, to handle the communications for these applications. The various libraries resulting from these workarounds operate differently and therefore break in different ways.
The WebSocket protocol replaces all these different techniques with a single highly optimized code set that's installed natively in each browser. This makes a big difference in the time to load the first page. Fette said that Google used Websockets to reduce the startup payload for Gmail from 40 Kbytes to about 2 Kbytes.
Furthermore, the protocol itself adds less overhead to each transmission — 2 bytes of packaging to a simple 5-byte message, while HTTP adds about a thousand bytes. Peter Lubbers, director of Kaazing's documentation and training, demonstrated an application in which WebSockets reduced the bandwidth demand from 665 Mbps with HTTP to only 1.526 Mbps for 100,000 clients receiving one message per second.
Dark Clouds
Potential security concerns led browser makers Mozilla and Opera to postpone full support for WebSockets. An analysis of the number of Internet cache server configurations found that only about 0.12 percent would be vulnerable to a Web cache poisoning attack but the concern has been big enough to stall adoption. Adam Barth, a researcher who worked with Carnegie Mellon team to test various WebSockets security vulnerabilities, described Web cache poisoning as a way to confuse the proxy into doing things an attacker wants. The consequences are similar to cross-site scripting in which the attacker gets to choose the content purported to come from the Web.
Anne van Kesteren, a product developer at Opera, said they have shipped a WebSockets implementation and API in Opera 11, but it's disabled by default. "There are transparent and intercepting proxies that do not fully understand HTTP," van Kesteren said, explaining the company's decision. "In particular, they don't understand the upgrade-based handshake WebSockets is using and therefore the cache of these proxies can be poisoned." Once a cache is poisoned, he said, it would affect all users behind that proxy.
Barth said this problem has two relatively simple fixes. The first is to encrypt all of the traffic so that the proxy doesn't get confused. This adds a 1 percent overhead on traffic. The second method is to use the Connect method within HTML, which incurs no overhead.
What's Next
Chris Blizzard, a technology evangelist for Mozilla, sees WebSockets progressing along the IETF standards track at a good rate. "The protocol isn't a product, so there's no release date in the classic sense," he said. Once the IETF standard is set, however, he expects modern browsers to adopt the protocol quickly. "It improves a user's experience, decreases loads on Web servers, and reduces the amount of bandwidth that low-latency applications require."
Vendors like Kaazing have already released WebSockets development libraries for HTML 5. The libraries support backward compatibility with existing browsers, which will make it easier for organizations to move to HTML 5 without having to manage a separate code base for older browsers.
"What we are implementing now is not final, but it's pretty darn close," said IETF's Fette. "Over the course of the first half of 2011, we will see continued refinement to the protocol and in the second half, we will really get it locked down."
George Lawton is a freelance journalist in Guerneville, CA. Contact him via his website http://glawton.com.
