Re: 回复： Questions about QPACK

[Dmitri Tikhonov <[e-mail]>]

On Sun, Nov 24, 2019 at 01:14:04AM +0800, 漂泊的梦 wrote:
> I think it is not such a good idea to insert name with 0-length entry
> into dynamic table, because it needs to transmit more information to
> recipient through the encoder stream for synchronization of dynamic
> table between the sender and recipient.

I am afraid I don't understand what you mean here.

> In my option, it never need to insert name with 0-length entry into
> dynamic table. When we need reference the name only index in the
> Literal Header Field, we can use the index of the entry with the same
> name and a different value we first find in the dynamic table.

It is possible only to insert full name/value pairs into the dynamic
table, but it's not always the best thing to do.  If the value never
repeats again, it will just waste space in the dynamic table.

A good example of the header field whose name is not in the static
table and whose value rarely repeats is X-FB-Debug from the Facebook
server QIF file used for the QPACK interop [1].  ls-qpack inserts
such entries into the dynamic table with zero-length values [2].
This has a beneficial effect on compression ratio.  Without it (I
commented out this code for this test), encoding this QIF file [3]
makes compression ratio worse: from 0.176 to 0.178.

Now, if x-fb-debug is always inserted full -- including the value --
into the dynamic table, the compression ratio drops to 0.287.

> Could you please advise if this is a good idea or which method is
> better in the real situation?

There is no perfect method as different applications will produce
different header patterns.  ls-qpack uses history to decide which
entries to index; other implementations use hard-coded assumptions
(e.g. "user-agent" header never changes.).  This is an interesting
question.  A better method may yet be uncovered.

  - Dmitri.

1. https://github.com/qpackers/qifs/blob/master/qifs/fb-resp.qif
2. https://github.com/litespeedtech/ls-qpack/blob/d79ab9ae19d25bdb6e14d10bb76dbc9d7bcfcf21/lsqpack.c#L1795
3. Table size 4096, no risk, immediate ack.