Протокол HTTP 1.1 служил верой и правдой почти 20 лет, так что появление новой спецификации было лишь вопросом времени. Его заменил HTTP/2, официально принятый в прошлом году и основанный на протоколе SPDY, разработанном Google.

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

Для включения в Nginx (версия 1.9.5 или выше) в файле конфигурации (секция server) необходимо дополнить директиву listen:

Server { listen 443 ssl http2; server_name example.com; ssl_certificate server.crt; ssl_certificate_key server.key; }

# Nginx поддерживает HTTP/2 только в паре с TLS

Ну а в Apache (начиная с версии 2.4.17 и выше) нужно дополнить файл конфигурации:

# for a https server Protocols h2 http/1.1 # for a http server Protocols h2c http/1.1

# Поддержка HTTP/2 для защищенного и незащищенного подключения

Во-вторых, все новые версии самых популярных браузеров тоже поддерживают HTTP/2.

Ну и в-третьих, новая спецификация намного быстрее и производительнее HTTP 1.1. К тому же, более 7.1 % веб-сайтов по данным W3Techs уже поддерживают HTTP/2.

Главные отличия HTTP/2 от HTTP 1.1

Основных отличий между протоколами всего несколько.

Бинарность

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

Мультиплексирование

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

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

Приоритизация

Вместе с мультиплексированием появилась приоритизация трафика. Запросам можно назначить приоритет на основе важности и зависимости.

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

Компрессия заголовков HPACK

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

Server Push

При использовании протокола HTTP 1.1 браузер запрашивает страницу, сервер отправляет в ответ HTML и ждет, пока браузер его обработает и запросит все необходимые файлы: JavaScript, CSS и фото. Поэтому в новый протокол внедрили интересную функцию под названием Server Push.

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

Шифрование

Протокол HTTP/2 не требует шифрования канала. Тем не менее, все современные браузеры работают с HTTP/2 только вместе с TLS , как и Nginx. Так что массовое внедрение протокола должно поспособствовать распространению шифрования по Сети.

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

Оптимизация HTTP/2

Главная оптимизация HTTP/2 по сравнению с HTTP 1.1 — отключение или модификация многих оптимизаций прошлой версии протокола.

• Стоит отказаться от доменного шардинга. Такой способ распределения множества файлов по различным доменам и CDN актуален для HTTP 1.1, так как решает проблему параллельных соединений. Но в случае с новым протоколом такое решение ухудшает производительность и нивелирует приоритизацию трафика.
• По возможности откажитесь или модифицируйте спрайты. Объединение множества маленьких картинок в одно большое изображение способно увеличить скорость загрузки страницы, но если пользователь заходил на веб-страницу с одной маленькой картинкой, то ему все-равно отправлялся весь спрайт. В случае с HTTP/2 такое решение будет менее полезным в виду появления мультиплексирования.
• Еще один метод оптимизации изображений — встраивание при помощи DataURI. Он также может быть полезен в HTTP/2, но точно будет менее эффективным, чем в случае с прошлой версией.
• Лучше отказаться от объединения (конкатенации) файлов. Метод похож на спрайты — все необходимые файлы, CSS и JavaScript, объединяются в один большой для передачи одним потоком по одному соединению. Так что если пользователь зашел на страницу с одним небольшим кодом JS, ему все-равно будет отправлен весь объединенный файл. Еще одна сложность — все объединенные файлы нужно выгружать из кэша одновременно, а одно изменение в коде любого из них требует обновления всего набора. Так что благодаря все тому же мультиплексированию такой подход не имеет смысла.
• Также стоит отказаться от встраивания файлов в HTML код.

Самое главное

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

В прошлом году в мире сетевых технологий произошло очень важное событие: была утверждена и стандартизирована новая версия протокола HTTP — HTTP/2. HTTP/2 уже поддерживается в популярных веб-серверах: Apache и Nginx. Идёт работа по внедрению HTTP/2 в IIS. Реализована поддержка и в большинстве современных браузеров.

Использование HTTP/2 за последнее время существенно расширилось.

