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

Протокол передачи гипертекста, или HTTP, является протоколом приложения, который является стандартом де-факто для связи во всемирной сети с момента его изобретения в 1989 году. Начиная с выпуска HTTP / 1.1 в 1997 году и до недавнего времени в протокол было внесено несколько изменений. Но в 2015 году появилась новая версия HTTP / 2, в которой предлагалось несколько способов уменьшения задержки, особенно при работе с мобильными платформами, а также с графикой и видео, интенсивно использующими сервер. HTTP/2 has since become increasingly popular, with some estimates suggesting that around a third of all websites in the world support it. В этом меняющемся ландшафте веб-разработчики могут извлечь выгоду из понимания технических различий между HTTP / 1.1 и HTTP / 2, что позволяет им принимать обоснованные и эффективные решения в отношении развития передового опыта.

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

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

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

[[http-1-1 -—- pipelining-and-head-of-line-blocking]] === HTTP / 1.1 - конвейерная обработка и блокировка заголовка строки

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

HTTP/1.1 takes care of this problem by introducing persistent connections and pipelining. При постоянных соединениях HTTP / 1.1 предполагает, что TCP-соединение должно оставаться открытым, если не указано прямое закрытие. Это позволяет клиенту отправлять несколько запросов по одному и тому же соединению, не ожидая ответа на каждый, что значительно повышает производительность HTTP / 1.1 по сравнению с HTTP / 1.0.

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

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

[[http-2 -—- преимущества-уровня-двоичного-кадрирования]] === HTTP / 2 - Преимущества уровня двоичного кадрирования

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

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

На самом детальном уровне канал связи состоит из набора двоично-кодированных кадров, каждый из которых помечен для определенного потока. Идентификационные теги позволяют соединению чередовать эти кадры во время передачи и повторно собирать их на другом конце. Чередующиеся запросы и ответы могут выполняться параллельно, не блокируя стоящие за ними сообщения; этот процесс называетсяmultiplexing. Мультиплексирование решает проблему блокировки заголовка строки в 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 -—- stream-Prioritization]] === HTTP / 2 - Stream Prioritization

Приоритизация потоков не только решает возможную проблему запросов, конкурирующих за один и тот же ресурс, но также позволяет разработчикам настраивать относительный вес запросов для лучшей оптимизации производительности приложений. В этом разделе мы разберем процесс расстановки приоритетов, чтобы лучше понять, как можно использовать эту функцию 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 используют разные версии этого механизма для управления потоком данных в соответствии с их различными моделями доставки.

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

Однако есть решения этой проблемы: поскольку сервер заранее знает, что клиенту потребуются дополнительные файлы, сервер может сэкономить время клиента, отправляя эти ресурсы клиенту, прежде чем он их запросит. HTTP/1.1 and HTTP/2 have different strategies of accomplishing this, each of which will be described in the next section.

[[http-1-1 -—- resource-inlining]] === HTTP / 1.1 - Resource Inlining

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

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

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

[[http-2 -—- server-push]] === HTTP / 2 - Server Push

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

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

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

Хотя эта функция имеет большой потенциал, использование сервера не всегда является ответом на оптимизацию вашего веб-приложения. Например, некоторые веб-браузеры не всегда могут отменить отправленные запросы, даже если клиент уже кэшировал ресурс. Если клиент по ошибке разрешает серверу отправлять дублирующийся ресурс, сервер push может излишне израсходовать соединение. В конце концов, серверный push должен использоваться по усмотрению разработчика. Чтобы узнать больше о том, как стратегически использовать push-уведомления сервера и оптимизировать веб-приложения, ознакомьтесь сPRPL pattern, разработанным Google. Чтобы узнать больше о возможных проблемах с сервером push, см. Сообщение в блоге Джейка АрчибальдаHTTP/2 push is tougher than I thought.

Распространенным методом оптимизации веб-приложений является использование алгоритмов сжатия для уменьшения размера HTTP-сообщений, которые передаются между клиентом и сервером. HTTP/1.1 and HTTP/2 both use this strategy, but there are implementation problems in the former that prohibit compressing the entire message. В следующем разделе будет обсуждаться, почему это так, и как HTTP / 2 может обеспечить решение.

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

Если вы хотите увидеть сравнение производительности между HTTP / 1.1 и HTTP / 2, посмотрите этотGoogle demo, который сравнивает протоколы для разных задержек. Обратите внимание, что при запуске теста на вашем компьютере время загрузки страницы может варьироваться в зависимости от нескольких факторов, таких как пропускная способность, ресурсы клиента и сервера, доступные на момент тестирования, и так далее. Если вы хотите изучить результаты более полного тестирования, ознакомьтесь со статьейHTTP/2 – A Real-World Performance Test and Analysis. Наконец, если вы хотите изучить, как создать современное веб-приложение, вы можете следовать нашему руководствуHow To Build a Modern Web Application to Manage Customer Information with Django and React on Ubuntu 18.04 или настроить свой собственный сервер HTTP / 2 с помощью нашего руководстваHow To Set Up Nginx with HTTP/2 Support on Ubuntu 16.04.