6 ms·

Is this the start of a move by more and more sites to support SPDY? Is there any reason not to support it?

warp 15y ago
whatever stack you're using, it probably doesn't have very stable support yet. afaik there is no SPDY for nginx, the apache module seems quite experimental, etc.. So, unless you have the chops to fix issues when they come up, you may want to wait a bit until things mature.
- igrigorik 15y ago
  nginx support is in the works and I'm hoping we'll see something public in first half of this year. The apache module also got a lot of love recently, so definitely check it out. Dev wise, probably the biggest hurdle for most people today is simply installing the latest SSL builds for NPN support (usually entails recompiling your favorite language against it as well).
rmc 15y ago
Browser support?
- RobAtticus 15y ago
  Chrome and Firefox both have builds that support it. Also, I believe it gracefully degrades to HTTP if the client does not support it.
- mbrubeck 15y ago
  SPDY has been enabled by default in Chrome for a while. SPDY is enabled by default in Firefox 13, currently on the nightly channel. In Firefox 11 (beta channel) or 12 (aurora channel) [2] it can be enabled with a hidden preference [3]. After Firefox 13 is released in a few months, over 40% of web users worldwide will be browsing with SPDY. (Today the number is already over 25% worldwide thanks to Chrome alone, based on numbers from StatCounter.) [1] http://nightly.mozilla.org/ http://nightly.mozilla.org/ [2] http://www.firefox.com/channel http://www.firefox.com/channel [3] https://hacks.mozilla.org/2012/02/spdy-brings-responsive-and-scalable-transport-to-firefox-11/ https://hacks.mozilla.org/2012/02/spdy-brings-responsive-and...
pilif 15y ago
Aside of the lacking availability of stable servers, another issue is that SPDY runs over SSL exclusively. That means that due to XP's lack of support of SNI, it's still not possible to do name-based virtual hosting. Wasting an ip address for smaller sites is not always opportune or even possible, especially as we are running out of IP addresses.
- aaronblohowiak 15y ago
  I wish browsers could use SRV records in dns so we didn't have to run everything on 80/443. Stupid magic numbers.
- tonfa 15y ago
  > That means that due to XP's lack of support of SNI, it's still not possible to do name-based virtual hosting. I thought Chrome supported SNI on XP, so since it is the only browser with SPDY, there are no problems.
  - mooism2 15y ago
    http://en.wikipedia.org/wiki/Server_Name_Indication http://en.wikipedia.org/wiki/Server_Name_Indication says that Chrome on XP supports SNI since Chrome 6.
alayne 15y ago
Well, it's not standardized yet. A draft was just submitted last month.
- mooism2 15y ago
  The ietf draft confused me by saying spdy runs over tcp, instead of saying it runs over tls over tcp. Probably I am misreading it --- I'm out of practice at reading rfcs, and I expect it would have been all over HN if they were no longer mandating tls --- but I didn't find any language in the current draft that says it runs over tls.
  - bgentry 15y ago
    Upon closer review, you're right in that it's not very clear that SPDY requires TLS. I did find this in section 5, Security Considerations: 5.3. Cross-Protocol Attacks By utilizing TLS, we believe that SPDY introduces no new cross- protocol attacks. TLS encrypts the contents of all transmission (except the handshake itself), making it difficult for attackers to control the data which could be used in a cross-protocol attack. Also interesting is that the language in the Overview makes it seem as though TCP itself is not a requirement and that SPDY can be used over any reliable transport layer such as TCP.
    - mooism2 15y ago
      RFCs generally (or at least "modern RFCs when I was paying attention", which was about a decade ago) don't like to over-specify. e.g. RFC 2068 (HTTP/1.1) includes this paragraph: HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80, but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet, or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used; the mapping of the HTTP/1.1 request and response structures onto the transport data units of the protocol in question is outside the scope of this specification. This makes clear that although you can use HTTP/1.1 over, say Unix domain sockets, and it would still work, and you could still call it HTTP/1.1, they expect it to be mostly used over TCP/IP port 80. The language in the SPDY overview is probably the same sort of thing: making clear that they expect most usage to be over TCP, but allowing you to use something else if you really want to. The TLS issue is probably intended to be the same thing: there's no reason why I shouldn't be able to use SPDY directly over TCP if the connection's between machines in my datacentre. But they don't make it explicit that they expect SPDY to run over TLS in normal use. Perhaps it's careless editing.

