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

Протокол 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 % веб-сайтов по данным [http://w3techs.com/ 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 только вместе с [p467 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.