SPDY: What I Like About You | Hacker News Reader

SPDY: What I Like About You

bitsup.blogspot.com

211 pointsrobin_reala38 comments

He forgot one: SPDY is a bidirectional protocol, finally asynchronous notifications from server-side can be delivered without hacks such as long-polling or separate connection like websockets. This is long overdue. Huray!

technically cool, and under the hood an improvement, but end users won't notice anything different. Comet and websocket work just fine.

I'm more interested in browser developments that mean you can do stuff you couldn't before - access to geolocation/multitouch/sound/webcam etc.

End users might not notice speed improvements, but they do respond to them, according to the data.

SPDY vs comet may be noticable if you're doing a real time game or something. But SPDY vs websocket should be the same.

I'm just saying, it's not "wow you can now do X you couldn't before". It's "Oh they made X a bit faster"

SPDY also speeds up ordinary page loading.

WebSockets do not work "just fine." Please don't use them.

You're going to have to give us more than that to go on. Like, you know, an actual downside to using WebSockets?

The WebSockets standard is not finalized. Everybody deploying today is deploying a draft which is subject to change.

There is no single version of WebSockets which all browsers support. Firefox is not currently shipping WebSockets, but MozWebSocket, which is subtly different and also named differently to discourage usage. They don't want people doing WebSockets. (Aside: Try finding a Moz employee willing to talk about WebSockets. None are listed on the work page in their wiki.) Chrome ships the supposedly-insecure Hixie-76. Which is also HyBi-00. Which leads to...

WebSocket's versioning is somewhere between misleading and nonexistent. Many deployed versions predate the versioning header, so they have to be detected ad-hoc. The version in the protocol isn't always bumped with every new draft that comes out.

The protocol tries so very hard to be HTTP, but can't always cross proxies. This is really only important because (a) long-polling and Comet can easily cross proxies and (b) WebSockets aren't HTTP. It's less code to write a non-HTTP WebSockets server than to bolt one onto an existing HTTP server.

WebSockets security is non-existent. There is no WebSockets protection against proxy attacks, and there is no same-origin policy, so there is nothing stopping an attacker from opening a WebSocket to an unfriendly domain. No security advantage over boring plain sockets. (To their credit, WebSockets do specify SSL/TLS interaction.)

There are more issues, but that's what comes to me from memory after spending the better part of a year caring about these damn things.

An anecdote: About a month ago, just to experiment with websockets I built a tiny app using Tornad. I spent a long time trying to figure out why it didn't work before I realized that the latest versions of Tornado and Chromium spoke different versions of the web socket protocol. When Tornado 2.1 came out, the app started working.

I, and thousands of my users, use them fine every day thanks.

The same can be said of many of the other remarks in the article. You could even say it is elegant that SPDY only changes things under the hood, and keeps the good parts of HTTP.

SPDY is technically very cool. It's the update of HTTP that was way overdue. I didn't even mention end-users. Not only the user-facing parts of technology are important.

I've been playing around with asynchronous notifications to the browser for more than 10 years, when I wrote a simple html/js-based continuously loading chat. I've seen it all, from polling, comet, flash-based TCP, longpoll, to finally websockets. So for me it's great to finally see server push taken seriously as part of the spec and not sewn on as a third leg :-)

Sure. Same here. I was writing js chat and realtime games back in '99.

Don't get me wrong, SPDY is cool and good to see. But users won't notice any real difference. It's like when someone re-does a flash game in HTML5 and we (as geeks) go 'wow awesome', and non-geeks go 'uh? so what'

Except that it's faster, more secure and less prone to bugs caused by poor implementations of comet and other long polling techniques.

The non-geeks do notice. They notice when things don't work on their iPads. They'll notice as security and TLS become a larger and larger focus, and mobile users should appreciate the lower header overhead.

Another thought would be simply that if SPDY makes it more attractive/easier/secure/efficient for developers to implement push, then users will benefit simply from it being included in more apps.

I look forward to SPDY support in Firefox. Now web server software needs to keep up.

It took me (years?) to upgrade from Firefox 3.x to 6, but then only a week to upgrade to 7.

6 to 7 was seamless and added handy features - so I am changing my mind on the rapid release schedule as long as extensions aren't broken (often).

(7 is in release candidate build 2 already, give it a shot - it feels insanely fast)

"It took me (years?) to upgrade from Firefox 3.x to 6, but then only a week to upgrade to 7."

It's just numbers, they dont mean much.

Yeah but they used to mean something which is hard to unlearn.

Now I just mentally shift them to the right so they are minor version numbers in my head:

ie. 1.6 1.7 1.8 etc. and then I can deal with it.

But 3.x to 6 is a big jump. Took me an entire weekend of fiddling, tweaking and lots of googling and research to replace extensions and get everything just right.

