Как выполняется управление потоком HTTP/2 по ходу?

Question

Как spec говорит:

управления потоком является специфичным для соединения. Оба типа управления потоком находятся между конечными точками одним ходом, а не по всему пути .

И 6.9 WINDOW_UPDATE

Оба типа управления потоком хмель от хмеля, то есть только между две конечные точки. Посредники не пересылают кадры WINDOW_UPDATE между зависимыми соединениями. Однако, дросселирование передачи данных на , любой приемник может косвенно вызвать распространение информации об управлении потоком исходному отправителю.

Но как это возможно? Кажется, что это требует от всех посредников, чтобы понять h2 или h2c протокол, и у меня есть два вопроса:

1. HTTP/2 является относительно новым стандартом, и я видел много сайтов, эта функция включена (мой блог входит в комплект). Хотя я могу посещать эти веб-сайты без каких-либо проблем, означает ли это, что каждое промежуточное устройство по пути, как маршрутизаторы и концентраторы и т. Д. Уже реализовало свои собственные алгоритмы стека и управления потоком HTTP/2 (поскольку RFC7540 не предусматривает алгоритм управления потоком)?

2. Большинство сайтов использует h2, а не h2c, который шифрует данные прикладного уровня. Управление потоком HTTP/2 осуществляется приемниками, отправляющими WINDOW_UPDATE кадр, который также является данными уровня приложения, а затем как промежуточные устройства знают, что представляют собой эти данные? Если они не могут расшифровать данные и посмотреть часть Window Size Increment, как они выполняют контроль потока, не пересылая WINDOW_UPDATE кадр?

Answer 1

Во-первых, несколько исправлений.

Токен h2c относится к чистому текстовому HTTP/2 (отсюда c в h2c). В вашей второй пуле вы говорите, что большинство веб-сайтов используют ее, но на самом деле ее очень мало, потому что браузеры не реализуют ее. Подавляющее большинство веб-сайтов используют h2.

Токен h2 относится к зашифрованному h2c или эквивалентно h2c по TLS.

Когда клиент и сервер ведут переговоры, чтобы говорить h2, байты, которые отправляет клиент, зашифрованы и перемещаются зашифрованы до самого сервера. Это означает, что у посредников нет возможности расшифровать трафик (спасибо).

В этом случае «прыжок», обозначенный спецификацией HTTP/2, представляет собой весь сегмент сети, который находится между клиентом и сервером.

Спецификация HTTP/2, однако, должна быть общей и не беспокоится о том, как браузеры и веб-серверы взаимодействуют при определении проводного протокола, такого как HTTP/2.

Представьте себе ситуацию, когда клиент выполняет 2 запроса HTTP/с использованием h2 и нужно вызвать server2 выполнить запрос, на этот раз с помощью h2c. Например, может быть интерфейсом «прокси», который пересылает запросы на «правый» серверный сервер в зависимости от некоторой логики.

В этом случае у вас есть 2 перелета: client-server1 и server1-server2.

Каждый прыжок применяет собственный контроль потока.

Например, представьте, что клиент загружает большой файл на сервер. Как правило, окно отправки контроля потока клиента невелико, например, по умолчанию 65535 октетов. Клиент может отправлять до 65535 октетов до остановки загрузки.

Эти 65535 октетов принимаются . Теперь становится клиентом для связи с server2. Представим себе, что клиент был настроен с гораздо меньшим потоком управления потоком, когда он связывается с server2, скажем, всего лишь 16384 октетов.

В этом примере киосков загрузить на server2 после 16384 октетов, и должен управлять, чтобы сохранить вокруг оставшихся 65535-16384 октетов ждет server2 уведомления (через WINDOW_UPDATE кадра), что загруженные данные израсходован.

Когда клиент получает WINDOW_UPDATE от server2, он может отправлять дополнительные данные в server2; но также он должен решить, отправлять ли клиенту WINDOW_UPDATE (поскольку его окно управления потоком с клиентом имеет возможность дополнительных 16384 октетов) или подождать еще немного. Например, он может отправлять еще 16384 октетов в server2, и только после получения второго WINDOW_UPDATE от server2 может решить отправить WINDOW_UPDATE клиенту (с обновлением 16384 + 16384 октета).

Как видно из приведенного выше примера, управление потоком между клиентом и связано с независимым от управления потоком от и server2.

Вы также можете прочитать this answer для обсуждения реализаций стратегии управления потоком.

Answer 2

Это зависит от значения прыжков/посредников.

Если посредники находятся на более низких уровнях (шлюзы TCP, NAT, коммутаторы и т. Д.), Тогда они прозрачны для HTTP/2, поскольку управление потоком HTTP/2 применяется сквозным между HTTP/2 клиента и сервера. Их индивидуальные перелеты между ними могут использовать механизмы управления потоком более низкого уровня.

Если ваш посредник является прокси-сервером HTTP, то в основном происходит два отдельных HTTP-запроса, каждый из которых применяет собственный контроль потока. Прокси-приложение несет ответственность за подключение этих отдельных переходов, сохраняя при этом свойства управления потоком. Например. не прочитывая весь ответ со второго прыжка сразу и только затем пересылая его на первый прыжок, но путем потоковой передачи подходящих фрагментов данных.

В случае HTTP-прокси вы даже попадаете в ситуации, когда вы прокси-сервер HTTP/1.1 в HTTP/2 и наоборот. В этих ситуациях они прокси использовали бы механизмы управления потоком HTTP/2, чтобы гарантировать управление потоком для этого перерыва и использовать управление потоком TCP для обеспечения управления потоком на другом скачке. Если тип протокола правильно инкапсулирован в прокси-приложение (это означает, что он будет обеспечивать потоковые операции, которые учитывают управление потоком для типов Request и Response), тогда проксирование потоков между различными типами протоколов не должно быть слишком сложным.