Firefox Expression of Interest in HTTP/2.0

This is the Mozilla Firefox HTTP/2 Expression of Interest as per
http://trac.tools.ietf.org/wg/httpbis/trac/wiki/Http2CfI

The most severe limitations of the HTTP/1 Web transport framework
are poor performance over high latency networks and the routine
invasions of privacy end users endure when servers choose to operate in
plain text. Addressing these two concerns is the minimum bar at which
upsetting the current eco-system with a new protocol becomes worthwhile.

We have been working with SPDY since 2011 and have been pleased that the
result is a protocol that enhances confidentiality during transport 
while still providing performance improvements. In my experience, the 
better performance profile is driven fundamentally from multiplexing a 
large number of transactions concurrently without negatively impacting 
TCP’s congestion control scheme as HTTP/1 connection concurrency can. 
Other features such as prioritization and header compression play 
lesser, but sometimes still important, roles.

Quantifying the performance gains depends on both the composition of the
content and the connection latency. Our experience has been that typical
content and latency will generate whole page transfer time savings on 
the order of 10%, but the worst 20% of all latencies will see 
improvements 4 times as large. As we anticipate increasing 
Bandwidth:Delay products in the future this property of scaling with 
latency is SPDY’s largest contribution.

SPDY makes an excellent, though incomplete, basis for HTTP/2.

In support of this it is worth noting that there has been a lot of
operational experience around SPDY. Firefox has been able to work with
Chrome, Twitter, F5, Jetty, Google.com, Node.js, and many others to
work out operational issues. I believe in running code and what we
learn from it - and this extensive vetting is one of the most
compelling reasons to make this choice.

In addition to learning the strengths of SPDY we’ve learned where it
still needs to evolve. The client side credential infrastructure is
immature, server push holds promise but has solvable issues outstanding
around interaction with both client and third-party caches, and
connection management around mixed http/1 and SPDY environments has
proven to be the source of some frustration that could be alleviated
with standardization.

We have not implemented either draft-montenegro-httpbis-speed-mobility
or draft-tarreau-httpbis-network-friendly. While both are reasonable in
many ways, we don’t see an important compelling advantage of either as
a starting point over SPDY.  We welcome the code Microsoft has published 
in conjunction with their draft as an important contribution - but 
neither alternative proposal has the body of experience that SPDY 
offers. In my opinion they are best used as valued and informed inputs 
to the evolution of SPDY into HTTP/2.

However, if a community of critical mass were interested in
experimenting with a privacy-preserving variant of either we would
support that inquiry with code and data gathering telemetry available to
our testing audience and then decide whether or not to proceed based on 
that result. It is unlikely we would implement or ship any new transport
protocol that was not secure against at least passive eavesdropping
attacks.

Received on Thursday, 12 July 2012 14:19:37 UTC