The transparency with which Chrome did this was actually a problem for me. Google Docs/GMail did not work for months on my school's ethernet connection until I read about SPDY being implemented; sure enough, launching Chrome with SPDY disabled fixed the issue, and that requires a command line option. I wish Chrome were less transparent about this and added a few Preferences options, at least.

You can peek into your Chrome'ss current SPDY connections (and other interesting internals) in their internal pages:

chrome://net-internals/#events&q=type:SPDY_SESSION%20is:active

Really annoying that they didn't just use SCTP. One commenter on the page points out that it works on top of TCP, which is supported by most routers. This, however, is an entirely artificial limitation. It is a sad fact that this type of artificial restrictions are imposed, and i say that we should fight against them. Having all inet services running over port 80 and TCP does not make the net any safer or better. We as hackers should fight for making people aware of and remove such restrictions, not accept and worsen the crippled situation by working around the problem. This is one of the key problems in the digital world today, too few actually makes an effort to fix the underlying problems. Here Google could play a crucial role, and I must say that I am dissapointed by their choice.

If you want to see your SPDY sessions and an abundance of other related information, browse to about:net-internals from a new Chrome tab.

For those interested in playing with SPDY, ruby parser and generator: https://github.com/igrigorik/spdy

It's a good improvement over HTTP 1.1 and it's nice how they did it in a completely transparent way. Now it's time for the other browsers to support it and to implement way to hint the usage of spdy (maybe a <link rel="" in the first HTTP request, or an extra header in the HTTP request).

http://google.com/search?q=site%3Aycombinator.com+spdy

undefined

Does Apache support SPDY?