Разъяснение http2. IETF и рабочая группа HTTPbis
На момент написания (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.0HTTP сегодня
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
А не было бы лучше сделать усовершенствованный протокол? Который бы включал в себя следующее…
- Создать протокол, который был бы менее чувствителен к RTT
- Исправить конвейерную обработку и проблему блокировки начала очереди
- Остановить необходимость и желание в увеличении числа соединений к каждому хосту
- Сохранить существующие интерфейсы, всё содержимое, формат URI и схемы
- Сделать это внутри рабочей группы 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 - HTTP/2. HTTP/2 уже поддерживается в популярных веб-сервераx -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/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 – это протокол , который регулирует связь между вашим сервером и браузерами посетителей вашего сайта. 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.
23.04.18 827Протокол передачи гипертекста (HTTP ) управляет соединением между сервером и браузерами. Впервые с 1999 года мы получили новую версию этого протокола , и она обещает существенно более быстрые сайты для всех.
Я расскажу о ключевых особенностях нового протокола , рассмотрю его совместимость с браузерами и серверами.
Краткая история HTTP
HTTP – это старый протокол, изначально определённый в 1991 году , и в последний раз серьёзно изменённый в версии HTTP/1.1 .
Сайты в 1999 году сильно отличались от тех, которые мы разрабатываем сегодня. Сейчас, чтобы отобразить домашнюю страницу среднего сайта, требуется 1,9 Мб. При этом загружается более 100 отдельных ресурсов, от изображений и шрифтов до файлов JavaScript и CSS .
HTTP/1.1 плохо работает с большим количеством ресурсов. Поэтому лучшие практики оптимизации направлены на повышение производительности этой версии протокола.
SPDY
В 2009 году два инженера корпорации Google рассказали про исследовательский проект под названием SPDY . Этот проект был нацелен на решение проблем, связанных с работой протокола HTTP/1.1. SPDY позволяет:
- Использовать конкурирующие запросы в одном соединении TCP (мультиплексирование ).
- Браузерам устанавливать приоритеты так, чтобы ресурсы, важные для отображения страницы, загружались первыми.
- Сжимать и уменьшать заголовки HTTP
- Реализовать технологию server push , в рамках которой сервер может пересылать браузеру важные ресурсы, прежде чем его об этом попросят.
В добавление к этому SPDY обязывает шифровать соединение (HTTPS ) между браузером и сервером.
SPDY не заменяет HTTP . Он скорее является туннелем для протокола и изменяет процесс отправки запросов и ответов HTTP . Для него обязательна поддержка, как на стороне сервера, так и на стороне клиента. Благодаря поддержке, доступной в NGNIX и пакетах от Google для Apache , SPDY применялся достаточно широко. При этом современные версии основных браузеров поддерживают его в полном объеме.
Поддержка SPDY браузерами по данным « Can I Use »
HTTP/2
Поддержка SPDY была прекращена в Edge из-за того, что специалисты Microsoft реализовали в новом браузере поддержку HTTP/2 – последней по времени выхода версии протокола HTTP . Но другие современные браузеры всё ещё сохраняют поддержку SPDY .
Поддержка HTTP /2 браузерами по данным « Can I Use »
HTTP/2 строится на успехе SPDY , который был использован как стартовая платформа для нового протокола. При этом большинство задач SPDY так же реализовано в HTTP/2 . Требование соединения по HTTPS было отменено . Несмотря на это, разработчики всех браузеров решили реализовать поддержку HTTP/2 только для TLS (https ) соединений. Поэтому использования HTTP/2 подразумевает использование сайтом HTTPS .
Спецификация HTTP/2 была завершена в феврале 2015 года. Спустя год он прекрасно поддерживается браузерами. Так же, как и SPDY , HTTP/2 предполагает поддержку, как в браузере, так и на сервере.
Уже существует много его реализаций для серверов. Вы можете следить за ними в справочнике по HTTP/2 .
Придётся ли изменять сайты?
HTTP/2 обратно совместим с HTTP/1.1 , поэтому есть возможность его проигнорировать, и всё продолжит работать, как раньше. Изменение протокола незаметно для пользователей. Многие из читателей этой статьи уже используют протокол, отличный от HTTP/1.1 многие годы. Например, если у вас есть аккаунт в почтовом сервисе Gmail , и вы используете браузер Google Chrome для доступа к нему.
Но с течением времени, когда многие серверы и браузеры обновляются до HTTP/2 , ваш сайт, однажды оптимизированный в соответствии с лучшими практиками, начнёт казаться медленным по сравнению с интернет-ресурсами, оптимизированными под новый протокол.
Что нужно изменить, чтобы использовать преимущества HTTP/2?
Прежде чем вносить изменения, необходимые для перехода сайта на HTTP/2 , нужно определить, используют ли посетители вашего ресурса браузеры, которые поддерживают этот протокол.
Переходите на TLS
Для многих ресурсов наиболее сложным при переходе на HTTP/2 может быть вовсе не сам протокол, а требование о работе сайта через защищённое соединение. Если вы разрабатываете новый сайт или обновляете старый, первым шагом должен быть переход на https .
Это важно не только для HTTP/2 . Google использует защищённое соединение как сигнал при ранжировании сайта , а браузеры начинают отмечать не https сайты как «небезопасные ».
Преобразование нескольких файлов изображений в спрайты
При использовании протокола HTTP/1.1 получение одного большого изображения гораздо более эффективно для браузера, чем совершение множества запросов к маленьким файлам. Чтобы обойти это, можно включить иконки в один спрайт-файл .
Получающийся в результате этого спрайт возвращался в единственном HTTP-запросе , предотвращая возникновение очереди из запросов. Но даже если посетитель находился на странице, показывающей только одну из этих иконок, ему всё равно приходилось загружать гораздо больший файл, чтобы увидеть одну конкретную картинку.
Благодаря мультиплексированию в HTTP/2 очереди запросов к ресурсам больше не являются проблемой. Предоставление изображений по отдельности лучше по нескольким причинам: нужно будет отправить только то, что запрошено.
Но спрайт может уменьшить размер загружаемых данных. Особенно когда все эти изображения используются на загружаемой странице. Однако использование спрайтов больше не является лучшим вариантом.
Встраивание изображений с помощью Data URI
Другой метод решения проблемы множественных запросов в HTTP/1.1 – встраивание изображений в CSS, используя data URI . Встраивание изображений таким образом сильно увеличивает размер файла стилей. Если вы сочетаете этот метод с другой техникой оптимизации, то браузер загрузит весь этот CSS ? даже если пользователь не посетит страницы, на которых используются эти изображения. В HTTP/2 эта «лучшая практика » скорее будет вредить, чем улучшать производительность.
Соединение CSS и JavaScript
На финальной стадии сборки сайта многие соединяют все мелкие файлы CSS и JavaScript , используемые на нем. Мы зачастую разделяем их при разработке, чтобы было легче управлять ими. Но доставка одного файла браузеру более эффективна в плане производительности, чем доставка пяти. И мы снова пытаемся сократить количество HTTP-запросов .
Если вы это делаете, то посетителям придётся загрузить все стили CSS и JavaScript сайта. Можно обойти эту проблему, подключая только определённые файлы для каждой области сайта в процессе его сборки.
Запросы HTTP «дёшевы » в мире HTTP/2 . Постраничная организация используемых ресурсов при разработке сайта будет гораздо лучшей идеей. Так можно будет загружать в браузер только тот код, который требуется отображения текущей веб-страницы.
Разделение ресурсов между хостами: Sharding
При использовании протокола HTTP/1.1 вы ограничены в количестве одновременно открытых соединений. Если загрузка большого количества ресурсов неизбежна, один из методов обхода этого ограничения заключается в том, чтобы получать их с разных доменов. Этот метод известен как domain sharding . С его помощью можно сократить время загрузки. Но он может создать проблемы, не говоря уж о затратах на подготовку инфраструктуры сайта.
HTTP/2 устраняет необходимость использования domain sharding: можно запрашивать любое количество ресурсов. Но это навредит производительности: создаются дополнительные соединения TCP , и препятствует расстановке приоритетов в HTTP/2 .
Как подготовиться к HTTP/2
Несколько советов, как подготовиться к переходу на HTTP/2 .
Создавайте отдельные изображения в дополнение к спрайтам и встраиванию изображений
Оптимизируйте спрайты и отдельные изображения, использующихся на уровне страницы, если вы думаете, что при использовании спрайтов производительность сайта повысится. Это облегчит переход от больших спрайтов к маленьким.
Организуйте файлы по секциям сайта
При переходе на HTTP/2 вы получите лучшую производительность при аккуратном управлении ресурсами , когда только то, что требуется определённой странице, отправляется этой странице.
Управляйте разделением между доменами
На данный момент лучшая практика для HTTP/1.1 – ограничить разделение двумя именами хостов. В HTTP/2 существует способ объединить эти соединения, если сертификат TLS действителен для обоих хостов и хосты находятся на одном IP-адресе . TLS сертификат необходим для работы через HTTP/2 .
Дальнейшие действия
В этой статье я не рассказываю о том, как получить преимущество от новых инструментов HTTP/2 , таких как server push . Эта технология позволяет решать, какие ресурсы являются приоритетными, и заставляет сервер передавать их перед менее важными ресурсами.
Когда совершать переход?
Решение о переходе на HTTP/2 сводится к тому, поддерживается ли этот протокол большинством браузеров ваших пользователей . Помните, что HTTP/2 обратно совместим, поэтому вам не придётся делать ничего особенного.
Если большинство посетителей используют браузеры, поддерживающие HTTP/2 , настал момент для оптимизации под этих пользователей. Например, многие преимущества HTTP/2 наиболее остро ощутят пользователи мобильных устройств. Если у вашего сайта большой процент мобильного трафика – это может быть сигналом к переходу на HTTP/2 .
Ваш план действий в отношении HTTP/2
- Запустите сайт с безопасным соединением или перейдите на TLS прямо сейчас.
- Подготовьтесь к HTTP/2 в процессе сборки сайта. Используйте советы, приведенные выше, чтобы создать сайт, оптимизированный под обе версии протокола.
- Проверьте хостинг. Удостоверьтесь в том, что ваш сервер поддерживает HTTP/2 .
- Разверните оптимизацию под HTTP/2 . Прекратите использовать устаревшие практики и переходите к применению новых.
После того, как вы перейдёте на HTTP/2 , стоит проверить, насколько увеличится скорость вашего сайта.
Узнайте больше
Растущий объём информации о HTTP/2 доступен в сети. Ниже я перечислила некоторые ресурсы, к которым я обращалась при написании этой статьи.
- “Hypertext Transfer Protocol Version 2 (HTTP/2)
” (спецификация
).
Это для людей, получающих удовольствие от чтения спецификаций, или тех, кому требуется понимание тонких моментов. Для всех остальных HTTP/2 FAQ – это прекрасный обзор основных функций. - Индикатор HTTP/2
и SPDY
: Chrome
.
Этот плагин позволяют узнать, предоставляется ли сайт, на котором вы находитесь, через HTTP/2 .
Перевод статьи “Getting Ready For HTTP/2 A Guide For Web Designers And Developers ” был подготовлен дружной командой проекта .
Хорошо Плохо
18.07.2017 11:41
HTTP/2 - это вторая версия всем известного протокола HTTP. Полностью название этого протокола выглядит как HTTP/2.0. Как известно, HTTP - или Hypertex Transfer Protocol - это протокол, который используется для передачи гипертекста. Иными словами, благодаря HTTP веб-страницы загружаются и показываются через браузер интернет-пользователям.
Протокол HTTP появился давно: первая версия - даже не первая, а 0.9 - вышла в далеком 1991 году. Через восемь лет, в 1999 году, появилась те версия HTTP, которая активно используется сейчас, - HTTP/1.1. Казалось бы, если все работает, то зачем что-то менять? Но как и везде в разработке, прогресс не стоит на месте, все меняется и требует изменений.
Разработка
Разработкой новой версии протокола занималась рабочая группа HTTPbis из Internet Engineering Task Force (Инженерного совета интернета, который разрабатывает стандарты интернета). Она была сформирована в 2007 году специально для работой над этим проектом. Однако активные действия начали происходить лишь через пять лет, в 2012 году.
Основой для HTTP/2 стал протокол SPDY (можно расшифровать как “speedy” - быстрый). Разработчик этого прокола - компания Google - создавала его для того, чтобы снизить время загрузки веб-страниц. В частности, протокол SPDY позволяет расставлять приоритеты и использовать мультиплексирование передачи нескольких файлов так, чтобы для каждого клиента нужно лишь одно соединение.
Один из участников рабочей группы Даниэль Штенберг весной 2014 года опубликовал документ , в котором рассказано о том, зачем вообще начали работу над этим проектом, и как она происходит. Документ доступен и на русском языке: https://bagder.gitbooks.io/http2-explained/ru/
Вот кратко перечисленные в описании концепции пункты:
- должны поддерживаться парадигмы HTTP;
- должны остаться ссылки http:// и https://, не нужно добавлять новую схему;
- серверы и клиенты, использующие HTTP/1, должны быть проксированы к HTTP/2-серверам;
- возможности HTTP/2 должны быть конвертированы в HTTP/1.1 при помощи прокси;
- сокращение числа опциональных частей в протоколе;
- отсутствие минорных версий в HTTP/2; при необходимости будет разработан протокол HTTP/3.
Новшества
Главное, на что направлена разработка нового протокола, - это на увеличение скорости загрузки страниц. Поэтому разработчики в том числе целились на избавление от некоторых элементов, которые препятствуют к повышению производительности.
HTTP/2 это бинарный протокол . Выбор в сторону бинарности был сделан для того, чтобы формирование пакетов проходило легче и проще. В частности, это позволило проще разделять части, которые связаны с протоколом, и те части, которые связаны с пакетом данных (эта проблема присутствует в HTTP/1).
Мультиплексирование потоков - это то, на что делается основная ставка в новой разработке. Если раньше пакеты множества потоков поставлялись бы отдельно, то при протоколе HTTP/2 пакеты в рамках одного соединения смешаны, а разделяются уже на другой стороне.
При этом каждый поток имеет свой вес или, другими словами, приоритет для того, чтобы можно было понять, какие потоки считаются более важными, а какие - менее важными. Это актуально в тех ситуациях, когда есть ограничения ресурсов, и сервер вынужден выбирать потоки, которые будут отправлены сначала.
HTTP/2 использует бинарные фреймы, они могут облегчить работу с передачей потоков. В частности, фрейм PRIORITY позволяет указывать, какие потоки зависимы от данного потока, то есть создать некую схему, дерево приоритетов с указанием отношений между собой. При этом значимость потоков может динамически изменяться. В практическом смысле это позволяет, к примеру, указывать, какие картинки на странице нужно браузеру нужно загружать в первую очередь.
Отдельно стоит вопрос сжатия . HTTP является протоколом без состояния, а значит, повторяющимся протоколом. На практике это выражается в том, что если на сервер идет запрос нескольких ресурсов (к примеру, картинок), то это рождает серию запросов, которые сами по себе является практически идентичными. Поэтому логично, что сжатие необходимо.
Однако подводные камни есть и здесь. В частности, сжатие HTTPS и SPDY уязвимы к атаке BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext), использующей недочеты алгоритма сжатия gzip/DEFLATE, и атаке CRIME (Compression Ratio Info-leak Made Easy), которая также эксплуатирует алгоритмы сжатия данных.
В результате команда HTTPbis создала HPACK - это специализированный протокол для сжатия HTTP/2-заголовков. При использовании протокола HTTP/2 служебные заголовки (на загрузку элементов страницы) передаются сжатыми, благодаря чему уменьшаются количество ресурсов, которые требуются для такой операции.
Еще один полезный фрейм - RST_STEAM . Он отвечает за отмену отправки сообщения, это используется для уменьшения растраты полосы пропускания и исключения разрыва соединения. Например, этот фрейм подойдет, если вам нужно быстро отметить посланный поток, который оказался ненужным.
HTTP/2 позволяет повысить безопасность ресурса, однако перед переходом на HTTP/2 нужно предварительно перейти на HTTPS (хотя сейчас, пожалуйста, подавляющее большинство уже сделало это).
Впрочем, HTTP/2 имеет обратную совместимость с HTTP/1, поэтому в спешке с переводом сайта на новый протокол необходимости нет. Но в дальнейшем, конечно, вы можете заметить некоторое замедление загрузки вашего сайта, т.к. оптимизация, которая работала для HTTP/1, может уже не работать для второй версии этого протокола.
HTTP/2 поддерживают все основные браузеры: Chrome, Firefox, Opera, Edge, Safari.
Также рекомендуется быстрее перейти на HTTP/2 тем, у кого много мобильного трафика.
Переход на HTTP/2
Тем, кто заинтересовался переходом на HTTP/2, я советую прочитать вот эту документацию на английском языке: https://cdn.wp.nginx.com/wp-content/uploads/2015/09/NGINX_HTTP2_White_Paper_v4.pdf
Итог
HTTP/2 - это протокол, который, с одной стороны, содержит в себе наследие HTTP/1, а с другой стороны, имеет массу преимуществ по передаче данных, результатом чего стало значительное превосходство новой версии протокола над своим предшественником.