Re: Compression ratio of HPACK.

On Fri, Jan 31, 2014 at 9:24 AM, Amos Jeffries <squid3@treenet.co.nz> wrote:

> On 1/02/2014 5:22 a.m., Jeff Pinner wrote:
> > Just to sanity check I navigated to www.google.com -- the page load
> made 11
> > requests, each with the same 8 identical cookies. Thus the reference set
> in
> > this example saves 8 bytes per frame (as opposed to the 1.57 bytes in
> your
> > analysis).
> >
> > I'd suggest trying to capture data on a single domain to show the affect
> > the compression has on repeated cookies.
> >
>
> Here I was being pleased at how much like a real-world middleware
> traffic that test was.
>
> Good example results for what we middleware people have been saying
> about the compression, TLS, etc. having very little benefit compared to
> the amount of CPU/RAM resource consumption required to maintain the state.
>
>
For middleware boxes that do connection coalescing for multiple clients it
is almost certainly true that without the ability to divide the reference
set into groups (a feature that was dropped to its imagined complexity),
the best thing to do is to clear the reference set before each header set.
That's why the opcode was added to do just that.


> PS. The HTTP/2 test data so far appears to have been very biased towards
> traffic as seen on connections which are terminated at a origin server
> or browser / UA client simply by being grouped by :authority. Traffic as
> seen by middleware is much more volatile.
>
> Amos
>
>
>