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

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

Итак, что же такое HTTP/2. Это всего лишь маркетинговое словечко или действительно что-то стоящее внимания?

HTTP/2 - это последняя версия знаменитого сетевого протокола HTTP- Hypertext Transfer Protocol , который используется во Всемирной паутине. Этот протокол даёт возможность разделить текстовую и мультимедийную информацию, используя так называемые веб линки между неподключенными узлами, такими как браузер и сервер. Например, ваш браузер использует этот протокол для загрузки данной статьи. Но без протокола HTTP не было бы Интернета!

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

СЕТЕВОЙ ПРОТОКОЛ HTTP

НТТР использует технологию “клиент-сервер”. Это значит, что ваш браузер (Firefox, Chrome и т.д.) является “клиентом”, а наш блог работает на сервере хостинга. Например, эта статья может быть идентифицирована и загружена с помощью URL - Uniform Resource Locator (уникальный определитель ресурса). Если вы открываете URL этой статьи, ваш клиент делает НТТР запрос на сервер и получает информацию в HTML формате. Как только трансфер данных (на транспортном уровне по протоколу ТСР) будет проведён, ваш браузер отобразит полученный ответ в HTML коде для вывода на экран текста, который вы сейчас читаете.

Исторический факт: Термин «hypertext» впервые был использован Тэдом Нельсоном в 1965 год (проект Xanadu). HTTP и HTML были созданы Тимом Бернерс-Ли и его командой в CERN в 1989 году. Между прочим, первый сайт был опубликован 6 августа 1991 года.

Сетевой протокол поддерживает сессии и аутентификацию. Сессия это открытая последовательность транзакций запрос-ответ по ТСР соединению на определённый порт. Порт 80 используется для НТТР и 443 для НТТРS соединений. HTTPS это HTTP поверх SSL/TLS , который обозначает, что сквозное соединение создано через зашифрованный канал с помощью криптографического протокола Transport Layer Security (TLS) .

HTTP/1.0 и HTTP/1.1

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

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

ПОДРОБНЕЕ О МЕТОДАХ ЗАПРОСА HTTP

Чуть выше мы рассказали про запросы к серверу. HTTP определяет несколько методов запроса, которые могут быть использованы для разных целей и действий на определённом ресурсе. Наиболее распространённые методы это GET и POST, которые должны быть вам знакомы.

Когда вы вызываете URL, кликая по обычной ссылке, то ваш браузер создаёт GET запрос. Вы можете видеть GET параметры прямо в URL , например?id=42 . В этом примере переменная GET это идентификатор со значением 42. Когда вы подписываетесь на услугу вводя свои данные в форме и кликаете на кнопку подтверждения, то ваш клиент выполнит POST запрос. Кроме этих методов НТТР поддерживает несколько других методов, которые обычно не используются браузером во время интернет-сёрфинга. Вот эти методы:

• HEAD (подобное методу GET, но без тела ответа),
• PUT (меняет или создаёт ресурс),
• DELETE (удаляет ресурс),
• TRACE (эхо-запрос),
• OPTIONS (возвращает поддерживаемые HTTP методы),
• CONNECT (преобразовывает запросы в TCP/IP туннель),
• PATCH (применяет изменения для ресурса).

HTTP ОТВЕТЫ И КОДЫ СТАТУСОВ HTTP

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

Первая строка HTTP ответа всегда содержит так называемый код статуса, который помогает клиенту правильно обработать ответ. Кто не знает печально известное сообщение “Ошибка сервера 500” . Именно этот статус код 500 был отослан сервером в браузер из-за внутренних проблем сервера. Есть несколько главных категорий, которые определяются по первой цифре:

• 1 – информационный,
• 2 – успешный,
• 3 – переадресация,
• 4 – клиентская ошибка,
• 5 – серверная ошибка.

ПРЕИМУЩЕСТВА HTTP/2

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

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

КАК МНЕ АКТИВИРОВАТЬ HTTP/2 НА СВОЕМ СЕРВЕРЕ? ИСПОЛЬЗУЙТЕ PLESK!

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

