Поиск по сайту:

HTTP/1.1 против HTTP/2: в чем разница?


Автор выбрал программу Write for DOnations.

Введение

Протокол передачи гипертекста, или HTTP, является прикладным протоколом, который был стандартом де-факто для связи во Всемирной паутине с момента его изобретения в 1989 году. С момента выпуска HTTP/1.1 в 1997 году до недавнего времени протокол. Но в 2015 году стала использоваться переосмысленная версия под названием HTTP/2, которая предлагала несколько методов для уменьшения задержки, особенно при работе с мобильными платформами и графикой и видео, интенсивно использующими сервер. С тех пор HTTP/2 становится все более популярным, и, по некоторым оценкам, его поддерживает около трети всех веб-сайтов в мире. В этом меняющемся ландшафте веб-разработчики могут извлечь выгоду из понимания технических различий между HTTP/1.1 и HTTP/2, что позволит им принимать обоснованные и эффективные решения о развитии лучших практик.

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

Фон

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

HTTP/1.1

Разработанный Тимоти Бернерс-Ли в 1989 году в качестве стандарта связи для Всемирной паутины, HTTP представляет собой прикладной протокол верхнего уровня, который обменивается информацией между клиентским компьютером и локальным или удаленным веб-сервером. В этом процессе клиент отправляет текстовый запрос на сервер, вызывая метод, например GET или POST. В ответ сервер отправляет клиенту ресурс, например HTML-страницу.

Например, предположим, что вы посещаете веб-сайт в домене www.example.com. Когда вы переходите по этому URL-адресу, веб-браузер на вашем компьютере отправляет HTTP-запрос в виде текстового сообщения, подобного показанному здесь:

GET /index.html HTTP/1.1
Host: www.example.com

Этот запрос использует метод GET, который запрашивает данные с хост-сервера, указанного после Host:. В ответ на этот запрос веб-сервер example.com возвращает HTML-страницу запрашивающему клиенту в дополнение к любым изображениям, таблицам стилей или другим ресурсам, запрашиваемым в HTML. Обратите внимание, что не все ресурсы возвращаются клиенту при первом вызове данных. Запросы и ответы будут передаваться между сервером и клиентом до тех пор, пока веб-браузер не получит все ресурсы, необходимые для отображения содержимого HTML-страницы на вашем экране.

Вы можете рассматривать этот обмен запросами и ответами как единый прикладной уровень стека интернет-протокола, находящийся поверх уровня передачи (обычно с использованием протокола управления передачей, или TCP) и сетевые уровни (с использованием Интернет-протокола или IP):

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

Закончив с этим базовым обзором HTTP/1.1, мы можем теперь перейти к рассказу о ранней разработке HTTP/2.

HTTP/2

HTTP/2 начинался как протокол SPDY, разработанный в первую очередь в Google с целью уменьшить задержку загрузки веб-страниц с помощью таких методов, как сжатие, мультиплексирование и установка приоритетов. Этот протокол послужил шаблоном для HTTP/2, когда рабочая группа по протоколу передачи гипертекста httpbis из IETF (Internet Engineering Task Force) разработала стандарт, кульминацией чего стала публикация HTTP/2 в мае 2015 года. С самого начала многие браузеры поддержали эти усилия по стандартизации, включая Chrome, Opera, Internet Explorer и Safari. Частично из-за этой поддержки браузера с 2015 года наблюдается значительный уровень внедрения протокола, особенно высокий уровень среди новых сайтов.

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

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

Модели доставки

Как упоминалось в предыдущем разделе, HTTP/1.1 и HTTP/2 имеют общую семантику, гарантируя, что запросы и ответы, передаваемые между сервером и клиентом по обоим протоколам, достигают места назначения в виде традиционно отформатированных сообщений с заголовками и телами с использованием знакомых методов, таких как GET и POST. Но в то время как HTTP/1.1 передает их в виде простых текстовых сообщений, HTTP/2 кодирует их в двоичный код, что позволяет использовать значительно отличающиеся возможности модели доставки. В этом разделе мы сначала кратко рассмотрим, как HTTP/1.1 пытается оптимизировать эффективность с помощью своей модели доставки, и проблемы, возникающие в связи с этим, а затем преимущества двоичного уровня кадрирования HTTP/2 и описание того, как он расставляет приоритеты. Запросы.