По данным на середину 2015 года, процент сайтов и веб-сервисов, перешедших на HTTP/2, был невелик ― всего 0,4%. Совсем свежая статистика (январь 2016) свидетельствует о значительном росте: с 0,4 до 6,5%. Есть все основания полагать, что в ближайшее время темпы роста будут увеличиваться.

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

От HTTP к HTTP/2

Немного истории

Из-за ограничения на количество одновременных подключений в HTTP/1.1 загрузка страниц, содержащих большое количество «тяжёлого» контента, осуществляется медленно. Можно выделить два пути решения этой проблемы. Первый заключается в использовании различных техник оптимизации производительности (о некоторых из них мы уже писали), а второй — в попытке модификации самого протокола HTTP с целью устранения возможных узких мест. Рассмотрим такие попытки более подробно.

Первый масштабный проект реформирования HTTP был представлен в 2009 году инженерами Google. Это протокол SPDY , целью которого в первую очередь было ускорение работы веб-сайтов и приложений путём модификации традиционных способов приёма и отправки запросов.

SPDY требует поддержки как на стороне сервера, так и на стороне клиента. Разработчики Google создали специализированные модули для Apache (mod_spdy) и для Nginx (ngx_http_spdy_module). Поддерживается он и практически во всех популярных браузерах.

HTTP/2, представленный шестью годами позже, во многом основывается на SPDY. Новая версия HTTP была создана рабочей группой Hypertext Transfer Protocol working group. В мае 2015 года спецификация HTTP/2 была опубликована как RFC 7540 .

Протокол HTTP/2 обратно совместим с HTTP/1.1. Изменения, направленные на устранение узких мест и повышения производительности, во многом продолжают линию SPDY. Рассмотрим вкратце наиболее важные из них.

HTTP/2: основные нововведения

Мультиплексирование

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

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

Приоритеты

В первом подходе каждый поток получает определённый вес. Потом на основе веса сервер распределяет нагрузку между потоками. Такой подход уже использовался в протоколе SPDY.

Второй метод, являющийся основным в HTTP/2, заключается в следующем: браузер просит сервер загружать определённые элементы контента в первую очередь. Например, браузер может попросить сервер сначала загрузить CSS-файлы или JavaScript, а уже потом — HTML или изображения.

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

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

В HTTP/2 заголовки передаются в сжатом виде. Благодаря этому уменьшается количество информации, которой обмениваются между собой сервер и браузер. Вместо алгоритмов gzip/deflate используется HPACK . Это снижает уязвимость к атакам типа BREACH .

HTTP/2 и безопасность

Это нужно не только для HTTP/2. В поиске Google использование безопасного соединения является одним из критериев ранжирования . Браузеры (см. и ) скоро будут помечать сайты, не поддерживающие https, как «небезопасные». Добавим также, что многие возможности HTML5 ― например, геолокация ― без безопасного соединения будут недоступны .

Базовая настройка HTTP/2 в Nginx и Apache

Nginx

После этого откройте конфигурационный файл /etc/nginx/nginx.conf и найдите в секции server следующую строку:

Listen 443 ssl;

И замените её на:

Listen 443 ssl http2;

Сохраните внесённые изменения и перезагрузите Nginx:

$ sudo service nginx reload

Apache

# for a https server Protocols h2 http/1.1 # for a http server Protocols h2c http/1.1

После этого перезапустите Apache. Вот и всё — для базовой настройки этого вполне достаточно.

HTTP/2 и оптимизация сайтов

Многие способы оптимизации, успешно используемые в HTTP/1.1, в HTTP/2 работать не будут. Некоторые из них потребуется модифицировать, а от некоторых ― отказаться вообще. Рассмотрим этот вопрос более подробно.

Объединение изображений в спрайты

Спрайт возвращался в ответ на единственный запрос. Даже если пользователь заходил на страницу, на которой находится всего одно небольшое изображение, нужно было загрузить весь спрайт.

В HTTP/2 c его мультиплексированием таких проблем нет, однако использование спрайтов в определённых ситуациях может оказаться полезным. Объединение нескольких изображений в спрайт (особенно если все эти изображения находятся на одной странице) помогает улучшить сжатие и таким образом снизить общий объём загружаемых данных.

Встраивание изображений с помощью DataURI

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

Конкатенация JS и CSS

