Ascii-based SPDY "compression" idea

>From the SPDY whitepaper <http://dev.chromium.org/spdy/spdy-whitepaper>,
the primary performance benefit of header compression is in the upload
direction. The benefit can be as much as a 1 second impact for slow DSL
(375 Kbps) links based on these tests. This is primarily due to long
repeating strings in URLs, User Agents, and Cookies. Ideally we could find
a way to reduce the bytes associated with these headers without obscuring
them.

Since a SPDY session is associated with a single TCP connection, we can
assume all GETs on that connection are being routed to the same web server.
This allows us to consider other "compression" schemes for SPDY that will
maintain transparency on the wire, or at least make it easier for tools to
be built to interpret the headers. For instance, in a given TCP connection
/ SPDY session, HTTP headers in GETs and responses can be dropped if they
have the same value as previous. If different from previous, only
differences can be sent. This would immediately drop User Agent headers
from all but the first GET. Additionally requests would contain only
cookies whose values are changing, similar to the way that Set-Cookie works
in HTTP responses today. Even URLs could use relative paths from the
previous object.

This would provide some of the benefit of header compression without any of
the opaqueness downside.

Peter






On Sun, Apr 1, 2012 at 12:39 AM, Willy Tarreau <w@1wt.eu> wrote:
>
> On Fri, Mar 30, 2012 at 03:22:12PM +0200, Mike Belshe wrote:
> > What is "transparency on the wire"?  You mean an ascii protocol that you
> > can read?  I don't think this is a very interesting goal, as most people
> > don't look at the wire.
>
> I agree with you here Mike, despite being used to look at network captures
> all the day and testing proxies with "printf|netcat" at both ends. But we
> must admit that if developers need tools, they will develop their tools.
> Having an HTTP option for netcat would work well, or even having an
1.1-to-2.0
> and 2.0-to-1.1 message converter on stdin/stdout would do the trick. So I
> prefer to lose the ability to easily debug and have something efficient
than
> the opposite. And it costs me a lot to say this :-)
>
> Willy
>