Microsoft published their SPDY proposal today to the IETF. They call it “HTTP + Mobility”. Here are some quick comments on their proposal.
a) It’s SPDY!
The Microsoft proposal is SPDY at its core. They’ve fully retained the major elements of SPDY, including multiplexing, prioritization, and compression, and they’ve even lifted the exact syntax of most of the framing layer – maintaining SYN_STREAM, SYN_RESET, SYN_REPLY, HEADERS, etc.
It’s a huge relief for me to see Microsoft propose SPDY with a few minor tweaks.
b) WebSockets Syntax
When SPDY started a couple of years ago, WebSockets didn’t exist. Microsoft is proposing taking existing SPDY, and changing the syntax to be more like WebSockets. This won’t have any feature impact on the protocol, but does make the protocol overall more like other web technologies.
Personally, I don’t think syntax matters much, and I also see value in symmetry across web protocols. I do think the WebSocket syntax is more complicated than SPDY today, but its not that big of a deal. Overall, this part of the Microsoft proposal may make sense. I’m happy that Microsoft has presented it.
c) Removal of Flow Control
The Microsoft proposal is quick to dismiss SPDY’s per-stream flow control as though it is already handled at the TCP layer. However, this is incorrect. TCP handles flow control for the TCP stream. Because SPDY introduces multiple concurrent flows, a new layer of flow control is necessary. Imagine you were sending 10 streams to a server, and one of those streams stalled out (for whatever reason). Without flow control, you either have to terminate all the streams, buffer unbounded amounts of memory, or stall all the streams. None of these are good outcomes, and TCP’s flow control is not the same as SPDY’s flow control.
This may be an example of where SPDY’s implementation experience trumps any amount of protocol theory. For those who remember, earlier drafts of SPDY didn’t have flow control. We were aware of it long ago, but until we fully implemented SPDY, we didn’t know how badly it was needed nor how to do it in a performant and simple manner. I can’t emphasize enough with protocols how important it is to actually implement your proposals. If you don’t implement them, you don’t really know if it works.
d) Optional Compression
HTTP is full of “optional” features. Experience shows that if we make features optional, we lose them altogether due to implementations that don’t implement them, bugs in implementations, and bugs in the design. Examples of optional features in existing HTTP/1.1 include: pipelining, chunked uploads, absolute URIs, and there are many more.
Microsoft did not include any benchmarks for their proposal, so I don’t really know how well it performs. What I do know, however, is that the header compression which Microsoft is advocating be optional was absolutely critical to mobile performance for SPDY. If the Microsoft proposal were truly optimized for mobile, I suspect it would be taking more aggressive steps toward compression rather than pulling it out.
Lastly, I’m puzzled as to why anyone would propose removing the header compression. We could argue about which compression algorithm is best, but it has been pretty non-controversial that we need to start compressing headers with HTTP. (See also: SPDY spec, Mozilla example, UofDelaware research)
e) Removal of SETTINGS frames
SPDY has the promise of “infinite flows” – that a client can make as many requests as it wants. But this is a jedi mind trick. Servers, for a variety of reasons, still want to limit a client to a reasonable number of flows. And different servers have very different ideas about what “reasonable” is. The SETTINGS frame is how servers communicate to the client that they want to do this.
I’m guessing this is an oversight in the Microsoft proposal.
f) Making Server Push Optional
Microsoft proposes to make server push optional. There is a fair discussion to be had about removing Server Push for a number of reasons, but to make it optional seems like the worst of all worlds. Server Push is not trivial, and is definitely one of the most radical portions of the protocol. To make it optional without removing it leaves implementors with the burden of all the complexity with potentially none of the benefits.
The authors offer opinions as to the merits of Server Push, but offer no evidence or data to back up those claims.
h) Removal of IP Pooling
The Microsoft writeup eliminates connection pooling, but it is unclear why. Connection pooling is an important element of SPDY both for performance and for efficiency on the network. I’m not sure why Microsoft would recommend removing this, especially without benchmarks, data, or implementation details. The benchmarks clearly show it has measurable benefit, and without this feature, mobile performance for the Microsoft proposal will surely be slower than for SPDY proper.
Conclusion
I’m happy with the writeup from Microsoft. I view their proposal as agreement that the core of SPDY in acceptable for HTTP/2.0, which should help move the standardization effort along more quickly. They’ve also raised a couple of very reasonable questions. It’s clear that Microsoft hasn’t done much testing or experimentation with their proposal yet. I’m certain that with data, we’ll come to resolution on all fronts quite quickly.
Mike thanks for sharing your thoughts on HTML + Mobility. This post is very helpful in understanding the differences with SPDY.
One comment I had on regard of “d”, I find the option of “optional compression” useful when debugging issues. I often have to fire up wireshark or other capture tools to see what is happening between a client and server – and compression + ssl makes the debugging super hard. I would love to have the option to disable it on client or server, just temporarily to debug (although the behavior might change).
Of course if wireshark, or other packet capture tools, did the decompression and handled SSL – it will make this option not worth while.
Optional compression or optional security for debugging purposes is just fine. We should definitely invest in more tools to help people debug that way. I have no objection 🙂
Inside of chrome, you can use the about:net-internals to see all the frames (post encryption and post compression) if that helps.
There is also one major difference between SPDY and HTTP S+M as I read it. TLS is optional.
I think optional TLS is great. SSL requires far to much horepower for any of my embedded web servers (arduinos and such). And, more importantly, managing SSL certs is a pain. How can we except users of some fridge with a webserver or other embedded device to acquire and install a valid certificate? Some day in the furture DNSSEC might make this a bit easier, but it will still be hard.
I understand the need to keep ISPs and others from messing with the content and provide end-to-end security. But I like the idea of letting this be up to the content owner, not something being enforced by the protocol.
per.bauer – you are incorrect.
Nowhere in the spdy specification does it require TLS.
I think it should, but, the fact remains that right now it does not.
You do not need to make compression optional in order to do debugging. You can make it mandatory, and each side specifies which compression scheme it uses. The two mandatory-to-implement schemes would be “none” and “deflate”.
If the main objection to TLS being mandatory is handling PKIX certs, then the new public-key-only certificate type (with out-of-band trust) could be mandatory to implement. This still means that the entire TLS stack needs to be used (which may be too much for small devices), but it allows small devices to not need a PKIX validation stack.
Paul –
Your jedi-mind-trick won’t work on me 🙂 Mandatory “none” is the same as optional, but you know this 🙂
There are many examples of “mandatory to implement but optional to use” which have failed and are now basically unusable on the web. Example #1: Pipelining. Example #2: chunked uploads. Example #3: use of absolute URIs in the request.
With specific regard to compression, we know that only about 70% of compress-able content is compressed. The rest is just sad, because it hurts the net, it hurts the users, and it hurts the sites. If we let header compression be optional, I see no reason why it wouldn’t end up like the myriad of mandatory-but-optional features that went before and are no longer usable.
Regarding your objections on TLS – there was a time people said an entire HTTP stack was too much for small embedded devices. It’s just not true anymore. Also – keep in mind you don’t need general CA support for all TLS in embedded devices. Bake in the cert you expect on your server with an infinite lifetime and be done with it. If you’re not worried about authentication (or were otherwise willing to settle with HTTP anyway), you’re done.
At the end of the day, we shouldn’t decide yes-or-no for security based on technical principles for small devices. We should be deciding for security because we think its necessary for users or not. I think it is necessary, and it is clear that when it is optional, too many people don’t know better and opt out – creating the unsecured world we live in now.
Mike
As to SPDY compression, why not to use Snappy, QuickLZ or LZO, which are faster that gzip?
@jerzyglowacki: “It’s faster” has 3 components:
time to compress + time to transmit compressed bytes + time to decompress
There have been a few such comparisons over the years which take into account all 3 factors, but I haven’t seen these for some of the newer compressors you mention. If you have benchmark data, that would be great. Other than that, the only reason is to avoid any patent messes.
@mike: There are some recent benchmarks, like: http://blog.erdemagaoglu.com/post/4605524309/lzo-vs-snappy-vs-lzf-vs-zlib-a-comparison-of or http://code.google.com/p/snappy/source/browse/trunk/README, in which Snappy and LZO performs far beter than Zlib. Snappy is made and used by Google, it’s on New BSD license, LZO is on GPL, but QuickLZ is commercial.
Therefore I suggest to incorporate Snappy into Google Chrome for faster SPDY compression.
Pingback:HTTP Compression use by Alexa Top 1000 | Zoompf