Разъяснение http2. Что такое протокол? Шаги, предпринятые для преодоления задержки

В этой статье поговорим о том, что же такое 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. В мае 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/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.

Это документ, описывающий http2 с позиции технического и протокольного уровня. Первоначально он появился как презентация, которую я представлял в Стокгольме в апреле 2014 года. Я получил с тех пор множество вопросов о содержимом презентации от людей, которые не смогли посетить мероприятие, поэтому я решил сконвертировать его в полноценный документ с деталями и надлежащими пояснениями.
На момент написания (28 апреля 2014), окончательная спецификация http2 не завершена и не выпущена. Текущая версия черновика называется draft-12 , но мы ожидаем увидеть ещё по крайне мере одну версию перед тем как http2 будет завершён. Данный документ описывает текущую ситуацию, которая может измениться или не измениться в окончательной спецификации. Все ошибки в данном документе – мои собственные, появившиеся по моей вине. Пожалуйста сообщите мне о них и я выпущу обновление с исправлениями.

Версия этого документа – 1.2.

Автор

Меня зовут Даниэль Штенберг и я работаю в Mozilla. Открытым программным обеспечением и сетями я занимаюсь уже более двадцати лет в различных проектах. Вероятно, я наиболее известен, как основной разработчик curl и libcurl. Многие годы я был вовлечён в рабочую группу IETF HTTPbis и работал как над поддержкой HTTP 1.1, для соответствия новейшим требованиям, так и работой над стандартизацией http2.

Email: [email protected]
Twitter: @bagder
Web: daniel.haxx.se
Blog: daniel.haxx.se/blog

Помогите!

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

Лицензия

Этот документ лицензируется под лицензией Creative Commons Attribution 4.0: creativecommons.org/licenses/by/4.0

HTTP сегодня

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

HTTP 1.1 огромен

Когда HTTP был создан и выпущен в мир, он, вероятно, воспринимался скорее как простой и прямолинейный протокол, но время показало, что это не так. HTTP 1.0 в RFC 1945 – это 60 страниц спецификации, выпущенной в 1996. RFC 2616, который описывал HTTP 1.1, был выпущен лишь тремя годами позднее в 1999 и значительно разросся до 176 страниц. Кроме того, когда мы в IETF работали над обновлением спецификации, она была разбита на шесть документов с ещё большим числом страниц в итоге. Без сомнений, HTTP 1.1 большой и включает мириады деталей, тонкостей и в не меньшей степени опциональных разделов.

Мир опций

Природа HTTP 1.1, заключённая в наличии большого числа мелких деталей и опций, доступных для последующего изменения, вырастила экосистему программ, где нет ни одной реализации, которая бы воплотила всё – и, на самом деле, невозможно точно сказать, что представляет из себя это «всё». Что привело к ситуации, когда возможности, которые первоначально мало использовались появлялись лишь в небольшом числе реализаций, и те кто их реализовывал после наблюдали незначительное их использование.
Позже это вызывало проблемы в совместимости, когда клиенты и сервера начали активнее использовать подобные возможности. Конвейерная обработка HTTP (HTTP pipelining ) – это один из показательных примеров подобных возможностей.

Неполноценное использование TCP

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

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

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

Размер передачи и число объектов

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

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

Задержка убивает

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

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

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

Блокировка начала очереди

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

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

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

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

Дополнительные сведения по этой проблеме могут быть найдены в баг-трекере Firefox под номером .

Шаги, предпринятые для преодоления задержки

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

Создание спрайтов

Создание спрайтов – это термин, который часто используется для описания действия, когда вы собираете множество маленьких изображений в одно большое. Затем используете javascript или CSS для «нарезки» частей большого изображения для отображения маленьких картинок.

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

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

Встраивание

Встраивание – это ещё одна уловка для избежания отправки отдельных изображений, использование вместо этого data – URL, встроенный в CSS файл. Это имеет те же преимущества и недостатки, что и случай со спрайтами.

Icon1 { background: url(data:image/png;base64,) no-repeat; } .icon2 { background: url(data:image/png;base64,) no-repeat; }

Объединение

Также как и в двух предыдущих случаях, на сегодняшний день большие сайты могут иметь и множество javascript файлов. Утилиты разработчиков позволяют объединить все эти файлы в один огромный ком, чтобы браузер получил один файл вместо множества маленьких. Большое число данных отправляется, тогда лишь как небольшой фрагмент реально требуется. Излишнее большое количество данных требуется перезагрузить, когда потребуется сделать изменение.

Раздражение разработчиков и принуждение к выполнению этих требований – это, конечно, «просто» боль для причастных людей и не отображено ни в каких графиках производительности.

Шардинг

Заключительный трюк, который я упомяну, применяемый владельцами сайтов для улучшения загрузки в браузерах, часто называют «шардингом». Это в основном означает рассредоточение вашего сервиса по максимально возможному числу различных хостов. На первый взгляд это звучит безумно, но на это есть простая причина!

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

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

Ещё одна причина шардинга – это размещение изображений и подобных ресурсов на отдельных хостах, которые не используют cookie, поскольку cookie на сегодняшний день могут быть значительного размера. Используя хосты изображений без cookie вы можете увеличить производительность просто за счёт значительно меньших HTTP-запросов!

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

Обновление HTTP

А не было бы лучше сделать усовершенствованный протокол? Который бы включал в себя следующее…

1. Создать протокол, который был бы менее чувствителен к RTT
2. Исправить конвейерную обработку и проблему блокировки начала очереди
3. Остановить необходимость и желание в увеличении числа соединений к каждому хосту
4. Сохранить существующие интерфейсы, всё содержимое, формат URI и схемы
5. Сделать это внутри рабочей группы IETF HTTPbis

IETF и рабочая группа HTTPbis

Инженерный совет Интернета (IETF) – это организация, которая разрабатывает и продвигает интернет стандарты. Большей частью на протокольном уровне. Они хорошо известны по серии RFC-документов, документирующих всё: от TCP, DNS, FTP до лучших практик, HTTP и множества вариантов протокола, которые нигде не были применены.

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

Рабочая группа HTTPbis была сформирована в течении лета 2007 года и должна была обновить спецификацию HTTP 1.1 - отсюда и суффикс «bis». Обсуждение в группе новой версии HTTP протокола по-настоящему началось в конце 2012 года. Работа над обновлением HTTP 1.1 была завершена в начале 2014 года.

Заключительное совещание для рабочей группа HTTPbis перед ожидаемым финальным выпуском версии спецификации http2, пройдёт в Нью-Йорке в начале июня 2014 года.

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

Суффикс «bis»

Группа названа HTTPbis, где суффикс «bis» происходит от латинского наречия, которое означает «два». Бис часто используют как суффикс или часть имени внутри IETF для обновления или второй попыткой работы над спецификацией. Также, как в случае HTTP 1.1.

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

Протокол передачи гипертекста (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 .

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