search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.48k stars 4.76k forks source link

Use Huffman encoding for pre-generated HPACK and QPACK header names #63046

Open geoffkizer opened 2 years ago

geoffkizer commented 2 years ago

For known headers that are not in the HPACK/QPACK static table, we pre-generate their HPACK/QPACK encoding and store them in the KnownHeaders instance.

We currently aren't using Huffman encoding for these encoded values. We probably should -- the benefit here is less bytes on the wire, and the cost is simply a one-time initialization cost.

Even better would be to generate and cache these on demand since most are not commonly used. This would reduce initialization cost beyond where it is today without Huffman.

ghost commented 2 years ago

Tagging subscribers to this area: @dotnet/ncl See info in area-owners.md if you want to be subscribed.

Issue Details
For known headers that are not in the HPACK/QPACK static table, we pre-generate their HPACK/QPACK encoding and store them in the KnownHeaders instance. We currently aren't using Huffman encoding for these encoded values. We probably should -- the benefit here is less bytes on the wire, and the cost is simply a one-time initialization cost. Even better would be to generate and cache these on demand since most are not commonly used. This would reduce initialization cost beyond where it is today without Huffman.
Author: geoffkizer
Assignees: -
Labels: `area-System.Net.Http`, `tenet-performance`
Milestone: -
karelz commented 2 years ago

Triage: It should not impact server (@JamesNK can you please confirm as you did work in the area recently). If that is true, this should be fairly straightforward.

JamesNK commented 2 years ago

This would only be for header names that are in the known table and not in the static table?

My impression of huffman encoding is that it's only worth it for large values. Do small header names benefit?

Kestrel supports response dynamic header compression so I don't think it would offer a benifit. Response header names should be in the dynamic header table.