HTTP/1.1 — Конвейерная обработка и блокировка заголовка строки

Первый ответ, который клиент получает на HTTP-запрос GET, часто не является полностью отображаемой страницей. Вместо этого он содержит ссылки на дополнительные ресурсы, необходимые запрашиваемой странице. Клиент обнаруживает, что для полного рендеринга страницы требуются эти дополнительные ресурсы с сервера, только после загрузки страницы. Из-за этого клиенту придется делать дополнительные запросы для получения этих ресурсов. В HTTP/1.0 клиенту приходилось разрывать и переустанавливать TCP-соединение при каждом новом запросе, что требовало больших затрат времени и ресурсов.

HTTP/1.1 решает эту проблему, вводя постоянные соединения и конвейерную обработку. С постоянными соединениями HTTP/1.1 предполагает, что TCP-соединение должно оставаться открытым, если только прямо не указано закрыть. Это позволяет клиенту отправлять несколько запросов по одному и тому же соединению, не дожидаясь ответа на каждый из них, что значительно повышает производительность HTTP/1.1 по сравнению с HTTP/1.0.

К сожалению, у этой стратегии оптимизации есть естественное узкое место. Поскольку несколько пакетов данных не могут передаваться друг другу при перемещении к одному и тому же месту назначения, бывают ситуации, когда запрос в начале очереди, который не может получить требуемый ресурс, блокирует все последующие запросы. Это известно как блокировка заголовка строки (HOL) и представляет собой серьезную проблему с оптимизацией эффективности подключения в HTTP/1.1. Добавление отдельных параллельных TCP-соединений может решить эту проблему, но существуют ограничения на количество одновременных TCP-соединений, возможных между клиентом и сервером, и каждое новое соединение требует значительных ресурсов.

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

HTTP/2 — преимущества уровня двоичного кадрирования

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

Давайте подробнее рассмотрим, как это работает. В отличие от HTTP/1.1, который должен использовать несколько TCP-соединений, чтобы уменьшить эффект блокировки HOL, HTTP/2 устанавливает один объект соединения между двумя машинами. В этом соединении есть несколько потоков данных. Каждый поток состоит из нескольких сообщений в знакомом формате запрос/ответ. Наконец, каждое из этих сообщений разбито на более мелкие блоки, называемые фреймами:

На самом детальном уровне канал связи состоит из группы двоично-кодированных кадров, каждый из которых помечен для определенного потока. Идентифицирующие теги позволяют соединению чередовать эти кадры во время передачи и собирать их на другом конце. Чередующиеся запросы и ответы могут выполняться параллельно, не блокируя последующие сообщения. Этот процесс называется мультиплексированием. Мультиплексирование решает проблему блокировки начала строки в HTTP/1.1, гарантируя, что ни одному сообщению не придется ждать завершения другого. Это также означает, что серверы и клиенты могут одновременно отправлять запросы и ответы, что обеспечивает больший контроль и более эффективное управление соединениями.

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

Одно соединение TCP также повышает производительность протокола HTTPS, поскольку клиент и сервер могут повторно использовать один и тот же защищенный сеанс для нескольких запросов/ответов. В HTTPS во время рукопожатия TLS или SSL обе стороны договариваются об использовании одного ключа на протяжении всего сеанса. Если соединение разрывается, начинается новый сеанс, требующий вновь сгенерированного ключа для дальнейшего взаимодействия. Таким образом, поддержка одного соединения может значительно сократить ресурсы, необходимые для производительности HTTPS. Обратите внимание, что хотя спецификации HTTP/2 не требуют обязательного использования уровня TLS, многие основные браузеры поддерживают только HTTP/2 с HTTPS.