Команда Plesk создала расширение безопасности Security Advisor , с помощью которого можно активировать HTTP/2 , а также активировать сертификат SSL и поддержку HTTPS в 1 клик в WordPress. Откройте каталог расширений Plesk и установите Security Advisor. Расширение абсолютно бесплатное и не только защитит ваш сайт, но и ускорит!

«… мы не меняем весь HTTP - методы, коды статусов и большинство заголовков остаются теми же. Мы лишь переработали его с точки зрения повышения эффективности использования, чтобы он был более щадящим по отношению к интернету…»

Важно отметить, что новая версия HTTP идёт в качестве расширения для своего предшественника, и вряд ли в обозримом будущем заменит HTTP 1.1. Реализация HTTP/2 не подразумевает автоматической поддержки всех типов шифрования, доступных в HTTP 1.1, но определённо поощряет использование более интересных альтернатив, или дополнительное обновление совместимости шифрования в ближайшем будущем. Тем не менее, в сравнениях «HTTP/2 против HTTP 1» и «SPDY против HTTP/2» герой этой статьи выходит победителем по производительности, безопасности и надёжности.

Чем был плох HTTP 1.1?

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

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

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

Сетевой индустрии фактически пришлось хакнуть эти ограничения с помощью таких методик, как доменный шардинг (domain sharding), конкатенация, встраивание и спрайтинг (spriting) данных, а также ряд других. Неэффективное использование HTTP 1.1 базовых TCP-соединений является причиной плохой приоритезации ресурсов, и в результате - экспоненциальной деградации производительности по мере роста сложности, функциональности и объёма веб-приложений.

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

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

Особенности HTTP/2

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

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

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

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

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

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

Отправка данных по инициативе сервера (Server Push)

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

Полученный от сервера ресурс Y кэшируется на клиенте для будущего использования. Этот механизм позволяет экономить циклы «запрос-ответ» и снижает сетевую задержку. Изначально Server Push появился в протоколе SPDY. Идентификаторы потоков, содержащие псевдозаголовки наподобие:path , инициируют передачу сервером дополнительной информации, которая должна быть закэширована. Клиент должен либо явным образом позволить серверу передавать себе кэшируемые ресурсы посредством HTTP/2, либо прервать инициированные потоки, имеющие специальный идентификатор.

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

Реализация HTTP/2 демонстрирует высокую производительность при работе с инициативно передаваемыми ресурсами:

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

В неоптимальных методиках наподобие встраивания (Inlining) также используются push-функциональности, позволяющие заставить сервер откликаться на запросы. При этом Server Push представляет собой решение на уровне протокола, помогающее избежать возни с оптимизационными хаками.

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

Двоичный протокол

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

Читать двоичные команды будет труднее, чем аналогичные текстовые, но зато сети будет легче их генерировать и парсить фреймы. Семантика остаётся без изменений. Браузеры, использующие HTTP/2, перед отправкой в сеть конвертируют текстовые команды в двоичные. Двоичный слой фреймов не имеет обратной совместимости с клиентами и серверами, использующими HTTP 1.x. Он является ключевым фактором, обеспечивающим значительный прирост производительности по сравнению с SPDY и HTTP 1.x. Какие преимущества даёт интернет-компаниям и онлайн-сервисам использование двоичных команд:

• Низкие накладные расходы при парсинге данных - критически важное преимущество HTTP/2 по сравнению с HTTP 1.
• Ниже вероятность ошибок.
• Решение проблем с безопасностью, наподобие атак с разделением запросов (response splitting attack), проистекающих из текстовой природы HTTP 1.x.
• Реализуются прочие возможности HTTP/2, включая сжатие, мультиплексирование, приоритезацию, управление потоками и эффективную обработку TLS.
• Компактность команд упрощают их обработку и реализацию.
• Выше эффективность и устойчивость к сбоям при обработке данных, передаваемых между клиентом и сервером.
• Снижение сетевой задержки и повышение пропускной способности.

Приоритезация потоков

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

