Speed and Mobility: An Approach for HTTP 2.0 to Make Mobile Apps and the Web Faster


This week begins face to face meetings at the IETF on how to approach HTTP 2.0 and improve the Internet. How the industry moves forward together on the next version of HTTP – how every application and service on the web communicates today – can positively impact user experience, operational and environmental costs, and even the battery life of the devices you carry around.

As part of this discussion of HTTP 2.0, Microsoft will submit to the IETF a proposal for “HTTP Speed+Mobility.” The approach we propose focuses on all the web’s end users – emphasizing performance improvements and security while at the same time accounting for the important needs of mobile devices and applications.

Why HTTP 2.0?

Today’s HTTP has historical limitations based on what used to be good enough for the web. Because of this, the HTTPbis working group in the Internet Engineering Task Force (IETF) has approved a new charter to define HTTP “2.0” to address performance limitations with HTTP. The working group’s explicit goal is to keep compatibility with existing applications and scenarios, specifically to preserve the existing semantics of HTTP.

Why this approach?

Improving HTTP starts with speed. There is already broad consensus about the need to make web browsing much faster.

We think that apps—not just browsers—should get faster too. More and more, apps are how people access web services, in addition to their browser.

Improving HTTP should also make mobile better. For example, people want their mobile devices to have better battery life. HTTP 2.0 can help decrease the power consumption of network access. Mobile devices also give people a choice of networks with different costs and bandwidth limits. Embedded sensors and clients face similar issues. HTTP 2.0 can make this better.

This approach includes keeping people and their apps in control of network access. Specifically, the client remains in control over the content that it receives from the web. This extends a key attribute of the existing HTTP protocol that has served the Web well. The app or browser is in the best position to assess what the user is currently doing and what data is already locally available. This approach enables apps and browsers to innovate more freely, delivering the most relevant content to the user based on the user’s actual needs.

We think that rapid adoption of HTTP 2.0 is important. To make that happen, HTTP 2.0 needs to retain as much compatibility as possible with the existing Web infrastructure. Awareness of HTTP is built into nearly every switch, router, proxy, load balancer, and security system in use today. If the new protocol is “HTTP” in name only, upgrading all of this infrastructure would take too long. By building on existing web standards, the community can set HTTP 2.0 up for rapid adoption throughout the web.

Done right, HTTP 2.0 can help people connect their devices and applications to the Internet fast, reliably, and securely over a number of diverse networks, with great battery life and low cost.

How?

The HTTP Speed+Mobility proposal starts from both the Google SPDY protocol (a separate submission to the IETF for this discussion) and the work the industry has done around WebSockets.

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. The main departures from SPDY are to address the needs of mobile devices and applications.

Looking ahead

We are looking forward to a vigorous, open discussion within the IETF around the design of HTTP 2.0. We are excited by the promise of an HTTP 2.0 that will serve the Internet for decades to come. As the effort progresses, we will continue to provide updates on this blog. Consistent with our other web standards engagements, we will also provide early implementations of the HTTP 2.0 specification on the HTML5 Labs site.

– Sandeep Singhal, Group Program Manager, Windows Core Networking

– Jean Paoli, General Manager, Interoperability Strategy

Comments (14)

  1. As this is the interoperability blog, care to comment on SPDY interoperability with Firefox, Chrome, Apache, Node, NGinx?

  2. Benno says:

    « The main departures from SPDY are to address the needs of mobile devices and applications. »

    In what way for what reasons in particular? I would love to hear more details about this.

  3. DrPizza says:

    Is there any kind of comparison between your proposal and SPDY?

  4. Anon says:

    And where is the actual proposal. I want to read it.

  5. FremyCompany says:

    Any place where we can download the spec?

  6. annonioanaa says:

    heard of SPDY ???? WWHY ON EARTH WOULD YOU DO STH DIFFERENT

  7. WebManWlkg says:

    Could you please have some other developer maintain this page? The one who designed it seems to think 0.86em sans-serif gray on white is readable.

  8. Kevin Swiber says:

    I'm very interested in this initiative.  I'd like to see a technical in-depth post explaining where SPDY falls short and how Speed+Mobility addresses that.  Also, I'm curious if there were attempts to collaborate with SPDY authors prior to pushing this initiative.  If the goal is to make the Web faster, no one disagrees.  Let's pool talent and make it happen.

  9. testman says:

    Do you have already an SPDY+ (aka S&M) implementation for IE or IIS ?

    Chrome is running SPDY & Firefox is on the way, having the feature already on IE will show that IE is still proposing a premium customer experience.

    By the way, please change S&M because it is are really bad name, unless you like bad jokes 😉

  10. Jamesb says:

    FremyCompany: it seems the spec is available on the ietf.org website there: tools.ietf.org/…/draft-montenegro-httpbis-speed-mobility-00

  11. obloch says:

    The proposal can be read and downloaded from here: tools.ietf.org/…/draft-montenegro-httpbis-speed-mobility-01.

    It is important to note that HTTP Speed+Mobility builds on the best parts of SPDY, but also stresses compatibility with existing standards and the needs of small and mobile internet connected devices, specifically battery life in mobile devices.

    @testman, we are definitively planning to provide an early implementation of the specification on the HTML5 Labs site (html5labs.interoperabilitybridges.com), stay tuned.

    – Olivier

  12. SPDY = IE? says:

    Will SPDY interfere with the speed of IE or will it help?

  13. The latest implementable HTTP/2.0 draft can be accessed here – tools.ietf.org/…/draft-ietf-httpbis-http2-04