В прошлом году в мире сетевых технологий произошло очень важное событие: была утверждена и стандартизирована новая версия протокола 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-соединения:
В современных браузерах количество одновременных 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/2 FAQ — краткая, но информативная выдержка из спецификаций по ссылке выше;
- разъяснения по HTTP/2, написанные разработчиком утилиты curl Даниэлем Стернбергом (см. также русский перевод);
- презентация об оптимизации сайтов под HTTP/2.
Читателей, которые по тем или иным причинам не могут оставлять комментарии здесь, приглашаем в наш блог.
Комментарии (80)
Scf
01.03.2016 11:45+4Уже перевел свой сервер на HTTP/2 на nginx. Если у вас на сайте есть TLS, то для новых браузеров этот протокол существенно уменьшает время загрузки страницы. С нетерпением жду, когда же разработчики nginx реализуют HTTP/2 prefetch/preload/server push — это ускорит загрузку еще на один roundtrip.
achekalin
03.03.2016 01:37Ну это даже не «уже» :) Если, конечно, вы в значении «включил недавно».
HTTP/2 на nginx работает (и отлично!) более чем давно, и польза от него есть. Но, да, prefetch/preload/server push в нем все нет и нет. Правда, они и требуют уже не просто замены «ssl» на «http2» в конфиге, а именно указания, с чем и как делать те самые prefetch/preload/server push, так что «эту кошку надо уметь готовить» — но пока, да, не с чем готовить.
4umak
01.03.2016 11:56Когда планировать переход на HTTP/2? Однозначного ответа на этот вопрос нет и быть не может. Дадим, однако, одну подсказку: регулярно просматривайте логи посещаемости вашего сервиса. Когда вы увидите, что большая часть посетителей используют поддерживающие HTTP/2 браузеры — можно переходить.
Но если HTTP/2 обратно совместим с 1.1, то, в целом, переходить можно уже сейчас, ничего не опасаясь?Scf
01.03.2016 12:19+2Тут всё хорошо расписано: https://www.nginx.com/blog/7-tips-for-faster-http2-performance/
gwer
01.03.2016 13:24Работать всё будет. Можно переходить уже сейчас. Но переход на HTTP2 имеет смысл при избавлении от костылей, которые раньше обеспечивали рост производительности. То есть пользователи старых браузеров (~30%, в основном IE) получат некоторое падение скорости.
stalkerg
01.03.2016 13:12Спасибо! Уже как 3 месяца на HTTP/2 полёт отличный. Правда до этого где то полгода использовал SPDY.
matmuchrapna
01.03.2016 13:25перевод без ссылки на оригинал это нечестно https://www.smashingmagazine.com/2016/02/getting-ready-for-http2/
AndreiYemelianov
01.03.2016 14:10+1Во-первых, это не совсем перевод. Во-вторых, мы и не скрываем, что использовали эту статью.
Pulse
01.03.2016 13:58+1Только вот пересобрать nginx из исходников c openssl 1.0.2f все-таки придется, по крайней мере, в Ubuntu 14.04LTS ;)
Pulse
01.03.2016 14:02+1Т.к в репе nginx собран с либой 1.0.1, а на 1.0.1 не будет работать ALPN, т.е запросы TLS 1.2 будут уходить на http/1.1, а не H2 (HTTP/2)
PS. Поправьте, если что не такanarx
01.03.2016 19:35Да-да, удивительно, что для своих репозиториев они собирают версии с 1.0.1. Проверил и на репозиториях для CentOS 6/7.
Появилась поддержка модульности, теперь уже можно использовать и сжатие brotli, не пересобирая nginx, (но нужно под каждую конкретную версию собрать плагин). А вот для работы такой классной возможности недостаточно даже обновления OpenSSL на сервере.
Проверил требования в rpm: openssl >= 1.0.1. Но после тестовой замены системного OpenSSL на 1.0.2 ALPN не появился.
stalkerg
02.03.2016 00:43Как это проверить?
Pulse
02.03.2016 02:12+2В инструментах разработчика браузера колонка Protocol во вкладке Network: если h2, то используется http/2
stalkerg
02.03.2016 10:34Ни в Chromium ни в Firefox такого не нашёл. Но в firefox нашёл версию: пишет 2.0 и в Chrome при помощи плагина отследил наличии http2 сессии и даже смог лог http2 коннекта глянуть.
Так что я думаю всё работает и это без каких либо телодвижений связанных с OpenSSL.Pulse
02.03.2016 11:50+1в Хроме добавить колонку Protocol по пкм, если ее нет.
в FF смотреть header X-Firefox-Spdy
ну, или плагины, да
Pulse
02.03.2016 11:56(echo | openssl s_client -alpn h2 -connect google.com:443) | grep ALPN
вместо google.com вставить свой хост.
ALPN protocol: h2 — все гуд.
No ALPN negotiated — не гуд.stalkerg
02.03.2016 12:03В Хроме и Firefox показывает что протокол h2 но вот openssl: No ALPN negotiated.
Может это только openssl проблема?
Pulse
02.03.2016 12:06тест на ssllabs.com уже тоже показывает наличие ALPN
stalkerg
02.03.2016 12:40Ну ALPN нету при этом:
Application-Layer Protocol Negotiation (ALPN) No
Next Protocol Negotiation (NPN) Yes h2 http/1.1
т.е. NPN достаточно кажется для браузеров.
Nickmob
04.03.2016 10:45До 15 мая да, но потом будет только ALPN (по крайней мере, в Chromium-подобных браузерах): http://blog.chromium.org/2016/02/transitioning-from-spdy-to-http2.html
VBart
03.03.2016 00:30ALPN не нужен для работы HTTP/2 с большинством популярных браузеров на данный момент, достаточно NPN, который есть и в OpenSSL 1.0.1.
Scf
01.03.2016 15:19Я пересобирал nginx с OpenSSL 1.0.2e, полет нормальный. Пришлось написать длинный-длинный Dockerfile.
Revertis
01.03.2016 15:30> В современных браузерах количество одновременных TCP-соединений ограничено. Поэтому страницы с большим количеством статического контента загружаются не так быстро, как хотелось бы.
А в чем проблема поднять количество соединений? Если интернет плохой, то не важно сколько соединений будет, всё равно будет медленно. Если интернет хороший, то количество соединений решит проблему. Об этом в гугле не подумали?
> Многие браузеры уже помечают сайты, не поддерживающие https, как «небезопасные».
Это какие браузеры? Я просто давно мечтаю о таком, но не видел нигде еще.
Кроме того, передача одного и того же объема данных через 2-3 соединения почти всегда быстрее, чем передача через одно соединение. До сих пор не вижу нигде ничего убедительного в пользу перехода на HTTP/2.gwer
01.03.2016 15:45Количество соединений ограничено первой версией стандарта HTTP, ибо на момент его проектирования интернеты были медленные. Рост количества соединений возможен через доменный шардинг. Но он решает проблему менее эффективно, чем работа через одно соединение: затраты на создание множества соединения достаточно высоки, чтобы оно негативно влияло на производительность. Профита от отказа от мультиплексирования запросов в одно соединение не будет.
Revertis
01.03.2016 16:02+1Количество соединений ограничено скрытыми настройками в самих браузерах. И вместо шести, можно сейчас поставить и 12, если подключение хорошее, то будет нормально.
gwer
01.03.2016 16:08Это вам нормально, а пользователи вашего сайта вообще ничего о соединениях могут не знать.
Revertis
01.03.2016 16:09-1Я намекаю на то, что сейчас производителям браузеров проще поднять количество одновременных соединений, чем внедрять новые сомнительные протоколы.
gwer
01.03.2016 16:16«Сомнительные» протоколы — инструмент борьбы с действительно сомнительными хаками, к которым всё равно придётся прибегать если не с целью победить количество одновременных соединений, то с целью уменьшить количество трафика и избавиться от задержек на создание новых соединений.
AndreiYemelianov
01.03.2016 15:51Это какие браузеры? Я просто давно мечтаю о таком, но не видел нигде еще.
Поправил: это ещё не реализовано. Но скоро будет внедрено и в 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/Revertis
01.03.2016 15:56Насколько я вижу, они еще в режиме Proposal, так что не надо писать «МНОГИЕ браузеры УЖЕ помечают».
Nickmob
04.03.2016 10:48Обратите внимание, что это TCP-соединения. А значит, для получения данных на полной скорости каждому соединению нужно пройти процесс TCP Slow Start, время которого зависит от величины RTT. Поэтому использование одного соединения в HTTP/2 и даёт прирост скорости, особенно на каналах с большим RTT.
VBart
04.03.2016 12:35+1Только ситуация как раз обратная, 6 TCP соединений имеют большее суммарное окно, как в начале, сразу после открытия, так и в конце, после передачи данных.
Nickmob
04.03.2016 12:58Спасибо за уточнение, с этой стороны я не смотрел на проблему. Получается выбор между TCP handshake (HTTP/1.1) и TCP slow start (HTTP/2)?
VBart
05.03.2016 13:35TCP-хэндшейк достаточно дешевый чтобы в большинстве случаев на типичных задержках его не замечать. Основная экономия там достигается на TCP+TLS хэндшейках вместе взятых. HTTP/2 в браузерах работает только поверх TLS.
VBart
05.03.2016 13:42Плюс из-за того, что можно отправить запросы сразу ко всем ресурсам и нет такого жесткого ограничения на кол-во параллельных потоков, устраняется проблема HOL-блокировки. Это не влияет на общее время загрузки, но в некоторых случаях позволяет браузерам получать минимально необходимые ресурсы для отрисовки страницы в первую очередь и страница отображается быстрее. Загружаться она может при этом дольше, но визуально пользователю кажется, что сайт работает шустрее.
Aingis
07.03.2016 12:47+1Плюс из-за того, что можно отправить запросы сразу ко всем ресурсам и нет такого жесткого ограничения на кол-во параллельных потоков, устраняется проблема HOL-блокировки.
Ну, так поэтому и придумали QUIC. Насколько я знаю, руководство в Гугле сильно настаивает на его повсеместном включении (наряду с HTTP/2).
EvilFox
01.03.2016 17:50+1Недавно натыкался на упоминания что HTTP2 вовсе не всегда даёт прирост производительности, а даже замедляет её. Где-то даже в рассылке было обсуждение. Насколько помню если файлов мало грузится то выигрыша не будет.
el777
01.03.2016 19:42Более того, в случае с HTTP/2 шардирование не улучшит производительность, а приведёт скорее к противоположному эффекту, так как создаст дополнительные TCP-соединения и будет мешать приоритизации.
Вот как раз по этому поводу вопрос: если шардируются 3 домена на одном и том же IP — будет ли браузер открывать к каждому отдельное tcp-соединение, или он переиспользует одно и тоже?VBart
03.03.2016 00:28Зависит от сертификата. Если сертификат валиден для всех трех доменов, то будет одно соединение. Если валиден для двух из трех, скажем, то к этим двум будет одно соединение и еще одно к третьему.
el777
03.03.2016 11:10Если я верно понимаю, с невалидным сертификатом он подключаться вообще не станет?
Интересно, а как-то в стандарте такое поведение описано? По идее в нем немало уделено вниманию совместимости со старыми решениями и прочим, и как сделать так, чтобы не сломать все наследие.VBart
03.03.2016 13:35+1С невалидным поведение такое же как и раньше: браузер предупредит пользователя и тому нужно будет нажать кнопку. И скорее всего такое соединение не будет использоваться для запросов к другим хостам, даже если принятый таким способом самоподписной сертификат валиден и для них.
Вот чего-чего, а совместимости и разным деталям в стандарте уделено внимания не очень много, он вообще создает впечатление довольно сырого и написанного на скорую руку. Т.н. connection reuse, о котором я рассказал, описан в этой части: https://tools.ietf.org/html/rfc7540#section-9.1.1
resurection
08.03.2016 13:55+1Не могу понять в чём основное приемущество http/2?
Мультиплексирование же позволяет браузеру выполнять множество запросов в рамках одного TCP-соединения
Чем это отличается от keep-alive? У меня дежавю или в 1999 нам уже это обещали?selenite
08.03.2016 19:43+1тем, что ответы могут начать приходить по частям и одновременно.
P.S. а QUIC уже дозрел до продакшна, хотя и с использованием реверс-прокси… хромоклиенты радуются увеличению скорости, все довольны.resurection
08.03.2016 19:50+1В любом TCP-соединении ответ может приходить по частям, пакетами. Даже в http/1.0.
Я вместо автора статьи слазил в интернет и узнал, что в http/2 мультиплексирование позволяет посылать http-запросы ОДНОВРЕМЕННО. Keep-alive не позволял этого делать.
vladimirkolyada
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% сам контент медленно отдается, с базы, с файловой системы и так далее.
kolu4iy
Я так понимаю, IIS — не самый распространённый веб-сервер в интернете. В современном nginx HTTP/2 работает «из коробки», и, как ни странно, действительно делает именно то, что обещали разработчики — ускоряет загрузку, отдавая контент в те самые много потоков. Например статика: картинки, js и css теперь грузятся одновременно, а gzip уже много лет как нагрузку (и время) на свою работу даёт совершенно неощутимые. А если учесть, как nginx всё это кеширует, то количество соединений действительно является решающим фактором.
vladimirkolyada
В IIS как раз включено по умолчанию это будет, насколько я понял. Тут же нужно конфигурировать, исходя из статьи (я не специалист в NIX стеке). Никто не говорил о нагрузке, пункт 6 говорит о том, что скорость передачи заголовка быстрее чем его сжатие, это лишь предположение. Уменьшение тут за счет количества заголовков, а не за счет сжатия.
vladimirkolyada
Кстати, из статистики, быстро нашел (2013 год): Наибольший прирост клиентской базы продемонстрировал IIS от Microsoft (23.10% рынка), у которого за отчетный период появилось 16,5 млн новых хостов. За ним с отрывом в 7% следует nginx, чей месячный прирост составил 11,4 млн хостов, в том числе 1,5 млн хостов, решивших отказаться от Apache.
Само собой первый апач, хотя сранивать IIS или Apache и nginx, насколько я понимаю, не корректно.
kolu4iy
Любой NIX-сервер надо конфигурировать. И в случае с nginx достаточно указать в директиве listen не ssl, а http2. Более того, есть глубокий смысл внимательно отнестись к настройкам ciphers, ssl_stapling и ssl_dhparam. Но это относится и к обычному https. От apache, как правило, не отказываются, но перестают его выставлять «голым задом» в интернет, и в качестве реверс-прокси применяют как раз nginx. Это помогает буферизовать всё общение апача с внешним миром, не заставляя его тратить мегабайты памяти на поддержку, например, медленных соединений. А IIS… Основная его прелесть на сегодняшний день это глубокая интеграция с .Net, на котором действительно просто решать сложные и интересные задачи. Кстати, есть еще одна не решенная задача с nginx: сквозная авторизация ntlm. Хотя-бы потому, что он не умеет сопоставлять соединения входящие и к backend один-к-одному. С другой стороны, если бы он умел, то были бы проблемы с буферизацией, ради чего его и используют.
Зачем еще растить IIS в интернете — честно говоря, я ума не приложу.
VBart
VBart
Можно было и за какой-нибудь 2000-ый поискать, когда nginx не существовало.
http://w3techs.com/technologies/cross/web_server/ranking
vladimirkolyada
Для тех, кто в танке и не умеет пользоваться поиском: http://w3techs.com/technologies/overview/web_server/all тут больше 10 процентов. Это все равно значительная часть. Я уже не говорю, что статья вообще не об этом, но надо же потешить свое самолюбие Developer @ NGINX, Inc.
VBart
Для справки, сайт w3techs.com специализируется на статистике интернет-ресурсов и обновляет данные раз в сутки. Разница между вашей и моей ссылкой лишь в разбивке данных. По моей ссылке она чуть более подробная и содержит выборку для топ 1000, 10 000, 100 000 и 1 млн. самых посещаемых сайтов, а также процент "Overall" (т.е. в целом по всем отслеживаемым хостам). По вашей ссылке точь в точь та же самая статистика по "Overall", но для чуть более расширенного списка серверов.
;-)Я нигде не отрицал, что в целом по интернету IIS вероятно имеет свои "чуть больше 10 процентов" и продолжает их стремительно терять. Но все верно, статья не об IIS, так что непонятно, зачем его было приплетать, а уж переходить на личности точно не стоило.
VBart
И если уж вы решили цитировать статистику и что-то этим пытаетесь доказать или утверждать на тему, то замечу, раз статья на русском, то наверное статистика по русскоязычным сайтам более актуальна для целевой аудитории: http://w3techs.com/technologies/segmentation/cl-ru-/web_server
Ernado
Согласно статистике доля IIS составляет не менее 25%
И это не учитывая того, что часто IIS находится за тем же nginx, который используется в качестве кэширующего прокси.
Так что это как раз один из популярных веб-серверов.
kolu4iy
Тут вопрос в том, что именно считать.
Я нашел вот такой подсчет:
http://news.netcraft.com/archives/2015/06/25/june-2015-web-server-survey.html
И в нём я вижу некоторое отличие веб-серверов «All sites» и «Active sites», не говоря про «top million busiest sites». Исходя из этого, я предлагаю прекратить бесполезный спор о распространённости серверов. Всё равно каждый увидит именно то, что хочет увидеть.
ArjLover
Это они удачно подкупили godaddy, который повесил на один IIS миллионы припаркованных доменов.
GamePad64
HTTP/2 почти везде поддерживается только через TLS, а через него передавать HTTP-сжатые данные небезопасно.
k12th
Надо быть странным человеком, чтобы галереи фотографий перегонять в DataURI. А вот мелкие интерфейсные элементы (в основном иконки) в CSS загоняют частенько.
ValdikSS
Внезапно, Гугл Картинки так делают для первых результатов.
k12th
Хорошее замечание. Но все-таки это исключение.
Igogo2012
IIS это же продукт microsoft, а microsoft как всем давно известно — *овно...
gwer
В целом HTTP2 — это лишь инструмент для избавления от хаков, которых требовал устаревший протокол.
vladimirkolyada
Страшно стало на хабр писать.
1. Не знаю, где вы прочитали, что он не умеет или умеет хуже, чем NIX стек
3. Я привел пример с точки зрения того, что никто галереи так не строит. Т.е. нет тут большого количества информации, размер маленький. Вы уже второй, кто понимает это как: надо делать галереи в датаюрл. Почему вы считаете себя умнее других, ведь вам в голову это не пришло, другие первоклассники?
4. Каким образом CDN является следствием шардинга? Или API? Никак уж не появился сначала шардинг из-за проблем с количеством запросов, а потом такие подхватили CDN-щики и т.д. Это все параллельные ветви.
6. От куда возьмутся кукисы, если вы их не вешаете? Тем более с каким-то размером адским?
gwer
Боюсь, вам стоит перечитать сначала свой комментарий, потом мой. Потому что сейчас вы в половине случаев противоречите своим словам, а во второй — выставляете утверждения, обратные моим, за слова, мною сказанные. Естественно, звучат они нелепо.
Пока перечитывание и осознание происходящего не осилите, дальнейший диалог смысла иметь не будет.
vladimirkolyada
Видимо я все-таки не доходчиво написал.
3. Любой нормальный человек понимает, что галереи не надо делать в датаюрл. Это понятно всем. Зачем задавать вопрос, на который вы заранее знаете ответ? Я не кому не говорил что я делаю так или знаю того, кто делает так. Я утверждал, что наоборот, если это и встречается, то крайне редко и в виде просто мизерных масштабов информации, по отношению к размеру хотя бы одной галереи на сайте. Вот что я имел ввиду. Так понятнее?:)
Не жду ответа уже ни на 4 ни на 6 вопросы. Происходящее в том, что вы кинулись искать бревно в глазу соседа, свое не заметив. Это свойственно всему хабру уже года 3 как. Даже банальные вещи типа своего 1 пункта вы все равно не признаете. У меня четко написано, что IIS умеет, у вас же, сразу: IIS ничего не умеет, инструмент не правильный, какие-то предположения.
GamePad64
В таких случаях рекомендуется терминировать HTTP/2 и TLS на reverse-proxy, а IIS запускать за ним по нешифрованному HTTP/1.1. Это классическая схема.