• Перевод

Недавно вышла новая версия стандарта HTTP. В мае 2015 года был утвержден HTTP/2, который получил распространение среди браузеров и веб-серверов (включая NGINX и NGINX Plus). На данный момент более 60% используемых браузеров поддерживают HTTP/2, причем эта цифра продолжает увеличиваться с каждым месяцем.

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

Основные особенности HTTP/2 аналогичны SPDY:

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

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

1. Терминируйте HTTP/2
2. Начните с использования SPDY
3. Откажитесь от HTTP/1.x оптимизации
4. Внедрите HTTP/2 или SPDY
5. Пересмотрите HTTP/1.x оптимизации
6. Рассмотрите дружественный HTTP/2 шардинг

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

Оцените необходимость внедрения HTTP/2

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

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

1. Используется только одно соединение с сервером вместо множества соединений, передающих по одному файлу. Другими словами, уменьшается количество соединений, что особенно полезно при использовании TLS.
2. Эффективное использование TLS. HTTP/2 делает только один TLS хэндшейк, а мультиплексирование позволяет эффективно использовать это соединение. HTTP/2 также сжимает данные заголовка, а устранение HTTP/1.x оптимизаций (таких как конкатенация файлов) позволяет алгоритму кэширования работать более эффективно.
3. Упрощение веб-приложений. При использовании HTTP/2 можно избавиться от HTTP/1.x оптимизаций, которые доставляют лишение неудобства и разработчикам.
4. Отлично подходит для сложных веб-страниц. HTTP/2 отлично подходит для веб-страниц, которые одновременно используют HTML, CSS, JavaScript, картинки и видеоролики. Браузеры могут приоритезировать запросы к файлам, чтобы наиболее необходимые части страницы присылались в первую очередь.
5. Безопасность соединения. Хотя при использовании HTTP/2 может произойти потеря производительности из-за использования TLS, но в то же время TLS сделает веб-приложения более безопасными для пользователей.

И пять соответствующих недостатков, с которыми можно столкнуться:

1. Большие затраты для одного соединения. Алгоритм сжатия данных HPACK требует поддержки таблицы преобразования на обоих концах. Также для одного соединения требуется больше памяти.
2. Возможно использование TLS избыточно. Если передаваемая информация не нуждается в защите или уже защищена с помощью DRM (или другого шифрования), то в этом случае TLS вряд ли будет полезен.
3. Поиск и удаление существующих HTTP/1.x оптимизаций необходимы для увеличения производительности HTTP/2, что является дополнительной работой.
4. Не дает преимуществ при загрузке больших файлов. Если веб-приложение в основном рассчитано на загрузку больших файлов или видеостриминг, то, скорее всего, использование TLS будет ошибочно, а мультиплексирование не принесет никакой пользы.
5. Безопасность не важна. Возможно посетителям не важно, что видео с котиками, которыми они делятся на вашем сайте, не защищено TLS и HTTP/2 (что может быть верно).

Все сводится к производительности и здесь есть хорошие и плохие новости.

Хорошие новости в том, что исходя из тестов, которые были проведены в NGINX следуют результаты предсказанные из теории: для сложных веб-страниц, запрошенных с типичными задержками (latency), производительность HTTP/2 выше, чем HTTP/1.x и HTTPS. Результаты разделены на три группы в зависимости от типичного round-trip time (RTT):

• Очень низкое RTTs (0-20 мс): практически никакой разницы между HTTP/1.x, HTTP/2, и HTTPS не наблюдается.
• Среднее (типичное для интернета) RTTs (30-250 мс): HTTP/2 быстрее чем HTTP/1.x, и оба быстрее чем HTTPS. Для соседних городов в США, RTT составляет около 30 мс, и около 70 мс от одного берега до другого (около 3000 миль). По одному из самых коротких маршрутов между Токио и Лондоном, RTT составляет около 240 мс.
• Высокое RTTs (300 мс и выше): HTTP/1.x быстрее чем HTTP/2, который быстрее чем HTTPS.

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

Более подробно с процессом тестирования и результатами можно ознакомиться в презентации с конференции nginx.conf 2015.

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

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

Терминируйте HTTP/2

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

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

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

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

Начните с использования SPDY

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

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

Откажитесь от HTTP/1.x оптимизаций

Перед внедрением HTTP/2 необходимо выявить оптимизации для HTTP/1.x. Далее перечислены четыре типа оптимизаций, на которые стоит обратить внимание:

1. Шардинг. Размещение файлов на разных доменах для параллельной передачи браузеру; сети доставки контента (CDNs) делают это автоматически. Такая оптимизация может повредить производительности HTTP/2. Вы можете использовать дружественный с HTTP/2 шардинг для пользователей HTTP/1.x (см. дружественный HTTP/2 шардинг).
2. Использование спрайтов. Спрайтами называют коллекции картинок, которые передаются в виде одного файла; после этого на стороне клиента картинки по необходимости извлекаются из коллекции. Эта оптимизация менее эффективна при использовании HTTP/2, хотя все равно может быть полезна.
3. Объединение файлов. Подобно спрайтам, часть файлов, которые обычно хранятся отдельно, объединяются в один. После чего браузер находит и запускает код по мере необходимости в рамках склеенного файла.
4. Встраивание файлов. CSS, JavaScript и даже изображения вставляются непосредственно в HTML-файл, что уменьшает количество передаваемых файлов, за счет увеличения исходного HTML-файла.

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

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

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

