[Перевод] Семь советов по внедрению HTTP/211.11.2015 18:18

Недавно вышла новая версия стандарта 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, а также рассматривает возможные оптимизации при внедрении протокола.

Далее приведен список из семи советов по внедрению HTTP/2:

Оцените необходимость внедрения HTTP/2
Терминируйте HTTP/2
Начните с использования SPDY
Откажитесь от HTTP/1.x оптимизации
Внедрите HTTP/2 или SPDY
Пересмотрите HTTP/1.x оптимизации
Рассмотрите дружественный 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. Поэтому сначала стоит проверить этот случай.

Далее перечислены пять основных потенциальных преимуществ от использования HTTP/2:

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

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

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

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

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

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

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

Рассмотрите дружественный HTTP/2 шардинг

Шардинг является, пожалуй, самой непростой, и в то же время, возможно, самой успешной стратегией оптимизации HTTP/1.x. Шардинг можно использовать для повышения производительности HTTP/1.x, но для HTTP/2 (в котором используется только одно соединение) он в основном игнорируется.

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

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

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

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

Заключение

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

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