Семь Советов По Реализации Http/2

Недавно была выпущена новая версия стандарта HTTP. HTTP/2 был одобрен в мае 2015 года и получил широкое распространение среди браузеров и веб-серверов (включая 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:

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

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

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

Внедрение HTTP/2 несложно и процесс подробно описан.

Здесь .

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

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

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



Семь советов по реализации HTTP/2

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

    Алгоритм сжатия данных HPACK требует поддержки LUT на обоих концах.

    Кроме того, для каждого соединения требуется больше памяти.

  2. Возможно, TLS используется избыточно.

    Если передаваемая информация не нуждается в защите или уже защищена с помощью DRM (или другого шифрования), то TLS вряд ли будет полезен.

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

  4. Не дает преимуществ при загрузке больших файлов.

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

  5. Безопасность не важна.

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

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

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

  • Очень низкие значения RTT (0–20 мс): разницы между HTTP/1.x, HTTP/2 и HTTPS практически нет.
  • Среднее (типичное для Интернета) RTT (30–250 мс): HTTP/2 быстрее, чем HTTP/1.x, и оба быстрее, чем HTTPS. Для соседних городов США RTT составляет около 30 мс, а от побережья до побережья (около 3000 миль) — около 70 мс.

    На одном из самых коротких маршрутов между Токио и Лондоном RTT составляет около 240 мс.

  • Высокие значения RTT (300 мс и выше): HTTP/1.x быстрее, чем HTTP/2, который быстрее HTTPS.


Семь советов по реализации HTTP/2

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

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

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

Например, если у вас потоковое видео или большие загруженные файлы, то ваши результаты могут быть другими или даже противоположными.

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



Завершить HTTP/2

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

изображение ниже).



Семь советов по реализации HTTP/2

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

Серверы могут совместно использоваться физически, виртуально или в облачной среде, например АВС .

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

После установки физического или виртуального сервера перед существующей системой становятся доступны дополнительные возможности.

Новый сервер освобождает другие серверы от обработки клиентских сообщений.

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

Становится намного проще добавлять и заменять серверные приложения и другие серверы по мере необходимости.

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. Шардинг.

    Размещение файлов на разных доменах для параллельной передачи в браузер; Сети доставки контента (CDN) делают это автоматически.

    Эта оптимизация может снизить производительность 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

Примечание.

Поскольку при включении 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 включен , а затем протестируйте подходящие шифры во всех популярных версиях браузера.

Индикатор для популярных браузеров Тест SSL-сервера Qualys (по состоянию на ноябрь 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 сегментирование и примечания).

    Вы можете просто полностью избавиться от оптимизаций.

Кэширование имеет некоторые особенности.

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

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

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



Рассмотрите возможность дружественного сегментирования HTTP/2

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

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

  • Убедитесь, что доменные имена для сегментирования ресурсов разрешаются в одни и те же IP-адреса.

  • Убедитесь, что используется групповой сертификат — в этом случае он будет действителен для всех доменных имен, используемых для шардинга.

    Или убедитесь, что у вас есть соответствующий многодоменный сертификат.

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

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



Заключение

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

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

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

Теги: #Nginx #HTTP/2 #http 1.x #tls #sharding #Высокая производительность #Разработка веб-сайтов

Вместе с данным постом часто просматривают: