Twitter uses SPDY | Hacker News Reader

Twitter uses SPDY

skitch.com

119 pointsropiku26 comments

Probably using the code for SPDY that they contributed to Netty: http://netty.io/blog/2012/02/04/

Is this the start of a move by more and more sites to support SPDY?

Is there any reason not to support it?

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.

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

Browser support?

Chrome and Firefox both have builds that support it. Also, I believe it gracefully degrades to HTTP if the client does not support it.

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/

[2] http://www.firefox.com/channel

[3] https://hacks.mozilla.org/2012/02/spdy-brings-responsive-and...

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.

I wish browsers could use SRV records in dns so we didn't have to run everything on 80/443. Stupid magic numbers.

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

http://en.wikipedia.org/wiki/Server_Name_Indication says that Chrome on XP supports SNI since Chrome 6.

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

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.

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.

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.

I think the specification is written in a way to not differentiate between SSL or non SSL use.

Sure, but they don't make clear their expectation that SPDY runs over SSL by default.

Is there a rule of thumb or generally accepted thought on the performance increase that would be gained SPDY vs legacy?

Raffi tweeted this last night: https://twitter.com/#!/raffi/status/177616491204714497/photo...

I'd rather have a smaller page: relevant: http://news.ycombinator.com/item?id=3666826

Twitter is the slowest site of all the major sites that I visit (apart from HN). I often open individual twit links, and pretty much every time all I see is the blue cloud background. It easily takes 3 to 5 seconds to load the actual content. (I'm on an 8-Mbit connection, other sites work fine.)

Twitter is slow for me too, but I don't see what this has to do with the discussion here. It seems like you're implying SPDY must be at fault, which doesn't seem likely.

Also if you want to take advantage of SPDY, only Firefox 13 and Chrome/Chromium have it enabled by default.

Reply on news.ycombinator.com