When Tim Berners-Lee specified the first version of the HTTP protocol in 1991, the Internet was still quaintly simple. On just one page, he described in a few words how a server was to respond to a GET request, and this description laid the foundation for the World Wide Web. One year later, he produced a draft that eventually led to RFC 1945, “Hypertext Transfer Protocol,” which was finally standardized as HTTP 1.0 in May 1996.

Just three years later, HTTP 1.1 was standardized to reflect the increasing load on the web. The revised protocol reduced the number of connection attempts required for a website by introducing keepalive connections, and HTTP pipelining allowed for multiple requests in sequence, without the need to wait for a response. HTTP hasn’t changed much since then, even though the web landscape has changed fundamentally. Realtime applications like Google+ and Facebook were unimaginable at the time HTTP 1.1 appeared, and features such as Ajax, real-time updates, and the appearance of 10Gb networks (or even some 100Gbps backbones) have changed the shape of the web.

The IETF Working Group “Hypertext Transfer Protocol Bis (httpbis)” is looking into the topic of how to fix HTTP, and it is assigned the role of revising RFC 2616 (Hypertext Transfer Protocol – HTTP/1.1). This group only intends to clear up current misunderstandings. On the mailing list, Mark Nottingham, the chair of the group recently tripped a discussion relating to HTTP 2.0, the first draft of which is due May 2012. One year later, the changes are to be implemented in the scope of the “last call” before the standard is submitted to the IESG.

Thus far, very few tangible facts exist on HTTP 2.0; however, the requirements for the future web protocol do include good performance for conventional and mobile browsers and a wide degree of downward compatibility. One new protocol that might find its way into the HTTP 2.0 specifications is SPDY (pronounced “speedy”), which is promoted by Google and has been implemented in working code, thus improving its chance for general acceptance. Google has added SPDY capabilities to its Chrome browser, and the protocol is already implemented in the developer version of Firefox. In just a few months, the final Version 11 of Firefox could include the SPDY code. The Google Chrome 11 browser uses SPDY by default if users access Google’s servers via SSL. To discover whether or not your own version of Chrome supports SPDY, type in the URL chrome://net-internals/#spdy (Figure 1).

Figure 1: Recent versions of Chrome already use the SPDY protocol for SSL connections to Google servers.

In December, the developers – including Google Apache developers – updated Apache to provide more or less state-of-the-art SPDY support. The mod_spdy module for Apache 2.2 attempts to add the SPDY protocol to the Apache server.

The hard-working and innovative developers of the JavaScript web framework Node.js have also produced a SPDY module available from GitHub. Additional implementations of the (experimental) protocol exist for Python, Java, Ruby, Go, Erlang, and C, providing sufficient potential for experiments of your own. Google will be releasing the source code for the server implementation sometime in the near future.

The recent appearance of SPDY in the wild means that you might be bumping into this innovative new protocol sooner than you think.

Meet SPDY

According to Google, “SPDY adds a session layer atop of SSL that allows for multiple concurrent, interleaved streams over a single TCP connection.”

Because of the complex interaction between HTTP and the underlying TCP Transport layer protocol, browsers often have to open multiple concurrent connections (see the box titled “HTTP Issues”). Managing multiple TCP sessions to support these simultaneous connections increases overhead and latency. SPDY addresses this problem by managing multiple concurrent connections through a single TCP connection. In essence, SPDY is actually a protocol that sits between SSL and HTTP. SPDY plays the role of multiplexing multiple HTTP connections through a single TCP session.

By slipping an additional protocol between HTTP and SSL, the SPDY developers provide significant latency improvements while requiring minimal change to existing infrastructures. The Transport layer and lower layers operate without the need for modification. More importantly, existing webpages and web applications do not have to be aware of this new protocol below HTTP.

SPDY aims to retain compatibility and keep the basic structure of HTTP, such as the semantics of requests and responses. In the SPDY whitepaper, the authors report up to 64 percent improvements in load times; the declared objective is an average of 50 percent. In addition to stream multiplexing, SPDY also provides additional benefits. Prioritization of requests ensures that important requests are given priority over less important ones. And SPDY compresses the HTTP header to reduce data traffic. SPDY also allows connections initiated by the server, which will make past hacks such as Comet obsolete. Along with performance improvements, Google wants to make HTTP more secure, and to this end, SPDY will rely on SSL-protected connections.

TCP Improvements

Google is not satisfied with just contributing a new protocol and is also working on optimizing TCP. As connections grow faster, say the Google techies, a faster TCP protocol will remove the need to close the initial congestion window in TCP after four packets, as required by RFC 3390. In some tests, increasing the window to a value of 10 packets achieved substantial latency reductions, and this goal is also reflected in an IETF draft. A patch that implements this change within the Linux kernel already exists. Also planned is an effort to reduce the initial timeout when opening a TCP connection from three seconds to one second.

The idea of sending the payload data in the form of HTTP requests when opening a connection with a TCP SYN packet is also interesting; this change reduces load time by an average of 10 percent. Look online for more about how to make the web faster.

Conclusions

Suddenly HTTP 2.0 is just around the corner; the first draft is due in May, and Google’s SPDY protocol could be a part of it. SPDY has the advantage of already being implemented on Google’s own servers and the Chrome and Firefox browsers. Implementations of the draft protocol in various programming languages let users experiment. You will even find a book on SPDY available in electronic form.