Однако при использовании конкатенации может возникнуть та же проблема, что и со спрайтами: зайдя на какую-то одну страницу сайта, пользователь загрузит все используемые на нём СSS- и JS-файлы (при этом очень вероятно, что большинство из этих файлов ему никогда не понадобятся). Конечно, можно тщательно отбирать файлы для каждой страницы сайта, но это будет занимать слишком много времени.

Ещё одна сложность заключается в том, что все элементы конкатенированного файла нужно вычищать из кэша одновременно. Невозможно сделать так, чтобы для одних элементов была выставлена одна дата истечения срока действия, а для других (которые к тому же и используются гораздо чаще) — другая. Если изменить хотя бы одну строку в CSS — срок действия истечёт сразу у всех элементов.

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

Доменное шардирование

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

Когда переходить?

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

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

Полезные ссылки

Протокол передачи гипертекста (HTTP ) управляет соединением между сервером и браузерами. Впервые с 1999 года мы получили новую версию этого протокола , и она обещает существенно более быстрые сайты для всех.

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

Краткая история HTTP

HTTP – это старый протокол, изначально определённый в 1991 году , и в последний раз серьёзно изменённый в версии HTTP/1.1 .

Сайты в 1999 году сильно отличались от тех, которые мы разрабатываем сегодня. Сейчас, чтобы отобразить домашнюю страницу среднего сайта, требуется 1,9 Мб. При этом загружается более 100 отдельных ресурсов, от изображений и шрифтов до файлов JavaScript и CSS .

HTTP/1.1 плохо работает с большим количеством ресурсов. Поэтому лучшие практики оптимизации направлены на повышение производительности этой версии протокола.

SPDY

В 2009 году два инженера корпорации Google рассказали про исследовательский проект под названием SPDY . Этот проект был нацелен на решение проблем, связанных с работой протокола HTTP/1.1. SPDY позволяет:

• Использовать конкурирующие запросы в одном соединении TCP (мультиплексирование ).
• Браузерам устанавливать приоритеты так, чтобы ресурсы, важные для отображения страницы, загружались первыми.
• Сжимать и уменьшать заголовки HTTP
• Реализовать технологию server push , в рамках которой сервер может пересылать браузеру важные ресурсы, прежде чем его об этом попросят.

В добавление к этому SPDY обязывает шифровать соединение (HTTPS ) между браузером и сервером.

SPDY не заменяет HTTP . Он скорее является туннелем для протокола и изменяет процесс отправки запросов и ответов HTTP . Для него обязательна поддержка, как на стороне сервера, так и на стороне клиента. Благодаря поддержке, доступной в NGNIX и пакетах от Google для Apache , SPDY применялся достаточно широко. При этом современные версии основных браузеров поддерживают его в полном объеме.

Поддержка SPDY браузерами по данным « Can I Use »

HTTP/2

Поддержка SPDY была прекращена в Edge из-за того, что специалисты Microsoft реализовали в новом браузере поддержку HTTP/2 – последней по времени выхода версии протокола HTTP . Но другие современные браузеры всё ещё сохраняют поддержку SPDY .

Поддержка HTTP /2 браузерами по данным « Can I Use »

HTTP/2 строится на успехе SPDY , который был использован как стартовая платформа для нового протокола. При этом большинство задач SPDY так же реализовано в HTTP/2 . Требование соединения по HTTPS было отменено . Несмотря на это, разработчики всех браузеров решили реализовать поддержку HTTP/2 только для TLS (https ) соединений. Поэтому использования HTTP/2 подразумевает использование сайтом HTTPS .

Спецификация HTTP/2 была завершена в феврале 2015 года. Спустя год он прекрасно поддерживается браузерами. Так же, как и SPDY , HTTP/2 предполагает поддержку, как в браузере, так и на сервере.

Уже существует много его реализаций для серверов. Вы можете следить за ними в справочнике по HTTP/2 .

Придётся ли изменять сайты?

HTTP/2 обратно совместим с HTTP/1.1 , поэтому есть возможность его проигнорировать, и всё продолжит работать, как раньше. Изменение протокола незаметно для пользователей. Многие из читателей этой статьи уже используют протокол, отличный от HTTP/1.1 многие годы. Например, если у вас есть аккаунт в почтовом сервисе Gmail , и вы используете браузер Google Chrome для доступа к нему.

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

