SPDY is Google’s protocol that is intended to improve user experience on the web, by reducing the latency of web pages, sometimes up to a factor of 3. Yes, three times faster.
How does SPDY accomplish that ?
SPDY reduces roundtrips with the server, reduces the HTTP verboseness by compressing HTTP headers, improves the utilization of the TCP connection, multiplexes requests into a single TCP connection (instead of using a limited number of connections, each serving only one request), and allows for server to push secondary resources (like CSS, images, scripts, etc.) associated with a primary resource (typically a web page) without incurring in additional round-trips.
Now, the really cool thing is that Jetty has an implementation of SPDY (see the documentation) in the newly released 7.6.2 and 8.1.2 releases.
Your web applications can immediately and transparently benefit of many of the SPDY improvements without changes, because Jetty does the heavy lifting for you under the covers.
With Chromium/Chrome already supporting SPDY, and Firefox 11 supporting it also (although it needs to be enabled, see how here), more than 50% of the web browsers will be supporting it, so servers needs to catch up, and where Jetty shines.
The Jetty project continues to foster innovation by supporting emerging web protocols: first WebSocket and now SPDY.
A corollary project that came out from the SPDY implementation is a pure Java implementation of the Next Protocol Negotiation (NPN) TLS Extension, also available in Jetty 7.6.2 and 8.1.2.
To prove that this is no fluke, we have updated Webtide’s website with Jetty’s SPDY implementation, and now the website can be served via SPDY, if the browser supports it.
We encourage early adopters to test out Jetty’s SPDY and feedback us on email@example.com.
12 thoughts on “SPDY support in Jetty”
Pingback:Fast, Easy Web Design! » Blog Archive » InfoQ Ratpack Classy and Compact Groovy Web Apps
I downloaded both 8.1.2 and 7.6.2 but there is no sign of the spdy code. Is there an additional package that I need to download?
In the 7.6.2 and 8.1.2 releases, we forgot to make SPDY available in the distribution; we will fix this in 7.6.3 and 8.1.3.
Meanwhile, you can download the SPDY jars from http://repo2.maven.org/maven2/org/eclipse/jetty/spdy/.
Sorry about that, SPDY was there but slipped out of the distribution packaging.
I actually am interested in the source code, so I followed the Sources link to the page that explains how to grab the code from the Eclipse git server. Unfortunately the checkout fails with:
$ git clone http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git
Cloning into org.eclipse.jetty.project…
error: The requested URL returned error: 403 (curl_result = 22, http_code = 403, sha1 = 1b72c3a0a79654ac272aea6eb2f3f9aa1d20c7e6)
error: Unable to get pack index http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/objects/pack/pack-4f01a64aa08c03b8317ede41ac67aa3fff82e6cf.idx
$ git clone http://git.eclipse.org/gitroot/jetty/org.eclipse.jetty.project.git
Can you please file a bug at https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Jetty so we can update the docs ?
Is there any chance to have some futeares of SPDY to be backported into a new version of HTTP (say, HTTP 1.2) in order to get most of speedy SPDY futeares (but without TLS) into HTTP, that is, in order not to have to do a more radical move ? Is SPDY making mandatory the use of spdy:// addresses ?Thanks.
Pingback:Jetty-SPDY is joining the revolution! | Webtide Blogs
I was wondering is the java requirement for OpenJDK 1.7 only or it will work with Oracle’s JDK 7 also?
Ian,if you can’t get a consensus that it is a seicruty bug, then the IETF will pick something that you might IYNSHO think is a seicruty bug.Conversely, I’ve argued that sentinel framing is a seicruty vulnerability in websockets because it is susceptible to injection attacks (as is HTTP but no reason to repeat mistakes), yet the WHATWG process goes with your opinion and ships anyway. Can you give me the emails of the WHATWG members so I can appeal your decision?
Pingback:500,000 Requests/Sec? Piffle! 1,000,000 Is Better « The Low Latency Web
Pingback:Jetty-SPDY blogged | Webtide Blogs
IANA had good reasons to useggst the usage of port 80/443, and I’ve actually got few objections to that happening. The upgrade mechanism is there in HTTP for a reason.But the initial upgrade request should be a real HTTP request (not something that just looks like a HTTP request), and the entire internet community need to be involved in the process of developing the upgraded protocol not just the browser vendors.
Comments are closed.