
SPDY: What I Like About You - robin_reala
http://bitsup.blogspot.com/2011/09/spdy-what-i-like-about-you.html
======
wladimir
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!

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

~~~
wladimir
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 :-)

~~~
spokengent
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'

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

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

~~~
FlowerPower
"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.

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

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

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

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

~~~
icebraining
_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.

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

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

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

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

~~~
asomiv
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?

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

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

------
Corrado
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. :(

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

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

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

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

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