Внедрите HTTP/2 или SPDY

На самом деле переход на HTTP/2 или SPDY довольно прост. Для пользователей NGINX, необходимо просто «включить» протокол в конфигурации NGINX, как описано на примере HTTP/2. После этого, сервер будет уведомлять браузер клиента о возможности использования HTTP/2 или SPDY.

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

Примечание: Так как при включении HTTP/2 используется одно соединение, то некоторые настройки конфигурации в NGINX становятся более важными. Рекомендуется просмотреть конфигурацию NGINX с особым вниманием к настройке и тестированию параметров таких директив, как output_buffers, proxy_buffers и ssl_buffer_size. Следует обратить внимание на , конкретные советы по TLS ( и ), и о производительности NGINX при использовании TLS.

Примечание: При использовании шифров совместно с HTTP/2, следует обратить внимание на следующее: RFC для HTTP/2 имеет длинный список шифров, которых следует избегать. Если у вас есть желание настроить список шифров самостоятельно, то в таком случае рекомендуется рассмотреть настройку ssl_ciphers и включение ssl_prefer_server_ciphers on , после чего протестировать подходящие шифры со всеми популярными версиями браузеров. Индикатор для популярных браузеров Qualys’ SSL Server test (на ноябрь 2015) считается ненадежным для подсчета HTTP/2 хэндшейков .

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

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

• Все уже готово. Если приложения не были оптимизированы под HTTP/1.x или были сделаны незначительные изменения, то все готово, чтобы использовать HTTP/2.
• Смешанный подход. Можно уменьшить конкатенацию данных, но не устранить полностью. Например, некоторые спрайты изображений могут остаться, в то же время избавиться от данных, встроенных в HTML.
• Полный отказ от HTTP/1.x оптимизации (но см. дружественный HTTP/2 шардинг и примечания). Можно просто полностью избавиться от оптимизаций.

Кэширование имеет некоторые особенности. В теории кэширование работает эффективно в случае, когда применяется ко множеству небольших файлов. Тем не менее, в этом случае выполняется большое количество операций I/O. Поэтому объединение связанных между собой файлов может быть полезным, как для рабочего процесса, так и для производительности приложений. Шардинг является, пожалуй, самой непростой, и в то же время, возможно, самой успешной стратегией оптимизации HTTP/1.x. Шардинг можно использовать для повышения производительности HTTP/1.x, но для HTTP/2 (в котором используется только одно соединение) он в основном игнорируется.

Для использования шардинга в паре с HTTP/2, следует сделать две вещи:

• Сделать так, чтобы доменные имена для шардинговых ресурсов резолвились в одинаковые IP-адреса.
• Убедиться в том, что используется wildcard-сертификат - в таком случае он будет валидным для всех доменных имен, используемых при шардинге. Либо убедиться, в наличии соответствующего мультидоменного сертификата.

Подробную информацию можно найти .

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

Заключение

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

Советы, описанные выше, должны помочь достичь наилучшей производительности 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 (HyperText Transfer Protocol) было опубликовано в 1991 году. В 1999 году была разработана и описана версия HTTP 1.1, используемая и по сей день. В то далёкое время (почти 20 лет назад) веб-сайты были совсем не такими, как сейчас. За относительно небольшой период времени сайты стали «весить» гораздо больше. Домашняя страница среднестатического современного сайта содержит примерно 1,9 МБ данных: изображения, JS, CSS и многое другое.

Из-за ограничения на количество одновременных подключений в 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: основные нововведения

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

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

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

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

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. Нажимаем правой кнопкой мыши на названии какого-либо столбца и выбираем в контекстном меню «Протокол», добавив тем самым соответствующий столбец.

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

Мы внедрили поддержку HTTP/2 на новых серверах. HTTP – это протокол , который регулирует связь между вашим сервером и браузерами посетителей вашего сайта. HTTP/2 — это первое обновление протокола с 1999г. И оно обещает нам, что сайты станут намного быстрее для всех. Насколько протокол HTTP/2 быстрее HTTP/1.1 вы можете увидеть

Какие возможности у нового протокола?

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

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

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

Мультиплексирование позволяет браузеру выполнять множество запросов в рамках одного TCP-соединения

Приоритетность

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

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

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

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

Server push

Это еще одна мощная возможность протокола HTTP/2. Теперь сервер в ответ на запрос может отсылать дополнительные элементы, которые понадобятся браузеру. Например, теперь при запросе страницы сервер может кроме самой страницы сразу отправлять JavaScript и CSS файлы, которые нужны для ее отображения.

SSL и шифрование

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

Если вы хотите попробовать возможности нового протокола, мы предоставляем тестовые на месяц. Также, при заказе новых Pro тарифов мы предоставляем сроком на год.

Все остальные наши клиенты имеют возможность приобрести до конца марта 2016 г.

Как перейти на HTTP/2?

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

Если вы желаете, чтобы ваш сайт работал по протоколу HTTP/2, просто сообщите нам на и мы перенесем его на сервер с поддержкой 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 .

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