9 ms·

“SPDY does not clearly outperform HTTP over cellular networks” [pdf]

93 points by jsnell 13y ago

lxyu 13y ago
Twitter seems to have an opposite opinion: https://blog.twitter.com/2013/cocoaspdy-spdy-for-ios-os-x https://blog.twitter.com/2013/cocoaspdy-spdy-for-ios-os-x > 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.
justinsb 13y ago
I think QUIC is supposed to address this: http://blog.chromium.org/2013/06/experimenting-with-quic.html http://blog.chromium.org/2013/06/experimenting-with-quic.htm...
- jsnell 13y ago
  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.
- fsiefken 13y ago
  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.
  - gsnedders 13y ago
    Opera Max is meant to be something like that — a generic VPN that compresses all non-encrypted transfers (which are, of course, increasingly infrequent).
- youngtaff 13y ago
  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
  - dragonwriter 13y ago
    Isn't that how SPDY started out?
    - youngtaff 13y ago
      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.
blueskin_ 13y ago
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.
- StavrosK 13y ago
  Saying "instead of working to improve things" means that you think SPDY is not an improvement. Why do you think that?
  - blueskin_ 13y ago
    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.
    - ch0wn 13y ago
      It's a new protocol, what do you expect? Tooling will improve over time.
      - d0ugie 13y ago
        > It's a new protocol, what do you expect? 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.
    - 13y ago
josteink 13y ago
It doesn't matter if SPDY offers and technical improvements or not to our good, robust and lasting protcols HTTP. It's Google who is promoting it and all the "hip" hackers will rally for its cause.
- matthewmacleod 13y ago
  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.
  - josteink 13y ago
    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?
    - username223 13y ago
      If they want to save a bit of bandwidth, how about removing this HTTP header? > P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 http://www.google.com/support/accounts/bin/answer.py?hl=en&a... for more info." I can't believe they're still adding that...
- znowi 13y ago
  Their promotion style is rather interesting [1]. 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.html http://www.ietf.org/mail-archive/web/tls/current/msg10598.ht... [2] http://www.ietf.org/mail-archive/web/tls/current/msg10616.html http://www.ietf.org/mail-archive/web/tls/current/msg10616.ht...
jbb555 13y ago
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.
- matthewmacleod 13y ago
  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.
  - bsdetector 13y ago
    The problem with SPDY is that HTTP pipelining has essentially the same performance as it: http://research.microsoft.com/apps/pubs/?id=170059 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.
    - hobohacker 13y ago
      To your points about pipelining, there's a reason it doesn't get compared. It's not usable - https://insouciant.org/tech/status-of-http-pipelining-in-chromium/ https://insouciant.org/tech/status-of-http-pipelining-in-chr... 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-dominant-domains/ 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"?
tinco 13y ago
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.
- jsnell 13y ago
  You're wrong on all counts. 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-performance-on-mobile-networks.html 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.
  - tinco 13y ago
    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.
d0ugie 13y ago
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? Thanks for lowering my bounce by the way..
- igrigorik 13y ago
  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.
salient 13y ago
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.
- gsnedders 13y ago
  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.
kdot 13y ago
Anyone else find it strange that they tested 3G (UMTS) instead of LTE?
- username223 13y ago
  Not really. If you venture outside major cities, you'll find that a lot of the US runs on 3G at best.
- rprospero 13y ago
  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.
  - dded 13y ago
    That'd be ~120,000 (according to Wikipedia). In case anyone else didn't know that off the top of their head. A better analogy for Americans would be Springfield. You can almost just pick one: IL, MA, MO (OH is a bit too small).
mdwelsh 13y ago
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.
- igrigorik 13y ago
  Some recent SPDYv3 vs HTTPS performance numbers from various Google properties: http://blog.chromium.org/2013/11/making-web-faster-with-spdy-and-http2.html http://blog.chromium.org/2013/11/making-web-faster-with-spdy...

93 points by jsnell 13y ago

lxyu 13y ago

Twitter seems to have an opposite opinion: https://blog.twitter.com/2013/cocoaspdy-spdy-for-ios-os-x https://blog.twitter.com/2013/cocoaspdy-spdy-for-ios-os-x > 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.

justinsb 13y ago

I think QUIC is supposed to address this: http://blog.chromium.org/2013/06/experimenting-with-quic.html http://blog.chromium.org/2013/06/experimenting-with-quic.htm...

jsnell 13y ago
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.
fsiefken 13y ago
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.
- gsnedders 13y ago
  Opera Max is meant to be something like that — a generic VPN that compresses all non-encrypted transfers (which are, of course, increasingly infrequent).
youngtaff 13y ago
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
- dragonwriter 13y ago
  Isn't that how SPDY started out?
  - youngtaff 13y ago
    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.

blueskin_ 13y ago

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.

StavrosK 13y ago
Saying "instead of working to improve things" means that you think SPDY is not an improvement. Why do you think that?
- blueskin_ 13y ago
  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.
  - ch0wn 13y ago
    It's a new protocol, what do you expect? Tooling will improve over time.
    - d0ugie 13y ago
      > It's a new protocol, what do you expect? 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.
  - 13y ago

josteink 13y ago

It doesn't matter if SPDY offers and technical improvements or not to our good, robust and lasting protcols HTTP. It's Google who is promoting it and all the "hip" hackers will rally for its cause.

matthewmacleod 13y ago
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.
- josteink 13y ago
  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?
  - username223 13y ago
    If they want to save a bit of bandwidth, how about removing this HTTP header? > P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 http://www.google.com/support/accounts/bin/answer.py?hl=en&a... for more info." I can't believe they're still adding that...
znowi 13y ago
Their promotion style is rather interesting [1]. 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.html http://www.ietf.org/mail-archive/web/tls/current/msg10598.ht... [2] http://www.ietf.org/mail-archive/web/tls/current/msg10616.html http://www.ietf.org/mail-archive/web/tls/current/msg10616.ht...

jbb555 13y ago

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.

matthewmacleod 13y ago
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.
- bsdetector 13y ago
  The problem with SPDY is that HTTP pipelining has essentially the same performance as it: http://research.microsoft.com/apps/pubs/?id=170059 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.
  - hobohacker 13y ago
    To your points about pipelining, there's a reason it doesn't get compared. It's not usable - https://insouciant.org/tech/status-of-http-pipelining-in-chromium/ https://insouciant.org/tech/status-of-http-pipelining-in-chr... 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-dominant-domains/ 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"?

tinco 13y ago

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.

jsnell 13y ago
You're wrong on all counts. 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-performance-on-mobile-networks.html 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.
- tinco 13y ago
  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.

d0ugie 13y ago

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? Thanks for lowering my bounce by the way..

igrigorik 13y ago
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.

salient 13y ago

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.

gsnedders 13y ago
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.

kdot 13y ago

Anyone else find it strange that they tested 3G (UMTS) instead of LTE?

username223 13y ago
Not really. If you venture outside major cities, you'll find that a lot of the US runs on 3G at best.
rprospero 13y ago
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.
- dded 13y ago
  That'd be ~120,000 (according to Wikipedia). In case anyone else didn't know that off the top of their head. A better analogy for Americans would be Springfield. You can almost just pick one: IL, MA, MO (OH is a bit too small).

mdwelsh 13y ago

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.

igrigorik 13y ago
Some recent SPDYv3 vs HTTPS performance numbers from various Google properties: http://blog.chromium.org/2013/11/making-web-faster-with-spdy-and-http2.html http://blog.chromium.org/2013/11/making-web-faster-with-spdy...