Хотя мультиплексирование, присущее двоичному уровню кадрирования, решает некоторые проблемы HTTP/1.1, несколько потоков, ожидающих одного и того же ресурса, все равно могут вызывать проблемы с производительностью. Однако дизайн HTTP/2 учитывает это, используя приоритезацию потоков, тему, которую мы обсудим в следующем разделе.

HTTP/2 — приоритизация потоков

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

Как вы теперь знаете, уровень двоичного кадрирования организует сообщения в параллельные потоки данных. Когда клиент отправляет одновременные запросы на сервер, он может расставить приоритеты для запрашиваемых ответов, назначив каждому потоку вес от 1 до 256. Большее число указывает на более высокий приоритет. В дополнение к этому клиент также указывает зависимость каждого потока от другого потока, указывая идентификатор потока, от которого он зависит. Если родительский идентификатор опущен, считается, что поток зависит от корневого потока. Это показано на следующем рисунке:

На иллюстрации канал содержит шесть потоков, каждый из которых имеет уникальный идентификатор и связан с определенным весом. Поток 1 не имеет связанного с ним родительского идентификатора и по умолчанию связан с корневым узлом. Все остальные потоки имеют помеченный родительский идентификатор. Распределение ресурсов для каждого потока будет основываться на их весе и требуемых зависимостях. Например, потоки 5 и 6, которым на рисунке присвоен одинаковый вес и один и тот же родительский поток, будут иметь одинаковый приоритет при распределении ресурсов.

Сервер использует эту информацию для создания дерева зависимостей, которое позволяет серверу определять порядок, в котором запросы будут извлекать свои данные. На основе потоков на предыдущем рисунке дерево зависимостей будет выглядеть следующим образом:

В этом дереве зависимостей поток 1 зависит от корневого потока, и нет другого потока, производного от корня, поэтому все доступные ресурсы будут выделяться потоку 1 раньше других потоков. Поскольку дерево показывает, что поток 2 зависит от завершения потока 1, поток 2 не будет продолжаться до тех пор, пока задача потока 1 не будет завершена. Теперь давайте посмотрим на потоки 3 и 4. Оба этих потока зависят от потока 2. Как и в случае с потоком 1, поток 2 получит все доступные ресурсы раньше, чем потоки 3 и 4. После того, как поток 2 выполнит свою задачу, потоки 3 и 4 получат ресурсы; они разделены в соотношении 2:4, как указано их весами, что приводит к большему количеству ресурсов для потока 4. Наконец, когда поток 3 завершится, потоки 5 и 6 получат доступные ресурсы в равных частях. Это может произойти до того, как поток 4 завершит свою задачу, даже если поток 4 получает больший объем ресурсов; потоки на более низком уровне могут запускаться, как только завершатся зависимые потоки на более высоком уровне.

Как разработчик приложения, вы можете устанавливать веса в своих запросах в зависимости от ваших потребностей. Например, вы можете назначить более низкий приоритет для загрузки изображения с высоким разрешением после предоставления эскиза изображения на веб-странице. Предоставляя эту возможность присвоения весов, HTTP/2 позволяет разработчикам лучше контролировать отрисовку веб-страницы. Протокол также позволяет клиенту изменять зависимости и перераспределять веса во время выполнения в ответ на действия пользователя. Однако важно отметить, что сервер может самостоятельно изменить назначенные приоритеты, если доступ определенного потока к определенному ресурсу заблокирован.

Переполнение буфера

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

Однако бывают ситуации, когда буфера недостаточно. Например, сервер может передавать большой объем данных со скоростью, с которой клиентское приложение не может справиться из-за ограниченного размера буфера или более низкой пропускной способности. Аналогичным образом, когда клиент загружает на сервер большое изображение или видео, буфер сервера может переполниться, что приведет к потере некоторых дополнительных пакетов.

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

