IETF has discussed the future of HTTP, and the next version is to be using SPDY as a starting point. There is a controversy though: Microsoft claims SPDY is no better than HTTP/1.1 with all optimizations turned on, while SPDY’s inventor says Microsoft’s tests actually confirm SPDY’s advantage in a real world scenario.
The IETF HTTPBIS Working Group met in Vancouver this month to discuss the future of HTTP/1.1 and HTTP/2.0. The meeting centered around a proposed new charter, establishing future actions to be taken regarding both versions of the protocol:
HTTP/1.1
- The RFC2616, the IETF document defining the HTTP/1.1 protocol, will be updated to clarify any misunderstandings and to remove ambiguities that negatively affect interoperability
- Remove or deprecate features that are not widely used
- Add implementation advice
- Document security – authentication, cookies, TLS
There won’t be an HTTP/1.2, the changes will be part of HTTP/1.1 as clarifications.
HTTP/2.0
Some of the most important decisions made were:
- The new version of HTTP will retain the semantics of HTTP/1.1 in order to be able to convert a HTTP/2.0 request into HTTP/1.1 and back
- HTTP/2.0 will have a new not-yet-defined syntax
- HTTP/2.0 will use the SPDY Draft as a starting point
- HTTP/2.0 will be able to use other transport protocols than TCP
- HTTP/2.0 should be significantly faster than HTTP/1.1
- HTTP/2.0 should consume less network resources, such as sockets
The working group will propose a draft version of HTTP/2.0 in September of this year, and the completion of the standard is targeted for November 2014.
Regarding SPDY, Mark Nottingham, Chair of the HTTPBIS Working Group, wrote:
It’s important to understand that SPDY isn’t being adopted as HTTP/2.0; rather, that it’s the starting point of our discussion, to avoid a laborious start from scratch.
Also, Adalberto Foresti, editor of the HTTP Speed+Mobility at Microsoft, wrote in a post:
The group agreed that seven key areas need deep, data-driven discussion as part of the HTTP/2.0 specification process, and the resulting standard will not be backward compatible with any existing proposals (SPDY, HTTP Speed+Mobility, and Network-Friendly HTTP Upgrade).
We asked Nottingham what will happen with SPDY installations if HTTP/2.0 won’t be backward compatible with SPDY, and we received this response:
I think everyone expects them to go away; all of the folks advocating SPDY have made it very clear that it's an experimental protocol.
Regarding the fate of current SPDY installations, Mike Belshe, SPDY Inventor and editor of the SPDY protocol, said in a conversation with InfoQ:
Assuming HTTP/2.0 is as-fast or faster than SPDY, Chrome & Firefox will drop SPDY after some grace period. The sites are still implementing HTTP/1.1, so those sites will still work fine even if SPDY's current form goes away.
Then, if the sites wish to get the speed back, they'll need to upgrade to HTTP/2.0. All in all, there will be no disruption in service for users. But its a bit of a transition for web sites.
Foresti also downplayed SPDY’s importance, saying that in their tests SPDY showed the same performance as HTTP/1.1 with all optimizations turned on:
To compare the performance of SPDY with HTTP 1.1 we have run tests comparing download times of several public web sites using a controlled tested study. The test uses publically available software run with mostly default configurations while applying all the currently available optimizations to HTTP 1.1. You can find a preliminary report on the test results here:http://research.microsoft.com/apps/pubs/?id=170059. The results mirror other data (http://www.guypo.com/technical/not-as-spdy-as-you-thought) that indicate mixed results with SPDY performance.
Our results indicate almost equal performance between SPDY and HTTP 1.1 when one applies all the known optimizations to HTTP 1.1. SPDY's performance improvements are not consistent and significant. We will continue our testing, and we welcome others to publish their results so that HTTP 2.0 can choose the best changes and deliver the best possible performance and scalability improvements compared to HTTP 1.1.
We asked Belshe to comment Foresti’s affirmation:
The Microsoft results confirm SPDY's speed advantage. I'm also really excited to see Microsoft actively testing the protocols!
Microsoft's test was reasonable: they wanted to know if SPDY was better than pipelining & content-minification. In the end, they concluded, "judicious use of existing and well-understood optimizations such as pipelining and minification can bring HTTP’s performance close to that of SPDY"
I basically agree with that - but it forgets to mention that their 'solution' is non-deployable on today's internet.
The big problem is that the test compares SPDY to pipelining. Pipelining was standardized as part of HTTP/1.1 over 12 years ago. But it has never been deployed by a major browser. Why not? Because it simply doesn't work - its not deployable without subjecting users to random hangs and stalls. Late last year, the Firefox team revived an effort to try to make it work, but have put that on hold to work on SPDY instead. There are too many problems with pipelining to enumerate here, but feel free to ask the Firefox team too.
Second, the way this test was constructed didn't leverage multiplexing. A significant advantage of multiplexing over pipelining is that while pipelining "blocks" during server processing time of each request, multiplexing does not. But in this test, they cached all the files and replayed them statically, creating a zero-latency server processing time. This type of lab testing is fine for many cases, but for comparing SPDY and pipelining, its a no-no. If we had no server processing time and no packet loss and no queuing delays, the needs for multiplexing are substantially less. Under the MSFT test conditions, I'd fully expect a good pipelining implementation to be faster than SPDY.
Overall, its an academic paper only and has little relevance to the real world. It does confirm that SPDY is faster than HTTP, and it does confirm that SSL is expensive. But pipelining is a non-starter. If it were deployable, it would be running in Chrome, Firefox, and IE long ago.
Firefox implements pipelining but it is turned off by default, the issue being discussed at least since 2004 as this Mozilla bug shows. According to entries in this bug, some people have run Firefox with pipelining turned on for years without having any problems, while others had serious site crashes. That’s why pipelining has not been turned on by default yet. A Mozilla zine, Network.http.pipelining, contains more details on this issue.
There have been some attempts to test HTTP pipelining in Chrome lately, with 10% of the Chrome Dev Channel turned on by default, as this Chromium issue shows, but the issue has been closed by now. HTTP Pipelining is still turned off by default in the official build of Chrome 21.
As a conclusion, while HTTP/2.0 may start from SPDY, it is not known what the final version will be. While current installations of SPDY provide a speed improvement over non-pipelined HTTP/1.1, those servers will need to be upgraded to HTTP/2.0 when the standard is stable if they are to benefit from it.
Previous related posts: SPDY versus WebSockets? and HTTPbis Working Group Start To Consider HTTP/2.0.