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

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

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

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

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

изображение: https: //assets.digitalocean.com/articles/cart_63893/Protocol_Stack.png [стек протоколов Интернета]

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

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

изображение: https: //assets.digitalocean.com/articles/cart_63893/Streams_Frames.png [потоки, сообщения и кадры]

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

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

изображение: https: //assets.digitalocean.com/articles/cart_63893/Stream_Priority2.png [Приоритет потока]

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

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

изображение: http: //assets.digitalocean.com/articles/cart_63893/Dependency_Tree.png [Дерево зависимостей]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Запрос № 1

Запрос № 2

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

Рамка заголовка для запроса № 1

Рамка заголовка для запроса № 2

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