As I said in response to the previous submission re: SPDY, I think the protocol is great. However, relying on TLS NPN to enable it means I can't implement a SPDY server with OpenSSL versions prior to 1.1.0, or any version of Windows SChannel (even in Windows 7).

Please, please could browser developers consider supporting the Connection: Upgrade and/or Alternate-Protocol headers as an alternative?

(I know I'll probably get downvoted for sounding like a broken record, but I'd really like to spread the word about this issue)

Why should people care about what certain obsolete versions of OpenSSL support? Also - it doesn't appear that 1.1.0 is released; do you mean to say it's only supported by an unreleased version?

It would appear so, yes: http://www.openssl.org/news/changelog.html

    Changes between 1.0.1 and 1.1.0

    [..]

    *) Add Next Protocol Negotiation,
       http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-00. Can be
       disabled with a no-npn flag to config or Configure. Code donated
       by Google.

This whole thread is a broken record for going on two years now or whenever google first rolled out SPDY for gmail, but I guess it's relevant again right now because Silk uses it.

I know this is old news. I think the fact that Silk is using it (successfully?) attracted my attention. I dismissed it way back when I heard of it because of the same reasons.

But We have to agree that Amazon has very smart people, if they decided to use SPDY, then it is interesting to learn why they thought this was the best solution.

This paper obviously doesn't answer that. But in my quest to understand, I found this paper and thought it would be an interesting read for the people in HN who haven't read it.

It was probably an easy answer, really. It's better than HTTP, is included in Android, which they chose as a base platform, and they don't have to worry about Windows compatibility on their own hardware.

SPDY is also a more optimized solution for mobile devices. The ability to do server-push resources means that Amazon can fetch/preprocess/compress/cache the resources for a page, and then when that page is requested from another user and can be served from cache, they can dump all the required resources down the pipe automatically without the client having to fetch/parse/request/load/etc.

Amazon's 'everything goes through us' solution also optimizes in cases where SPDY normally wouldn't; external resources, such as jQuery served from Google's or Microsoft's AJAX cache, can be pushed to the client, whereas in a normal browsing situation you'd still need one connection to every server, so using multiple hostnames/servers would be detrimental to performance.

It looks like SPDY was added in Honeycomb so they would have had to add support themselves since Amazon started with Eclair.

https://groups.google.com/d/msg/spdy-dev/bwb-qhiLICc/NzbWN0K...

Patches for stable OpenSSL are linked from: http://technotes.googlecode.com/git/nextprotoneg.html

I understand that NPN can be a pain, but it's the right thing to do. Connection: Upgrade is slower and breaks over MITM proxies.

You can't apply a patch if you're using it as a shared library, and OpenSSL is only part of the problem - what about SChannel on Windows? That can never get NPN support, until perhaps Windows 8.

I know NPN is the right thing to do long-term, but shouldn't any possible alternative be supported if it makes SPDY more accessible?

This is the protocol that Amazon's new Browser (Silk) uses to keep the connection with Amazon EC2. I think it is very interesting that this protocol works so great.

I would love to test silk just to test the speed.

Where did you get that information? is there an official statement about it? I thought about this too when I read the blog post but couldn't find more information about it.

edit: after reading another HN's thread I found this http://aws.amazon.com/es/amazonsilk-jobs/ suggesting the same thing. Thanks anyway.

I actually got it from a thread in HN: "Amazon's Silk Web browser adds new twist to old idea" http://news.ycombinator.net/item?id=3049216.

SPDY is probably landing in Firefox trunk soon, for release early next year.

The real problem is lack of good server implementations now. Google has whatever they use, but basically nobody else does.

Community of the web, let's get this rolling!

The http server in Go supports SPDY.

http://golang.org/pkg/http/spdy/

Good luck finding an example of actually using it to serve pages though. My Google-fu isn't normally that weak, but I couldn't find anything helpful. :[

Don't blame your Google Fu, blame Google for calling it Go.

I usually get lucky with using "golang" but the best I came up with were other people asking how to use the SPDY server along with ListenAndServe without any helpful replies.

You can always use: http://go-lang.cat-v.org/go-search

Apache SPDY module: http://code.google.com/p/mod-spdy/

Tomcat SPDY implementation: http://svn.apache.org/repos/asf/tomcat/trunk/modules/tomcat-...

(haven't tried yet)

You're not the only one. I can't find a single person who tried the Apache SPDY module. There is also no recent activity on their discussion board, which is not promising.

Anyone want to start work on a nginx module? :)

For those of you running chrome, browse to chrome://net-internals/#spdy in order to check out the SPDY connections currently open in your browser (probably at least gmail for most here.)

"For best performance, it is expected that clients will not close open connections until the user navigates away from all web pages referencing a connection, or until the server closes the connection. Servers are encouraged to leave connections open for as long as possible, but can terminate idle connections after some amount of inactivity if necessary. " it's basically a "long connection" scheme, the servers will suffer. But skimming the spec, I can't find a TCP preferred port nor an URI scheme, how do I start a connection ?

Overall, the servers would have to suffer less than they do now. It's just a single pipe instead of multiple short-lived parallel connections.

I didn't get my idea right: the profile load of the server will change (from many short connections to less long connections), I'm not sure they are prepared. But I'd like to try it, just because it looks interesting.

FWIW, a google for spdy uri gave me this: http://groups.google.com/group/spdy-dev/browse_thread/thread...

Great news! The IANA has approved our application for a dedicated port for non-SSL SPDY. We have been assigned the port number 6121.

I've been following japhr's blog http://japhr.blogspot.com/. He has some great articles on his chain about writing http://spdybook.com/

If you want to know more about spdy from on node.js w/ full unit testing then I recommend reading through his blog and book.

While SPDY seems pretty good actually, and that I understand they just want "a quick hack to get that out fast" a part of me can't help to think "I'd rather have it done the Right Way and use SCTP"

SPDY runs over TCP and SCTP is a replacement for TCP. Getting SCTP supported across all operating systems and hardware is a huge endeavor almost at par with converting to IPv6. SPDY, by comparison, is already in place and working. Getting it "done right" may never happen.

SCTP would still necessitate a new application-layer protocol.

What exactly is the advantage of this vs http over sctp?

Actually the true advantage is that you don't need a new protocol, you don't need people to change fw setups etc, it'll just workd.

SCTP needs more work from everyone.

Then what's the true advantage of SCTP over SPDY? Well it works for non-web stuff.

Then they have some technical differences but I think the points above are what _really_ matter

As previously discussed, SCTP does not pass through home NATs and thus effectively cannot be used on the Internet. Also, SPDY has very effective HTTP header compression.

Edit: I forgot to mention that neither Windows nor OS X include SCTP. (Unless you want Chrome to install kernel modules.)

SCTP passes through home NATs just fine if you layer it on top of UDP

Note: This is officially pronounced 'speedy', not 'spidey' as I persist in doing in my own head.