Приоритезация осуществляется с помощью присваивания каждому потоку зависимостей (Dependencies) и веса (Weight). Хотя все потоки, по сути, и так зависят друг от друга, ещё добавляется присваивание веса в диапазоне от 1 до 256. Детали механизма приоритезации всё ещё обсуждаются. Тем не менее, в реальных условиях сервер редко управляет такими ресурсами, как ЦПУ и подключения к БД. Сложность реализации сама по себе не даёт серверам выполнять запросы на приоритезацию потоков. Продолжение работ в этом направлении имеет особенное значение для успеха HTTP/2 в долгосрочной перспективе, потому что протокол позволяет обрабатывать многочисленные потоки в рамках единственного TCP-соединения.

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

• Эффективное использование сетевых ресурсов.
• Снижение времени доставки запросов первичного контента.
• Повышение скорости загрузки страниц.
• Оптимизация передачи данных между клиентом и сервером.
• Снижение отрицательного эффекта от сетевых задержек.

Сжатие заголовков с сохранением состояния

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

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

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

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

• Эффективную приоритезацию потоков.
• Эффективное использование механизмов мультиплексирования.
• Снижает накладные расходы при использовании ресурсов. Это один из первых вопросов, обсуждаемых при сравнении HTTP/2 с HTTP 1 и SPDY.
• Кодирование больших и часто используемых заголовков, что позволяет не отправлять весь фрейм с заголовком. Передаваемый размер каждого потока быстро уменьшается.
• Устойчивость к атакам, например, CRIME - эксплойтам потоков данных со сжатыми заголовками.

Различия между HTTP 1.x и SPDY

Базовая семантика приложения HTTP в последней итерации HTTP/2 осталась без изменений, включая коды статусов, URI, методики и файлы заголовков. HTTP/2 основан на SPDY, созданной в Google альтернативе HTTP 1.x. Основные различия кроются в механизмах обработки клиент-серверных запросов. В таблице отражены основные различия между HTTP 1.x, SPDY и HTTP/2:

HTTP 1.x	SPDY	HTTP2
	Необходим SSL.	SSL не требуется, но рекомендуется.
Медленное шифрование.	Быстрое шифрование.	Шифрование стало ещё быстрее.
Один клиент-серверный запрос на одно TCP-соединение.	Много клиент-серверных запросов на одно TCP-соединение. Осуществляются одновременно на одном хосте.	Многохостовое мультиплексирование. Осуществляются на нескольких хостах в одном экземпляре.
Нет сжатия заголовков.	Введено сжатие заголовков.	Используются улучшенные алгоритмы сжатия заголовков, что повышает производительность и безопасность.
Нет приоритезации потоков.	Введена приоритезация потоков.	Улучшенные механизмы приоритезации потоков.

Как HTTP/2 работает с HTTPS

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

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

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

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

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

Основные преимущества HTTP/2

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

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

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

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

Производительность сети

Это понятие отражает совокупный эффект всех нововведений HTTP/2. Результаты бенчмарков (см. главу «Сравнение производительности HTTPS, SPDY и HTTP/2») демонстрируют увеличение производительности при использовании HTTP/2 по сравнению с его предшественниками и альтернативными решениями.

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

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

Что происходит, когда механизмы передачи данных сметают все преграды на пути к повышению производительности сети? У высокой скорости работы сайтов есть побочные явления: пользователи получают больше удовольствия, улучшается оптимизация для поисковых сервисов, ресурсы используются эффективнее, растёт аудитория и объёмы продаж, и многое другое.

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

Производительность мобильной сети

Ежедневно миллионы пользователей выходят в сеть со своих мобильных устройств. Мы живём в «эру постПК», множество людей используют смартфоны в качестве основного устройства для доступа к онлайн-сервисам и выполнения большинства рутинных вычислительных задач прямо на ходу, вместо длительного сидения перед мониторами настольных компьютеров.

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

Интернет подешевле

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

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

Экспансивный охват

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

Насыщенность мультимедиа

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

Улучшение опыта использования мобильного интернета

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

Более эффективное использование сети

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

Безопасность

Преимущества HTTP/2 не ограничиваются одной лишь производительностью. Алгоритм HPACK позволяет обходить распространённые угрозы, нацеленные на текстовые протоколы уровня приложения. Для защиты данных, передаваемых между клиентом и сервером, в HTTP/2 используется подход «Безопасность через непонятность» (Security by Obscurity): команды представлены в двоичном виде, применяется сжатие метаданных HTTP-заголовков. Кроме того, протокол может похвастаться полноценной поддержкой шифрования и требует применения улучшенной версии Transport Layer Security (TLS1.2).