Yeah, I wish the numbers didn't matter. I love that Chrome auto updates and I never see an extension update dialog box pop up. I love that I don't have to hack XPI zips to change the manifest to allow installation (the instructions for getting Firefox to ignore version checks are no longer accurate for the latest version).

I think they're working on the new extension framework to allow reboot-less installs, etc, but their extension developers aren't adopting them quickly enough.

One thing I dislike about SSL (and SPDY by extension) is that it destroys shared caching. My college has a transparent Squid proxy which they use to block Rapidshare/Megaupload, but also to cache static content, and it does speed them up significantly (latency to the US can be a bitch sometimes).

I guess the upsides make up for it, but I have a feeling we wouldn't need CDNs so badly if HTTP caching was used at ISP level.

But if they knew what's being requested, then the privacy would not be a part of the system. Unless the whole request was preceded by some signed hash of the request+headers that the cache could use for identification... Then again by doing mitm you could maybe poison the cache with a known content having the same hash (depends on the complexity of solution of course).

That seems to get really complicated quite fast.

Then again by doing mitm you could maybe poison the cache with a known content having the same hash (depends on the complexity of solution of course).

That should be almost impossible; I mean, digital signatures (include PGP) are still considered safe, as far as I know.

What I meant is that if it has to be sent outside of the protected stream, it could be also exchanged with mitm. Unless the hash itself is somehow related to the stream in a visible way. That kind of implementation complexity, rather than the signature/hash complecity.

SPDY is indeed always over SSL, but it requires TLS NPN (Next Protocol Negotiation), making it impossible to implement with older versions of OpenSSL or with any version of the Windows SChannel API.

This doesn't make it a particularly inviting protocol to use. I'd have to switch my entire SChannel layer for OpenSSL on Windows, and probably link statically to the version of OpenSSL with NPN on *nix.

Yep, the problem is that SChannel is part of Windows, so that it will take a new version of Windows to support it. Hopefully they are planning to implement support in Win8.

If your servers support it, and a few major web browsers support it, then SPDY should work for most people. You can always fall back on HTTP, so if 80% of your users speak SPDY, that's a good situation.

There is this thing called Stream Control Transmission Protocol (SCTP) already, which does sort of what SPDY does, without breaking the OSI model. Ie multiple concurrent streams over a single session.

Not sure how it interacts with SSL/TLS thou.

Good luck making SCTP work with the $50 routers that everybody has in their homes. While you're at it, will you convince the rest of the world to switch to IPv6 please?

What has kept SCTP down is the fact that the NAT code would have to be modified to support SCTP connections because they can be multi-homed. That will never happen. So, ironically, once the majority of the world has transitioned to IPv6, SCTP should be theoretically usable to talk to anyone if you're both not behind NAT anymore.

Yeah, but the cheap consumer routers that do not let SCTP through the NAT do not generally let IPv6 through either.

Yeah, this is unfortunately in the same bucket as all the other awesome things we could do if NAT didn't exist :(

Good luck getting everyone to switch from IE6.

SPDY is over port 443 because of network discrimination against unusual TCP port numbers - good luck using an entirely different IP protocol number!

I really like SPDY and welcome including more clients on the bandwagon, but where are the server implementations? Nginx is quite popular as of late but it doesn't plan to implement SPDY any time soon. There is mod-spdy for Apache but it is still experimental and there doesn't seem to be support in IIS or LigHTTPd at all. :(

The server implementations are significantly more difficult than the client implementations. And the client implementations aren't easy.

Among other problems:

* Need an SSL key, which means self-signing, $$, or a monthly update to keep your free key current * Implementing SPDY server-push means explicit dependency lists you currently don't keep * The protocol is young and has changed multiple times * It's binary and hard to test -- it's not always clear where a problem lives

Add up those and "oh, my site is fast enough for what I'm doing" and you get a recipe for no good free server implementations.

Presumably some larger companies are working on it, but they have to justify that (substantial) effort for improvements only the Chrome portion of their userbase ever see.

So at least Firefox supporting SPDY will put more pressure on companies to support it.

For those, like me, that didnt know what SPDY was. http://en.wikipedia.org/wiki/SPDY

Does anyone know how SPDY ensures backward-compatibility? How does an SPDY-enabled browser detect a non-SPDY-enabled server without getting it confused?

The way Chrome achieves this backward-compatibility is by using the SSL Next Protocol Negotiation (NPN) extension during SSL handshaking. When the browser is establishing an SSL session, it mentions to the server that it's willing to speak SPDY (as part of the ClientHello message). If the server also speaks SPDY, it can communicate that fact back to the client. If the client sees that the server supports SPDY, it proceeds to send SPDY messages over the newly established connection once the SSL handshaking is complete. Otherwise, it sends HTTP messages. The cool thing about this approach is that it doesn't add any additional network round trips.

Ah, thanks, I forgot it was all over SSL. I was thinking regular HTTP, which doesn't have a negotiation step before sending the headers.

Reply on news.ycombinator.com