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

61–66 of 66 posts

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

#61

Post by stormbrew »

nostrademons wrote: post #60
stormbrew wrote: post #59

Earlier quoted context omitted.

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

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.

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

#62

Post by nostrademons »

stormbrew wrote: post #61
nostrademons wrote: post #60

Earlier quoted context omitted.

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

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 "n…

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.

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

#63

Post by bsdetector »

hobohacker wrote: post #56
bsdetector wrote: post #51

Earlier quoted context omitted.

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

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.

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

#64

Post by M2Ys4U »

rektide wrote: post #52
ajacksified wrote: post #44

Earlier quoted context omitted.

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

HTTP/2 doesn't prevent us from using lower-level protocols like QUIC, though. HTTP/2 over QUIC would work just as HTTP/2 over TCP

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

#65

Post by hobohacker »

bsdetector wrote: post #63
hobohacker wrote: post #56

Earlier quoted context omitted.

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

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…

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.

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

#66

Post by youngtaff »

dragonwriter wrote: post #47
youngtaff wrote: post #18

Earlier quoted context omitted.

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

Isn't that how SPDY started out?

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.

Post reply on HN