Комментарии 92
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% сам контент медленно отдается, с базы, с файловой системы и так далее.
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% сам контент медленно отдается, с базы, с файловой системы и так далее.
Я так понимаю, IIS — не самый распространённый веб-сервер в интернете. В современном nginx HTTP/2 работает «из коробки», и, как ни странно, действительно делает именно то, что обещали разработчики — ускоряет загрузку, отдавая контент в те самые много потоков. Например статика: картинки, js и css теперь грузятся одновременно, а gzip уже много лет как нагрузку (и время) на свою работу даёт совершенно неощутимые. А если учесть, как nginx всё это кеширует, то количество соединений действительно является решающим фактором.
В IIS как раз включено по умолчанию это будет, насколько я понял. Тут же нужно конфигурировать, исходя из статьи (я не специалист в NIX стеке). Никто не говорил о нагрузке, пункт 6 говорит о том, что скорость передачи заголовка быстрее чем его сжатие, это лишь предположение. Уменьшение тут за счет количества заголовков, а не за счет сжатия.
Кстати, из статистики, быстро нашел (2013 год): Наибольший прирост клиентской базы продемонстрировал IIS от Microsoft (23.10% рынка), у которого за отчетный период появилось 16,5 млн новых хостов. За ним с отрывом в 7% следует nginx, чей месячный прирост составил 11,4 млн хостов, в том числе 1,5 млн хостов, решивших отказаться от Apache.
Само собой первый апач, хотя сранивать IIS или Apache и nginx, насколько я понимаю, не корректно.
Само собой первый апач, хотя сранивать IIS или Apache и nginx, насколько я понимаю, не корректно.
Любой NIX-сервер надо конфигурировать. И в случае с nginx достаточно указать в директиве listen не ssl, а http2. Более того, есть глубокий смысл внимательно отнестись к настройкам ciphers, ssl_stapling и ssl_dhparam. Но это относится и к обычному https. От apache, как правило, не отказываются, но перестают его выставлять «голым задом» в интернет, и в качестве реверс-прокси применяют как раз nginx. Это помогает буферизовать всё общение апача с внешним миром, не заставляя его тратить мегабайты памяти на поддержку, например, медленных соединений. А IIS… Основная его прелесть на сегодняшний день это глубокая интеграция с .Net, на котором действительно просто решать сложные и интересные задачи. Кстати, есть еще одна не решенная задача с nginx: сквозная авторизация ntlm. Хотя-бы потому, что он не умеет сопоставлять соединения входящие и к backend один-к-одному. С другой стороны, если бы он умел, то были бы проблемы с буферизацией, ради чего его и используют.
Зачем еще растить IIS в интернете — честно говоря, я ума не приложу.
Зачем еще растить IIS в интернете — честно говоря, я ума не приложу.
Кстати, есть еще одна не решенная задача с nginx: сквозная авторизация ntlm. Хотя-бы потому, что он не умеет сопоставлять соединения входящие и к backend один-к-одному.Умеет: nginx.org/r/ntlm/ru, но за деньги.
Можно было и за какой-нибудь 2000-ый поискать, когда nginx не существовало.
http://w3techs.com/technologies/cross/web_server/ranking
http://w3techs.com/technologies/cross/web_server/ranking
Для тех, кто в танке и не умеет пользоваться поиском: http://w3techs.com/technologies/overview/web_server/all тут больше 10 процентов. Это все равно значительная часть. Я уже не говорю, что статья вообще не об этом, но надо же потешить свое самолюбие Developer @ NGINX, Inc.
Для справки, сайт w3techs.com специализируется на статистике интернет-ресурсов и обновляет данные раз в сутки. Разница между вашей и моей ссылкой лишь в разбивке данных. По моей ссылке она чуть более подробная и содержит выборку для топ 1000, 10 000, 100 000 и 1 млн. самых посещаемых сайтов, а также процент "Overall" (т.е. в целом по всем отслеживаемым хостам). По вашей ссылке точь в точь та же самая статистика по "Overall", но для чуть более расширенного списка серверов.
Я нигде не отрицал, что в целом по интернету IIS вероятно имеет свои "чуть больше 10 процентов" и продолжает их стремительно терять. Но все верно, статья не об IIS, так что непонятно, зачем его было приплетать, а уж переходить на личности точно не стоило.
Я нигде не отрицал, что в целом по интернету IIS вероятно имеет свои "чуть больше 10 процентов" и продолжает их стремительно терять. Но все верно, статья не об IIS, так что непонятно, зачем его было приплетать, а уж переходить на личности точно не стоило.
Для тех, кто в танке и не умеет пользоваться поиском;-)
И если уж вы решили цитировать статистику и что-то этим пытаетесь доказать или утверждать на тему, то замечу, раз статья на русском, то наверное статистика по русскоязычным сайтам более актуальна для целевой аудитории: http://w3techs.com/technologies/segmentation/cl-ru-/web_server
Я так понимаю, IIS — не самый распространённый веб-сервер в интернете
Согласно статистике доля IIS составляет не менее 25%
И это не учитывая того, что часто IIS находится за тем же nginx, который используется в качестве кэширующего прокси.
Так что это как раз один из популярных веб-серверов.
Тут вопрос в том, что именно считать.
Я нашел вот такой подсчет:
http://news.netcraft.com/archives/2015/06/25/june-2015-web-server-survey.html
И в нём я вижу некоторое отличие веб-серверов «All sites» и «Active sites», не говоря про «top million busiest sites». Исходя из этого, я предлагаю прекратить бесполезный спор о распространённости серверов. Всё равно каждый увидит именно то, что хочет увидеть.
Я нашел вот такой подсчет:
http://news.netcraft.com/archives/2015/06/25/june-2015-web-server-survey.html
И в нём я вижу некоторое отличие веб-серверов «All sites» и «Active sites», не говоря про «top million busiest sites». Исходя из этого, я предлагаю прекратить бесполезный спор о распространённости серверов. Всё равно каждый увидит именно то, что хочет увидеть.
Это они удачно подкупили godaddy, который повесил на один IIS миллионы припаркованных доменов.
HTTP/2 почти везде поддерживается только через TLS, а через него передавать HTTP-сжатые данные небезопасно.
Надо быть странным человеком, чтобы галереи фотографий перегонять в DataURI. А вот мелкие интерфейсные элементы (в основном иконки) в CSS загоняют частенько.
IIS это же продукт microsoft, а microsoft как всем давно известно — *овно...
- Проблема выбора инструмента. Если ваш IIS не умеет в HTTP2, это не значит, что HTTP2 не нужен.
- Туда же.
- Галереи фотографий в HTML встраивать? Для этого тоже надо быть странным человеком.
- Доменный шардинг используется для обхода ограничения на число соединений и для сокращения заголовков (чтобы избавиться от тех же лишних Cookie). Что касается CDN и API — вы путаете причину и следствие. В этом случае доменный шардинг не умышленный, это просто побочный эффект (который может приводить к некоторой деоптимизации даже).
- Вообще, количество соединений — одна из больных тем производительности в вебе, не даром столько времени уделяется сейчас склеиванию, инлайнингу, шардингу.
- В HTTP2 сжатие заголовков помимо кодирования Хаффмана и статических таблиц также использует динамические таблицы, что позволяет не передавать для каждого запроса заголовок, а, грубо говоря, ссылаться на ранее переданный. Одни только куки могут занимать кучу места, и с каждым запросом при этом они дублируются. Да и большая часть заголовков также постоянно повторяется. Это ещё одна проблема, которая обходилась ранее сочетанием склеивания-инлайнинга файлов с шардингом по cookie-free доменам.
В целом HTTP2 — это лишь инструмент для избавления от хаков, которых требовал устаревший протокол.
Страшно стало на хабр писать.
1. Не знаю, где вы прочитали, что он не умеет или умеет хуже, чем NIX стек
3. Я привел пример с точки зрения того, что никто галереи так не строит. Т.е. нет тут большого количества информации, размер маленький. Вы уже второй, кто понимает это как: надо делать галереи в датаюрл. Почему вы считаете себя умнее других, ведь вам в голову это не пришло, другие первоклассники?
4. Каким образом CDN является следствием шардинга? Или API? Никак уж не появился сначала шардинг из-за проблем с количеством запросов, а потом такие подхватили CDN-щики и т.д. Это все параллельные ветви.
6. От куда возьмутся кукисы, если вы их не вешаете? Тем более с каким-то размером адским?
1. Не знаю, где вы прочитали, что он не умеет или умеет хуже, чем NIX стек
3. Я привел пример с точки зрения того, что никто галереи так не строит. Т.е. нет тут большого количества информации, размер маленький. Вы уже второй, кто понимает это как: надо делать галереи в датаюрл. Почему вы считаете себя умнее других, ведь вам в голову это не пришло, другие первоклассники?
4. Каким образом CDN является следствием шардинга? Или API? Никак уж не появился сначала шардинг из-за проблем с количеством запросов, а потом такие подхватили CDN-щики и т.д. Это все параллельные ветви.
6. От куда возьмутся кукисы, если вы их не вешаете? Тем более с каким-то размером адским?
Боюсь, вам стоит перечитать сначала свой комментарий, потом мой. Потому что сейчас вы в половине случаев противоречите своим словам, а во второй — выставляете утверждения, обратные моим, за слова, мною сказанные. Естественно, звучат они нелепо.
Пока перечитывание и осознание происходящего не осилите, дальнейший диалог смысла иметь не будет.
Пока перечитывание и осознание происходящего не осилите, дальнейший диалог смысла иметь не будет.
Видимо я все-таки не доходчиво написал.
3. Любой нормальный человек понимает, что галереи не надо делать в датаюрл. Это понятно всем. Зачем задавать вопрос, на который вы заранее знаете ответ? Я не кому не говорил что я делаю так или знаю того, кто делает так. Я утверждал, что наоборот, если это и встречается, то крайне редко и в виде просто мизерных масштабов информации, по отношению к размеру хотя бы одной галереи на сайте. Вот что я имел ввиду. Так понятнее?:)
Не жду ответа уже ни на 4 ни на 6 вопросы. Происходящее в том, что вы кинулись искать бревно в глазу соседа, свое не заметив. Это свойственно всему хабру уже года 3 как. Даже банальные вещи типа своего 1 пункта вы все равно не признаете. У меня четко написано, что IIS умеет, у вас же, сразу: IIS ничего не умеет, инструмент не правильный, какие-то предположения.
3. Любой нормальный человек понимает, что галереи не надо делать в датаюрл. Это понятно всем. Зачем задавать вопрос, на который вы заранее знаете ответ? Я не кому не говорил что я делаю так или знаю того, кто делает так. Я утверждал, что наоборот, если это и встречается, то крайне редко и в виде просто мизерных масштабов информации, по отношению к размеру хотя бы одной галереи на сайте. Вот что я имел ввиду. Так понятнее?:)
Не жду ответа уже ни на 4 ни на 6 вопросы. Происходящее в том, что вы кинулись искать бревно в глазу соседа, свое не заметив. Это свойственно всему хабру уже года 3 как. Даже банальные вещи типа своего 1 пункта вы все равно не признаете. У меня четко написано, что IIS умеет, у вас же, сразу: IIS ничего не умеет, инструмент не правильный, какие-то предположения.
В таких случаях рекомендуется терминировать HTTP/2 и TLS на reverse-proxy, а IIS запускать за ним по нешифрованному HTTP/1.1. Это классическая схема.
Отличная статья, спасибо!
Правильно ли я понимаю, что HTTP/2 так же решает проблему размещения нескольких сайтов защищенных SSL-сертификатами на одном IP-адресе?
Правильно ли я понимаю, что HTTP/2 так же решает проблему размещения нескольких сайтов защищенных SSL-сертификатами на одном IP-адресе?
Уже перевел свой сервер на HTTP/2 на nginx. Если у вас на сайте есть TLS, то для новых браузеров этот протокол существенно уменьшает время загрузки страницы. С нетерпением жду, когда же разработчики nginx реализуют HTTP/2 prefetch/preload/server push — это ускорит загрузку еще на один roundtrip.
Ну это даже не «уже» :) Если, конечно, вы в значении «включил недавно».
HTTP/2 на nginx работает (и отлично!) более чем давно, и польза от него есть. Но, да, prefetch/preload/server push в нем все нет и нет. Правда, они и требуют уже не просто замены «ssl» на «http2» в конфиге, а именно указания, с чем и как делать те самые prefetch/preload/server push, так что «эту кошку надо уметь готовить» — но пока, да, не с чем готовить.
HTTP/2 на nginx работает (и отлично!) более чем давно, и польза от него есть. Но, да, prefetch/preload/server push в нем все нет и нет. Правда, они и требуют уже не просто замены «ssl» на «http2» в конфиге, а именно указания, с чем и как делать те самые prefetch/preload/server push, так что «эту кошку надо уметь готовить» — но пока, да, не с чем готовить.
Когда планировать переход на HTTP/2? Однозначного ответа на этот вопрос нет и быть не может. Дадим, однако, одну подсказку: регулярно просматривайте логи посещаемости вашего сервиса. Когда вы увидите, что большая часть посетителей используют поддерживающие HTTP/2 браузеры — можно переходить.
Но если HTTP/2 обратно совместим с 1.1, то, в целом, переходить можно уже сейчас, ничего не опасаясь?
Тут всё хорошо расписано: https://www.nginx.com/blog/7-tips-for-faster-http2-performance/
Работать всё будет. Можно переходить уже сейчас. Но переход на HTTP2 имеет смысл при избавлении от костылей, которые раньше обеспечивали рост производительности. То есть пользователи старых браузеров (~30%, в основном IE) получат некоторое падение скорости.
Спасибо! Уже как 3 месяца на HTTP/2 полёт отличный. Правда до этого где то полгода использовал SPDY.
НЛО прилетело и опубликовало эту надпись здесь
Только вот пересобрать nginx из исходников c openssl 1.0.2f все-таки придется, по крайней мере, в Ubuntu 14.04LTS ;)
Т.к в репе nginx собран с либой 1.0.1, а на 1.0.1 не будет работать ALPN, т.е запросы TLS 1.2 будут уходить на http/1.1, а не H2 (HTTP/2)
PS. Поправьте, если что не так
PS. Поправьте, если что не так
Да-да, удивительно, что для своих репозиториев они собирают версии с 1.0.1. Проверил и на репозиториях для CentOS 6/7.
Появилась поддержка модульности, теперь уже можно использовать и сжатие brotli, не пересобирая nginx, (но нужно под каждую конкретную версию собрать плагин). А вот для работы такой классной возможности недостаточно даже обновления OpenSSL на сервере.
Проверил требования в rpm: openssl >= 1.0.1. Но после тестовой замены системного OpenSSL на 1.0.2 ALPN не появился.
Появилась поддержка модульности, теперь уже можно использовать и сжатие brotli, не пересобирая nginx, (но нужно под каждую конкретную версию собрать плагин). А вот для работы такой классной возможности недостаточно даже обновления OpenSSL на сервере.
Проверил требования в rpm: openssl >= 1.0.1. Но после тестовой замены системного OpenSSL на 1.0.2 ALPN не появился.
Как это проверить?
В инструментах разработчика браузера колонка Protocol во вкладке Network: если h2, то используется http/2
Ни в Chromium ни в Firefox такого не нашёл. Но в firefox нашёл версию: пишет 2.0 и в Chrome при помощи плагина отследил наличии http2 сессии и даже смог лог http2 коннекта глянуть.
Так что я думаю всё работает и это без каких либо телодвижений связанных с OpenSSL.
Так что я думаю всё работает и это без каких либо телодвижений связанных с OpenSSL.
в Хроме добавить колонку Protocol по пкм, если ее нет.
в FF смотреть header X-Firefox-Spdy
ну, или плагины, да
в FF смотреть header X-Firefox-Spdy
ну, или плагины, да
(echo | openssl s_client -alpn h2 -connect google.com:443) | grep ALPNвместо google.com вставить свой хост.
ALPN protocol: h2 — все гуд.
No ALPN negotiated — не гуд.
В Хроме и Firefox показывает что протокол h2 но вот openssl: No ALPN negotiated.
Может это только openssl проблема?
Может это только openssl проблема?
тест на ssllabs.com уже тоже показывает наличие ALPN
Ну ALPN нету при этом:
Application-Layer Protocol Negotiation (ALPN) No
Next Protocol Negotiation (NPN) Yes h2 http/1.1
т.е. NPN достаточно кажется для браузеров.
Application-Layer Protocol Negotiation (ALPN) No
Next Protocol Negotiation (NPN) Yes h2 http/1.1
т.е. NPN достаточно кажется для браузеров.
До 15 мая да, но потом будет только ALPN (по крайней мере, в Chromium-подобных браузерах): http://blog.chromium.org/2016/02/transitioning-from-spdy-to-http2.html
ALPN не нужен для работы HTTP/2 с большинством популярных браузеров на данный момент, достаточно NPN, который есть и в OpenSSL 1.0.1.
Я пересобирал nginx с OpenSSL 1.0.2e, полет нормальный. Пришлось написать длинный-длинный Dockerfile.
> В современных браузерах количество одновременных TCP-соединений ограничено. Поэтому страницы с большим количеством статического контента загружаются не так быстро, как хотелось бы.
А в чем проблема поднять количество соединений? Если интернет плохой, то не важно сколько соединений будет, всё равно будет медленно. Если интернет хороший, то количество соединений решит проблему. Об этом в гугле не подумали?
> Многие браузеры уже помечают сайты, не поддерживающие https, как «небезопасные».
Это какие браузеры? Я просто давно мечтаю о таком, но не видел нигде еще.
Кроме того, передача одного и того же объема данных через 2-3 соединения почти всегда быстрее, чем передача через одно соединение. До сих пор не вижу нигде ничего убедительного в пользу перехода на HTTP/2.
А в чем проблема поднять количество соединений? Если интернет плохой, то не важно сколько соединений будет, всё равно будет медленно. Если интернет хороший, то количество соединений решит проблему. Об этом в гугле не подумали?
> Многие браузеры уже помечают сайты, не поддерживающие https, как «небезопасные».
Это какие браузеры? Я просто давно мечтаю о таком, но не видел нигде еще.
Кроме того, передача одного и того же объема данных через 2-3 соединения почти всегда быстрее, чем передача через одно соединение. До сих пор не вижу нигде ничего убедительного в пользу перехода на HTTP/2.
Количество соединений ограничено первой версией стандарта HTTP, ибо на момент его проектирования интернеты были медленные. Рост количества соединений возможен через доменный шардинг. Но он решает проблему менее эффективно, чем работа через одно соединение: затраты на создание множества соединения достаточно высоки, чтобы оно негативно влияло на производительность. Профита от отказа от мультиплексирования запросов в одно соединение не будет.
Количество соединений ограничено скрытыми настройками в самих браузерах. И вместо шести, можно сейчас поставить и 12, если подключение хорошее, то будет нормально.
Это вам нормально, а пользователи вашего сайта вообще ничего о соединениях могут не знать.
Я намекаю на то, что сейчас производителям браузеров проще поднять количество одновременных соединений, чем внедрять новые сомнительные протоколы.
Это какие браузеры? Я просто давно мечтаю о таком, но не видел нигде еще.
Поправил: это ещё не реализовано. Но скоро будет внедрено и в 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/
Обратите внимание, что это TCP-соединения. А значит, для получения данных на полной скорости каждому соединению нужно пройти процесс TCP Slow Start, время которого зависит от величины RTT. Поэтому использование одного соединения в HTTP/2 и даёт прирост скорости, особенно на каналах с большим RTT.
Только ситуация как раз обратная, 6 TCP соединений имеют большее суммарное окно, как в начале, сразу после открытия, так и в конце, после передачи данных.
Спасибо за уточнение, с этой стороны я не смотрел на проблему. Получается выбор между TCP handshake (HTTP/1.1) и TCP slow start (HTTP/2)?
TCP-хэндшейк достаточно дешевый чтобы в большинстве случаев на типичных задержках его не замечать. Основная экономия там достигается на TCP+TLS хэндшейках вместе взятых. HTTP/2 в браузерах работает только поверх TLS.
Плюс из-за того, что можно отправить запросы сразу ко всем ресурсам и нет такого жесткого ограничения на кол-во параллельных потоков, устраняется проблема HOL-блокировки. Это не влияет на общее время загрузки, но в некоторых случаях позволяет браузерам получать минимально необходимые ресурсы для отрисовки страницы в первую очередь и страница отображается быстрее. Загружаться она может при этом дольше, но визуально пользователю кажется, что сайт работает шустрее.
Стоило упомянуть о механизме Server Push в http/2, тоже интересная фича
Недавно натыкался на упоминания что HTTP2 вовсе не всегда даёт прирост производительности, а даже замедляет её. Где-то даже в рассылке было обсуждение. Насколько помню если файлов мало грузится то выигрыша не будет.
Более того, в случае с HTTP/2 шардирование не улучшит производительность, а приведёт скорее к противоположному эффекту, так как создаст дополнительные TCP-соединения и будет мешать приоритизации.
Вот как раз по этому поводу вопрос: если шардируются 3 домена на одном и том же IP — будет ли браузер открывать к каждому отдельное tcp-соединение, или он переиспользует одно и тоже?
если шардируются 3 домена на одном и том же IP — будет ли браузер открывать к каждому отдельное tcp-соединение, или он переиспользует одно и тоже?
Будет открывать три соединения, т.к. соединения учитываются по доменному имени, а не IP.
Зависит от сертификата. Если сертификат валиден для всех трех доменов, то будет одно соединение. Если валиден для двух из трех, скажем, то к этим двум будет одно соединение и еще одно к третьему.
Если я верно понимаю, с невалидным сертификатом он подключаться вообще не станет?
Интересно, а как-то в стандарте такое поведение описано? По идее в нем немало уделено вниманию совместимости со старыми решениями и прочим, и как сделать так, чтобы не сломать все наследие.
Интересно, а как-то в стандарте такое поведение описано? По идее в нем немало уделено вниманию совместимости со старыми решениями и прочим, и как сделать так, чтобы не сломать все наследие.
С невалидным поведение такое же как и раньше: браузер предупредит пользователя и тому нужно будет нажать кнопку. И скорее всего такое соединение не будет использоваться для запросов к другим хостам, даже если принятый таким способом самоподписной сертификат валиден и для них.
Вот чего-чего, а совместимости и разным деталям в стандарте уделено внимания не очень много, он вообще создает впечатление довольно сырого и написанного на скорую руку. Т.н. connection reuse, о котором я рассказал, описан в этой части: https://tools.ietf.org/html/rfc7540#section-9.1.1
Вот чего-чего, а совместимости и разным деталям в стандарте уделено внимания не очень много, он вообще создает впечатление довольно сырого и написанного на скорую руку. Т.н. connection reuse, о котором я рассказал, описан в этой части: https://tools.ietf.org/html/rfc7540#section-9.1.1
НЛО прилетело и опубликовало эту надпись здесь
Не могу понять в чём основное приемущество http/2?
Мультиплексирование же позволяет браузеру выполнять множество запросов в рамках одного TCP-соединенияЧем это отличается от keep-alive? У меня дежавю или в 1999 нам уже это обещали?
После перехода на HTTP/2 под Nginx Яндекс.Бот перестаёт индексировать сайт
Вот даже статья по этому поводу https://talk.pr-cy.ru/topic/21406-bot-yandeksa-i-podderzhka-protokola-http2/
Может кто знает как для NGINX исправить это?
Вот даже статья по этому поводу https://talk.pr-cy.ru/topic/21406-bot-yandeksa-i-podderzhka-protokola-http2/
Может кто знает как для NGINX исправить это?
У меня тоже не индексирует… Не ожидал такого от Яндекса. Исправляется скорее всего аналогично — нужно в
if вставить директиву, удаляющую заголовок Upgrade. Вечером займусь.Если получится, поделитесь пожалуйста правилом :)
Итак. голый http у меня возвращает 301 на https-версию. Как оказалось, https-версию сайта нужно добавлять руками в вебмастер, чтобы видеть статистику по HTTPS-версии сайта. Добавил, зашел на бета-версию вебмастера яндекса, страница "Проверка ответа сервера". Респонс есть, хтмл возвращается. Вот заголовки:
Да, HTTP/2 у меня включен, https://tools.keycdn.com/http2-test не станет врать. Или уже починили, или я чего-то не понимаю.
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 не станет врать. Или уже починили, или я чего-то не понимаю.
Перевели больше 10 сайтов на HTTP/2, никаких проблем с индексацией нет. На счет склейки зеркал (установки основного зеркала в Вебмастере) есть задержка. Оставьте 301 редирект с HTTP на HTTPS и подождите примерно месяц, основной адрес обновится. Также полезно добавить HTTPS версию как отдельный сайт (у Гугла то же самое). На время перехода может снизиться трафик, после переиндексации все восстановится.
НЛО прилетело и опубликовало эту надпись здесь
Использую CentOS 7 + EPEL, похоже простого способа заполучить HTTP/2, без ручной пересборки apache, у меня пока нет.
Я никак не могу понять одной вещи.
Есть у меня динамическая html страница и для нее статические css, картинки
Клиент первый раз заходит, сервер ему отдает html страницу и пушит в догонку статические css, картинки.
Если клиент заходит второй раз получается я тоже отдаю html страницу и сервер пушит в догонку статические css, картинки.
Хотелось бы как то кешировать статику.
Или CSS + картинки отдавать отдельным запросто что бы клиент мог закешировать.
Есть у меня динамическая html страница и для нее статические css, картинки
Клиент первый раз заходит, сервер ему отдает html страницу и пушит в догонку статические css, картинки.
Если клиент заходит второй раз получается я тоже отдаю html страницу и сервер пушит в догонку статические css, картинки.
Хотелось бы как то кешировать статику.
Или CSS + картинки отдавать отдельным запросто что бы клиент мог закешировать.
А как у него с сжатием контента (например json) и безопасностью TLS?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
HTTP/2: готовимся к переходу