Что нужно изменить, чтобы использовать преимущества HTTP/2?

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

Переходите на TLS

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

Это важно не только для HTTP/2 . Google использует защищённое соединение как сигнал при ранжировании сайта , а браузеры начинают отмечать не https сайты как «небезопасные ».

Преобразование нескольких файлов изображений в спрайты

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

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

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

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

Встраивание изображений с помощью Data URI

Другой метод решения проблемы множественных запросов в HTTP/1.1 – встраивание изображений в CSS, используя data URI . Встраивание изображений таким образом сильно увеличивает размер файла стилей. Если вы сочетаете этот метод с другой техникой оптимизации, то браузер загрузит весь этот CSS ? даже если пользователь не посетит страницы, на которых используются эти изображения. В HTTP/2 эта «лучшая практика » скорее будет вредить, чем улучшать производительность.

Соединение CSS и JavaScript

На финальной стадии сборки сайта многие соединяют все мелкие файлы CSS и JavaScript , используемые на нем. Мы зачастую разделяем их при разработке, чтобы было легче управлять ими. Но доставка одного файла браузеру более эффективна в плане производительности, чем доставка пяти. И мы снова пытаемся сократить количество HTTP-запросов .

Если вы это делаете, то посетителям придётся загрузить все стили CSS и JavaScript сайта. Можно обойти эту проблему, подключая только определённые файлы для каждой области сайта в процессе его сборки.

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

Разделение ресурсов между хостами: Sharding

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

HTTP/2 устраняет необходимость использования domain sharding: можно запрашивать любое количество ресурсов. Но это навредит производительности: создаются дополнительные соединения TCP , и препятствует расстановке приоритетов в HTTP/2 .

Как подготовиться к HTTP/2

Несколько советов, как подготовиться к переходу на HTTP/2 .

Создавайте отдельные изображения в дополнение к спрайтам и встраиванию изображений

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

Организуйте файлы по секциям сайта

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

Управляйте разделением между доменами

На данный момент лучшая практика для HTTP/1.1 – ограничить разделение двумя именами хостов. В HTTP/2 существует способ объединить эти соединения, если сертификат TLS действителен для обоих хостов и хосты находятся на одном IP-адресе . TLS сертификат необходим для работы через HTTP/2 .

Дальнейшие действия

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

Когда совершать переход?

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

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

Ваш план действий в отношении HTTP/2

1. Запустите сайт с безопасным соединением или перейдите на TLS прямо сейчас.
2. Подготовьтесь к HTTP/2 в процессе сборки сайта. Используйте советы, приведенные выше, чтобы создать сайт, оптимизированный под обе версии протокола.
3. Проверьте хостинг. Удостоверьтесь в том, что ваш сервер поддерживает HTTP/2 .
4. Разверните оптимизацию под HTTP/2 . Прекратите использовать устаревшие практики и переходите к применению новых.

После того, как вы перейдёте на HTTP/2 , стоит проверить, насколько увеличится скорость вашего сайта.

Узнайте больше

Растущий объём информации о HTTP/2 доступен в сети. Ниже я перечислила некоторые ресурсы, к которым я обращалась при написании этой статьи.

• “Hypertext Transfer Protocol Version 2 (HTTP/2) ” (спецификация ).
  Это для людей, получающих удовольствие от чтения спецификаций, или тех, кому требуется понимание тонких моментов. Для всех остальных HTTP/2 FAQ – это прекрасный обзор основных функций.
• Индикатор HTTP/2 и SPDY : Chrome .
  Этот плагин позволяют узнать, предоставляется ли сайт, на котором вы находитесь, через HTTP/2 .

Перевод статьи “Getting Ready For HTTP/2 A Guide For Web Designers And Developers ” был подготовлен дружной командой проекта .

Хорошо Плохо

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

Ключевые особенности HTTP/2

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

