Re: Choosing a header compression algorithm

Ya, connection management and compression are linked.

Sharing of connections when both the cert and the DNS resolution match is
something that is done today for SPDY and which does reduce latency
(generally by at least 2 RTT but often effectively more due to slow start,
etc. ) as well as reducing connection counts, server load, etc.

In SPDY4, we'll be experimenting with policy w.r.t. connection sharing, as
what exists today is both too much or too little, depending on what one
wants, but the latency (etc.) savings are likely to be compelling.

The proxy case is another where this matters, as you point out, but that
isn't where the biggest win has been so far since there has been
significant experience with that mode of operation yet (unless Amazon
speaks up!). It is an interesting case though.

-=R
On Mar 22, 2013 1:12 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote:

> On 22 March 2013 10:45, Roberto Peon <grmocg@gmail.com> wrote:
> > Correct, delta2 uses a header group per host, however, the real benefits
> of
> > this don't show up with the current streamifier, which removes the
> > intermingling of requests to different hosts (which is a bit unrealistic,
> > but does makes the graphs easier to parse visually).
> > This can end up really mattering to the compression in the cases where
> there
> > is some ping-ponging between different host headers.
>
> Isn't this only a concern/advantage for the hop between a client and a
> client-side proxy?  Requests toward different hosts are going to be on
> their own connections in all other situations.  Origin servers are
> unlikely to see any benefits from improved compression between hosts.
>
> The question of reuse of a connection for different authorities is
> still unresolved.  I know that  this is on some people's minds, but we
> haven't seen any proposals, nor do I think we're ready to go there
> just yet.
>