Инновационность

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

Преимущества HTTP/2 с точки зрения SEO

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

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

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

Сравнение производительности HTTPS, SPDY и HTTP/2

Результаты бенчмарков ясно показывают ситуацию с улучшением производительности в новом протоколе.

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

Подробности тестирования:

Результаты этого теста говорят нам следующее:

• Размеры заголовков клиентского запроса и серверного отклика : HTTP/2 демонстрирует, что использование сжатия позволяет значительно уменьшить размер заголовка. При этом SPDY уменьшает заголовок только серверного отклика для данного запроса. HTTPS вообще не уменьшает заголовки.
• Размер сообщения серверного отклика : размер отклика HTTP/2-сервера оказался больше, но зато в нём применялось более стойкое шифрование.
• Количество использованных TCP-соединений : при обработке многочисленных одновременных запросов(мультиплексирование) HTTP/2 и SPDY используют меньше сетевых ресурсов, следовательно, снижается задержка.
• Скорость загрузки страницы : HTTP/2 постоянно был быстрее SPDY. HTTPS был значительно медленнее из-за отсутствия сжатия заголовков и инициативной отправки данных сервером.

Браузерная поддержка HTTP/2 и доступность

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

Клиентская поддержка

Пользователям не нужно заботиться о настройке поддержки HTTP/2 в своих браузерах - «полноценных» и мобильных. Chrome и Firefox давно поддерживают эту технологию , а в Safari поддержка HTTP/2 появилась в 2014. В IE данный протокол поддерживается только начиная с Windows 8.

Основные мобильные браузеры, включая Android Browser, Chrome для Android и iOS, а также Safari в iOS8 и выше, уже поддерживают HTTP/2. Рекомендуется на всякий случай поставить последние стабильные версии мобильных и настольных браузеров, чтобы получить максимальную производительность и преимущества в безопасности.

Серверная поддержка: Apache и Nginx

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

Nginx -серверы, составляющие 66% всех активных веб-серверов , могут похвастаться встроенной поддержкой HTTP / 2. А для обеспечения браузерной поддержки HTTP/2 на Apache, нужно воспользоваться модулем mod_spdy . Он разработан Google для внедрения поддержки в Apache 2.2 таких функций, как мультиплексирование и сжатие заголовков. Это ПО было передано в дар Apache Software Foundation.

Как начать использовать HTTP/2?

Для настройки HTTP/2 на своём сайте воспользуйтесь этой простой инструкцией:

1. Проверьте, чтобы был включен HTTPS:
   • Приобретите в проверенной организации сертификат SSL или TLS.
   • Активируйте сертификат.
   • Установите сертификат.
   • Обновите сервер для включения протокола HTTPS.
2. Проверьте, чтобы базовая сетевая инфраструктура включала в себя поддержку HTTP/2 на уровне серверного ПО. Серверы Nginx имеют нативную поддержку, в Apache она появилась в октябре 2015 (в версии 2.4). В более ранних версиях для поддержки HTTP/2 нужно установить дополнительные модули.
3. Обновите, сконфигурируйте и протестируйте ваши серверы. описана конфигурация и процедуры тестирования для серверов Apache. Свяжитесь со своим хостинг-провайдером и удостоверьтесь, что ваш сайт готов к использованию HTTP/2.
4. Для проверки правильности конфигурации HTTP/2 воспользуйтесь этим инструментом .

Заключение

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

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

Теги: Добавить метки

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

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

Для дальнейшего прочтения

• Все, что вы должны знать о сайтах, оптимизированных для мобильных устройств

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

Если у ваш сайт использует только http, тогда мое предложение как можно скорее перейти на https, и уже тогда определится с HTTP/2 стратегией.

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

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

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

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

Встраивание изображений за счет использования data uri

Другое обходное решение проблемы множества HTTP-запросов - встраивание изображений в css с использованием data uri . Использование изображений подобным способом делает css-файл намного больше. Если вы в добавок используете сжатие и объединение ассетов, посетители будут загружать огромное количество кода, даже если никогда не перейдут на страницу, где он действительно нужен.

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

