HTTP/2 потоки против HTTP/1.1 соединений

Question

Если мы проигнорируем накладные расходы на создание нового соединения в HTTP/1.1, есть ли случаи, когда соединения работают лучше, чем потоки HTTP/2?

Я провел некоторые тесты производительности для времени загрузки страницы, и я заметил, что HTTP/1.1 (https) работает лучше, чем HTTP/2 для запросов с большими ответами. Затем, когда я начинаю увеличивать уровень параллелизма, HTTP/2 начинает работать лучше. Другими словами, уровень параллелизма, который HTTP/2 начинает давать лучшую производительность, увеличивается с размером ответного сообщения.

Для меня понятно, почему HTTP/2 начинает лучше работать с увеличением уровня параллелизма. Но я не могу понять, почему запросы, возвращающие более крупные ответы, требуют большего параллелизма, чтобы показать лучшую производительность, чем запросы, возвращающие небольшие ответы.

Добавление некоторых результатов испытаний.

Сервер: Причал, Браузер: Хром, Задержка: 100 мс, Пропускная способность: 100 мбит

я восстановил Х количество 100KB изображений с веб-страницы, где Х изменяется от 1 до 500.

Кроме того, при загрузке 100 номеров 1 МБ изображений было получено HTTP/2 на 50% медленнее, чем HTTP/1.1.

Answer 1

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

Обычно браузеры отправляют кадр WINDOW_UPDATE, чтобы увеличить окно управления потоком их сеанса приема (по умолчанию только 65535 октетов) и, следовательно, окно управления потоком сеанса сервера.

Что касается управления потоком HTTP/1, то это дополнительная переменная, которую следует учитывать при сравнении загрузки HTTP/1 и HTTP/2.

Сервер может начать записывать данные, вытолкнуть поток или сеанс управления потоком отправки сеанса и прекратить запись до тех пор, пока клиент не понесет данные и не отправит серверу WINDOW_UPDATE.

С помощью протокола HTTP/2 поток или сеанс могут останавливаться из-за управления потоком, то, что в HTTP/1 не происходит.

В этом случае Jetty может быть сконфигурирован.

Прежде всего, вы можете контролировать, остановился ли сеанс или поток. Это отображается через JMX в реализации FlowControlStrategy (AbstractFlowControlStrategy.get[Session|Stream]StallTime()).

Если вы пытаетесь выполнить тест с HTTP клиента Jetty в/2, а не в браузере, вы можете также настроить когда отправить WINDOW_UPDATE кадров путем настройки параметра BufferingFlowControlStrategy.bufferRatio. Чем ближе к 0.0, тем раньше отправляется кадр WINDOW_UPDATE, тем ближе к 1.0, а затем отправляется кадр WINDOW_UPDATE.

В тесте также следует сообщить о том, что представляет собой межсетевое взаимодействие между клиентом и сервером, поскольку это влияет (часто доминирует) на количество кадров, которое WINDOW_UPDATE принимает для перехода от клиента к серверу.

В идеальной загрузке вы хотите, чтобы клиент отправил фрейм WINDOW_UPDATE достаточно рано, чтобы к тому моменту, когда кадр WINDOW_UPDATE дошел до сервера, сервер еще не использовал окно управления потоком/сеансом отправки потока, и поэтому он будет всегда открывать окно управления потоком отправки и никогда не останавливаться.

Я не знаю, как настраивается , когда браузер отправляет WINDOW_UPDATE кадров, однако для больших загрузок это может повредить скорость загрузки.

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

Наконец, другим параметром, который может влиять на скорость загрузки, является используемый шифра TLS. Может случиться так, что ваше соединение HTTP/1 согласовывает гораздо более слабый шифр, чем согласованный для HTTP/2 (поскольку HTTP/2 требует только очень сильные шифры), поэтому рендеринг даже нестационарной загрузки HTTP/2 медленнее, чем HTTP/1 просто из-за замедления шифрования.