Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
Илья Шипицин Wrote: --- > у вас же должны быть логи по html страницам и по css-файлам. > посмотрите на них. > если > > а) у вас хорошее кеширование (т.е. ноль 304-х) > б) количество ответов css соответствует количеству отданных html страниц > > то, вероятно, в вашем случае будет профит от того, что сделаете push на css > ну и наоборот, если css отдается меньше, или отдается столько же, но > много 304-х, то выигрыш будет отрицательный Доля ответов 304 среди 304 + 200 для CSS за месяц — 0,094%. Их практически нет. Отношение CSS / HTML — 0,164. На трафике порядка миллиона хитов к страницам в месяц. CSS отдаётся «навечно», инвалидируется версией в URL. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287846,288123#msg-288123 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
> насчет действительно связанных css и js - в принципе можно их > эмбедить > прямо в html разметку. и отдавать вместе с основной страницей. > тот же push. Только без потенциального выигрыша в попадании из push-кэша в основной с возможностью отказаться от получения ресурса в дальнейшем. А если клиент не умеет отказываться от ресурсов или не разделяет кэши — получаем полный аналог простого включения в HTML. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287846,288119#msg-288119 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
S.A.N Wrote: --- > > Решение о push'е принимается при генерации HTML-ответа за запрос к > > странице. > > В этот момент доступны If-None-Match и/или If-Modified-Since только > > самой страницы и странно ориентироваться на них, так как они ничего > > не говорят о наличии в кэше клиента тех ресурсов, которые мы планируем > > протолкнуть в ответе. > > Дело в том, что в этом ответе на запрос (у вас это НТМЛ страница), > формируется url к ресурсам для push, если в эти url вы добавляете > версии, вы можете включить хеш всех версий ресурсов для push, в ETag > заголовка ответа НТМЛ страницы, тогда вы сможете сопоставлять > клиенские заголовки If-None-Match и актуальные версии ресурсов, если > вы не можете детектить валидность клиенского кеша для этих ресурсов, > тогда лучше link без push. Ясно, версии pushed-ресурсов влияют на слепок ETag'а. Благодарю за информацию. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287846,288117#msg-288117 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
Hello! On Wed, Apr 29, 2020 at 01:26:27PM -0400, gz wrote: > > > Востребованные ресурсы из push-кэша переходят в основной и будут > > > использованы для следующих страниц. > > > Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся > > в > > > кэше. > > > В крайнем случае несложно пометить клиента стандартным способом > > через > > > cookie. > > > > Проблема в том, что даже отказ от push-ресурсов - это нагрузка как > > на сервер, так и на канал. И статистика как бы говорит нам, что в > > среднем эти накладные расходы - больше, чем польза. > > Я таковой статистикой не располагаю. Ссылку на статистику я привёл. Если вы не располагаете другой - вероятно, другой и нет. > Но предполагаю, что клиенту отказаться от push'а проще, чем сделать > дополнительный запрос к ресурсу. По ресурсам "получить push" и "сделать дополнительный запрос и получить на него ответ" - строго одно и то же. Разница - только во времени, полученный push будет доступен чуть раньше, что в хорошем случае немного сократит время до показа страницы. А в плохом - потребует передачи по сети дополнительных данных (начала push'а и его отмены) и приведёт к увеличению времени до показа страницы. Именно на баланс "хороших" и "плохих" случаев и стоит смотреть. > > Что будет конкретно в вашем случае - зависит, безусловно, от > > конкретной нагрузки и от того, насколько "в крайнем случае > > несложно" вам будет избежать лишних push'ей. Но, повторюсь, в > > среднем - будет хуже, потому что "в крайнем случае" никто не > > заморачивается. Именно поэтому я начал с вопроса пробовали ли вы > > тестировать, что получится. Подозреваю, что от банального > > перекладывания существующих в push'ы - > > станет только хуже. > > Да, я понял Вашу точку зрения. > Да, узкого эксперимента я не проводил. > > > > https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf > > > > > > Не совсем понимаю какие выводы делают авторы. > > > > > > Предлагают работать над приоритезацией (которая и так корректная, и > > > регулируется preload'ом), использовать экспериментальный QUIC, > > поддержики > > > которого толком нет. > > > > Авторы ясно и однозначно показывают, что server push - в среднем > > вредит, и в большинстве случаев лишь способ выстрелить себе в > > ногу. И предлагают работать над другими технологиями, > > потенциально более полезными. > > > > Тут важно понимать, что речь идёт про взгляд разработчиков > > браузера, и рассказывалось это всё на HTTP working group, то есть > > в рамках встречи людей, занимающихся разработкой протокола. > > Из Ваших соображений и трактовке вышеприведённого исследования складывается > впечатление, что даже разработчики протокола не донца понимают зачем push > нужен. > При том, что не только они описали его в протоколе, но и сторонние > разработчики реализовали поддержку push'а клиентах и нескольких серверах. Зачем нужен push - все понимают. Насколько он при этом полезен для интернета в среднем - можно выяснить только практически. Вот есть исследование от команды одного из браузеров, которое говорит, что в среднем - вреден. Что до "реализовали поддержку push'а", то вот мы - всегда считали, что полезность push'а, мягко говоря, преувеличена. Но, тем не менее, вынуждены были реализовать, просто мотому, что пользователи читают маркетинговые материалы, рассказывающие о новом красивом протоколе HTTP/2 и его замечательных возможностях. А понимать, какие недостатки есть у этих замечательных возможностей - не пытаются. > > (Ну и да, про приоритезацию - смешно. Нет, это не про preload, > > это, как я понимаю, про приоритеты в рамках HTTP/2. Там самолёт с > > бассейном и джакузи запроектирован в рамках стандарта, корректности > > ждать не приходится.) > > Я о текущей примитивной приоретизации. > Сомневаюсь, что когда-нибудь появятся инстументы точного управления ею, > браузеры всё равно будут вынуждены использовать указания как рекомендацию. Приоритизация в рамках стандарта HTTP/2 - это вполне конкретная вещь, и именно она и упоминается в соответствующем докладе. И с ней проблемы, именно потому она там и упоминается. > > > Я прекрасно понимаю, что push — не панацея, и хотел попробовать на > > практике > > > проталкивание критических ресурсов, которые в любом случае > > приоритетны и > > > будут загружены для отрисовки. > > > > Именно с этого я и начал: попробуйте на практике на отдельных > > страницах, без попыток вытаскивать версии ресурсов через SSI и вот > > этого всего. Получите статистику, сравните. > > > > Сейчас же вы пришли и убеждаете разработчиков, что вам надо, > > потому что оно точно будет лучше, но тестировать вы ничего не > > тестировали и не хотите. > > Где именно и кого я в чём-то убеждал и убеждал в том, что мне нужно? > Я задал вопрос о планах. И получили на него ответ. А равно рекоменацию о том, с чего начать, если вы вдруг считаете, что вам, тем не менее, надо. Но почему-то пытаетесь спорить, убеждая меня в том,
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
чт, 30 апр. 2020 г. в 01:59, Slawa Olhovchenkov : > On Thu, Apr 30, 2020 at 01:41:13AM +0500, Илья Шипицин wrote: > > > чт, 30 апр. 2020 г. в 00:00, Evgeniy Berdnikov : > > > > > On Wed, Apr 29, 2020 at 01:26:27PM -0400, gz wrote: > > > > Но предполагаю, что клиенту отказаться от push'а проще, чем сделать > > > > дополнительный запрос к ресурсу. > > > > > > Если клиент умеет cache digest, то да, может отказаться заранее. > > > А если нет, то к тому моменту, когда клиент сможет отклонить push, > > > данные уже летят по сети и отъедают пропускную способность канала, > > > это обстоятельство может навредить желанию загрузить все причандалы > > > к странице побыстрее. > > > > > > Вообще, почти про всё связанное с http2 можно сказать "близкий к нулю > > > профит от сложной и очень тяжёлой технологии". И push в том ряду. > > > > > > > > > http2 решает искуственную проблему - у браузера по каким-то странным > > причинам ограничего количество одновременных > > tcp сессий, обычно двумя сессиями. И, допустим, браузер параллельно тащит > > два оочень медленных ответа, все остальные > > элементы, как то css стили, которые нужны для того, чтобы отрендерить > > страницу, на паузе. > > > > т.е. браузер решил сам себе ограничить количество сессий - удачи ему. > > а потом пришли разработчики http2 и сказали "а давайте внутри одной tcp > > сессии будет типа еще один инкапсулированный tcp > > с мультиплексированием". ну то есть нам дорого открыть несколько честных > > tcp потоков, лучше мы заморочимся тем, что будем > > мультиплексировать tcp внутри tcp. > > нет-нет. > не так все было. > много соединений на сервер == много одновременных запросов == большая > нагрузка на сервер (особенно если там апач или томкат). > это же почти DDoS! > видимо, Слава забыл тег в приведенном (выдуманном) примере описано, что надо защищать сервер апач от ддоса, притом, что задача не позволить открыть больше конекшенов, чем сервер способен осилить, выглядит скорее, как задача самого сервера но да, какая-то подобная логика вполне могла быть в этой всей истории. > > разработчики браузеров сказали -- а мы за все хорошее и против всего > плохого! > ограничим число одновоременных запросов от каждого браузера двумя! > фиг вам зловереды а не DDoS! > > прошло некоторое время, все уже забыли почему так получилось и > разрабочки стандарта придумали э... монстра. > > ну надеюсь теперь все догадываются что будет дальше? > подсказываю: зловредные страницы котрые будут содержать миллионы > ссылок на http2 сайты которые будут по двум соединениям делать 100500 > одновременных запросов на разные ресурсы. после этого разработчки > браузеров разрешат по каждому http2 соединению делать не более 2 > запосов. > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
On Thu, Apr 30, 2020 at 01:41:13AM +0500, Илья Шипицин wrote: > чт, 30 апр. 2020 г. в 00:00, Evgeniy Berdnikov : > > > On Wed, Apr 29, 2020 at 01:26:27PM -0400, gz wrote: > > > Но предполагаю, что клиенту отказаться от push'а проще, чем сделать > > > дополнительный запрос к ресурсу. > > > > Если клиент умеет cache digest, то да, может отказаться заранее. > > А если нет, то к тому моменту, когда клиент сможет отклонить push, > > данные уже летят по сети и отъедают пропускную способность канала, > > это обстоятельство может навредить желанию загрузить все причандалы > > к странице побыстрее. > > > > Вообще, почти про всё связанное с http2 можно сказать "близкий к нулю > > профит от сложной и очень тяжёлой технологии". И push в том ряду. > > > > > http2 решает искуственную проблему - у браузера по каким-то странным > причинам ограничего количество одновременных > tcp сессий, обычно двумя сессиями. И, допустим, браузер параллельно тащит > два оочень медленных ответа, все остальные > элементы, как то css стили, которые нужны для того, чтобы отрендерить > страницу, на паузе. > > т.е. браузер решил сам себе ограничить количество сессий - удачи ему. > а потом пришли разработчики http2 и сказали "а давайте внутри одной tcp > сессии будет типа еще один инкапсулированный tcp > с мультиплексированием". ну то есть нам дорого открыть несколько честных > tcp потоков, лучше мы заморочимся тем, что будем > мультиплексировать tcp внутри tcp. нет-нет. не так все было. много соединений на сервер == много одновременных запросов == большая нагрузка на сервер (особенно если там апач или томкат). это же почти DDoS! разработчики браузеров сказали -- а мы за все хорошее и против всего плохого! ограничим число одновоременных запросов от каждого браузера двумя! фиг вам зловереды а не DDoS! прошло некоторое время, все уже забыли почему так получилось и разрабочки стандарта придумали э... монстра. ну надеюсь теперь все догадываются что будет дальше? подсказываю: зловредные страницы котрые будут содержать миллионы ссылок на http2 сайты которые будут по двум соединениям делать 100500 одновременных запросов на разные ресурсы. после этого разработчки браузеров разрешат по каждому http2 соединению делать не более 2 запосов. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
чт, 30 апр. 2020 г. в 00:00, Evgeniy Berdnikov : > On Wed, Apr 29, 2020 at 01:26:27PM -0400, gz wrote: > > Но предполагаю, что клиенту отказаться от push'а проще, чем сделать > > дополнительный запрос к ресурсу. > > Если клиент умеет cache digest, то да, может отказаться заранее. > А если нет, то к тому моменту, когда клиент сможет отклонить push, > данные уже летят по сети и отъедают пропускную способность канала, > это обстоятельство может навредить желанию загрузить все причандалы > к странице побыстрее. > > Вообще, почти про всё связанное с http2 можно сказать "близкий к нулю > профит от сложной и очень тяжёлой технологии". И push в том ряду. > http2 решает искуственную проблему - у браузера по каким-то странным причинам ограничего количество одновременных tcp сессий, обычно двумя сессиями. И, допустим, браузер параллельно тащит два оочень медленных ответа, все остальные элементы, как то css стили, которые нужны для того, чтобы отрендерить страницу, на паузе. т.е. браузер решил сам себе ограничить количество сессий - удачи ему. а потом пришли разработчики http2 и сказали "а давайте внутри одной tcp сессии будет типа еще один инкапсулированный tcp с мультиплексированием". ну то есть нам дорого открыть несколько честных tcp потоков, лучше мы заморочимся тем, что будем мультиплексировать tcp внутри tcp. насчет действительно связанных css и js - в принципе можно их эмбедить прямо в html разметку. и отдавать вместе с основной страницей. тот же push. > -- > Eugene Berdnikov > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
On Wed, Apr 29, 2020 at 01:26:27PM -0400, gz wrote: > Но предполагаю, что клиенту отказаться от push'а проще, чем сделать > дополнительный запрос к ресурсу. Если клиент умеет cache digest, то да, может отказаться заранее. А если нет, то к тому моменту, когда клиент сможет отклонить push, данные уже летят по сети и отъедают пропускную способность канала, это обстоятельство может навредить желанию загрузить все причандалы к странице побыстрее. Вообще, почти про всё связанное с http2 можно сказать "близкий к нулю профит от сложной и очень тяжёлой технологии". И push в том ряду. -- Eugene Berdnikov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
> то выигрыш будет отрицательный у меня эта фраза вызывает когнитивный диссонанс On Wed, Apr 29, 2020 at 8:41 PM Илья Шипицин wrote: > > > ср, 29 апр. 2020 г. в 22:26, gz : > >> > > Востребованные ресурсы из push-кэша переходят в основной и будут >> > > использованы для следующих страниц. >> > > Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся >> > в >> > > кэше. >> > > В крайнем случае несложно пометить клиента стандартным способом >> > через >> > > cookie. >> > >> > Проблема в том, что даже отказ от push-ресурсов - это нагрузка как >> > на сервер, так и на канал. И статистика как бы говорит нам, что в >> > среднем эти накладные расходы - больше, чем польза. >> >> Я таковой статистикой не располагаю. >> Но предполагаю, что клиенту отказаться от push'а проще, чем сделать >> дополнительный запрос к ресурсу. >> >> > Что будет конкретно в вашем случае - зависит, безусловно, от >> > конкретной нагрузки и от того, насколько "в крайнем случае >> > несложно" вам будет избежать лишних push'ей. Но, повторюсь, в >> > среднем - будет хуже, потому что "в крайнем случае" никто не >> > заморачивается. Именно поэтому я начал с вопроса пробовали ли вы >> > тестировать, что получится. Подозреваю, что от банального >> > перекладывания существующих в push'ы - >> > станет только хуже. >> >> Да, я понял Вашу точку зрения. >> Да, узкого эксперимента я не проводил. >> >> > >> >> https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf >> > > >> > > Не совсем понимаю какие выводы делают авторы. >> > > >> > > Предлагают работать над приоритезацией (которая и так корректная, и >> > > регулируется preload'ом), использовать экспериментальный QUIC, >> > поддержики >> > > которого толком нет. >> > >> > Авторы ясно и однозначно показывают, что server push - в среднем >> > вредит, и в большинстве случаев лишь способ выстрелить себе в >> > ногу. И предлагают работать над другими технологиями, >> > потенциально более полезными. >> > >> > Тут важно понимать, что речь идёт про взгляд разработчиков >> > браузера, и рассказывалось это всё на HTTP working group, то есть >> > в рамках встречи людей, занимающихся разработкой протокола. >> >> Из Ваших соображений и трактовке вышеприведённого исследования >> складывается >> впечатление, что даже разработчики протокола не донца понимают зачем push >> нужен. >> При том, что не только они описали его в протоколе, но и сторонние >> разработчики реализовали поддержку push'а клиентах и нескольких серверах. >> >> > (Ну и да, про приоритезацию - смешно. Нет, это не про preload, >> > это, как я понимаю, про приоритеты в рамках HTTP/2. Там самолёт с >> > бассейном и джакузи запроектирован в рамках стандарта, корректности >> > ждать не приходится.) >> >> Я о текущей примитивной приоретизации. >> Сомневаюсь, что когда-нибудь появятся инстументы точного управления ею, >> браузеры всё равно будут вынуждены использовать указания как рекомендацию. >> >> > > Я прекрасно понимаю, что push — не панацея, и хотел попробовать на >> > практике >> > > проталкивание критических ресурсов, которые в любом случае >> > приоритетны и >> > > будут загружены для отрисовки. >> > >> > Именно с этого я и начал: попробуйте на практике на отдельных >> > страницах, без попыток вытаскивать версии ресурсов через SSI и вот >> > этого всего. Получите статистику, сравните. >> > >> > Сейчас же вы пришли и убеждаете разработчиков, что вам надо, >> > потому что оно точно будет лучше, но тестировать вы ничего не >> > тестировали и не хотите. >> >> Где именно и кого я в чём-то убеждал и убеждал в том, что мне нужно? >> Я задал вопрос о планах. >> >> А учитывая, что использовать саму директиву http2_push затруднительно — >> один >> ресурс за раз, невозможность использования в if — и предвидя рекомендацию >> использовать http2_push_preload, я рассказал о том, в какую сторону пошёл >> и >> что уже попробовал сделать своими силами, и о том, какие возможности могли >> бы помочь в решении задачи. >> >> > Так это не работает. Придёте со >> > стастикой, явно показывающей плюсы - мы задумаемся над тем, как >> > облегчить вам жизнь в конфигурации с SSI. Пока же из статистике >> > есть вот только ссылка выше, из которой явно следует, что делать >> > что-либо для лучше поддержки HTTP/2 push - в среднем бессмысленно. >> >> То, о чём я рассказываю и есть эксперимент. >> Проще внедрить это на dev- или даже production-версии сайта, чем готовить >> узкие эксперименты из двух страниц. >> > > у вас же должны быть логи по html страницам и по css-файлам. посмотрите на > них. > если > > а) у вас хорошее кеширование (т.е. ноль 304-х) > б) количество ответов css соответствует количеству отданных html страниц > > то, вероятно, в вашем случае будет профит от того, что сделаете push на css > ну и наоборот, если css отдается меньше, или отдается столько же, но много > 304-х, > то выигрыш будет отрицательный > > > >> В случае pdocution'а можно прогнозировать значимое изменение в статистике >> загрузки страниц, в том
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
ср, 29 апр. 2020 г. в 22:26, gz : > > > Востребованные ресурсы из push-кэша переходят в основной и будут > > > использованы для следующих страниц. > > > Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся > > в > > > кэше. > > > В крайнем случае несложно пометить клиента стандартным способом > > через > > > cookie. > > > > Проблема в том, что даже отказ от push-ресурсов - это нагрузка как > > на сервер, так и на канал. И статистика как бы говорит нам, что в > > среднем эти накладные расходы - больше, чем польза. > > Я таковой статистикой не располагаю. > Но предполагаю, что клиенту отказаться от push'а проще, чем сделать > дополнительный запрос к ресурсу. > > > Что будет конкретно в вашем случае - зависит, безусловно, от > > конкретной нагрузки и от того, насколько "в крайнем случае > > несложно" вам будет избежать лишних push'ей. Но, повторюсь, в > > среднем - будет хуже, потому что "в крайнем случае" никто не > > заморачивается. Именно поэтому я начал с вопроса пробовали ли вы > > тестировать, что получится. Подозреваю, что от банального > > перекладывания существующих в push'ы - > > станет только хуже. > > Да, я понял Вашу точку зрения. > Да, узкого эксперимента я не проводил. > > > > > https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf > > > > > > Не совсем понимаю какие выводы делают авторы. > > > > > > Предлагают работать над приоритезацией (которая и так корректная, и > > > регулируется preload'ом), использовать экспериментальный QUIC, > > поддержики > > > которого толком нет. > > > > Авторы ясно и однозначно показывают, что server push - в среднем > > вредит, и в большинстве случаев лишь способ выстрелить себе в > > ногу. И предлагают работать над другими технологиями, > > потенциально более полезными. > > > > Тут важно понимать, что речь идёт про взгляд разработчиков > > браузера, и рассказывалось это всё на HTTP working group, то есть > > в рамках встречи людей, занимающихся разработкой протокола. > > Из Ваших соображений и трактовке вышеприведённого исследования складывается > впечатление, что даже разработчики протокола не донца понимают зачем push > нужен. > При том, что не только они описали его в протоколе, но и сторонние > разработчики реализовали поддержку push'а клиентах и нескольких серверах. > > > (Ну и да, про приоритезацию - смешно. Нет, это не про preload, > > это, как я понимаю, про приоритеты в рамках HTTP/2. Там самолёт с > > бассейном и джакузи запроектирован в рамках стандарта, корректности > > ждать не приходится.) > > Я о текущей примитивной приоретизации. > Сомневаюсь, что когда-нибудь появятся инстументы точного управления ею, > браузеры всё равно будут вынуждены использовать указания как рекомендацию. > > > > Я прекрасно понимаю, что push — не панацея, и хотел попробовать на > > практике > > > проталкивание критических ресурсов, которые в любом случае > > приоритетны и > > > будут загружены для отрисовки. > > > > Именно с этого я и начал: попробуйте на практике на отдельных > > страницах, без попыток вытаскивать версии ресурсов через SSI и вот > > этого всего. Получите статистику, сравните. > > > > Сейчас же вы пришли и убеждаете разработчиков, что вам надо, > > потому что оно точно будет лучше, но тестировать вы ничего не > > тестировали и не хотите. > > Где именно и кого я в чём-то убеждал и убеждал в том, что мне нужно? > Я задал вопрос о планах. > > А учитывая, что использовать саму директиву http2_push затруднительно — > один > ресурс за раз, невозможность использования в if — и предвидя рекомендацию > использовать http2_push_preload, я рассказал о том, в какую сторону пошёл и > что уже попробовал сделать своими силами, и о том, какие возможности могли > бы помочь в решении задачи. > > > Так это не работает. Придёте со > > стастикой, явно показывающей плюсы - мы задумаемся над тем, как > > облегчить вам жизнь в конфигурации с SSI. Пока же из статистике > > есть вот только ссылка выше, из которой явно следует, что делать > > что-либо для лучше поддержки HTTP/2 push - в среднем бессмысленно. > > То, о чём я рассказываю и есть эксперимент. > Проще внедрить это на dev- или даже production-версии сайта, чем готовить > узкие эксперименты из двух страниц. > у вас же должны быть логи по html страницам и по css-файлам. посмотрите на них. если а) у вас хорошее кеширование (т.е. ноль 304-х) б) количество ответов css соответствует количеству отданных html страниц то, вероятно, в вашем случае будет профит от того, что сделаете push на css ну и наоборот, если css отдается меньше, или отдается столько же, но много 304-х, то выигрыш будет отрицательный > В случае pdocution'а можно прогнозировать значимое изменение в статистике > загрузки страниц, в том числе по данным браузеров — в той же Метрике, > Google > Console или PageSpeed Insights. > > Простой эксперимент, конечно, имеет право на жизнь, но это пара страниц и > несколько доступных браузеров и инструментов. > > Posted at Nginx Forum: >
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
> > Востребованные ресурсы из push-кэша переходят в основной и будут > > использованы для следующих страниц. > > Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся > в > > кэше. > > В крайнем случае несложно пометить клиента стандартным способом > через > > cookie. > > Проблема в том, что даже отказ от push-ресурсов - это нагрузка как > на сервер, так и на канал. И статистика как бы говорит нам, что в > среднем эти накладные расходы - больше, чем польза. Я таковой статистикой не располагаю. Но предполагаю, что клиенту отказаться от push'а проще, чем сделать дополнительный запрос к ресурсу. > Что будет конкретно в вашем случае - зависит, безусловно, от > конкретной нагрузки и от того, насколько "в крайнем случае > несложно" вам будет избежать лишних push'ей. Но, повторюсь, в > среднем - будет хуже, потому что "в крайнем случае" никто не > заморачивается. Именно поэтому я начал с вопроса пробовали ли вы > тестировать, что получится. Подозреваю, что от банального > перекладывания существующих в push'ы - > станет только хуже. Да, я понял Вашу точку зрения. Да, узкого эксперимента я не проводил. > https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf > > > > Не совсем понимаю какие выводы делают авторы. > > > > Предлагают работать над приоритезацией (которая и так корректная, и > > регулируется preload'ом), использовать экспериментальный QUIC, > поддержики > > которого толком нет. > > Авторы ясно и однозначно показывают, что server push - в среднем > вредит, и в большинстве случаев лишь способ выстрелить себе в > ногу. И предлагают работать над другими технологиями, > потенциально более полезными. > > Тут важно понимать, что речь идёт про взгляд разработчиков > браузера, и рассказывалось это всё на HTTP working group, то есть > в рамках встречи людей, занимающихся разработкой протокола. Из Ваших соображений и трактовке вышеприведённого исследования складывается впечатление, что даже разработчики протокола не донца понимают зачем push нужен. При том, что не только они описали его в протоколе, но и сторонние разработчики реализовали поддержку push'а клиентах и нескольких серверах. > (Ну и да, про приоритезацию - смешно. Нет, это не про preload, > это, как я понимаю, про приоритеты в рамках HTTP/2. Там самолёт с > бассейном и джакузи запроектирован в рамках стандарта, корректности > ждать не приходится.) Я о текущей примитивной приоретизации. Сомневаюсь, что когда-нибудь появятся инстументы точного управления ею, браузеры всё равно будут вынуждены использовать указания как рекомендацию. > > Я прекрасно понимаю, что push — не панацея, и хотел попробовать на > практике > > проталкивание критических ресурсов, которые в любом случае > приоритетны и > > будут загружены для отрисовки. > > Именно с этого я и начал: попробуйте на практике на отдельных > страницах, без попыток вытаскивать версии ресурсов через SSI и вот > этого всего. Получите статистику, сравните. > > Сейчас же вы пришли и убеждаете разработчиков, что вам надо, > потому что оно точно будет лучше, но тестировать вы ничего не > тестировали и не хотите. Где именно и кого я в чём-то убеждал и убеждал в том, что мне нужно? Я задал вопрос о планах. А учитывая, что использовать саму директиву http2_push затруднительно — один ресурс за раз, невозможность использования в if — и предвидя рекомендацию использовать http2_push_preload, я рассказал о том, в какую сторону пошёл и что уже попробовал сделать своими силами, и о том, какие возможности могли бы помочь в решении задачи. > Так это не работает. Придёте со > стастикой, явно показывающей плюсы - мы задумаемся над тем, как > облегчить вам жизнь в конфигурации с SSI. Пока же из статистике > есть вот только ссылка выше, из которой явно следует, что делать > что-либо для лучше поддержки HTTP/2 push - в среднем бессмысленно. То, о чём я рассказываю и есть эксперимент. Проще внедрить это на dev- или даже production-версии сайта, чем готовить узкие эксперименты из двух страниц. В случае pdocution'а можно прогнозировать значимое изменение в статистике загрузки страниц, в том числе по данным браузеров — в той же Метрике, Google Console или PageSpeed Insights. Простой эксперимент, конечно, имеет право на жизнь, но это пара страниц и несколько доступных браузеров и инструментов. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287846,287886#msg-287886 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
> Советую смотреть не на куки, а на наличия клиенских заголовков - > If-None-Match и/или If-Modified-Since, только при отсутствии или не > валидности данных заголовков делать push. > Из нашего опыта - push полезен только для клиентов у которых нет > валидного кеша, в этом случаи вы получите не большой прирост в > скорости около 5-10%. Не совсем понимаю Ваш совет. Решение о push'е принимается при генерации HTML-ответа за запрос к странице. В этот момент доступны If-None-Match и/или If-Modified-Since только самой страницы и странно ориентироваться на них, так как они ничего не говорят о наличии в кэше клиента тех ресурсов, которые мы планируем протолкнуть в ответе. А если поступит conditional-get-запрос к самому ресурсу, то что-либо делать с push'ем уже поздно. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287846,287887#msg-287887 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
Hello! On Tue, Apr 28, 2020 at 02:19:48PM +0200, Valery Kholodkov wrote: > On 27-04-2020 22:29, gz wrote: > > https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf > > > > Не совсем понимаю какие выводы делают авторы. > > Мне, кроме того, и непонятно где автор взял исходные данные. На четвёртом слайде английским по белому: это данные из экспериментов в beta-канале Chrome. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
On 27-04-2020 22:29, gz wrote: https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf Не совсем понимаю какие выводы делают авторы. Мне, кроме того, и непонятно где автор взял исходные данные. -- Val ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
Hello! On Mon, Apr 27, 2020 at 04:29:44PM -0400, gz wrote: > > > Maxim Dounin Wrote: > > > --- > > > > > В HTML страницы бэкендом выдаются элементы > > с > > > > указанием > > > > > на ресурсы для предзагрузки. > > > > > Хотелось бы перейти с предзагрузки на http2_push указанных > > ресурсов. > > > > > > > > А вы пробовали тестировать, что вы получите на выходе? > > > > > > Практически не проверял, но здравый смысл подсказывает, что даже в > > рамках > > > HTTP2 проталкивание ресурсов в первом запросе позволит сэкономить > > минимум > > > один запрос на получение ресурсов, объявленных в > rel="preload">. > > > > Здравый смысл тут подсказывает неправильно. Поскольку сервер не > > знает, какие ресурсы уже есть у клиента, а каких ещё нет, он шлёт > > push'ы всегда, и тем самым расходует как канал, так и лишние > > ресурсы на сервере. Соответственно результат будет зависеть от > > того, насколько польза от push'а (сэкономленный 1 rtt при запросе > > дополнительных ресурсов у тех клиентов, у которых этих ресурсов > > нет) больше или меньше тех проблем, которые push добавляет всем > > остальным клиентам. > > Востребованные ресурсы из push-кэша переходят в основной и будут > использованы для следующих страниц. > Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся в > кэше. > В крайнем случае несложно пометить клиента стандартным способом через > cookie. Проблема в том, что даже отказ от push-ресурсов - это нагрузка как на сервер, так и на канал. И статистика как бы говорит нам, что в среднем эти накладные расходы - больше, чем польза. Что будет конкретно в вашем случае - зависит, безусловно, от конкретной нагрузки и от того, насколько "в крайнем случае несложно" вам будет избежать лишних push'ей. Но, повторюсь, в среднем - будет хуже, потому что "в крайнем случае" никто не заморачивается. Именно поэтому я начал с вопроса пробовали ли вы тестировать, что получится. Подозреваю, что от банального перекладывания существующих в push'ы - станет только хуже. > > > > Имеющиеся исследования про эффективность HTTP/2 push позволяют > > предолжить, > > > > > > > что результат скорее всего будет хуже, чем то, что у вас есть > > > > сейчас. > > > > > > Я встречал обратные исследования. > > > https://dexecure.com/blog/http2-push-vs-http-preload/ > > > > По ссылке нет исследований, там только общие соображения. > > Исследования выглядят как-то так: > > > > > https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf > > Не совсем понимаю какие выводы делают авторы. > > Предлагают работать над приоритезацией (которая и так корректная, и > регулируется preload'ом), использовать экспериментальный QUIC, поддержики > которого толком нет. Авторы ясно и однозначно показывают, что server push - в среднем вредит, и в большинстве случаев лишь способ выстрелить себе в ногу. И предлагают работать над другими технологиями, потенциально более полезными. Тут важно понимать, что речь идёт про взгляд разработчиков браузера, и рассказывалось это всё на HTTP working group, то есть в рамках встречи людей, занимающихся разработкой протокола. (Ну и да, про приоритезацию - смешно. Нет, это не про preload, это, как я понимаю, про приоритеты в рамках HTTP/2. Там самолёт с бассейном и джакузи запроектирован в рамках стандарта, корректности ждать не приходится.) > > > Плюс у push шире поддерживается. > > > > Я бы не был столь категоричен. > > Нет никакой категоричности: > https://caniuse.com/#search=rel%20preload — 84% > https://caniuse.com/#feat=http2 — 94% > > Не совсем корректное сравнение точно preload vs push, тем не менее. Ну вот это сравнение - говорит о минимальной разнице, и при этом мы не знаем, сколько в том http2 поддержики push'а, и не знаем, сколько глюков там, где она таки есть. > Я прекрасно понимаю, что push — не панацея, и хотел попробовать на практике > проталкивание критических ресурсов, которые в любом случае приоритетны и > будут загружены для отрисовки. Именно с этого я и начал: попробуйте на практике на отдельных страницах, без попыток вытаскивать версии ресурсов через SSI и вот этого всего. Получите статистику, сравните. Сейчас же вы пришли и убеждаете разработчиков, что вам надо, потому что оно точно будет лучше, но тестировать вы ничего не тестировали и не хотите. Так это не работает. Придёте со стастикой, явно показывающей плюсы - мы задумаемся над тем, как облегчить вам жизнь в конфигурации с SSI. Пока же из статистике есть вот только ссылка выше, из которой явно следует, что делать что-либо для лучше поддержки HTTP/2 push - в среднем бессмысленно. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
> В крайнем случае несложно пометить клиента стандартным способом через > cookie. Советую смотреть не на куки, а на наличия клиенских заголовков - If-None-Match и/или If-Modified-Since, только при отсутствии или не валидности данных заголовков делать push. Из нашего опыта - push полезен только для клиентов у которых нет валидного кеша, в этом случаи вы получите не большой прирост в скорости около 5-10%. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287846,287855#msg-287855 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
вт, 28 апр. 2020 г. в 01:29, gz : > > > Maxim Dounin Wrote: > > > --- > > > > > В HTML страницы бэкендом выдаются элементы > > с > > > > указанием > > > > > на ресурсы для предзагрузки. > > > > > Хотелось бы перейти с предзагрузки на http2_push указанных > > ресурсов. > > > > > > > > А вы пробовали тестировать, что вы получите на выходе? > > > > > > Практически не проверял, но здравый смысл подсказывает, что даже в > > рамках > > > HTTP2 проталкивание ресурсов в первом запросе позволит сэкономить > > минимум > > > один запрос на получение ресурсов, объявленных в > rel="preload">. > > > > Здравый смысл тут подсказывает неправильно. Поскольку сервер не > > знает, какие ресурсы уже есть у клиента, а каких ещё нет, он шлёт > > push'ы всегда, и тем самым расходует как канал, так и лишние > > ресурсы на сервере. Соответственно результат будет зависеть от > > того, насколько польза от push'а (сэкономленный 1 rtt при запросе > > дополнительных ресурсов у тех клиентов, у которых этих ресурсов > > нет) больше или меньше тех проблем, которые push добавляет всем > > остальным клиентам. > > Востребованные ресурсы из push-кэша переходят в основной и будут > использованы для следующих страниц. > Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся в > кэше. > В крайнем случае несложно пометить клиента стандартным способом через > cookie. > > > > > Имеющиеся исследования про эффективность HTTP/2 push позволяют > > предолжить, > > > > > > > что результат скорее всего будет хуже, чем то, что у вас есть > > > > сейчас. > > > > > > Я встречал обратные исследования. > > > https://dexecure.com/blog/http2-push-vs-http-preload/ > > > > По ссылке нет исследований, там только общие соображения. > > Исследования выглядят как-то так: > > > > > > https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf > > Не совсем понимаю какие выводы делают авторы. > > Предлагают работать над приоритезацией (которая и так корректная, и > регулируется preload'ом), использовать экспериментальный QUIC, поддержики > которого толком нет. > > > > Плюс у push шире поддерживается. > > > > Я бы не был столь категоричен. > > Нет никакой категоричности: > https://caniuse.com/#search=rel%20preload — 84% > https://caniuse.com/#feat=http2 — 94% > > Не совсем корректное сравнение точно preload vs push, тем не менее. > > Я прекрасно понимаю, что push — не панацея, и хотел попробовать на практике > проталкивание критических ресурсов, которые в любом случае приоритетны и > будут загружены для отрисовки. > я бы с интересом посмотрел на аналитику, которая привела к такому развитию событий. какие метрики вы с приложения снимаете, методика, всё вот это. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,287846,287852#msg-287852 > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
> > Maxim Dounin Wrote: > > --- > > > > В HTML страницы бэкендом выдаются элементы > с > > > указанием > > > > на ресурсы для предзагрузки. > > > > Хотелось бы перейти с предзагрузки на http2_push указанных > ресурсов. > > > > > > А вы пробовали тестировать, что вы получите на выходе? > > > > Практически не проверял, но здравый смысл подсказывает, что даже в > рамках > > HTTP2 проталкивание ресурсов в первом запросе позволит сэкономить > минимум > > один запрос на получение ресурсов, объявленных в rel="preload">. > > Здравый смысл тут подсказывает неправильно. Поскольку сервер не > знает, какие ресурсы уже есть у клиента, а каких ещё нет, он шлёт > push'ы всегда, и тем самым расходует как канал, так и лишние > ресурсы на сервере. Соответственно результат будет зависеть от > того, насколько польза от push'а (сэкономленный 1 rtt при запросе > дополнительных ресурсов у тех клиентов, у которых этих ресурсов > нет) больше или меньше тех проблем, которые push добавляет всем > остальным клиентам. Востребованные ресурсы из push-кэша переходят в основной и будут использованы для следующих страниц. Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся в кэше. В крайнем случае несложно пометить клиента стандартным способом через cookie. > > > Имеющиеся исследования про эффективность HTTP/2 push позволяют > предолжить, > > > > > что результат скорее всего будет хуже, чем то, что у вас есть > > > сейчас. > > > > Я встречал обратные исследования. > > https://dexecure.com/blog/http2-push-vs-http-preload/ > > По ссылке нет исследований, там только общие соображения. > Исследования выглядят как-то так: > > https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf Не совсем понимаю какие выводы делают авторы. Предлагают работать над приоритезацией (которая и так корректная, и регулируется preload'ом), использовать экспериментальный QUIC, поддержики которого толком нет. > > Плюс у push шире поддерживается. > > Я бы не был столь категоричен. Нет никакой категоричности: https://caniuse.com/#search=rel%20preload — 84% https://caniuse.com/#feat=http2 — 94% Не совсем корректное сравнение точно preload vs push, тем не менее. Я прекрасно понимаю, что push — не панацея, и хотел попробовать на практике проталкивание критических ресурсов, которые в любом случае приоритетны и будут загружены для отрисовки. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287846,287852#msg-287852 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
Hello! On Mon, Apr 27, 2020 at 02:44:26PM -0400, gz wrote: > Maxim Dounin Wrote: > --- > > > В HTML страницы бэкендом выдаются элементы с > > указанием > > > на ресурсы для предзагрузки. > > > Хотелось бы перейти с предзагрузки на http2_push указанных ресурсов. > > > > А вы пробовали тестировать, что вы получите на выходе? > > Практически не проверял, но здравый смысл подсказывает, что даже в рамках > HTTP2 проталкивание ресурсов в первом запросе позволит сэкономить минимум > один запрос на получение ресурсов, объявленных в . Здравый смысл тут подсказывает неправильно. Поскольку сервер не знает, какие ресурсы уже есть у клиента, а каких ещё нет, он шлёт push'ы всегда, и тем самым расходует как канал, так и лишние ресурсы на сервере. Соответственно результат будет зависеть от того, насколько польза от push'а (сэкономленный 1 rtt при запросе дополнительных ресурсов у тех клиентов, у которых этих ресурсов нет) больше или меньше тех проблем, которые push добавляет всем остальным клиентам. > > Имеющиеся исследования про эффективность HTTP/2 push позволяют предолжить, > > > что результат скорее всего будет хуже, чем то, что у вас есть > > сейчас. > > Я встречал обратные исследования. > https://dexecure.com/blog/http2-push-vs-http-preload/ По ссылке нет исследований, там только общие соображения. Исследования выглядят как-то так: https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf > Плюс у push шире поддерживается. Я бы не был столь категоричен. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
Maxim Dounin Wrote: --- > > В HTML страницы бэкендом выдаются элементы с > указанием > > на ресурсы для предзагрузки. > > Хотелось бы перейти с предзагрузки на http2_push указанных ресурсов. > > А вы пробовали тестировать, что вы получите на выходе? Практически не проверял, но здравый смысл подсказывает, что даже в рамках HTTP2 проталкивание ресурсов в первом запросе позволит сэкономить минимум один запрос на получение ресурсов, объявленных в . > Имеющиеся исследования про эффективность HTTP/2 push позволяют предолжить, > что результат скорее всего будет хуже, чем то, что у вас есть > сейчас. Я встречал обратные исследования. https://dexecure.com/blog/http2-push-vs-http-preload/ Плюс у push шире поддерживается. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287846,287848#msg-287848 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
Hello! On Mon, Apr 27, 2020 at 09:33:08AM -0400, gz wrote: > В HTML страницы бэкендом выдаются элементы с указанием > на ресурсы для предзагрузки. > Хотелось бы перейти с предзагрузки на http2_push указанных ресурсов. А вы пробовали тестировать, что вы получите на выходе? Имеющиеся исследования про эффективность HTTP/2 push позволяют предолжить, что результат скорее всего будет хуже, чем то, что у вас есть сейчас. [...] > Нет ли в планах поддерживать преобразования в > http2_push? Нет, такого в планах нет. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
http2 push — не планируется ли поддержка по аналогии с заголовком Link?
В HTML страницы бэкендом выдаются элементы с указанием на ресурсы для предзагрузки. Хотелось бы перейти с предзагрузки на http2_push указанных ресурсов. Казалось бы, нет проблемы перейти на заголовок Link, который модулем ngx_http_v2_module при http2_push_preload on будет преобразован в push'и. Однако, в путях к ресурсам используются SSI-вставки с текущими версиями, а HTML вместе в SSI-директивами хранится в кэше. Условно: " as="style"/> … "/> … … А после работы SSI получаем нужный результат: … … … Выходит, поможет либо поддержка SSI в заголовках ответа — чего nginx не умеет, либо поддержка модулем ngx_http_v2_module преобразования в http2_push. Посмотрел, было, в строну njs в надежде что смогу процессить тело ответа после SSI, выкусывать оттуда , преобразовывать их в Link-заголовки, которые затем будут преобразованы в ngx_http_v2_module в push'и, но в js_content тело ответа оказалось пустым, а js_filter работает на уровне stream'а. Так же попробовал использовать js_set для формирования заголовка Link на основе в теле, но в этом случае в теле в теле сохранятся и неясно как поведёт себя браузер при получении и preload-инструкций и http2_push'а. Нет ли в планах поддерживать преобразования в http2_push? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287838,287838#msg-287838 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