HTTP/1.1

В HTTP/1.1 управление потоком зависит от базового TCP-соединения. Когда это соединение инициируется, и клиент, и сервер устанавливают свои размеры буфера, используя свои системные настройки по умолчанию. Если буфер получателя частично заполнен данными, он сообщит отправителю свое окно приема, т. е. объем доступного пространства, оставшегося в его буфере. Это окно приема объявляется в сигнале, известном как пакет ACK, который является пакетом данных, который получатель отправляет, чтобы подтвердить получение сигнала открытия. Если этот объявленный размер окна приема равен нулю, отправитель больше не будет отправлять данные, пока клиент не очистит свой внутренний буфер, а затем не запросит возобновление передачи данных. Здесь важно отметить, что использование окон приема на основе базового TCP-соединения может реализовать управление потоком только на любом конце соединения.

Поскольку HTTP/1.1 полагается на транспортный уровень, чтобы избежать переполнения буфера, для каждого нового TCP-соединения требуется отдельный механизм управления потоком. Однако HTTP/2 мультиплексирует потоки в одном TCP-соединении и должен будет реализовать управление потоком другим способом.

HTTP/2

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

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

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

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

Прогнозирование запросов ресурсов

В типичном веб-приложении клиент отправляет запрос GET и получает страницу в формате HTML, обычно индексную страницу сайта. Изучая содержимое страницы индекса, клиент может обнаружить, что ему необходимо получить дополнительные ресурсы, такие как файлы CSS и JavaScript, чтобы полностью отобразить страницу. Клиент определяет, что ему нужны эти дополнительные ресурсы, только после получения ответа на свой первоначальный запрос GET, и поэтому должен сделать дополнительные запросы для получения этих ресурсов и завершения сборки страницы. Эти дополнительные запросы в конечном итоге увеличивают время загрузки соединения.

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

HTTP/1.1 — встраивание ресурсов

В HTTP/1.1, если разработчик заранее знает, какие дополнительные ресурсы потребуются клиентскому компьютеру для отображения страницы, он может использовать метод, называемый встраивание ресурсов, чтобы включить требуемый ресурс непосредственно в документ HTML, который сервер отправляет в ответ на первоначальный запрос GET. Например, если клиенту нужен определенный файл CSS для отображения страницы, встраивание этого файла CSS предоставит клиенту необходимый ресурс до того, как он его запросит, что уменьшит общее количество запросов, которые должен отправить клиент.

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

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

HTTP/2 — отправка сервера

Поскольку HTTP/2 допускает несколько одновременных ответов на исходный запрос GET клиента, сервер может отправить ресурс клиенту вместе с запрошенной HTML-страницей, предоставив ресурс до того, как клиент запросит его. Этот процесс называется отправка на сервер. Таким образом, соединение HTTP/2 может достичь той же цели встраивания ресурсов, сохраняя при этом разделение между отправленным ресурсом и документом. Это означает, что клиент может решить кэшировать или отклонить отправленный ресурс отдельно от основного HTML-документа, устраняя основной недостаток встраивания ресурсов.

В HTTP/2 этот процесс начинается, когда сервер отправляет кадр PUSH_PROMISE, чтобы сообщить клиенту, что он собирается передать ресурс. Этот фрейм включает только заголовок сообщения и позволяет клиенту заранее знать, какой ресурс будет отправлен сервером. Если ресурс уже кэширован, клиент может отклонить отправку, отправив в ответ кадр RST_STREAM. Фрейм PUSH_PROMISE также избавляет клиента от отправки дублирующего запроса на сервер, поскольку он знает, какие ресурсы сервер собирается отправить.

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

