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.
