Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

conferences.sigcomm.org

Post reply on HN
Print view View original

51–60 of 66 posts

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

#51

Post by bsdetector »

matthewmacleod wrote: post #15
jbb555 wrote: post #13

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…

The problem with SPDY is that HTTP pipelining has essentially the same performance as it:

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.

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

#52

Post by rektide »

ajacksified wrote: post #44
pilif wrote: post #7

Earlier quoted context omitted.

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…

What don't you like about where HTTP/2.0 is going?

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.

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

#53

Post by mdwelsh »

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.

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

#54

Post by igrigorik »

mdwelsh wrote: post #53

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 re…

Some recent SPDYv3 vs HTTPS performance numbers from various Google properties: http://blog.chromium.org/2013/11/making-web-faster-with-spdy...

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

#55

Post by igrigorik »

d0ugie wrote: post #22

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..

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.

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

#56

Post by hobohacker »

bsdetector wrote: post #51
matthewmacleod wrote: post #15

Earlier quoted context omitted.

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…

The problem with SPDY is that HTTP pipelining has essentially the same performance as it: 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 uns…

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-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-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"?

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

#57

Post by rprospero »

kdot wrote: post #34

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

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.

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

#58

Post by dded »

rprospero wrote: post #57
kdot wrote: post #34

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

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.

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).

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

#59

Post by stormbrew »

FooBarWidget wrote: post #41
jbb555 wrote: post #13

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.

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.

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.

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

#60

Post by nostrademons »

stormbrew wrote: post #59
FooBarWidget wrote: post #41

Earlier quoted context omitted.

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.

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…

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.

Post reply on HN