В состав исходных текстов nginx принят (https://hg.nginx.org/nginx/rev/641306096f5b) код с реализацией механизма Server Push (https://www.w3.org/TR/preload/#server-push-http-2) для протокола HTTP/2. Server Push предоставляет возможность отправки push-запросов от сервера к клиенту, семантически эквивалентные ответам на обычные запросы к серверу при обработке ресурсов с меткой preload (link rel=preload), но инициируемые со стороны сервера.
Для управления отправкой push-запросов в nginx предложена директива "http2_push". При включении настройки "http2_push_preload" данные о ресурсах, которые можно передавать через Server Push, определяются на основе анализа содержимого отправляемых клиентом HTTP-заголовков Link. Для обеспечения должного уровня защиты обрабатываются только относительные URI с полным путём к ресурсу. Ограничение на число одновременных push-запросов определяется на стороне клиента, но не может превышать значения директивы nginx "http2_max_concurrent_pushes".
URL: https://www.reddit.com/r/linux/comments/7x5wok/nginx_http2_s.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=48064
Ждём пушей с паролями.
Ждём пушей с троянами.
Пользователи H2O смотрят на это снисходительно позёвывая... :-)
> Пользователи H2O смотрят на это снисходительно позёвывая... :-)Наслышан про H2O. Расскажите, пожалуйста, Вашу историю успешного внедрения H2O на production.
>> Пользователи H2O смотрят на это снисходительно позёвывая... :-)
> Наслышан про H2O. Расскажите, пожалуйста, Вашу историю успешного внедрения H2O на production.Продукшн он у всех разный, но их есть у меня.
Покажите же!
Ссылка на страницу, где работает Ваш позёвывающий пуш, вполне подойдёт.
Легко. Но не здесь, дабы не пиарить ничего не подозревающих людей.
> Легко. Но не здесь, дабы не пиарить ничего не подозревающих людей.Пруфов не будет. Расходимся
Ну, как вариант, мой блог вовсю на H2O фигачит. Но я там пуш не включал - не вижу смысла в данном случае.
Можете поставить, потренироваться. И на настройки CASPER внимание обратите.
> Ну, как вариант, мой блог вовсю на H2O фигачит.Другой разговор.
> http-server-header: h2o/2.2.4
Das is proof, das ist zer gut
Мой опыт говорит, что упереться в производительность асинхронного (вот на этом месте apache напару с IIS идут лесом) http-сервера -- это очень специфичный кейс. Обычно тормозит FastCGI-приложение (или не дай боже CGI. Впрочем, ещё не все динозавры вымерли)
Блог вы поднимали сразу на h2o или изначально был другой http-сервер? Если вы меняли сервер с $http_server на h2o, то что изменилось?
Ну вы ж push хотели, а там он вообще не принципиален. Хотя, может и стоит прикрутить чисто для лулзов.
Не буду опять же по этическим причинам показывать пальцем, но внедрение пуша на одном довольно тяжёлом сайте дало на ~25% быстрее отрисовку, и на ~15% общую загрузку (там внешнее дерьмо ещё тянет). Это в сравнении с просто HTTP/2 (не 1!). Переход с HTTP/1.1 на /2 даёт где-то до ~40% в скорости.
Тут же не только и не столько производительность теперь играет роль, но user experience. Быстрее рисуется - больше юзеров, говоря грубо.> Блог вы поднимали сразу на h2o или изначально был другой http-сервер?
Lighttpd был ещё с тех пор, когда nginx родители даже не планировали :-). Именно на блоге я не замерял, но по субъективным ощущениям прирост близок к озвученным выше процентам.
> Ну вы ж push хотели, а там он вообще не принципиален.
> Наслышан про H2O. Расскажите, пожалуйста, Вашу историю успешного внедрения H2O на production.Где(?!) push?
> внедрение пуша на одном довольно тяжёлом сайте дало на ~25% быстрее отрисовку, и на ~15% общую загрузку (там внешнее дерьмо ещё тянет). Это в сравнении с просто HTTP/2 (не 1!). Переход с HTTP/1.1 на /2 даёт где-то до ~40% в скорости прироста.
Пока что это можно провернуть на любом другом web-сервере.
> Именно на блоге я не замерял, но по субъективным ощущениям прирост близок к озвученным выше процентам.
Притом push не включали
Я подозреваю, что точными измерениями вы не заморачивались (это нормально. В повседневной работе на первом месте решение задач, а не холливары лучше/хуже/быстрее/выше/сильнее/длиннее). Измерения проводились на разных настройках для разных серверов: фактически мы сравниваем длинное и зелёное.
Короче, нужно тестировать. Пруф вы привели -- оно работает. Теперь открыта куча вопросов, что h2o вообще умеет, как он реально жуёт нагрузку (бенчмарки реально меряют только способность проходить этот бенчмарк. Есть корреляция с реальной производительностью, но это сырые данные), etc. И на них даст ответы только эксплуатация.
> Где(?!) push?Пардон, этот запрос был не ваш.
> Я подозреваю, что точными измерениями вы не заморачивались (это нормально. В повседневной
> работе на первом месте решение задач, а не холливары лучше/хуже/быстрее/выше/сильнее/длиннее)Мерили, но не проводили развернутое тестирование с разными нагрузками на статистически значимых интервалах, как это водится. Иначе была б статья :-)
> Короче, нужно тестировать. Пруф вы привели -- оно работает. Теперь открыта куча
> вопросов, что h2o вообще умеет, как он реально жуёт нагрузкуЯ бы тоже с удовольствием потестировал. Надо понять как, что и на чём именно тестировать.
Но, скажу объективно, H2O местами сыроват. Многое из этого решаемо на встроенном Ruby, но, тем не менее. Однако проект крайне любопытный. Тем более что там ещё и QUIC обещали подвезти в ближайшем обозе.
> Пользователи H2O смотрят на это снисходительно позёвывая... :-)Все три с половиной?
Я вместе с вами радуюсь вашим успехам, что, однако, не мешает отмечать и некоторое запаздывание во внедрении полезных технологий в nginx. Впрочем, это объяснимо тем, что автор H2O является активным разработчиком стандартов HTTP/2 и иже с ним, поэтому ему и флаг первопроходца в руки.
А что в ней полезного?
Если вы о push, то это ускорение отрисовки (функционирования). Иногда существенное. Надо смотреть на конкретную структуру сайта.
> Все три с половиной?Да там и побольше может быть. H2O вполне реально использовать в качестве встраиваемой либы в своем проекте. Нжинкс так в принципе не умеет. И писать модуль для него - затрахаешься. Так что если надо что-то сверх отгружалки статики... упсь.
> Пользователи H2O смотрят на это снисходительно позёвывая... :-)Чтобы не позёвывать, надо пользовать не в чистом виде H2O, а экстракт частей растений, обладающих тонизирующим эффектом.
>> Пользователи H2O смотрят на это снисходительно позёвывая... :-)
> Чтобы не позёвывать, надо пользовать не в чистом виде H2O, а экстракт
> частей растений, обладающих тонизирующим эффектом.Не волнуйтесь, он крепко настоен на Ruby, что не может не бодрить :-)
> Пользователи H2O смотрят на это снисходительно позёвывая... :-)Оба? А что не выспались, всю ночь реанимировали?
Срочно надо застолбить названия и логотипы уязвимостей pushup и pushthetempo
>Для управления отправкой push-запросов в nginx предложена директива "http2_push".Не понятно, какие возможности дает эта директива (каков синтаксис).
Ну она предложена же. Остальное будет позже.
> Ну она предложена же. Остальное будет позже.Предложено то сами не знаем что?
>>Для управления отправкой push-запросов в nginx предложена директива "http2_push".
> Не понятно, какие возможности дает эта директива (каков синтаксис).Про возможности читайте в RFC7540 and RFC7541, а про синтаксис (и пунктуацию) вам ответит Всеволод чуть выше ;-)
RFC - конечно, хорошее дело. Но вопрос о том как это прикручено к nginx. Управление на основе регулярных выражений, глобально на весь сайт. Сам по себе push без возможности толковой настройки правил где и как применять мало полезен.
> Сам по себе push без возможности толковой настройки правил где и как применять мало полезен.Совершенно согласен.
Данный функционал появится в очень ближайшем времени в версии 1.13.9. Ожидайте :)
> Данный функционал появится в очень ближайшем времени в версии 1.13.9. Ожидайте :)Nginx уже научился в приоритеты статику отдавать по протоколу http2?
H2O websrv уже это давно умеет.
>> Данный функционал появится в очень ближайшем времени в версии 1.13.9. Ожидайте :)
> Nginx уже научился в приоритеты статику отдавать по протоколу http2?
> H2O websrv уже это давно умеет.Кстати, спасибо что напомнили. Надо бы обкатать с оказией.
А вы пользуете?
> Данный функционал появится в очень ближайшем времени в версии 1.13.9. Ожидайте :)https://github.com/h2o/h2o/issues/421#issuecomment-130194520
Биткойны будут пушиться принудительно
Он пушить сможет только статику?
Пушить, например, новые сообщения пользователю от других пользователей он сможет пушить мгновенно, и без постоянного опроса, как это делается на AJAX?
Или это не то о чём я подумал и для этого всё равно использовать nodejs будет нужно?
Вы пробовали не флудить, а читать документацию? Или за вас это должны другие сделать?
prefetch readahead
Это технология, позволяющая серверу «протолкнуть» дополнительные данные клиенту, в момент запроса основного документа. То есть в обычной ситуации запрашивает браузер html-страничку, затем обрабатывает её и приходит к выводу, что ему для корректного отображения необходимо подгрузить дополнительные файлы: стили, скрипты, изображения. После чего скачивает их и отображает конечный результат. Server push позволяет отправить дополнительные файлы уже в момент получения основного документа, и они уже будут иметься в кэше, когда они потребуются браузеру. За счёт этого возрастает скорость загрузки сайта.
> Это технология, позволяющая серверу «протолкнуть» дополнительные данные клиенту,
> в момент запроса основного документа. То есть в обычной ситуации запрашивает
> браузер html-страничку, затем обрабатывает её и приходит к выводу, что ему
> для корректного отображения необходимо подгрузить дополнительные файлы: стили, скрипты,
> изображения. После чего скачивает их и отображает конечный результат. Server push
> позволяет отправить дополнительные файлы уже в момент получения основного документа, и
> они уже будут иметься в кэше, когда они потребуются браузеру. За
> счёт этого возрастает скорость загрузки сайта.А если я отключил в браузере чужие javascript, картинки, стили и шрифты, сервер всё равно мне их будет пушить в канал?
> А если я отключил в браузере чужие javascript, картинки, стили и шрифты, сервер всё равно мне их будет пушить в канал?Отличный вопрос, между прочим!
Если отключить push глобально, не будет. Иначе будет.
Всё-таки хайп задавил и реализовали этот функционал.Не советую http2 ставить и поддаваться хайпу, чуть пакетики потеряются (актуально при перебоях в ДЦ и/или мобильной инете) у вас он начнёт лагать, а в случае заливки каких-то данных вешать соединение на минуты! Причём при открытии новой вкладки новое соединение устанавливаться не будет. В то же время http1.1 будет вполне стабильно работать.
H2 может быть есть смысл повесить на второй айпи и пускать на него настольных клиентов когда с сетью всё хорошо.
а вы замеряли скорость? больше 2х лет на http2 сижу и пока нареканий не было, клиентов диназавров нет.
Скорость загрузки при сравнительно большом количестве контента на сайте немного больше, но в случае нестабильной связи всё это нивелируется. Если у вас много клиентов с мобильной связью (кстати говоря это не всегда смартфоны) http2 может создавать у них проблемы. Короче технология очень нежная, сымитируйте потерю пакетов и сами всё.
> и сами всё.увидите.
> увидите.хорошо, посмотрим
Вот интересная статья на эту тему: https://www.twilio.com/blog/2017/10/http2-issues.html
> Вот интересная статья на эту тему: https://www.twilio.com/blog/2017/10/http2-issues.htmlОчень интересно, спасибо.
Теперь понятна одна из причин появления QUIC.
Вопрос нафига жить в таком DC, с перебоями.
Клиент может отказать в пуше?
Т.е. серверх хочет пушить а ему - отказ.
nginx будет дудосить клиента до заполнения линка :D
> nginx будет дудосить клиента до заполнения линка :DЕсли клиент не дурак, отправит RST и на этом все закончится :)
Для пуша нужно подключить конкретный инфо-канал (или перечень). Например на бирже операции USD-RUB или USD-EUR, ленты новостей по темам, .. Это будут делать скрипты, которые вы скачаете в составе странички от сайта (или сами себе напишете).