Twitter adds SPDY support to Netty

spullara · on Feb 7, 2012

This is a big deal for sites that want to rival Google sites performance-wise. Especially now that it will be in Firefox 11 in addition to Chrome. It would be great if any of the popular proxy servers - like Nginx - also had support for it.

firemanx · on Feb 7, 2012

Last I heard, it was in the works for NGinx:

https://twitter.com/#!/nginxorg/status/150112670966747137

bensummers · on Feb 7, 2012

I presume that it doesn't support SNI (for SSL vhosts) as the underlying JVM doesn't support it for servers? (I couldn't see anything in the docs, and it says it uses the JVM's SSL support underneath.)

One of the Google chaps said that SPDY required SNI when it was originally announced, so I was hopeful for a while.

ivanr · on Feb 7, 2012

Server Name Indication was added in Java 7, so I would expect that Netty supports it too, assuming you're running the latest version of the Java runtime.

wbier · on Feb 8, 2012

the missing piece is next protocol negotiation. we're working on releasing this code soon. expanded support in finagle (github.com/twitter/finagle) is also forthcoming.

bensummers · on Feb 9, 2012

In the server as well as the client?

tlrobinson · on Feb 7, 2012

Cool, support seems to be picking up. Here's a list of implementations: http://dev.chromium.org/spdy

Nginx seems to be the big missing one. I think Mongrel2 would be a good fit too.

moonchrome · on Feb 8, 2012

Yey ! I just wrote a server on top of Netty and figured out how to use SPDY to boost my performance but couldn't find SPDY implementation for Netty. Thank you twitter !

ww520 · on Feb 7, 2012

That's very cool. Netty is amazing already in term of performance. This just pushes it up another rung.

benmmurphy · on Feb 8, 2012

i have an example of SPDY+Netty+NPN here: https://github.com/benmmurphy/netty_spdy_example

it works with chrome which is quite nice to see.

on Feb 7, 2012

[deleted]

JoshTriplett · on Feb 7, 2012

> Personally, I would hesitate to implement them unless they had wide browser support.

When "implement them" means either "change one config option in your web server" or "install one package containing a SPDY implementation for your server", it seems worth doing just to provide a better experience for the browsers that support it so far.

_airh · on Feb 7, 2012

You got me there. That does seem reasonable. I guess I need to do a bit more investigation. :-)

ComputerGuru · on Feb 7, 2012

I believe Firefox + Chrome easily qualifies as "wide browser support." IE is really the only one left now.

adpowers · on Feb 7, 2012

Uhh, Safari? Safari is the number one browser on one of my (non-technical) websites, primarily because of mobile traffic (iPhone and iPad).

ComputerGuru · on Feb 8, 2012

Mobile browsers are already slow and playing catchup with the desktop web. They're hardly the place cutting edge innovation is taking place.

tlrobinson · on Feb 7, 2012

SPDY "gracefully degrades" to HTTP, so there's not really a chicken and egg problem. If your web server makes it easy to enable SPDY, there's not a big reason not to (that I'm aware of).

Technically SPDY is an application layer protocol, but you shouldn't need to change your existing HTTP application to enable it.

chc · on Feb 7, 2012

Surely you just need your webserver to support the protocol. I don't think most apps will directly speak SPDY.

afimrishi · on Feb 8, 2012

That's true for the most part. But if you want to leverage certain SPDY features like SPDY server push, then your app must be SPDY aware. Likewise, if you want to undo normal HTTP optimizations like hostname sharding which are damaging for SPDY, your app should be SPDY aware. Check out http://dev.chromium.org/spdy/spdy-best-practices for other recommendations.