6 ms·

Life beyond HTTP 1.1: Google’s SPDY

204 points by igrigorik 16y ago

simonw 16y ago
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 16y ago
  chrome://net-internals/#spdy
  - deleted 16y ago
    [deleted]
  - snprbob86 16y ago
    Wow! When they removed the "http:// 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 16y ago
      No, this is pure conspiracy theory. :-) The decision to drop "http:// http:// from the display was a UI decision and had nothing to do with the internals. The idea is that the "http:// 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.
- JonnieCache 16y ago
  Wireshark works just fine on OSX. http://wireshark.org http://wireshark.org or brew install wireshark
- throw_away 16y ago
  In terminal: sudo tcpdump -s3000 -X -i en1 port 80 switch to -i en0 if you're using your ethernet, or you have a macbook air.
ck2 16y ago
So wait, if we somehow ran SPDY on our own servers, would Chrome auto-detect it, or is it hardwired to Google services?
- igrigorik 16y ago
  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.html http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-00.htm... Alternatively, there is work on sending an "upgrade" header in your regular HTTP response: http://code.google.com/p/chromium/issues/detail?id=69688 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.
- bmelton 16y ago
  The last bit of the article tells you how you can implement SPDY on Apache with either Ruby or Python. It looks like SPDY-enabled clients check for SPDY implentations first (which fails very quickly if absent) and then fails over to HTTP.
- mbelshe 16y ago
  Yes, its all open, and there are non-google SPDY servers out there already. My own site (you can probably find it) will speak SPDY for you. If you have any trouble, please hop on to the spdy-dev@google.com mailing list for help.
VladRussian 16y ago
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?
henryprecheur 16y ago
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_Protocol http://en.wikipedia.org/wiki/Stream_Control_Transmission_Pro...
- dchest 16y ago
  "Q: What about SCTP? A: SCTP is an interesting potential alternate transport, which offers multiple streams over a single connection. However, again, it requires changing the transport stack, which will make it very difficult to deploy across existing home routers. Also, SCTP alone isn't the silver bullet; application-layer changes still need to be made to efficiently use the channel between the server and client." http://www.chromium.org/spdy/spdy-whitepaper http://www.chromium.org/spdy/spdy-whitepaper
  - henryprecheur 16y ago
    I agree that SPDY would be a "quicker" solution. Just modify the browsers and wait a year or two, and 30%+ of the people browsing the web will have it. SCTP have the nice side effect of improving things like streaming, and games. As for application-layer changes, I don't think it would be too difficult to do, kind of like ipv6 (I don't have anything to back this up, it's just a hunch). SCTP deployment will much longer than SPDY, but SCTP seems to be the "right thing to do". Not only for the web, but for other things that use the network. Internet is not only http:// http://. UPDATE: I just realized that saying that the transition to SCTP will be like IPv6 isn't necessarily a good point for SCTP :-D ... I guess I'm a purist and not a pragmatist.
- drdaeman 16y ago
  Same thoughts. Present-day GNU/Linux should work with IPPROTO_SCTP, it's only Windows who lack the implementation out of the box.
  - deleted 16y ago
drdaeman 16y ago
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 16y ago
  Is there any need today to talk manually to a web server using telnet?
  - drdaeman 16y ago
    I don't know. Probably not, but it's sometimes convenient to do so. Well, I've did so when I had to debug some redirect caching problem with "walled garden" setup. This could also be done with a more specialized software, though, I just happened to use telnet as it was readily available. I also sometimes check server's availability (and overall response correctnes) by telnetting to it. Although, I was just too lazy to set up a tunnel to the LAN they're residing at.
  - HerraBRE 16y ago
    I very frequently use netcat (or openssl s_client for HTTPS servers) to connect directly to a server I am debugging. It could be argued that there is no "need" for this, but I find myself doing it quite frequently all the same. That may have something to do with the fact that I am developing a relatively low-level reverse HTTP proxy tool (PageKite), but I also did it quite a bit when working on more traditional webapps. Once you speak the protocol it's nice to be able to just connect and chat with the server directly. :-) Humans are really bad at speaking binary.
forensic 16y ago
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 16y ago
  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.
deleted 16y ago
[deleted]
trezor 16y ago
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 16y ago
  Also SPDY does everything HTTP does, as seen from the 'upper layers' it looks and acts just like HTTP. Maybe more like HTTPS.
