Сжатие заголовка HTTP/2

Question

Поскольку я не эксперт, у меня есть общий вопрос относительно HTTP/2.

Как известно, HTTP2 сжимает заголовки, чтобы уменьшить размер сообщения. Это относится только к ответу или также к запросу? Если выполнить небольшой эксперимент и запустить два небольших HTTP-сервера, один из которых использует версию 1.1, а другой, использующий версию 2, пусть оба отправят то же самое содержимое, а затем запросят обе страницы в Firefox, я вижу, что размер заголовка ответа значительно меньше для версия HTTP/2. Однако размер заголовка запроса почти такой же. В моем понимании это имеет смысл, потому что браузер не знает заранее, если сервер поддерживает протокол HTTP/2 и, следовательно, не может сжимать заголовки заранее. Я прав? И если это так, есть ли способ «принудить» клиента к использованию HTTP/2 (с клиентом я имею в виду не плюшевый, а программный), а также сжимать заголовки запросов?

И еще один вопрос: если бы я захотел оценить производительность HTTP/1.1 по сравнению с HTTP/2 под нагрузкой, как бы выглядела полезная тестовая установка, какие параметры были бы разнообразны и какие показатели имели бы смысл для измерения (RTT , TTFB, ...?)

Answer 1

При запуске соединения вы согласовываете протокол. Клиент должен знать, говорит ли он HTTP/1.1, HTTP/2 или что-то еще, прежде чем он узнает формат отправки. Для соединений HTTPS это осуществляется путем согласования соединения TLS с использованием ALPN.

Можно также запустить HTTP/1.1 для первых (или более) запросов, а затем перейти на HTTP/2 на более позднем этапе. Это обрабатывается поддержкой рекламы h2 сервера по HTTP/1.1-соединению, отправив в ответ HTTP-заголовок Upgrade: h2 (для HTTPS) или Upgrade: h2c (для HTTP), а затем клиент может выбрать обновление. Это более полезно для HTTP-соединений, где нет согласования TLS, поэтому клиент, скорее всего, предположил бы HTTP/1.1. Однако все веб-браузеры заявили, что не будут поддерживать HTTP/2 через HTTP (h2c) и будут поддерживать только HTTPS (h2). Я, честно говоря, не могу придумать, почему соединение HTTPS начнется в HTTP/1.1, а затем обновится до HTTP/2 - вместо того, чтобы просто начинать с HTTP/2 с выхода, но теоретически это возможно.

Вы можете увидеть пример заголовка обновления, нажав на эту ссылку: https://securityheaders.io/?q=https%3A%2F%2Fwww.tunetheweb.com&followRedirects=on Примечание Я только с помощью securityheaders.io сайт как быстрый способ, чтобы показать HTTP заголовки. В теории вы могли бы увидеть то же самое, перейдя непосредственно к https://www.tunetheweb.com с вашим браузером и посмотрев заголовки ответов, но это очень вероятно, что это будет сделано через HTTP/2, поэтому не будет заголовка. Также обратите внимание, что это необязательный заголовок, а не все серверы HTTP/2 отправляют его (Apache делает, например, NGINX) - возможно, потому, что это не так полезно для HTTPS, как обсуждалось выше.

Важно понимать, как сжатие работает через HTTP/2. Для начала вы получаете выгоду от того, что это бинарный, а не текстовый протокол, поэтому там есть сбережения. Однако основная экономия - это избежать повторения, создав словарь заголовков. Это означает, что самый первый запрос будет иметь полный размер, и только последующие запросы будут меньше, поскольку они заменят фактические заголовки ссылками на словарь. И аналогичные для заголовков ответов (сжатие используется для обоих).

Я уверен (хотя и не на 100%), что браузеры показывают полный размер без учета сжатия HTTP/2 HPACK, так как это нормально на более низком уровне (хотя большинство из них показывают две цифры - как с, так и без gzip, но это другое). Чтобы просмотреть фактические данные и данные HTTP/2, вам нужно будет использовать инструмент, например, проводную акулу или страницу чистых внутренних страниц Chrome. См. Эту страницу для некоторых предлагаемых инструментов: https://community.akamai.com/community/web-performance/blog/2015/06/05/useful-tools-for-http2-debugging. Другое замечание состоит в том, что размер заголовка часто крошечный по сравнению с большинством тел.

Что касается инструментов сравнения производительности, которые являются массивной темой, выходящей за пределы переполнения стека, так как существует так много переменных, которые будут влиять на это (например, местоположение сети, время задержки и пропускная способность - влияет на программную реализацию HTTP/2 на браузере и клиентская сторона ... и т.п.). Лучшее, что я могу предложить, - это как можно больше тиражировать типичные настройки ваших пользователей и повторять тесты столько, сколько вы можете или использовать показатели RUM (реального пользователя) в аналитическом программном обеспечении, например. HTTP/2 должен ускорить работу большинства сайтов, но это не так. Эта веб-страница является хорошим примером сайта с ограниченной пропускной способностью, который на самом деле медленнее через соединение HTTP/2 без настройки: https://99designs.ie/tech-blog/blog/2016/07/14/real-world-http-2-400gb-of-images-per-day/

Надеюсь, что это поможет.