Компания
153,19
рейтинг
1 марта в 11:03

Разработка → HTTP/2: готовимся к переходу

HTTP/2

В прошлом году в мире сетевых технологий произошло очень важное событие: была утверждена и стандартизирована новая версия протокола HTTP — HTTP/2. HTTP/2 уже поддерживается в популярных веб-серверах: 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 (HyperText Transfer Protocol) было опубликовано в 1991 году. В 1999 году была разработана и описана версия HTTP 1.1, используемая и по сей день. В то далёкое время (почти 20 лет назад) веб-сайты были совсем не такими, как сейчас. За относительно небольшой период времени сайты стали «весить» гораздо больше. Домашняя страница среднестатического современного сайта содержит примерно 1,9 МБ данных: изображения, JS, CSS и многое другое.

Из-за ограничения на количество одновременных подключений в HTTP/1.1 загрузка страниц, содержащих большое количество «тяжёлого» контента, осуществляется медленно. Можно выделить два пути решения этой проблемы. Первый заключается в использовании различных техник оптимизации производительности (о некоторых из них мы уже писали), а второй — в попытке модификации самого протокола HTTP с целью устранения возможных узких мест. Рассмотрим такие попытки более подробно.

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

SPDY требует поддержки как на стороне сервера, так и на стороне клиента. Разработчики Google создали специализированные модули для Apache (mod_spdy) и для Nginx (ngx_http_spdy_module). Поддерживается он и практически во всех популярных браузерах.

HTTP/2, представленный шестью годами позже, во многом основывается на SPDY. Новая версия HTTP была создана рабочей группой Hypertext Transfer Protocol working group. В мае 2015 года спецификация HTTP/2 была опубликована как RFC 7540.

Протокол HTTP/2 обратно совместим с HTTP/1.1. Изменения, направленные на устранение узких мест и повышения производительности, во многом продолжают линию SPDY. Рассмотрим вкратце наиболее важные из них.

HTTP/2: основные нововведения


Мультиплексирование


Возможно, это самое главное преимущество HTTP/2. В HTTP/1.1 для каждого запроса требуется устанавливать отдельное TCP-соединение. Мультиплексирование же позволяет браузеру выполнять множество запросов в рамках одного TCP-соединения:

HTTP/2

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

Полезные ссылки


В заключение приведём для заинтересованных читателей несколько полезных ссылок по теме:



Читателей, которые по тем или иным причинам не могут оставлять комментарии здесь, приглашаем в наш блог.
Автор: @AndreiYemelianov
Селектел
рейтинг 153,19