• Сжатие HTTP-заголовков. При отправке запросов клиентом и ответов сервером передаются HTTP-заголовки, которые содержат вспомогательную информацию. Если загружаемая страница содержит большое количество элементов - все заголовки будут занимать приличный объем. В HTTP/2 заголовки передаются в сжатом виде, что позволяет существенно сократить объем информации, которой обмениваются сервер и клиент. Кроме того, для сжатия используется специальный алгоритм HPACK, который снижает риски к атакам по перехвату информации.
• Приоритизация. Назначение приоритетов запросам позволяет обеспечить визуальную скорость загрузки страницы для пользователя. Например, браузер может попросить сервер отправить в первую очередь файлы CSS, так как они очень важны для определения вида страницы.
• Server Push. При использовании HTTP/1.1 сервер отправляет в ответ на запрос HTML-код и ожидает от браузера запросов на элементы страницы. В HTTP/2 добавлена функция Server Push, которая позволяет серверу сразу отправлять дополнительные элементы, которые могут понадобится браузеру в будущем.
• Бинарность. Протокол HTTP/2 является бинарным, в то время как HTTP/1.1 – текстовый. Поэтому он более эффективен для анализа и обработки сервером, более компактный при передаче и меньше подвержен ошибкам.

Поддержка браузерами

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

Важно! Протокол HTTP/2 не требует обязательного шифрования, однако разработчики браузеров приняли решение реализовать работу с новым протоколом только через TLS (HTTPS). Поэтому наличие установленного (коммерческого или бесплатного) является обязательным условием для работы по протоколу HTTP/2.

Ниже наглядно представлены версии браузеров, для которых реализована поддержка протокола HTTP/2 (выделены зеленым фоном). В Internet Explorer 11 новый протокол поддерживается только в Windows 10, в Safari - OSX 10.11 и выше.

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

HTTP/2 и поисковая оптимизация (SEO)

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

HTTP/2 и оптимизация сайтов

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

• Объединение изображений в спрайты. В HTTP/1.1 объединение небольших изображений в один спрайт эффективно, так как требуется всего одно HTTP-соединение и не возникает очереди запросов. Но если на странице используется всего одно изображение - нужно загрузить весь спрайт. В HTTP/2 с мультиплексированием очередь запросов больше не является проблемой, поэтому во многих случаях оптимально загружать много мелких изображений, которые используются на странице. Однако, в некоторых случаях объединение изображений в один спрайт может быть полезным, так как улучшается сжатие и уменьшается объем загрузки, особенно если все изображения используются на странице.
• Встраивание изображений с помощью data URI. Еще один способ решения проблемы с множественными запросами – встраивание изображений в CSS с помощью data URI. За счет этого может существенно увеличиваться размер файла со стилями, но требуется меньше HTTP-соединений. В HTTP/2 такой подход может быть полезным, но вряд ли будет помогать улучшению производительности.
• Объединение CSS и JavaScript. Еще один способ ограничения количества HTTP-соединений. При таком подходе все файлы css/js объединяются в один большой файл. А значит при загрузке одной страницы загружаются сразу все таблицы стилей и js-код, даже если они не используются на текущей странице. Кроме того, браузером кэшируется сразу весь общий файл и небольшое изменение кода потребует повторной загрузки всего файла. С мультиплексированием в HTTP/2 загрузка множества мелких файлов не является проблемой, поэтому распределение файлов css/js только на нужные страницы будет намного эффективнее и поспособствует увеличению скорости загрузки сайта.
• Доменный шардинг . Этот способ заключается в загрузке статических ресурсов с разных доменов или поддоменов основного домена и актуален только для HTTP/1.1. Причина та же - ограничение на количество параллельных HTTP-соединений. В HTTP/2 такой подход негативно влияет на производительность за счет открытия дополнительных TCP-соединений и препятствия в обработке приоритетов ресурсов.

Как проверить, поддерживает ли сайт протокол HTTP/2

• Онлайн-сервисы.

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

• Расширения для браузеров.

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

• Инструменты разработчика в браузере.

Рассмотрим для примера просмотр протокола в инструментах разработчика в браузерах Chrome и Firefox.

1. Открываем инструменты разработчика: нажимаем правой кнопкой мыши на странице и выбираем в контекстном меню «Просмотреть код» или нажимаем Ctrl+Shift+I.
2. Переходим на вкладку «Network» и нажимаем кнопку F5 для обновления страницы
3. Нажимаем правой кнопкой мыши на названии какого-либо столбца и выбираем в контекстном меню «Protocol», добавив тем самым соответствующий столбец.