Объединение CSS и Javascript

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

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

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

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

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

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

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

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

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

Создайте индивидуальные ассеты, дополнительно до спрайтов и data uri

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

Это также касается и data uri. Если используете в css, подготовьте также картинки для того времени, когда вы откажетесь от этой техники.

Упорядочьте ассеты по разделам сайта

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

Управление domain sharding

Текущая лучшая практика для HTTP/1.1 - ограничение sharding двумя хостами. В HTTP/2 возможно объединить соединения, если TLS сертификат валидный для обеих хостов и хост резолвится для одного IP-адресса. Поскольку браузерная реализация требует, чтобы HTTP/2 работал через https, необходимо получить TLS сертификат, чтобы использовать HTTP/2 . Посмотрите больше на 26 слайде Ilya Grigorik’s с Velocity Conference.

Это далеко не все

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

Когда переключиться?

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

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

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

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

План действий по работе с HTTP/2

1. Запустите проект, или перейдите но TLS сейчас.

Это должно быть вашим приоритетом.

2. Подготовьте ваш процесс сборки до HTTP/2 .

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

3. Проверьте вашу статистику

Проверив статистику использования браузеров и таблицу совместимости Can I Use , вы сможете увидеть, сколько процентов посетителей получать преимущества при оптимизации под HTTP/2 .

4. Проверьте свой хостинг

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

5. Займитесь оптимизацией под HTTP/2 .

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

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

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

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

• “Hypertext Transfer Protocol Version 2 (HTTP/2)
  • HTTP/2 and SPDY Indicator: Firefox and Chrome

  Этот плагин для браузера показывает, работает ли сайт с HTTP/2 .

  • Для дальнейшего прочтения также посмотрите на этот

В прошлом году в мире сетевых технологий произошло очень важное событие: была утверждена и стандартизирована новая версия протокола HTTP - HTTP/2. HTTP/2 уже поддерживается в популярных веб-сервераx -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/2 обратно совместим с HTTP/1.1. Изменения, направленные на устранение узких мест и повышения производительности, во многом продолжают линию SPDY. Рассмотрим вкратце наиболее важные из них.

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

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

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

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

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

Приоритеты

Ещё одно нововведение HTTP/2 - это приоритизация. Каждому запросу можно назначить приоритет.
Существует два подхода к назначению приоритетов: на основе веса и на основе зависимостей.

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

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

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

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

Современная веб-страница состоит из множества элементов: изображения, JS, CSS и другие. В запросе на загрузку каждого из этих элементов браузер передаёт HTTP-заголовок. Отправляя запрошенные элементы, сервер также добавляет к ним заголовок. Всё это сопряжено с излишним расходованием ресурсов.

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

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

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

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

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

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

Nginx

Поддержка HTTP/2 реализована только в новейших версиях Nginx (1.9.5 и выше). Если у вас установлена другая версия, вам потребуется обновить её.

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

Listen 443 ssl;

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

Listen 443 ssl http2;

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

$ sudo service nginx reload

Apache

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

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

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

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

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

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

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

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

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

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

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

Ещё один популярный способ решения проблемы множественных HTTP-запросов в HTTP/1.1 ― встраивание изображений с использованием Data URI . Это существенно увеличивает в размере таблицу стилей.

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

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

Для оптимизации работы сайтов часто используется конкатенация небольших CSS- и JS-файлов. Много маленьких файлов объединяются в один большой. Таким образом удаётся обойти лимит на количество HTTP-запросов.

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

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

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

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

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

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

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

Когда планировать переход на HTTP/2? Однозначного ответа на этот вопрос нет и быть не может. Дадим, однако, одну подсказку: регулярно просматривайте логи посещаемости вашего сервиса. Когда вы увидите, что большая часть посетителей используют поддерживающие HTTP/2 браузеры - можно переходить. На текущий момент поддержка HTTP/2 реализована в Chrome (в том числе и в мобильной версии для Android), Firefox, Opera, Edge, Safari.

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

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

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

В заключение приведём для заинтересованных читателей несколько полезных ссылок