“SPDY does not clearly outperform HTTP over cellular networks” [pdf]
conferences.sigcomm.org
conferences.sigcomm.org
HTTP remains pretty simple, and SPDY doesn't replace it - it's essentially a wrapper around HTTP. That said, you're correct in that it requires an additional layer, and that it's no longer plaintext. It will require additional debugging tools, but I'm not convinced that's actually a problem.
http://research.microsoft.com/apps/pubs/?id=170059
There hasn't been a single publication by Google that hasn't been fundamentally flawed, for instance comparing SPDY to HTTP without pipelining (all their claims) or leaving out the TCP handshake for SPDY but including it for HTTP (their claims for mobile).
There are a ton of unsubstantiated claims that followers just repeat without analysis, for instance "head of line blocking" across several connections is not a problem that needs to be solved.
SPDY was designed largely by one recent college grad. That isn't the way to design a protocol to replace HTTP because no matter how smart they may or may not be they don't have the experience to do a good job. Take for instance the compression not being secure... this attack was known to experts at the time SPDY was developed and should have been avoided.
Head of line blocking is so well documented that there are many common web performance techniques to get around it, like domain sharding: http://www.stevesouders.com/blog/2009/05/12/sharding-dominan.... It'd be very interesting to see where you get your data that head of line blocking is not a problem.
I'm not sure where you are getting your info that SPDY was designed largely by one recent college grad. I don't think of Mike Belshe and Roberto Peon as the same person, much less recent college grads :) Maybe 40+ year olds still counts as "recent"?
On your first link, note the "in chrome". Pipelining works great in Firefox, Opera, Android Browser, but Google has only ever tested with Chrome. In fact, probably the reason they didn't test pipelining in mobile Chrome was that it did not even support pipelining at the time. Google never went back once Chrome (kind of) supported pipelining.
Microsoft actually tested pipelining and found with it that HTTP was basically equivalent to SPDY in performance. Read the paper. And with an unoptimized pipelining implementation.
The page you link to provides a lot of hand waiving like about incompatibilities, but this is actually completely beside the point of whether the complication in SPDY actually improves anything. If you come up with a new protocol just to overcome bad proxies you can just as well have HTTP/1.2 that is exactly the same as HTTP/1.1 except pipelining works; incompatible proxies will only support HTTP/1.1 and the browser can disable pipelining (or some similar solution).
EDIT: apparently the main SPDY guy is older than I thought. The point stands however that having one or two people design a protocol to be used by the whole internet is a bad idea.
As for pipelining working great in those browsers, you should note that no major desktop browser uses pipelining. Firefox does not enable it by default. See the Firefox bug thread where it's explained why it's not on by default, and also identifying its head of line blocking issues: https://bugzilla.mozilla.org/show_bug.cgi?id=264354#c30.
Microsoft did test pipelining. In their theoretical lab network, with ideal situations, they can match SPDY performance. But the sad reality is that real websites and networks don't match that. Please see http://www.guypo.com/technical/http-pipelining-not-so-fast-n.... And you have to ask yourself, if Microsoft really believed that result, why don't they enable pipelining in IE?
It's fascinating to me that you still seem to hold onto your claims that HTTP pipelining is feasible in real networks, even though IE, Firefox, and Chrome developers have all clearly tried and given up on it.
As a developer you never deal with SPDY. You just deal with HTTP and HTTP headers. SPDY is just a configuration option in your web server. There is no complexity to deal with, it just works.
SPDY is a replacement (or, in the inevitable future where http/2.0 effectively is spdy, an upgrade) for http. There is no way to write an http client or server without wildly divergent code paths.
* Note: When I say client or server I mean at a low level. I don't mean an app server running on a library that implements the http part.
There are a lot of security and DOS concerns that you have to worry about when exposing a server to the public Internet - it's usually best to let mature software handle that and proxy to your custom stuff, particularly when the mature software is already open-source.
It's entirely reasonable to ask if complexity is worth it on every level. Many of the greatest successes of internet protocols have come through making things as simple and modular as possible. This doesn't mean SPDY is terrible necessarily, but "no one ever needs to work with it" is a clearly wrong answer to a criticism that it's overly complex.
Perhaps there are simpler solutions to the problem, but if they make things slower for end-users, that's inconveniencing millions to save effort for dozens, which is not a particularly good trade-off.
> However, we have measured as much as a 30% decrease in latency in the wild for API requests carried over SPDY relative to those carried over HTTP.
> In particular, we’ve observed SPDY helping more as a user’s network conditions get worse.
Either way, security at the application level on the Internet seems quite broken. We need easy to implement strong security at the Transport and IP levels. Google (or IETF, rather) should be experimenting with a CurveCP-like protocols to encrypt all the packets on the Internet to replace TCP. That's what I'd really like to see.
The former is generally more performant that HTTP, and the latter also offer benefits versus other options.
They're just google doing what Microsoft did in the 1990s, setting their own proprietary 'standards' instead of working to improve things.
This is dangerously wrong, for two reasons:
1. These are open standards. They're not proprietary. 2. What is "improving things" if not proposing open, alternative standards which solve existing problems?
WMA over MP3, WMV over AVI.
Too bad that it looks like it's going to be accepted, but that's a different issue alltogether (yeah. I don't like where HTTP/2.0 is going, but I can only "blame" the IETF, not Google).
Microsoft back then had no intention of submitting their changes to any standards body and was actually using patents and copyrights to ensure that it was difficult to impossible to reimplement their changes.
The whole process had the feel of a sham. SPDY should have evolved as its own protocol, continuing under the spdy name, and http/2.0 should have simply evolved to a semantically-driven protocol with standard negotiation mechanisms for choosing the wire protocol (which could be the MIMEish thing we have now or SPDY). This would have been a good way to ensure the web has a solid upgrade path.
It's the whole kit and caboodle when it should have been broken up into clean modular pieces: framing layers, protocol layers, semantic layers. QUIC or other hopefuls trying to break from the mobile-horror-show that is TCP are left with nothing to start from, and HTTP/2 docs devolve into a commingled big-ball-of-mud as it hops from low level aspects to higher level aspects.
The other part of your argument is based on the fact that it's a binary protocol which makes it less intuitive and impossible/hard to debug when something goes wrong. This is indeed a trade-off chosen by SPDY that makes sense for a lot of the use cases: you're optimizing the protocol for computer, not for humans. You'll need additional debugging tools to find out what's wrong in exchange for better performance.
It's a documented binary protocol, is open and reasonably easy to understand - spdyshark will help.
It's in use in significant capacities on the most-tracked websites with impressive results you are welcome to easily see for yourself firsthand on your own server. More browsers than Chrome support it. More than one popular server supports it, with Nginx bundling it. CDNs are getting on board. Etc. This is the first somewhat-negative article I've run into about it.
That Google keeps working on it and releasing new drafts rather than kicking back and leaving it alone for the sake of creating an appearance of maturity, tabling better ideas they come up with for later, I don't think is a sign of lack of maturation, rather a sign that the demand for SPDY and improved performance is strong because people are finding out it's helpful and that Google can be relied upon further to make the web faster.
Second, WebM is actually open source, not proprietary.
Where QUIC may come into it's own is as as a replacement protocol for things like WebRTC.
It's Google who is promoting it and all the "hip" hackers will rally for its cause.
That's something that can be worked on and indeed there's a recommendation for improving it. I'd hope something like this would be included in HTTP/2.0, or at least in a subsequent revision.
[1] Basically, the test was: will one web-request (including all of Google's tracking headers) to google.com or any of its adwords/analytics beacons exceed one TCP packet and cause possible TCP reassembly-issues or not when using regular consumer-grade DSL MTUs?
> P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&a... for more info."
I can't believe they're still adding that...
Implementers such as AGL are bypassing the WG, choosing to emit I-Ds and implementing and deploying because there is little to be gained from WG discussions. This is not necessarily a bad thing, but it does raise a question of whether what is good for Google is good for the Web as a whole
[2]:
If, a few years ago, Microsoft did the same thing I have no doubt what the public reaction would be.
Sadly, a lot of people still consider Google "don't be evil" heroes of the Internet, despite everything we've seen and heard. The brand loyalty is quite impressive.
[1] http://www.ietf.org/mail-archive/web/tls/current/msg10598.ht... [2] http://www.ietf.org/mail-archive/web/tls/current/msg10616.ht...
Thanks for lowering my bounce by the way..
a) QUIC makes headway on its own, delivers significant perf win, moves to IETF and becomes a standalone protocol in the long run. b) TCP and TLS leverage techniques & lessons learned from QUIC.
Either way, the users will win. It's too early to tell which of these paths it'll take.. But I do know that both TLS and TCP groups are paying close attention to QUIC and there are already discussions on how to improve performance based on some of the ideas being prototyped in QUIC.
The research question (sort of): Is SPDY, which was designed to make HTTP work better on connections with more bandwidth and not worse on less bandwidth, increase performance on connections with less bandwidth (and not really related more latency)?
Their answer (sort of): no, as designed SPDY only increases performance on connections with more bandwidth, and performs similar to HTTP on smaller bandwidths.
Their conclusion (sort of): TCP is not very suitable for transmitting data on high bandwidth (relatively) high latency connections, we should use a different transport layer protocol.
What your reaction should be (sort of): No shit sherlocks, that's exactly what everyone thought 15 years ago and only now the idea is picking up steam, with HTML5 including SCTP in the spec, and Google working on the QUIC effort.
First, the results aren't obvious (nor the underlying reasons). In fact Google published results a couple of years ago that got massive amounts of coverage suggesting the opposite (http://googledevelopers.blogspot.com/2012/05/spdy-performanc...). I've worked on TCP optimization of mobile networks for the past 3 years, publicly criticized Google's study when it came out, and still the results of this paper are somewhat surprising to me.
Second, the underlying issue isn't the latency or the bandwidth of the cellular connection. It's the unpredictability. In fact, the Google study was using dodgy methodology where they assumed that a cellular connection could be modeled simply by bandwidth throttling + delay.
Third, it's absolutely not true that everyone has been thinking that replacing TCP is the solution, even if its problems in the cellular context have been acknowledged. If anything, the opposite, nobody has been thinking of it as a viable solution before QUIC. The deployment problems have just been too big -- but Google is in a unique position to fix that.
I sort of want to defend that I counted the unreliableness of cellular as lack of bandwidth, but you're right if that's really wanted to say then I should have said it much differently. But do you really find it surprising that in the light of unreliability SPDY would not perform much better than plain HTTP?
To your third point: I wasn't saying everyone said it was a viable idea. Instead I say that only recently, with SCTP in HTML5 and QUIC people are beginning to think it might be a viable idea. But everyone has known for years that TCP just isn't suitable for the modern web, and if only we could, we would have substituted it with SCTP long ago.
Without testing, it's not at all obvious which set of benefits is actually more significant in the real world. But if I'd had to guess, I would have expected a reduction in roundtrips to be the dominant factor. So yes, I'm a bit surprised.
The conclusion I drew from the paper was a little different from "SPDY no faster than HTTP on mobile." My conclusion was "Mobile sucks equally hard for any application layer protocol."
I'm starting to find it curious how virtually every "SPDY doesn't improve things" study implements the same two critical flaws, to the point that it starts to seem conspiratorial.
a) They compare SPDY, with mandatory TLS, with unencrypted HTTP. HTTP needs to go away, and the only valid comparison would be with HTTPS.
b) They implement their test via a non-caching proxy that then proxies request to "top sites". This is identical to the critical fault that the other primary SPDY critical paper makes, because it essentially invalidates the primary value of SPDY (the upstream site becomes the weak link, itself not using SPDY). This is a ridiculous way of demonstrating the strengths or weaknesses of SPDY (akin to declaring a sports car slow by demanding that it drive behind a transport truck), yet this same methodology keeps curiously recurring.
A better analogy for Americans would be Springfield. You can almost just pick one: IL, MA, MO (OH is a bit too small).