Для каждого ресурса в столбце «Protocol» отображается протокол, по которому он загружен:

Firefox:

1. Открываем инструменты разработчика: нажимаем правой кнопкой мыши на странице и выбираем в контекстном меню «Исследовать элемент» или нажимаем Ctrl+Shift+I.
2. Переходим на вкладку «Сеть» и нажимаем кнопку F5 для обновления страницы
3. Нажимаем правой кнопкой мыши на названии какого-либо столбца и выбираем в контекстном меню «Протокол», добавив тем самым соответствующий столбец.

Для каждого ресурса в столбце «Протокол» отображается протокол, по которому он загружен:

18.07.2017 11:41

HTTP/2 - это вторая версия всем известного протокола HTTP. Полностью название этого протокола выглядит как HTTP/2.0. Как известно, HTTP - или Hypertex Transfer Protocol - это протокол, который используется для передачи гипертекста. Иными словами, благодаря HTTP веб-страницы загружаются и показываются через браузер интернет-пользователям.

Протокол HTTP появился давно: первая версия - даже не первая, а 0.9 - вышла в далеком 1991 году. Через восемь лет, в 1999 году, появилась те версия HTTP, которая активно используется сейчас, - HTTP/1.1. Казалось бы, если все работает, то зачем что-то менять? Но как и везде в разработке, прогресс не стоит на месте, все меняется и требует изменений.

Разработка

Разработкой новой версии протокола занималась рабочая группа HTTPbis из Internet Engineering Task Force (Инженерного совета интернета, который разрабатывает стандарты интернета). Она была сформирована в 2007 году специально для работой над этим проектом. Однако активные действия начали происходить лишь через пять лет, в 2012 году.

Основой для HTTP/2 стал протокол SPDY (можно расшифровать как “speedy” - быстрый). Разработчик этого прокола - компания Google - создавала его для того, чтобы снизить время загрузки веб-страниц. В частности, протокол SPDY позволяет расставлять приоритеты и использовать мультиплексирование передачи нескольких файлов так, чтобы для каждого клиента нужно лишь одно соединение.

Один из участников рабочей группы Даниэль Штенберг весной 2014 года опубликовал документ , в котором рассказано о том, зачем вообще начали работу над этим проектом, и как она происходит. Документ доступен и на русском языке: https://bagder.gitbooks.io/http2-explained/ru/

Вот кратко перечисленные в описании концепции пункты:

• должны поддерживаться парадигмы HTTP;
• должны остаться ссылки http:// и https://, не нужно добавлять новую схему;
• серверы и клиенты, использующие HTTP/1, должны быть проксированы к HTTP/2-серверам;
• возможности HTTP/2 должны быть конвертированы в HTTP/1.1 при помощи прокси;
• сокращение числа опциональных частей в протоколе;
• отсутствие минорных версий в HTTP/2; при необходимости будет разработан протокол HTTP/3.

Новшества

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

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

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

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

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

Отдельно стоит вопрос сжатия . HTTP является протоколом без состояния, а значит, повторяющимся протоколом. На практике это выражается в том, что если на сервер идет запрос нескольких ресурсов (к примеру, картинок), то это рождает серию запросов, которые сами по себе является практически идентичными. Поэтому логично, что сжатие необходимо.

Однако подводные камни есть и здесь. В частности, сжатие HTTPS и SPDY уязвимы к атаке BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext), использующей недочеты алгоритма сжатия gzip/DEFLATE, и атаке CRIME (Compression Ratio Info-leak Made Easy), которая также эксплуатирует алгоритмы сжатия данных.

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

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

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

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

HTTP/2 поддерживают все основные браузеры: Chrome, Firefox, Opera, Edge, Safari.
Также рекомендуется быстрее перейти на HTTP/2 тем, у кого много мобильного трафика.

Переход на HTTP/2

Тем, кто заинтересовался переходом на HTTP/2, я советую прочитать вот эту документацию на английском языке: https://cdn.wp.nginx.com/wp-content/uploads/2015/09/NGINX_HTTP2_White_Paper_v4.pdf

Итог

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