Hacker News Reader

Comment by jbb555 | Hacker News Reader

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.

View on HN

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.

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.

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

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.

Reply on news.ycombinator.com