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.
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).
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.
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.)
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.
That's just a small selection of the important elements delivered in the single tweet JSON packet. I didn't even get into the 'user' stuff, which is included so that all of the other fun things about the user can be displayed.
(Note: this is using the web interface to Twitter, which is what I'm assuming the OP was implying)
Small correction: the first twitter page downloads ~2MB. Most of the images, JS, and CSS get cached, so every page after the first downloads much less data.
