BT

Google and Microsoft Want to Improve HTTP

by Abel Avram on May 24, 2012 |

Google and Microsoft want to improve HTTP with SPDY and Speed+Mobility. This article reviews both proposals outlining what benefits they bring to the much used Internet protocol.

Along with W3C, the Internet Engineering Task Force (IETF) is coordinating efforts related to network routing, transport, and security, including the specification proposal for RFC 2616 on HTTP 1.1 elaborated in 1999 and signed by Roy Fielding and T. Berners-Lee among others. More than 12 years have passed since the last HTTP version was adopted, and some have drawn the attention that the highly used Internet protocol needs to be enhanced in order to face the needs of this time. A number of proposals have been submitted to IETF for HTTP 2.0, including Google SPDY and Microsoft HTTP Speed+Mobility. Both proposals mentioned are backward compatible with previous versions of the protocol, trying to built on existing infrastructure.

Google is trying to address the speed problems existing with HTTP 1.1:

One of the bottlenecks of HTTP implementations is that HTTP relies on multiple connections for concurrency. This causes several problems, including additional round trips for connection setup, slow-start delays, and connection rationing by the client, where it tries to avoid opening too many connections to any single server.

For that reason, SPDY

adds a framing layer for multiplexing multiple, concurrent streams across a single TCP connection (or any reliable transport stream). The framing layer is optimized for HTTP-like request- response streams, such that applications which run over HTTP today can work over SPDY with little or no change on behalf of the web application writer.

Practically, SPDY brings 4 major improvements to HTTP 1.1: Multiplexed Requests, Prioritized Requests, Compressed Headers, and Server Pushed Streams. SPDY is already implemented and in production although the protocol is still a proposal. Google uses it across many of its services and in Chrome. Other implementations are: Apache SPDY module, SDPY server for node.js, Netty, Firefox, Amazon Silk, Ngnix will follow soon.

Microsoft proposes for HTTP 2.0 a specification that will address speed issues but also mobility ones, starting from SPDY and work done on WebSockets. In an email exchange with InfoQ, Adalberto Foresti, a Senior Program Manager at Microsoft Open Technologies and a signatory of Microsoft’s proposal, said that “SPDY has done a great job raising awareness of web performance and taking a “clean slate” approach to improving HTTP to make the Web faster.” Microsoft’s proposal amends SPDY by simplifying “the session control messages to remove items that are redundant to WebSockets control frames, break compatibility with existing HTTP semantics, or implement concepts best addressed at the transport layer.”

Microsoft HTTP Speed+Mobility also adds 2 sections meant to improve HTTP usage across the “Internet of things”, considering CPU consumption, device battery and resources, security and others. The section 1.1.4 called “Client is in control of content” specifies:

Because of the variety of clients on the Internet and the number of connection scenarios, clients are in the best position to define what content is downloaded. The browser or app has firsthand information on what the user is currently doing and what data is already locally available. For example, most of the browsers in use today have powerful caches that should be leveraged to store web elements that change infrequently. …

HTTP 2.0 proposals should not force the browser or app to download content that has not been requested and may already be cached. Furthermore, the client must have the option to decline unwanted or unneeded content. Clients need the ability to inform the server about cached elements that do not need to be downloaded. Ideally this feedback from the client to the server would allow for incremental approval of content to enable an efficient "push" extension to deliver the right content, with the right security and with the right formatting.

In section 1.1.5, “Network Cost and Power”, the authors address the issue of power and bandwidth consumption:

The choice among speed, cost, and power is not a simple one. At times, speed may be the most important consideration. Other times, bandwidth cost or battery life may be the deciding factor. HTTP 2.0 must allow developers to optimize for the specific constraints of their problem space (which might change over time) rather than imposing a monolithic solution to a generic problem....

The goals of higher speed, lower cost, lower power may often be aligned. For instance, having less data sent on the wire will allow pages to load faster, allow the radio to power down sooner and consume less bandwidth. But given the variety of the scenarios where HTTP 2.0 will be used, this will not always be the case. For example, a device whose battery is about to run out, or whose cache is near capacity can provide a better user experience by disabling server push updates while retaining the other optimizations available in HTTP 2.0. Accordingly, the working group should consider power and cost as well as speed.

In order to address the issues just mentioned, Microsoft proposes using a WebSocket upgrade for session handshake, maintenance and framing, the specification containing low level details that users would expect from such a document.

Microsoft has submitted their proposal during the IETF 83 meeting that took place in March. They have also implemented an open source proof of concept prototype allowing developers to evaluate the HTTP Speed+Mobility proposal. The code is available on GitHub.

It remains to see what the industry will choose to implement. According to the IETF Standards Process, “a specification undergoes a period of development and several iterations of review by the Internet community and revision based upon experience, is adopted as a Standard by the appropriate body... and is published.”

Related resource: HTTPbis Working Group Start To Consider HTTP/2.0.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

SPDY is a session protocol by Ilya Grigorik

Abel, great writeup! Just a quick note on SPDY proposal: it is sometimes pitched as a replacement for HTTP, but that is not the right way to look at it. SPDY is a session level protocol, and HTTP is layered directly over it (application protocol). As such, the semantics of HTTP are not "broken" in any way. In fact, if you open up Chrome and navigate to chrome://net-internals#spdy you'll see the actual frames flowing back and forth and spot the very familiar "HTTP 1.1" headers in there.

Re: SPDY is a session protocol by Abel Avram

Ilya, yes, SPDY runs on top of TCP at the session level. IETF intends to include it in HTTP 2.0 which will supersede HTTP 1.1, remaining backwards compatible.

stability and less resource by songrit leemakdej

http is very unstable yet consume too much resource.
p2p features such as ability to connect from nearby peers and retries should be considered for added robustness for such a crucial protocol.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT