Обновление динамического размера таблицы http/2

Question

В протоколе http/2 мы видим следующее утверждение для динамического обновления размера таблицы:

SETTINGS_HEADER_TABLE_SIZE (0x1):  Allows the sender to inform the
      remote endpoint of the maximum size of the header compression
      table used to decode header blocks, in octets.  The encoder can
      select any size equal to or less than this value by using
      signaling specific to the header compression format inside a
      header block (see [COMPRESSION]).  The initial value is 4,096
      octets.

Начальный размер для кодера и декодера составляет 4096 байт согласно RFC.

В SETTINGS в wireshark, я вижу новый размер таблицы, переданный ENDPOINT (в данном случае google.com)

0000   00 00 12 04 00 00 00 00 00 **00 01 00 01 00** 00 00
0010   04 00 02 00 00 00 05 00 00 40 00

00 01 00 01 00 - это шаблон для SETTINGS_HEADER_TABLE_SIZE = 65536

Что я не могу понять, так это на самом деле говорит конечной точке, что динамическая таблица, используемая для декодирования заголовков из этого ENDPOINT внутри браузера, имеет длину 65536 байт, или это говорит ENDPOINT, что размер динамической таблицы ENDPOINT должен быть 65536?

И наоборот, я предполагаю, что ENDPOINT должен быть отправлен SETTINGS_HEADER_TABLE_SIZE сказать браузеру его динамическую таблицу, используемую для декодирования заголовков из ENDPOINT, но я не вижу эту опцию, возвращенную ENDPOINT. Может кто-нибудь объяснить это?

Также есть сигнал для динамического обновления размера таблицы, упомянутый в RFC, который отправляется внутри HEADERS Рамка.

 A dynamic table size update starts with the '001' 3-bit pattern,
   followed by the new maximum size, represented as an integer with a
   5-bit prefix (see Section 5.1).

   The new maximum size MUST be lower than or equal to the limit
   determined by the protocol using HPACK.  A value that exceeds this
   limit MUST be treated as a decoding error.  In HTTP/2, this limit is
   the last value of the SETTINGS_HEADER_TABLE_SIZE parameter (see
   Section 6.5.2 of [HTTP2]) received from the decoder and acknowledged
   by the encoder (see Section 6.5.3 of [HTTP2]).

Есть эта строчка received from the decoder and acknowledged by the encoder так же этот сигнал отправляется для ограничения encoding динамический размер таблицы? Я полностью проиграл, и это не очевидно из захватов Wireshark, как это обрабатывается правильно

ОБНОВИТЬ

Хорошо, я посмотрел больше на логи wireshark от firefox на сайте walmart.com (так как там много заголовков). Иногда Firefox отправляет dynamic table size update сигнал в кадре заголовков, размер которого меньше исходного SETTINGS_HEADER_TABLE_SIZE отправлено firefox в начале соединения. Я написал динамическую таблицу Firefox на paper и уменьшить его, как будто я ожидал dynamic table size update сделал бы. Оказывается, что сокращение его до меньшего размера приводит к неправильным заголовкам. dynamic table size update влияет только на удаленную конечную точку.. (ну, я думаю, это так). Я также посмотрел на реализацию nigthttp и aC#, и там они фактически уменьшают размер таблицы кодировщика при отправке dynamic table size update сигнал. У меня такое ощущение, что у каждого есть совершенно разные реализации этого протокола... это полный кошмар, чтобы понять.

Answer 1

Как вы поняли, есть несколько вещей, которые указывают размер таблицы:

• Максимальный размер таблицы (как указано в кадре HTTP/2 SETTINGS)
• Фактический размер используемой таблицы, которая закодирована в кадре HEADERS в формате HPACK.

Если мы посмотрим только на заголовки, которые передаются от клиента (браузера) к серверу, мы увидим следующее:

• Пока никто не имеет информации с удаленной стороны, используются значения по умолчанию, что означает, что клиент ожидает, что сервер поддерживает максимальный размер таблицы 4 КБ (SETTINGS_HEADER_TABLE_SIZE) и он также использует этот размер в качестве начального размера таблицы.
• Сервер может дополнительно сообщить клиенту через фрейм НАСТРОЙКИ HTTP / 2, что он поддерживает только таблицы заголовков меньшего размера. Эта информация содержится в SETTINGS_HEADER_TABLE_SIZE поле SETTINGS, которое отправляется с сервера на клиент.
• Клиент может настроить фактически используемый [динамический] размер таблицы заголовков через Dynamic Table Size Update в рамке заголовки. Это всегда будет указывать размер таблицы, который фактически используется на стороне кодера - и который, следовательно, также должен быть установлен на стороне декодера, чтобы иметь возможность извлекать те же данные. Отправляющая сторона может установить фактический размер используемой таблицы в диапазоне от 0 до максимального размера, поддерживаемого удаленной стороной (в SETTINGS_HEADER_TABLE_SIZE). Типичная стратегия для реализаций состоит в том, чтобы всегда уменьшать размер используемой таблицы, когда он в настоящее время больше, чем поддерживает удаленный. И увеличить размер таблицы, когда пульт поддерживает большие таблицы, а реализация также может пойти дальше. Могут быть некоторые условия состязания, когда один конец уже установлен и использует больший размер таблицы, чем тот, который фактически поддерживает удаленная сторона, например, потому что кадр SETTINGS, который указывает нижний предел, не был получен до того, как клиент закодировал первую пару заголовков. В этом случае удаленная сторона может обнаружить использование слишком большого размера таблицы и сбросить соединение. Чтобы избежать таких ситуаций, обе стороны соединения в действительности должны по крайней мере поддерживать размер таблицы по умолчанию, равный 4 КБ, и, в идеале, только динамически увеличивать ограничение и никогда не уменьшать его.

Теперь я упомянул, что одна пара макс. Настройки размера таблицы и фактического размера таблицы используются для передачи заголовков с одного конца соединения (клиент) на другой (сервер). Но в целом есть и вторая пара обоих, для заголовков, которые отправляются с сервера на клиент. Для этого случая клиент / браузер также указывает в кадре НАСТРОЙКИ, насколько велика макс. Таблица заголовков поддерживает и сервер отправляет размер используемой таблицы заголовков.