wladimir 16y ago
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 https://bugzilla.mozilla.org/show_bug.cgi?id=spdy
billpg 16y ago
What I don't understand is why having multiple streams inside a single TCP channel is preferable to having many TCP channels.
- guruz 16y ago
  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 16y ago
    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 16y ago
      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.

204 points by igrigorik 16y ago

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 16y ago
chrome://net-internals/#spdy
- deleted 16y ago
  [deleted]
- snprbob86 16y ago
  Wow! When they removed the "http:// 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 16y ago
    No, this is pure conspiracy theory. :-) The decision to drop "http:// http:// from the display was a UI decision and had nothing to do with the internals. The idea is that the "http:// 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.
JonnieCache 16y ago
Wireshark works just fine on OSX. http://wireshark.org http://wireshark.org or brew install wireshark
throw_away 16y ago
In terminal: sudo tcpdump -s3000 -X -i en1 port 80 switch to -i en0 if you're using your ethernet, or you have a macbook air.

ck2 16y ago

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

igrigorik 16y ago
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.html http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-00.htm... Alternatively, there is work on sending an "upgrade" header in your regular HTTP response: http://code.google.com/p/chromium/issues/detail?id=69688 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.
bmelton 16y ago
The last bit of the article tells you how you can implement SPDY on Apache with either Ruby or Python. It looks like SPDY-enabled clients check for SPDY implentations first (which fails very quickly if absent) and then fails over to HTTP.
mbelshe 16y ago
Yes, its all open, and there are non-google SPDY servers out there already. My own site (you can probably find it) will speak SPDY for you. If you have any trouble, please hop on to the spdy-dev@google.com mailing list for help.

VladRussian 16y ago

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?

henryprecheur 16y ago

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_Protocol http://en.wikipedia.org/wiki/Stream_Control_Transmission_Pro...

dchest 16y ago
"Q: What about SCTP? A: SCTP is an interesting potential alternate transport, which offers multiple streams over a single connection. However, again, it requires changing the transport stack, which will make it very difficult to deploy across existing home routers. Also, SCTP alone isn't the silver bullet; application-layer changes still need to be made to efficiently use the channel between the server and client." http://www.chromium.org/spdy/spdy-whitepaper http://www.chromium.org/spdy/spdy-whitepaper
- henryprecheur 16y ago
  I agree that SPDY would be a "quicker" solution. Just modify the browsers and wait a year or two, and 30%+ of the people browsing the web will have it. SCTP have the nice side effect of improving things like streaming, and games. As for application-layer changes, I don't think it would be too difficult to do, kind of like ipv6 (I don't have anything to back this up, it's just a hunch). SCTP deployment will much longer than SPDY, but SCTP seems to be the "right thing to do". Not only for the web, but for other things that use the network. Internet is not only http:// http://. UPDATE: I just realized that saying that the transition to SCTP will be like IPv6 isn't necessarily a good point for SCTP :-D ... I guess I'm a purist and not a pragmatist.
drdaeman 16y ago
Same thoughts. Present-day GNU/Linux should work with IPPROTO_SCTP, it's only Windows who lack the implementation out of the box.
- deleted 16y ago

drdaeman 16y ago

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 16y ago
Is there any need today to talk manually to a web server using telnet?
- drdaeman 16y ago
  I don't know. Probably not, but it's sometimes convenient to do so. Well, I've did so when I had to debug some redirect caching problem with "walled garden" setup. This could also be done with a more specialized software, though, I just happened to use telnet as it was readily available. I also sometimes check server's availability (and overall response correctnes) by telnetting to it. Although, I was just too lazy to set up a tunnel to the LAN they're residing at.
- HerraBRE 16y ago
  I very frequently use netcat (or openssl s_client for HTTPS servers) to connect directly to a server I am debugging. It could be argued that there is no "need" for this, but I find myself doing it quite frequently all the same. That may have something to do with the fact that I am developing a relatively low-level reverse HTTP proxy tool (PageKite), but I also did it quite a bit when working on more traditional webapps. Once you speak the protocol it's nice to be able to just connect and chat with the server directly. :-) Humans are really bad at speaking binary.

forensic 16y ago

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 16y ago
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.

deleted 16y ago

[deleted]

trezor 16y ago

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 16y ago
Also SPDY does everything HTTP does, as seen from the 'upper layers' it looks and acts just like HTTP. Maybe more like HTTPS.

wladimir 16y ago

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 https://bugzilla.mozilla.org/show_bug.cgi?id=spdy

billpg 16y ago

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

guruz 16y ago
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 16y ago
  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 16y ago
    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.