Хотя эта функция имеет большой потенциал, отправка на сервер не всегда является ответом на оптимизацию вашего веб-приложения. Например, некоторые веб-браузеры не всегда могут отменить принудительные запросы, даже если клиент уже кэшировал ресурс. Если клиент по ошибке разрешает серверу отправить дубликат ресурса, отправка сервера может излишне использовать соединение. В конце концов, серверный толчок должен использоваться на усмотрение разработчика. Чтобы узнать больше о том, как стратегически использовать push-уведомления сервера и оптимизировать веб-приложения, ознакомьтесь с информацией о том, как HTTP/2-push сложнее, чем я думал.

Сжатие

Распространенным методом оптимизации веб-приложений является использование алгоритмов сжатия для уменьшения размера сообщений HTTP, которые передаются между клиентом и сервером. Оба HTTP/1.1 и HTTP/2 используют эту стратегию, но в первом есть проблемы с реализацией, которые запрещают сжатие всего сообщения. В следующем разделе мы обсудим, почему это так, и как HTTP/2 может предоставить решение.

HTTP/1.1

Такие программы, как gzip, уже давно используются для сжатия данных, отправляемых в HTTP-сообщениях, особенно для уменьшения размера файлов CSS и JavaScript. Однако компонент заголовка сообщения всегда отправляется в виде обычного текста. Несмотря на то, что каждый заголовок довольно мал, бремя этих несжатых данных ложится на соединение все тяжелее и тяжелее по мере того, как делается больше запросов, особенно налагая штрафы на сложные веб-приложения с большим количеством API, которые требуют много разных ресурсов и, следовательно, много разных запросов ресурсов. Кроме того, использование файлов cookie иногда может сделать заголовки намного больше, что увеличивает потребность в каком-либо сжатии.

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

HTTP/2

Одной из тем, которая снова и снова поднималась в HTTP/2, является его способность использовать уровень двоичного кадрирования для демонстрации большего контроля над более мелкими деталями. То же самое относится и к сжатию заголовков. HTTP/2 может отделять заголовки от их данных, в результате чего получается кадр заголовка и кадр данных. Затем программа сжатия HTTP/2 HPACK может сжать этот кадр заголовка. Этот алгоритм может кодировать метаданные заголовка с использованием кодирования Хаффмана, тем самым значительно уменьшая его размер. Кроме того, HPACK может отслеживать ранее переданные поля метаданных и дополнительно сжимать их в соответствии с динамически изменяемым индексом, совместно используемым клиентом и сервером. Например, возьмем следующие два запроса:

method:		GET
scheme:		https
host:		example.com
path:		/academy
accept:		/image/jpeg
user-agent:	Mozilla/5.0 ...
method:		GET
scheme:		https
host:		example.com
path:		/academy/images
accept:		/image/jpeg
user-agent:	Mozilla/5.0 ...

Различные поля в этих запросах, такие как method, scheme, host, accept и user -agent, имеют те же значения; только поле path использует другое значение. В результате при отправке Request #2 клиент может использовать HPACK для отправки только индексированных значений, необходимых для восстановления этих общих полей и нового кодирования поля path. Результирующие кадры заголовков будут следующими:

method:		GET
scheme:		https
host:		example.com
path:		/academy
accept:		/image/jpeg
user-agent:	Mozilla/5.0 ...
path:		/academy/images

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

Заключение

Как видно из этого пошагового анализа, HTTP/2 во многом отличается от HTTP/1.1: некоторые функции обеспечивают более высокий уровень контроля, который можно использовать для лучшей оптимизации производительности веб-приложений, а другие функции просто улучшают производительность веб-приложений. предыдущий протокол. Теперь, когда вы получили общее представление о различиях между двумя протоколами, вы можете рассмотреть, как такие факторы, как мультиплексирование, приоритизация потоков, управление потоком, отправка сервером и сжатие в HTTP/2, повлияют на меняющийся ландшафт веб-разработки. .

Если вы хотите увидеть сравнение производительности между HTTP/1.1 и HTTP/2, ознакомьтесь с этим руководством Как настроить Nginx с поддержкой HTTP/2 в Ubuntu 20.04.