HTTP/2: The Long-Awaited Sequel

Ready to speed things up? Here at Microsoft, we’re rolling out support in Internet Explorer for the first significant rework of the Hypertext Transfer Protocol since 1999. It’s been a while, so it’s due.

While there have been lot of efforts to streamline Web architecture over the years, none have been on the scale of HTTP/2. We’ve been working hard to help develop this new, efficient and compatible standard as part of the IETF HTTPbis Working Group. It’s called, for obvious reasons, HTTP/2 – and it’s available now, built into the new Internet Explorer starting with the Windows 10 Technical Preview.

Why is Internet Explorer leading with HTTP/2 implementation?

Performance matters in an increasingly real-time and mobile world – even gains that may seem merely incremental make a difference. For instance a Bing study found that a 10ms increase in page load time costs the site $250K in revenue annually; a 100ms increase – that’s a third the speed of the blink of the human eye, mind you – undid three months of work that went into improving user engagement via better search results relevance. That 100ms delay in the responsiveness of a transactional web page has been shown to cost big online retailers up to 1% of sales due to search abandonment. So what this working group is doing has real economic impact.

What is wrong with what we had yesterday?

For the most part, the way a Web page gets loaded today happens pretty much the same way it did in the days of 800x600-pixel displays. Certainly the web is a faster place today, but it could be much faster and much more resource efficient.

Building a page today still requires a lot of individual queries between the browser and the server, and each individual call has to wait until the server responds before sending the next. Sure, you can open more independent, parallel connections, but this still limits how many items can be requested simultaneously. It also dictates the order of the responses and prevents the server from optimizing responses.

So how is HTTP/2 different?

HTTP/2 delivers the Web page elements quicker and more efficiently, taking advantage of all the available bandwidth. With long-lived connections and multiplexing (the protocol’s ability to combine multiple requests on one connection), more web page items arrive sooner. Experimental HTTP/2 features such as server push and request dependencies could further improve web performance in the future.

What does this mean for developers?

HTTP/2 was designed from the beginning to be backwards-compatible with HTTP/1.1. That means developers of HTTP libraries don't have to change APIs, and the developers who use those libraries won't have to change their application code. This is a huge advantage: developers can move forward without spending months bringing previous efforts up to date.

What about networks? And security?

Fewer and less frequent connections also means that HTTP/2 will put less pressure on the network – and when you consider the scale of the web today, that could significantly increase the efficiency of networks, particularly mobile ones. Given HTTP/2’s efficient connection model, the performance impact of adding TLS to a site will be lessened, opening up the opportunity for more administrators to add TLS to their sites.

SPDY was a good starting point for the HTTP/2 standard, but it is an experimental protocol that does not lend itself to long-term adoption. With the development of HTTP/2, we will remove support for SPDY in all future versions of IE. Web sites and applications currently using SPDY should be able to migrate to HTTP/2 with little or no changes.

The Technical Preview has HTTP/2 server support also. This means you can create sites in IIS and test your content end to end. Note: in the Technical Preview versions of both IE and IIS, non-secure connections (i.e. HTTP) are not supported on HTTP/2; only secure connections (i.e. HTTPS) are supported on HTTP/2.

Check out our HTTP/2 implementation and put it through its paces! Let us know if you have feedback via @IEDevChat or Connect.

Is HTTP/2 unblocked for use by non-IE WinINET/URLMon/WebOC consumers, or is it (like SPDY before it) limited to only Internet Explorer itself? Should we expect to see HTTP/2 support in WinHTTP and System.NET?

Does WinINET's implementation support upgrade to HTTP/2 via any mechanism other than ALPN?

The F12 Tools don't really show "HTTP/2 packets" do they? Do they show any information about how the response was delivered? Whether Server Push was used? Or any other HTTP/2 data other than a simple notation that the protocol was used?

So, it's something that developers "just get" in Windows 10 – no code changes, no explicit changes to any configuration files or property settings, etc.? IOW, if it's there, we get the benefit, without having to think about it?

What I got out of this is "we will remove support for SPDY in all future versions of IE", which makes sense considering that a lot of SPDY development happened at that one search engine company. Of course, they'll upgrade their stuff to HTTP/2 as well, since this is a new standard. It's just nice to be able to take credit for launching us into the future when other people did the work to bring us there.

That's akin to… wait, what does an approximation in a range of 300ms have to do with constants. Ooof, the internet.

Since you said "about 100-400", it might be said that any time between 33ms and 133ms would be "about right". But since you don't provide any samples, who's to say the mean isn't 300ms. But then what would that really indicate anyway? Certainly nothing definite, so "cannot be true" is blatantly false.

Ohhhh, maybe what you were trying to say is that the exact value should have been stated as One over Pi of a blink of an eye? That's precision. Well, it's absolutely sing-song'y and perfectly rhymed for sure.

@Brenno: Yes, HTTP/2 includes all of the meaningful features of SPDY, and all vendors will move from SPDY to HTTP/2 at some point.

If you look at the Windows 10 preview, you will find that it no longer advertises SPDY support with ALPN or NPN, which means that it cannot negotiate SPDY connections. You can further verify this by visiting sites like Facebook and Twitter, which used SPDY when loaded in IE11 on Windows 8.1.

@B. Clay Shannon: If you're a server operator, you need to have a HTTP/2 capable server or front-end; likely all of those that support SPDY will release updates to support HTTP/2 in the future. If you're a client developer, you get HTTP/2 "for free" in IE on Windows 10; as I remarked in my first comment, it's not clear whether you get HTTP/2 support if you're calling WinINET/URLMon/System.NET/WinHTTP directly or using the Web Browser control in your applications. They've also not stated how/when this functionality will come to Windows 7.

Good job, well done IE team! I'm wondering: what about support for HTTP/2 in Apache HTTP Server (httpd)? This, together with IE support for the new protocol, will really push the adoption rate… having HTTP/2 support on IIS only won't cut it for many SMB…

@ EricLaw: No – WinINet interface supports HTTP/2 but requires opting-in. HTTP/2 is on by default for IE. HTTP/2 is on by default for WWA & Webview. Other Webplatforms off by default. WebOC off by default, opt in via FCK.

Long term we hope to expand support to WinHTTP and System.NET.

We support the HTTP/2 spec which means ALPN only.

Let us know what kind of information you think would be useful in the F12 tool?

HTML/2 is not yet a standard; won't be proposed until December. It is a way of allowing a server to download whatever it wants to download onto my system without explicit requests from the browser. There are obvious security issues including forcing the browser to accept tracking mechanisms and scripts that I now have no way of stopping. No third-party endpoint security software is set up to handle HTML/2 responses. So the question is: How do I turn this crap off?

Great news! Will there be a way to detect which protocol was used from JavaScript? Chrome has this: window.chrome.loadTimes().wasFetchedViaSpdy for the base page. It would be helpful if this was made available for both the base page as well as page assets.