Комментарии (88)

  • –2
    1. В IIS пока только HTTPS и только в 2016 сервере, которого еще нет.
    2. Множество всего из IIS не реализовано и позиционируется лишь как прототип:
    2.1 Windows authentication (NTLM/Kerberos/Negotiate) is not supported with HTTP/2. In this case IIS will fall back to HTTP/1.1.
    2.2 Clear text – as mentioned above, IIS currently only supports HTTP/2 over TLS. Again, IIS will fall back to HTTP/1.1.
    2.3 Bandwidth throttling – IIS has a feature to limit bandwidth (in Inetmgr, select the site, ‘Limits’ under Configure of the Action pane). This applies to HTTP/1.1 but is not enforced for HTTP/2 (will proceed with no errors or bandwidth limiting).
    3. DataURI обычно встраивают в html сразу, а не в CSS файл. Надо быть странным человеком, чтобы галереи фотографий грузить из CSS. И это, как раз, в некоторых случаях облегчает кэширование и все с ним связанное. Как в HTTP 1, так и в HTTP 2.
    4.Доменное шардирование делается не только для того, чтобы уменьшить количество подключений к одному ресурсу. А для того, чтобы использовать CDN, API и многое, многое другое. Его использование пока не имеет альтернатив и уж никак не связано с версией HTTP.
    5. Вообще, этот упор по всей статье на количество соединений, выглядит нелепо.
    6. Заголовки, они процентное отношение к передаваемой информации какое имеют, дольше сжиматься будут, чем передадутся? Это мизер. В 99% сам контент медленно отдается, с базы, с файловой системы и так далее.
    • +8
      Я так понимаю, IIS — не самый распространённый веб-сервер в интернете. В современном nginx HTTP/2 работает «из коробки», и, как ни странно, действительно делает именно то, что обещали разработчики — ускоряет загрузку, отдавая контент в те самые много потоков. Например статика: картинки, js и css теперь грузятся одновременно, а gzip уже много лет как нагрузку (и время) на свою работу даёт совершенно неощутимые. А если учесть, как nginx всё это кеширует, то количество соединений действительно является решающим фактором.
      • –1
        В IIS как раз включено по умолчанию это будет, насколько я понял. Тут же нужно конфигурировать, исходя из статьи (я не специалист в NIX стеке). Никто не говорил о нагрузке, пункт 6 говорит о том, что скорость передачи заголовка быстрее чем его сжатие, это лишь предположение. Уменьшение тут за счет количества заголовков, а не за счет сжатия.
      • –1
        Кстати, из статистики, быстро нашел (2013 год): Наибольший прирост клиентской базы продемонстрировал IIS от Microsoft (23.10% рынка), у которого за отчетный период появилось 16,5 млн новых хостов. За ним с отрывом в 7% следует nginx, чей месячный прирост составил 11,4 млн хостов, в том числе 1,5 млн хостов, решивших отказаться от Apache.
        Само собой первый апач, хотя сранивать IIS или Apache и nginx, насколько я понимаю, не корректно.
        • 0
          Любой NIX-сервер надо конфигурировать. И в случае с nginx достаточно указать в директиве listen не ssl, а http2. Более того, есть глубокий смысл внимательно отнестись к настройкам ciphers, ssl_stapling и ssl_dhparam. Но это относится и к обычному https. От apache, как правило, не отказываются, но перестают его выставлять «голым задом» в интернет, и в качестве реверс-прокси применяют как раз nginx. Это помогает буферизовать всё общение апача с внешним миром, не заставляя его тратить мегабайты памяти на поддержку, например, медленных соединений. А IIS… Основная его прелесть на сегодняшний день это глубокая интеграция с .Net, на котором действительно просто решать сложные и интересные задачи. Кстати, есть еще одна не решенная задача с nginx: сквозная авторизация ntlm. Хотя-бы потому, что он не умеет сопоставлять соединения входящие и к backend один-к-одному. С другой стороны, если бы он умел, то были бы проблемы с буферизацией, ради чего его и используют.
          Зачем еще растить IIS в интернете — честно говоря, я ума не приложу.
          • 0
            Кстати, есть еще одна не решенная задача с nginx: сквозная авторизация ntlm. Хотя-бы потому, что он не умеет сопоставлять соединения входящие и к backend один-к-одному.
            Умеет: nginx.org/r/ntlm/ru, но за деньги.
        • 0
          Можно было и за какой-нибудь 2000-ый поискать, когда nginx не существовало.
          http://w3techs.com/technologies/cross/web_server/ranking
          • –1
            Для тех, кто в танке и не умеет пользоваться поиском: http://w3techs.com/technologies/overview/web_server/all тут больше 10 процентов. Это все равно значительная часть. Я уже не говорю, что статья вообще не об этом, но надо же потешить свое самолюбие Developer @ NGINX, Inc.
            • 0
              Для справки, сайт w3techs.com специализируется на статистике интернет-ресурсов и обновляет данные раз в сутки. Разница между вашей и моей ссылкой лишь в разбивке данных. По моей ссылке она чуть более подробная и содержит выборку для топ 1000, 10 000, 100 000 и 1 млн. самых посещаемых сайтов, а также процент "Overall" (т.е. в целом по всем отслеживаемым хостам). По вашей ссылке точь в точь та же самая статистика по "Overall", но для чуть более расширенного списка серверов.

              Я нигде не отрицал, что в целом по интернету IIS вероятно имеет свои "чуть больше 10 процентов" и продолжает их стремительно терять. Но все верно, статья не об IIS, так что непонятно, зачем его было приплетать, а уж переходить на личности точно не стоило.

              Для тех, кто в танке и не умеет пользоваться поиском
              ;-)
            • +1
              И если уж вы решили цитировать статистику и что-то этим пытаетесь доказать или утверждать на тему, то замечу, раз статья на русском, то наверное статистика по русскоязычным сайтам более актуальна для целевой аудитории: http://w3techs.com/technologies/segmentation/cl-ru-/web_server
      • 0
        Я так понимаю, IIS — не самый распространённый веб-сервер в интернете

        Согласно статистике доля IIS составляет не менее 25%
        И это не учитывая того, что часто IIS находится за тем же nginx, который используется в качестве кэширующего прокси.
        Так что это как раз один из популярных веб-серверов.
        • +2
          Тут вопрос в том, что именно считать.
          Я нашел вот такой подсчет:
          http://news.netcraft.com/archives/2015/06/25/june-2015-web-server-survey.html

          И в нём я вижу некоторое отличие веб-серверов «All sites» и «Active sites», не говоря про «top million busiest sites». Исходя из этого, я предлагаю прекратить бесполезный спор о распространённости серверов. Всё равно каждый увидит именно то, что хочет увидеть.
        • +3
          Это они удачно подкупили godaddy, который повесил на один IIS миллионы припаркованных доменов.
      • 0
        HTTP/2 почти везде поддерживается только через TLS, а через него передавать HTTP-сжатые данные небезопасно.
    • +4
      Надо быть странным человеком, чтобы галереи фотографий перегонять в DataURI. А вот мелкие интерфейсные элементы (в основном иконки) в CSS загоняют частенько.
      • 0
        Внезапно, Гугл Картинки так делают для первых результатов.
        • 0
          Хорошее замечание. Но все-таки это исключение.
    • –3
      IIS это же продукт microsoft, а microsoft как всем давно известно — *овно...
    • +5
      1. Проблема выбора инструмента. Если ваш IIS не умеет в HTTP2, это не значит, что HTTP2 не нужен.
      2. Туда же.
      3. Галереи фотографий в HTML встраивать? Для этого тоже надо быть странным человеком.
      4. Доменный шардинг используется для обхода ограничения на число соединений и для сокращения заголовков (чтобы избавиться от тех же лишних Cookie). Что касается CDN и API — вы путаете причину и следствие. В этом случае доменный шардинг не умышленный, это просто побочный эффект (который может приводить к некоторой деоптимизации даже).
      5. Вообще, количество соединений — одна из больных тем производительности в вебе, не даром столько времени уделяется сейчас склеиванию, инлайнингу, шардингу.
      6. В HTTP2 сжатие заголовков помимо кодирования Хаффмана и статических таблиц также использует динамические таблицы, что позволяет не передавать для каждого запроса заголовок, а, грубо говоря, ссылаться на ранее переданный. Одни только куки могут занимать кучу места, и с каждым запросом при этом они дублируются. Да и большая часть заголовков также постоянно повторяется. Это ещё одна проблема, которая обходилась ранее сочетанием склеивания-инлайнинга файлов с шардингом по cookie-free доменам.

      В целом HTTP2 — это лишь инструмент для избавления от хаков, которых требовал устаревший протокол.
      • –4
        Страшно стало на хабр писать.
        1. Не знаю, где вы прочитали, что он не умеет или умеет хуже, чем NIX стек
        3. Я привел пример с точки зрения того, что никто галереи так не строит. Т.е. нет тут большого количества информации, размер маленький. Вы уже второй, кто понимает это как: надо делать галереи в датаюрл. Почему вы считаете себя умнее других, ведь вам в голову это не пришло, другие первоклассники?
        4. Каким образом CDN является следствием шардинга? Или API? Никак уж не появился сначала шардинг из-за проблем с количеством запросов, а потом такие подхватили CDN-щики и т.д. Это все параллельные ветви.
        6. От куда возьмутся кукисы, если вы их не вешаете? Тем более с каким-то размером адским?
        • +5
          Боюсь, вам стоит перечитать сначала свой комментарий, потом мой. Потому что сейчас вы в половине случаев противоречите своим словам, а во второй — выставляете утверждения, обратные моим, за слова, мною сказанные. Естественно, звучат они нелепо.

          Пока перечитывание и осознание происходящего не осилите, дальнейший диалог смысла иметь не будет.
          • –1
            Видимо я все-таки не доходчиво написал.
            3. Любой нормальный человек понимает, что галереи не надо делать в датаюрл. Это понятно всем. Зачем задавать вопрос, на который вы заранее знаете ответ? Я не кому не говорил что я делаю так или знаю того, кто делает так. Я утверждал, что наоборот, если это и встречается, то крайне редко и в виде просто мизерных масштабов информации, по отношению к размеру хотя бы одной галереи на сайте. Вот что я имел ввиду. Так понятнее?:)
            Не жду ответа уже ни на 4 ни на 6 вопросы. Происходящее в том, что вы кинулись искать бревно в глазу соседа, свое не заметив. Это свойственно всему хабру уже года 3 как. Даже банальные вещи типа своего 1 пункта вы все равно не признаете. У меня четко написано, что IIS умеет, у вас же, сразу: IIS ничего не умеет, инструмент не правильный, какие-то предположения.
    • 0
      В таких случаях рекомендуется терминировать HTTP/2 и TLS на reverse-proxy, а IIS запускать за ним по нешифрованному HTTP/1.1. Это классическая схема.
  • 0
    Отличная статья, спасибо!

    Правильно ли я понимаю, что HTTP/2 так же решает проблему размещения нескольких сайтов защищенных SSL-сертификатами на одном IP-адресе?
    • +12
      HTTP/2 тут ни при чем — для этого нужен SNI, который работает и на HTTP/1.1.
  • +4
    Уже перевел свой сервер на HTTP/2 на nginx. Если у вас на сайте есть TLS, то для новых браузеров этот протокол существенно уменьшает время загрузки страницы. С нетерпением жду, когда же разработчики nginx реализуют HTTP/2 prefetch/preload/server push — это ускорит загрузку еще на один roundtrip.
    • 0
      Ну это даже не «уже» :) Если, конечно, вы в значении «включил недавно».

      HTTP/2 на nginx работает (и отлично!) более чем давно, и польза от него есть. Но, да, prefetch/preload/server push в нем все нет и нет. Правда, они и требуют уже не просто замены «ssl» на «http2» в конфиге, а именно указания, с чем и как делать те самые prefetch/preload/server push, так что «эту кошку надо уметь готовить» — но пока, да, не с чем готовить.
  • 0
    Когда планировать переход на HTTP/2? Однозначного ответа на этот вопрос нет и быть не может. Дадим, однако, одну подсказку: регулярно просматривайте логи посещаемости вашего сервиса. Когда вы увидите, что большая часть посетителей используют поддерживающие HTTP/2 браузеры — можно переходить.

    Но если HTTP/2 обратно совместим с 1.1, то, в целом, переходить можно уже сейчас, ничего не опасаясь?
    • +2
      Тут всё хорошо расписано: https://www.nginx.com/blog/7-tips-for-faster-http2-performance/
    • 0
      Работать всё будет. Можно переходить уже сейчас. Но переход на HTTP2 имеет смысл при избавлении от костылей, которые раньше обеспечивали рост производительности. То есть пользователи старых браузеров (~30%, в основном IE) получат некоторое падение скорости.
  • 0
    Спасибо! Уже как 3 месяца на HTTP/2 полёт отличный. Правда до этого где то полгода использовал SPDY.
  • 0
    перевод без ссылки на оригинал это нечестно https://www.smashingmagazine.com/2016/02/getting-ready-for-http2/
    • +1
      Во-первых, это не совсем перевод. Во-вторых, мы и не скрываем, что использовали эту статью.
  • +1
    Только вот пересобрать nginx из исходников c openssl 1.0.2f все-таки придется, по крайней мере, в Ubuntu 14.04LTS ;)
    • +1
      Т.к в репе nginx собран с либой 1.0.1, а на 1.0.1 не будет работать ALPN, т.е запросы TLS 1.2 будут уходить на http/1.1, а не H2 (HTTP/2)

      PS. Поправьте, если что не так
      • 0
        Да-да, удивительно, что для своих репозиториев они собирают версии с 1.0.1. Проверил и на репозиториях для CentOS 6/7.
        Появилась поддержка модульности, теперь уже можно использовать и сжатие brotli, не пересобирая nginx, (но нужно под каждую конкретную версию собрать плагин). А вот для работы такой классной возможности недостаточно даже обновления OpenSSL на сервере.
        Проверил требования в rpm: openssl >= 1.0.1. Но после тестовой замены системного OpenSSL на 1.0.2 ALPN не появился.
      • 0
        Как это проверить?
        • +2
          В инструментах разработчика браузера колонка Protocol во вкладке Network: если h2, то используется http/2
          • 0
            Ни в Chromium ни в Firefox такого не нашёл. Но в firefox нашёл версию: пишет 2.0 и в Chrome при помощи плагина отследил наличии http2 сессии и даже смог лог http2 коннекта глянуть.
            Так что я думаю всё работает и это без каких либо телодвижений связанных с OpenSSL.
            • +1
              в Хроме добавить колонку Protocol по пкм, если ее нет.
              в FF смотреть header X-Firefox-Spdy
              ну, или плагины, да
            • 0
              (echo | openssl s_client -alpn h2 -connect google.com:443) | grep ALPN

              вместо google.com вставить свой хост.
              ALPN protocol: h2 — все гуд.
              No ALPN negotiated — не гуд.
              • 0
                В Хроме и Firefox показывает что протокол h2 но вот openssl: No ALPN negotiated.
                Может это только openssl проблема?
              • 0
                тест на ssllabs.com уже тоже показывает наличие ALPN
                • 0
                  Ну ALPN нету при этом:
                  Application-Layer Protocol Negotiation (ALPN) No
                  Next Protocol Negotiation (NPN) Yes h2 http/1.1

                  т.е. NPN достаточно кажется для браузеров.
      • 0
        ALPN не нужен для работы HTTP/2 с большинством популярных браузеров на данный момент, достаточно NPN, который есть и в OpenSSL 1.0.1.
    • 0
      Я пересобирал nginx с OpenSSL 1.0.2e, полет нормальный. Пришлось написать длинный-длинный Dockerfile.
      • +1
        Ну, openssl 1.0.2f не принципиально, главное, чтобы 1.0.2 был.
      • 0
        На всякий случай, вдруг кому надо:
        https://github.com/scf37/docker-nginx
  • 0
    > В современных браузерах количество одновременных TCP-соединений ограничено. Поэтому страницы с большим количеством статического контента загружаются не так быстро, как хотелось бы.
    А в чем проблема поднять количество соединений? Если интернет плохой, то не важно сколько соединений будет, всё равно будет медленно. Если интернет хороший, то количество соединений решит проблему. Об этом в гугле не подумали?
    > Многие браузеры уже помечают сайты, не поддерживающие https, как «небезопасные».
    Это какие браузеры? Я просто давно мечтаю о таком, но не видел нигде еще.

    Кроме того, передача одного и того же объема данных через 2-3 соединения почти всегда быстрее, чем передача через одно соединение. До сих пор не вижу нигде ничего убедительного в пользу перехода на HTTP/2.
    • 0
      Количество соединений ограничено первой версией стандарта HTTP, ибо на момент его проектирования интернеты были медленные. Рост количества соединений возможен через доменный шардинг. Но он решает проблему менее эффективно, чем работа через одно соединение: затраты на создание множества соединения достаточно высоки, чтобы оно негативно влияло на производительность. Профита от отказа от мультиплексирования запросов в одно соединение не будет.
      • +1
        Количество соединений ограничено скрытыми настройками в самих браузерах. И вместо шести, можно сейчас поставить и 12, если подключение хорошее, то будет нормально.
        • 0
          Это вам нормально, а пользователи вашего сайта вообще ничего о соединениях могут не знать.
          • –1
            Я намекаю на то, что сейчас производителям браузеров проще поднять количество одновременных соединений, чем внедрять новые сомнительные протоколы.
            • 0
              «Сомнительные» протоколы — инструмент борьбы с действительно сомнительными хаками, к которым всё равно придётся прибегать если не с целью победить количество одновременных соединений, то с целью уменьшить количество трафика и избавиться от задержек на создание новых соединений.
              • 0
                На самом деле HTTP/2 во многом один большой хак. Так что не всё так однозначно.
                • 0
                  Количество решений как то не тянет на слово "хак". Может просто не очень удачное решение?
                  Ну и насколько я это себе понимаю, http2 больше помогает серверу чем клиенту.
    • 0
      Это какие браузеры? Я просто давно мечтаю о таком, но не видел нигде еще.
      Поправил: это ещё не реализовано. Но скоро будет внедрено и в Chrome, и в Firefox:

      https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure
      https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
      • 0
        Насколько я вижу, они еще в режиме Proposal, так что не надо писать «МНОГИЕ браузеры УЖЕ помечают».
        • 0
          Да, это момент я уже поправил.
    • 0
      Обратите внимание, что это TCP-соединения. А значит, для получения данных на полной скорости каждому соединению нужно пройти процесс TCP Slow Start, время которого зависит от величины RTT. Поэтому использование одного соединения в HTTP/2 и даёт прирост скорости, особенно на каналах с большим RTT.
      • +1
        Только ситуация как раз обратная, 6 TCP соединений имеют большее суммарное окно, как в начале, сразу после открытия, так и в конце, после передачи данных.
        • 0
          Спасибо за уточнение, с этой стороны я не смотрел на проблему. Получается выбор между TCP handshake (HTTP/1.1) и TCP slow start (HTTP/2)?
          • 0
            TCP-хэндшейк достаточно дешевый чтобы в большинстве случаев на типичных задержках его не замечать. Основная экономия там достигается на TCP+TLS хэндшейках вместе взятых. HTTP/2 в браузерах работает только поверх TLS.
            • 0
              Плюс из-за того, что можно отправить запросы сразу ко всем ресурсам и нет такого жесткого ограничения на кол-во параллельных потоков, устраняется проблема HOL-блокировки. Это не влияет на общее время загрузки, но в некоторых случаях позволяет браузерам получать минимально необходимые ресурсы для отрисовки страницы в первую очередь и страница отображается быстрее. Загружаться она может при этом дольше, но визуально пользователю кажется, что сайт работает шустрее.
              • +1
                Плюс из-за того, что можно отправить запросы сразу ко всем ресурсам и нет такого жесткого ограничения на кол-во параллельных потоков, устраняется проблема HOL-блокировки.
                Ну, так поэтому и придумали QUIC. Насколько я знаю, руководство в Гугле сильно настаивает на его повсеместном включении (наряду с HTTP/2).
  • +3
    Стоило упомянуть о механизме Server Push в http/2, тоже интересная фича
  • +1
    Недавно натыкался на упоминания что HTTP2 вовсе не всегда даёт прирост производительности, а даже замедляет её. Где-то даже в рассылке было обсуждение. Насколько помню если файлов мало грузится то выигрыша не будет.
  • 0
    Более того, в случае с HTTP/2 шардирование не улучшит производительность, а приведёт скорее к противоположному эффекту, так как создаст дополнительные TCP-соединения и будет мешать приоритизации.

    Вот как раз по этому поводу вопрос: если шардируются 3 домена на одном и том же IP — будет ли браузер открывать к каждому отдельное tcp-соединение, или он переиспользует одно и тоже?
    • 0
      если шардируются 3 домена на одном и том же IP — будет ли браузер открывать к каждому отдельное tcp-соединение, или он переиспользует одно и тоже?

      Будет открывать три соединения, т.к. соединения учитываются по доменному имени, а не IP.
      • 0
        Спасибо.
    • 0
      Зависит от сертификата. Если сертификат валиден для всех трех доменов, то будет одно соединение. Если валиден для двух из трех, скажем, то к этим двум будет одно соединение и еще одно к третьему.
      • 0
        Если я верно понимаю, с невалидным сертификатом он подключаться вообще не станет?
        Интересно, а как-то в стандарте такое поведение описано? По идее в нем немало уделено вниманию совместимости со старыми решениями и прочим, и как сделать так, чтобы не сломать все наследие.
        • +1
          С невалидным поведение такое же как и раньше: браузер предупредит пользователя и тому нужно будет нажать кнопку. И скорее всего такое соединение не будет использоваться для запросов к другим хостам, даже если принятый таким способом самоподписной сертификат валиден и для них.

          Вот чего-чего, а совместимости и разным деталям в стандарте уделено внимания не очень много, он вообще создает впечатление довольно сырого и написанного на скорую руку. Т.н. connection reuse, о котором я рассказал, описан в этой части: https://tools.ietf.org/html/rfc7540#section-9.1.1
          • 0
            Спасибо.
  • –1
    Не очень понял из текста, а где же проблемы-то?
  • +1
    Не могу понять в чём основное приемущество http/2?
    Мультиплексирование же позволяет браузеру выполнять множество запросов в рамках одного TCP-соединения
    Чем это отличается от keep-alive? У меня дежавю или в 1999 нам уже это обещали?
    • +1
      тем, что ответы могут начать приходить по частям и одновременно.
      P.S. а QUIC уже дозрел до продакшна, хотя и с использованием реверс-прокси… хромоклиенты радуются увеличению скорости, все довольны.
      • +1
        В любом TCP-соединении ответ может приходить по частям, пакетами. Даже в http/1.0.
        Я вместо автора статьи слазил в интернет и узнал, что в http/2 мультиплексирование позволяет посылать http-запросы ОДНОВРЕМЕННО. Keep-alive не позволял этого делать.
  • +1
    После перехода на HTTP/2 под Nginx Яндекс.Бот перестаёт индексировать сайт
    Вот даже статья по этому поводу https://talk.pr-cy.ru/topic/21406-bot-yandeksa-i-podderzhka-protokola-http2/

    Может кто знает как для NGINX исправить это?
    • +1
      У меня тоже не индексирует… Не ожидал такого от Яндекса. Исправляется скорее всего аналогично — нужно в if вставить директиву, удаляющую заголовок Upgrade. Вечером займусь.
      • +1
        Если получится, поделитесь пожалуйста правилом :)
        • +1
          Итак. голый http у меня возвращает 301 на https-версию. Как оказалось, https-версию сайта нужно добавлять руками в вебмастер, чтобы видеть статистику по HTTPS-версии сайта. Добавил, зашел на бета-версию вебмастера яндекса, страница "Проверка ответа сервера". Респонс есть, хтмл возвращается. Вот заголовки:

          Server: nginx/1.9.9
          Date: Mon, 14 Mar 2016 19:38:20 GMT
          Content-Type: text/html; charset=UTF-8
          Transfer-Encoding: chunked
          Connection: keep-alive
          Cache-Control: no-cache,no-store,max-age=0,must-revalidate
          Expires: Mon, 14 Mar 2016 19:38:20 GMT
          Strict-Transport-Security: max-age=31536000;
          Content-Encoding: gzip

          Да, HTTP/2 у меня включен, https://tools.keycdn.com/http2-test не станет врать. Или уже починили, или я чего-то не понимаю.
    • +1
      Перевели больше 10 сайтов на HTTP/2, никаких проблем с индексацией нет. На счет склейки зеркал (установки основного зеркала в Вебмастере) есть задержка. Оставьте 301 редирект с HTTP на HTTPS и подождите примерно месяц, основной адрес обновится. Также полезно добавить HTTPS версию как отдельный сайт (у Гугла то же самое). На время перехода может снизиться трафик, после переиндексации все восстановится.
      • 0
        Под NGINX проблемы действительно нет. А с Apache я ссылку бросал выше, где и написано как можно избежать проблем.
        Так что всё в порядке. Продолжаем тестирование.
  • 0
    простая тестилка http2.0 / spdy
    https://http2-check.com/t/www.facebook.com
    может кому пригодится

    (там еще полезная кнопка header есть)
  • 0
    Использую CentOS 7 + EPEL, похоже простого способа заполучить HTTP/2, без ручной пересборки apache, у меня пока нет.

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

Самое читаемое Разработка