Expression of Interest from Jetty.

Hi,

This is a response to the call for expressions of interest:
http://trac.tools.ietf.org/wg/httpbis/trac/wiki/Http2CfI

I'm the project leader of the Jetty project (http://eclipse.org/jetty)
and am making this initial response on behalf of the project and not
for eclipse as a whole (although we will solicit further feedback from
other projects within eclipse). I work for Webtide|Intalio who sell
support services around Jetty.

Jetty is an open source server and client written in java that
supports the 3.0 Servlet API, HTTP/1.1, Websocket 1.0 and SPDY v3.  We
have a reasonable market share of java servers (>10% < 30%) and are
deployed on everything from tiny embedded servers to very large
deployments with over 100k connections per server.

The Jetty project is very interested in the development and
standardisation of HTTP/2.0 and intend to be contributors to the WG
and early implementers.     We are well acquainted with the
limitations of HTTP/1.1 and have a desire to see the problems of
pipelining and multiple connections (>2) resolved.

The Jetty project SPDY effort is lead by Simone Bordet and it has
implemented SPDY v3 with flow control and push.  This is available in
the main releases of our Jetty-7 and jetty-8 servers (we also have a
java SPDY client).   The project has also provided an extension to the
JVM to implement the TLS NPN extension needed by SPDY, and we
understand that several other java SPDY implementations are using
this.

We chose SPDY to implement rather than any other HTTP/2.0  proposal
mainly because of the support available in deployed browsers, so that
we can achieve real world feedback.    However, we were also
encouraged in our adoption of SPDY by the open, methodical and
congenial approach of the SPDY project at Google (not always our
experience with projects at Google or elsewhere) .

We definitely see the potential of SPDY and it is already being used
by some sites.  However we still lack the feedback from widespread
deployment (it is early days) or from large deployments.   We are
actively seeking significant sites who are interested in working with
us to deploy SPDY.

There are several key features of SPDY that we see as promising:

Header compression greatly improves data density.  In our use of Ajax
and Comet over HTTP/1.1 we have often hit scalability limits due to
network saturation with very poor data density of small massages in
large HTTP framing.  While websocket is doing a lot to resolve this,
we are hoping that SPDY will provide improvement without the need to
redevelop applications.

Multiplexing of multiple streams over a single connection is also a
good development. Reducing the number of connections that the server
must handle is key to scalability, specially as modern HTTP browsers
are now exceeding the 2 connection limit.  The ability to send out of
order responses is good and we also suspect that receiving messages
from a single client over a single connection may help reduce some of
the non deterministic behaviours that can develop as multiple
connections from the same client set cookies or update session state.
It will also avoid the issue of load balancers directing connections
from the same client to different nodes in a cluster.     We recognise
the additional cost of multiplexing (extra copies and flow control),
but currently believe that it is worth the effort.

We see the potential of server push for content, but are struggling
with the lack of meta data knowledge available to know what to push
and when.  We are currently working on strategies that use the
referrer header to identify associated resources that can be pushed
together. We also check for if-modified-since headers as an indication
that associated content may already be cached and thus a push is not
required.   We see the challenge of push as not being the protocol to
send the content, but in working out the standards for meta data,
cache control etc so that we know what to push and when.

We have not yet implemented websocket over SPDY, but do intend to do
so if it is supported by the browsers. We see a lot of similarities in
the base framing of these two protocols and would hope that eventually
only one would need to be well supported.

We are bit ambivalent about the use of NPN and TLS only connections.
There is a question to be asked regarding if we should be sending any
web content in the clear, and how intermediaries should be able to (or
not) filter/inspect/mutate content.    However, I personally feel that
this is essentially a non technical issue and we should not use a
protocol to push any particular agenda.    The RTT argument for not
supporting in the clear connections is weak as there are several easy
technical solutions available.  Furthermore, the lack of support for
NPN is a barrier to adoption (albeit one that we have broken down for
some JVMs at least).   Debugging over TLS is and will always be
difficult.    We would like to HTTP/2.0 support standardised non
encrypted connections (at least from TLS offload to server).    If a
higher level debate determines that web deployments only accept TLS
connections, then we are fine with that non technical determination.

I repeat that we selected SPDY to implement because it's availability
in the browsers and not as the result of a  technical review against
other alternatives.  However we are generally pleased with the
direction and results obtained so far and look forward to gaining more
experience and feedback as it is more widely deployed.

However we do recognise that much of the "goodness" of SPDY can be
provided by the other proposals.  I'm particularly interested in the
HTTP/speed/mobility's use of websockets as it's framing layer (as that
addressed the concern I raised above).  But we currently do not have
any  plans to implement the alternatives, mainly because of resource
limitations and lack of browser support.  So currently we are
advocates of  the SPDY approach in the starship troopers sense: ie we
support SPDY until it is dead or we find something better.  Of course
Jetty is an open platform and we would really welcome and assist any
contributors who would like to build on our websocket support to
implement HTTP/SM.

We believe that there is high demand for a significant improvement
over HTTP/1.1 and that the environment is ripe for a rapid rollout of
an alternative/improved protocol and expect that HTTP/1.1 can quickly
be replaced.   Because of this, we have begun development of jetty-9
which replaces the HTTP protocol centric architecture of jetty-7/8
with something that is much better suited to multiple protocols and
multiplexed HTTP semantics. SPDY, Websocket and HTTP/1.1 are true
peers in Jetty-9 rather than the newer protocols being implemented as
HTTP facades. We believe that jetty-9 will be the ideal platform on
which to develop and deploy HTTP/2.0 and we invite anybody with an
interest to come contribute to the project.

regards

PS. Simone Bordet who has lead our SPDY development is currently on
vacation and may have more to say on his return.














-- 
Greg Wilkins <gregw@intalio.com>
www.webtide.com
Developer advice, services and support
from the Jetty & CometD experts.

Received on Tuesday, 3 July 2012 10:14:39 UTC