Re: Ascii-based SPDY "compression" idea

On Sun, Apr 1, 2012 at 8:14 PM, Willy Tarreau <w@1wt.eu> wrote:

> Hi Peter,
>
> On Sun, Apr 01, 2012 at 12:50:20PM -0400, Peter Lepeska wrote:
> > 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.
>
> The goal is now to optimize every agent in the chain, not to make it easy
> to read them from a human eye. Something like 1 requests over 1 billion is
> read by a human, yet networks are full of them and parsers have a lot of
> difficulties trying to get them right because they're made for humans.
> Don't get me wrong, I *love* to read captures and to quickly spot what's
> right or wrong, but people who do this like me are also able to develop
> some additional tools to continue doing this.
>

I agree with Willy. Peter, while it's indeed useful to discuss different
compression schemes, I'd urge you to stop optimizing for humans, since they
will write tools. Note that SPDY is pretty simple to write a tool for. I
think there are on the order of 20+ different implementations of it now,
which demonstrates that it is not hard.

While we're talking about tools, note that Adam Langley wrote code in NSS
(used by Chromium) to dump the secrets for TLS connections to stdout, which
can be imported into Wireshark to decode TLS streams.


> > 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.
>

> You should then take a look at what is proposed in our draft here, as it's
> more
> or less what you're describing, with binary-encoded header field names in
> order
> to save more space (stop sending "if-modified-since" for instance) :
>
>  http://tools.ietf.org/html/draft-tarreau-httpbis-network-friendly-00
>

Thanks for mentioning this Willy. Can you implement this and provide data
on how it performs? I think it will better inform the debate.


>
> Best regards,
> Willy
>
>
>