Re: Ascii-based SPDY "compression" idea

++

Willy has it right here.

The goal is to optimize for the user, not to make it easy to debug one
request at the cost of user experience or network price when we as
implementers are perfectly able to create tools that turn the binary into
formatted text and graphics.

-=R

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.
>
> > 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
>
> Best regards,
> Willy
>
>
>