QUIC could address it, but does not automatically do so. Specifically, it fixes the head of line blocking part of the problem. But it will still have a congestion control mechanism, and could be vulnerable to bogus retransmissions (and unnecessary lowering of the congestion window) from the extreme 3G jitter.
thx, something like that would be great to use over packet radio & gsm. If someone builds a QUIC proxy server service with client to speed up browsing over slow links like Opera does with their always open 'socket' connection we have another choice. The Opera solution is actually quite usable.
I wonder if similar performance gains can be achieved by using openvpn with udp with or without ziproxy. If so you wouldn't be locked to chrome or opera.
Opera Max is meant to be something like that — a generic VPN that compresses all non-encrypted transfers (which are, of course, increasingly infrequent).
My understanding is QUIC is being used as a proof of concept for protocol experiments - it may be pushed towards standardisation or the the lessons from it may be pushed into other protocols
It is but talking to some of the Dev Advocates at Google, they're pretty open that it could go either way - some of the things the QUIC guys have learnt about speeding up TLS negotiations is going information HTTPS stuff (can't remember the exact details)
Where QUIC may come into it's own is as as a replacement protocol for things like WebRTC.
I really don't see the point of stuff like SPDY and WEBP/WEBM. They're just google doing what Microsoft did in the 1990s, setting their own proprietary 'standards' instead of working to improve things.
Because it's a binary protocol without the documentation, intuitiveness, and openness of HTTP. Yes, implementations exist for $whateverWebserver, but most people who add them won't understand the protocol, and can't debug when something goes wrong.
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.
First of all, SPDY is a properly documented protocol -- there are far more "open" protocols that are documented far worse. It's inside Google's interests to make SPDY adoption as widespread as possible, so it makes sense they would properly document it.
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.
One, among many, of Microsoft's 1990's extensions was XMLHttpRequest. Fortunately, although it was (initially) vendor-specific, neither XMLHttpRequest nor SPDY is/was “proprietary” in the IP sense of the term.
The difference is that Google has actually submitted SPDY as a possible basis for HTTP/2.0.
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.
Can't speak for the person you're responding to, but personally, I don't think it makes sense for a semantically-similar but different in wire characteristics protocol to be called http/2.0. Nor do I think spdy has been around anywhere near long enough, nor been adopted organically enough, to justify being rammed through a process that seems to have been started almost specifically to get it that moniker (the call for proposals for the starting point was for less than a year, with only one possibility deployed at all, it was a foregone conclusion).
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 doesn't define high level semantics other such as QUIC can use or build from.
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.
I really don't see the point of stuff like SPDY and WEBP/WEBM.
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?
No, that's not at all like that. First off, they are proposing them to actually be standards, not just proprietary extensions that no one else can use, like Microsoft was doing.
Second, WebM is actually open source, not proprietary.
That's a non sequitur - SPDY shows markedly improved performance over wired and 802.11 networks. The underlying problem discussed in the paper is down to TCP's interaction with cellular networks, and just happens to particularly punish SPDY somewhat more than HTTP.
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.
Since SPDY was created with DSL MTUs in mind[1] and optimized for them only (unlike plain HTTP which was transport neutral and lasted almost 20 years) I don't find it hard to believe that if you look anywhere outside Google's test-matrix you will see the benefits of SPDY tapering away almost instantly.
[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?
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.
I'm not a fan of SPDY at all. HTTP was simple to implement and understand. This is neither. And it matters.
The small gains in performance are not worth the complexity.
Performance improvements are up to a 56% decrease in page load times over 802.11n for one of the websites examined in the paper. That's not small.
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.
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"?
Sharding is because of browsers only opening a few connections to each domain (6 for example). Even with keep-alive the resource on each connection must be finished before sending the next request, so there is a round trip for each resource -- exactly the problem pipelining solves by sending the other requests immediately. This is not "head of line blocking".
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.
Head of line blocking is when something ahead in the line blocks things behind it. If browsers choose to use connection limits, then that means that things ahead in the line and get to use the connections are blocking things behind in line which have to stay queued up waiting for the connections to free up. So yes, that's head of line blocking.
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.
SPDY is just HTTP, just like TLS is. TLS does not replace HTTP: it wraps HTTP. Same thing for SPDY.
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.
I think he was speaking from the perspective of a web-server developer, who does have to deal with the complexities of the protocol implementation. Not everyone gets to be shielded from that stuff.
That may be, but I've often needed to be familiar with the transport layer and all the quirks of how clients and servers handle connections, latency, etc. Only on those mythical "normal days" do I sit back and trust the abstractions completely, ignoring all of the underlying acrobatics.
TLS is not HTTP. TLS is a layer below HTTP and largely a black box to a client or server implementer (as it should be, as it's very hard to get right).
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.
How many people write Internet-facing HTTP servers, though? Usually even if you're writing a webapp framework, appserver host, or HTTP library, you'll stick Nginx in front of it.
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.
How many people write anything? This kind of reductive reasoning would basically leave everyone in the world writing software that can fit nicely in a UML model generator.
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.
I guess my point is that as projects mature, there are usually fewer serious options on the market, and those options do more, and so it makes sense to capture a lot of the complexity inherent in the problem within those few pieces of software rather than force all users of that software (which are numerous) to deal with it.
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.
Why did they take the effort to produce an entire paper, over a research question that has a simple logical answer?
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.
Ah, I did not know Google was actively positioning SPDY as a good solution for mobile networks, I missed 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.
There are factors favoring SPDY, such as fewer roundtrips thanks to pipelining, or header compression removing the uplink as a bottleneck. There are factors favoring HTTP, such as being less vulnerable to head of line blocking, higher effective congestion/receive windows, and a smaller reduction on the effective congestion window from a single packet loss.
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 cited Google paper used a simulated mobile network via USB tethering to a machine with traffic shaping. The AT&T paper used an actual air interface.
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."
SPDY is a significant net benefit for high latency / high bandwidth connections. Indeed, I would say that is its primary strength.
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.
Hey Ilya: Is it possibly in the works to merge QUIC's UDP and magical error correction into whatever SPDY doesn't have that QUIC could complement it with, maybe eventually abandoning QUIC and just going full-force on a further-supercharged SPDY?
Short answer, yes. Longer answer, there are two ways QUIC can succeed:
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.
Isn't SPDY encrypted by default? Why would you assume it should outperform the unencrypted HTTP? Is it because Google made that claim, or why?
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 problem is plenty of boxes (esp. consumer-grade NAT stuff!) drops any IP packet that is not TCP or UDP, hence introducing anything at that layer is as hard as introducing IPv6 (i.e., it might happen, eventually, maybe). This is why Google's QUIC is layered on top of UDP — as UDP is a thin enough layer (on top of IP) it doesn't add too much bloat.
I'm in an American city with a population equivalent to Reykjavik. I spend about 80% of my time on 2G and the remainder on 3G. The number of times I've seen LTE I can count on my fingers.
I did the original study at Google on SPDY over mobile networks, which was a small-scale lab study. Since then, we have collected data from millions of Chrome Mobile users which shows that SPDY does tend to outperform HTTP on cellular, but of course there are many factors involved - the content of the site, the network conditions, etc. I haven't had a chance to get this data into a form that can be shared, which I really need to do. Still, the authors of this CoNext paper did a really nice study. I hope we have more to share on this in the future.
65 comments
[ 217 ms ] story [ 2223 ms ] threadWhere QUIC may come into it's own is as as a replacement protocol for things like WebRTC.
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.
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.
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 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.
Second, WebM is actually open source, not proprietary.
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...
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.
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.
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.
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.
A better analogy for Americans would be Springfield. You can almost just pick one: IL, MA, MO (OH is a bit too small).
> 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.