

Life beyond HTTP 1.1: Google’s SPDY - igrigorik
http://www.igvita.com/2011/04/07/life-beyond-http-11-googles-spdy/

======
drdaeman
Nice, but a bit worrysome. Is such binary protocol a Good Thing?

Ancient people — even though they hadn't much CPU, memory and network
resources — in all their wisdom made high-level protocols text-oriented. Sure,
they didn't consider everything (so we're still haunted with evil spirits of,
for example, UTF-7 and quoted-printable), but overall design was simple yet
perfectly functional. And anyone could use just a telnet client to talk to
HTTP (FTP, SMTP, etc) server. With SPDY you can't do such thing anymore, you
need specialized software.

I'm all for something like "Upgrade: SPDY"/"HTTP/1.1 101 Switching Protocols"
(then binary framed message-oriented protocol goes into effect), but I somehow
worried with binary-from-the-beginnig "HTTP 2.0". Maybe I'm just too
conservative?

(Side question: If we want multiplexing streams so badly, why noone cares
about SCTP? Is it flawed or inappropriate?)

~~~
Ruudjah
Is there any need today to talk manually to a web server using telnet?

~~~
yuhong
I most commonly do it to read the HTTP headers using HEAD.

~~~
gnubardt

        curl -I

is an easy way to do that as well.

It requires fewer keystrokes :P

------
henryprecheur
I don't like SPDY. It's trying to solve a transport problem at the application
level. Plus it seems to be quite complex.

I'd love to see Google promote a transport protocol like SCTP[1], and do HTTP
over SCTP instead. If Google pushed SCTP a little bit, we might see it pop on
Linux and Windows within a few years.

[1]:[http://en.wikipedia.org/wiki/Stream_Control_Transmission_Pro...](http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol)

~~~
drdaeman
Same thoughts.

Present-day GNU/Linux should work with IPPROTO_SCTP, it's only Windows who
lack the implementation out of the box.

~~~
planckscnst
Correct me if I'm wrong, but as far as I'm aware, GNU has nothing to do with
SCTP. Linux supports SCTP.

My non-GNU Linux system talks SCTP just fine.

------
simonw
Whoa, so Google Chrome is now talking SPDY to www.google.com ? I had no idea.

Anyone know a good way of running a packet sniffer on OS X so I can see it in
action?

~~~
mdxch
chrome://net-internals/#spdy

~~~
snprbob86
Wow! When they removed the "<http://> from Chrome, I knew exactly why they
were doing it: to hide the SDPY rollout while simultaneously not breaking copy
paste interop with non-Chrome uses. However, I had _no idea_ they had already
done it! Amazingly clever and effective. I totally saw it coming and then
totally missed it's arrival. Awesome.

~~~
mbelshe
No, this is pure conspiracy theory. :-)

The decision to drop "<http://> from the display was a UI decision and had
nothing to do with the internals. The idea is that the "<http://> is just
user-confusion. Most users can't spell HTTP, much less know why it is there.
Why do we subject our poor users to it? Personally, I don't care.

Chrome does not recognize "spdy://" as a protocol scheme, and the UI display
changes nothing with respect to how chrome selects protocols.

------
forensic
The author is wrong about his HTTP history.

Keep-alive was a feature of HTTP/1.0 and was phased out in HTTP/1.1 in favour
of "persistent connections."

~~~
igrigorik
Hmm, that's good catch - thanks. HTTP 1.0 didn't explicitly specify anything
around persistent connections, so in practice you can add Keep-Alive header
and hope that the server will respect it. By comparison, HTTP 1.1 defaults to
persistent always and requires a "Connection: close" header to indicate
otherwise.

------
ck2
So wait, if we somehow ran SPDY on our own servers, would Chrome auto-detect
it, or is it hardwired to Google services?

~~~
igrigorik
There are several proposed mechanisms to "enable" SPDY. The preferred is to
run over SSL, and to use their NPN extension to negotiate SPDY support:
[http://tools.ietf.org/html/draft-agl-tls-
nextprotoneg-00.htm...](http://tools.ietf.org/html/draft-agl-tls-
nextprotoneg-00.html)

Alternatively, there is work on sending an "upgrade" header in your regular
HTTP response: <http://code.google.com/p/chromium/issues/detail?id=69688>

The NPN route is obviously the best in terms of performance, since the
protocol can be negotiated as part of the TLS handshake..

Long story short: you can definitely run your own SPDY server and Chrome will
auto-detect and use the protocol.

------
wladimir
Does anyone know of plans to build this into Firefox? Sounds like an
interesting project.

Edit: already found it <https://bugzilla.mozilla.org/show_bug.cgi?id=spdy>

------
VladRussian
great thing is that Google has enough gravitational mass to move world in such
direction without many years delay of negotiations inside protocol
specification committee.

Once everybody is onboard, when the license fee will be requested?

------
billpg
What I don't understand is why having multiple streams inside a single TCP
channel is preferable to having many TCP channels.

~~~
guruz
Because setting up a TCP connection is costly in terms of roundtrips/latency.
With SSL inside even more.

Also when you have only 1 connection you might better utilize the bandwidth
you have because of TCP's slow-start algo.

~~~
billpg
I wonder if the better plan would be to insert another layer between TCP and
HTTP (or any app layer protocol) that provides for multiple streams between
the same points.

(If that's exactly what SPDY is, never mind.)

~~~
mbelshe
That's basically what SPDY is. It has two halves, a framing layer (which is
generic), and a definition of how to embed HTTP within that framing layer. In
theory, you could use the framing layer for other purposes, but we designed it
tailor-made for http.

For the original question - HTTP can only send one request at a time. SPDY can
send many all at the same time, avoiding lots of round trips. As a side
effect, it sends fewer bytes and packets too. look for the IETF slides for the
latest data.

------
trezor
The title seems to imply HTTP 1.1 is already dead/abondoned, when in fact
almost _nobody_ except Google is supporting SPDY.

Firefox doesn't support it, but if it's open enough there's a chance they
might add support for it. MSIE support is far away and I wouldn't but any bets
on it being supported any time this year. If SPDY is supposed to be more than
a http-option (i.e. "beyond http 1.1") all clients need to support it. That's
far from the case today.

Given that last time I heard about it was quite some time ago and little has
changed, I would say a better title would be "Http-times: SPDY is still
around, still looking for friends".

Just because it comes out of Google's door doesn't make anything a guaranteed
success and I outside HN's usual Google-praising sphere I haven't ever heard a
single geek mention it. I'm not saying it's dead either, but at this point it
seems to have gathered very little interest and momentum.

~~~
Lennie
Also SPDY does everything HTTP does, as seen from the 'upper layers' it looks
and acts just like HTTP. Maybe more like HTTPS.