warp 15y ago

whatever stack you're using, it probably doesn't have very stable support yet. afaik there is no SPDY for nginx, the apache module seems quite experimental, etc.. So, unless you have the chops to fix issues when they come up, you may want to wait a bit until things mature.

igrigorik 15y ago
nginx support is in the works and I'm hoping we'll see something public in first half of this year. The apache module also got a lot of love recently, so definitely check it out. Dev wise, probably the biggest hurdle for most people today is simply installing the latest SSL builds for NPN support (usually entails recompiling your favorite language against it as well).

rmc 15y ago

Browser support?

RobAtticus 15y ago
Chrome and Firefox both have builds that support it. Also, I believe it gracefully degrades to HTTP if the client does not support it.
mbrubeck 15y ago
SPDY has been enabled by default in Chrome for a while. SPDY is enabled by default in Firefox 13, currently on the nightly channel. In Firefox 11 (beta channel) or 12 (aurora channel) [2] it can be enabled with a hidden preference [3]. After Firefox 13 is released in a few months, over 40% of web users worldwide will be browsing with SPDY. (Today the number is already over 25% worldwide thanks to Chrome alone, based on numbers from StatCounter.) [1] http://nightly.mozilla.org/ http://nightly.mozilla.org/ [2] http://www.firefox.com/channel http://www.firefox.com/channel [3] https://hacks.mozilla.org/2012/02/spdy-brings-responsive-and-scalable-transport-to-firefox-11/ https://hacks.mozilla.org/2012/02/spdy-brings-responsive-and...

pilif 15y ago

Aside of the lacking availability of stable servers, another issue is that SPDY runs over SSL exclusively. That means that due to XP's lack of support of SNI, it's still not possible to do name-based virtual hosting. Wasting an ip address for smaller sites is not always opportune or even possible, especially as we are running out of IP addresses.

aaronblohowiak 15y ago
I wish browsers could use SRV records in dns so we didn't have to run everything on 80/443. Stupid magic numbers.
tonfa 15y ago
> That means that due to XP's lack of support of SNI, it's still not possible to do name-based virtual hosting. I thought Chrome supported SNI on XP, so since it is the only browser with SPDY, there are no problems.
- mooism2 15y ago
  http://en.wikipedia.org/wiki/Server_Name_Indication http://en.wikipedia.org/wiki/Server_Name_Indication says that Chrome on XP supports SNI since Chrome 6.

alayne 15y ago

Well, it's not standardized yet. A draft was just submitted last month.

mooism2 15y ago
The ietf draft confused me by saying spdy runs over tcp, instead of saying it runs over tls over tcp. Probably I am misreading it --- I'm out of practice at reading rfcs, and I expect it would have been all over HN if they were no longer mandating tls --- but I didn't find any language in the current draft that says it runs over tls.
- bgentry 15y ago
  Upon closer review, you're right in that it's not very clear that SPDY requires TLS. I did find this in section 5, Security Considerations: 5.3. Cross-Protocol Attacks By utilizing TLS, we believe that SPDY introduces no new cross- protocol attacks. TLS encrypts the contents of all transmission (except the handshake itself), making it difficult for attackers to control the data which could be used in a cross-protocol attack. Also interesting is that the language in the Overview makes it seem as though TCP itself is not a requirement and that SPDY can be used over any reliable transport layer such as TCP.
  - mooism2 15y ago
    RFCs generally (or at least "modern RFCs when I was paying attention", which was about a decade ago) don't like to over-specify. e.g. RFC 2068 (HTTP/1.1) includes this paragraph: HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80, but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet, or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used; the mapping of the HTTP/1.1 request and response structures onto the transport data units of the protocol in question is outside the scope of this specification. This makes clear that although you can use HTTP/1.1 over, say Unix domain sockets, and it would still work, and you could still call it HTTP/1.1, they expect it to be mostly used over TCP/IP port 80. The language in the SPDY overview is probably the same sort of thing: making clear that they expect most usage to be over TCP, but allowing you to use something else if you really want to. The TLS issue is probably intended to be the same thing: there's no reason why I shouldn't be able to use SPDY directly over TCP if the connection's between machines in my datacentre. But they don't make it explicit that they expect SPDY to run over TLS in normal use. Perhaps it's careless editing.