HTTP/2 Server Push в Nginx

[grigori]

Они меня - и не только меня, конечно, услышали, и запилили-таки полную поддержку HTTP/2, которую аннонсировали в 2015

https://www.nginx.com/blog/nginx-1-13-9-http2-server-push/

Можно проектировать кеширование ассетов на главном балансировщике из апстрим-сервисов без задержек на соединение.

 

[fixxxer]

А этот server push вообще дружит с browser cache? Я тут вижу большую проблему: даже если браузер откажется от пушнутого и закроет стрим (а они это умеют?), tcp/ip не обманешь, пакетики уже полетели.

В итоге чем это отличается от inline assets?

 

[fixxxer]

Ну да, вон в h2o запилили cache-aware server-push на куках и черной магии. В nginx вроде ничего подобного нет (хотя, наверное, можно изобразить через njs).

 

[grigori]

тут все немного сложнее, я целый доклад делал на летнем devconf
по пунктам
1. дружит ли с browser cache - да, и устаревание этого кеша - это логика версионирования приложения, серверу в это лезть не надо
в h2o сделали простое решение для ламеров, у меня сделано руками, когда надо - пушим, не надо - не пушим

2. От inline assets отличается в первую очередь удобством. Ресурсы компилировать не нужно, а кешировать можно.

3. выигрыш заметный, проблема возникает на соединениях с потерями пакетов. При потере ключевых фреймов зависает все.

4. IE до Edge и Safari традиционно тупят.

 

[fixxxer]

А откуда ты знаешь, когда надо? Версионирование вообще по барабану (очевидно, что версия в урлах есть), откуда ты знаешь, что в кэше браузера уже есть? Я кроме кук, как-то вариантов и не вижу.

 

[grigori]

Кук хватает. Нет куки - выставляю заголовок Link из приложения, есть кука - не выставляю.
Решение на 4 строчки, включая if.

в конфиге nginx все это тоже есть
https://www.nginx.com/blog/nginx-1-13-9-http2-server-push/#selective-push

 

[grigori]

Пушить из Nginx лучше, чем из H2O потому что nginx умеет кешировать ассет для пуша у себя в памяти, без проксирования на аплинк. Удобно, чтобы вынести центральный роутер в отдельный контейнер.

 

[fixxxer]

На 4 строчки это по принципу "все или ничего". В ряде случаев, конечно, этого достаточно.

проблема возникает на соединениях с потерями пакетов

Это очевидная проблема http/2: тут в чем выиграли (единственное tcp-соединение), в том и проиграли. Тут решать только разве что сменой tcp на что-то кастомное поверх udp, типа гугловского quic.

 

[grigori]

На 4 строчки это по принципу "все или ничего". В ряде случаев, конечно, этого достаточно.

это уже анекдот: сколько нужно программистов, чтобы написать одну строчку маппинга бинарной маски на массив )))

 

[grigori]

с quik вопрос в том, что его поддержка ограничена чуть менее, чем одним веб-сервером

 

[fixxxer]

это уже анекдот: сколько нужно программистов, чтобы написать одну строчку маппинга бинарной маски на массив )))

Тогда в конфиге nginx "все это" вовсе не есть.

 

[grigori]

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

Дело в том, что пушить имеет смысл только те ресурсы, которые блокируют отрисовку страницы.
Пока грузится HTML, фоном отправляем CSS и шрифт.
JS лучше грузить в самом конце страницы, а сторонние либы - с async.
Большие картинки лучше грузить по Lazy Load при промотке страницы, а маленькие лучше оставить на усмотрение браузера. По http/2 мелкие ресурсы не тормозят загрузку, их не надо объединять в спрайты.
Так что, пушить нужно только 1 или 2 файла всего.

 

[AnrDaemon]

Пусть бы они уже DAV дописали. Пусть хоть модулем, но чтобы был в стандартной поставке, чтобы не бегать за ним по всему интернету.

 

[fixxxer]

@AnrDaemon, https://github.com/arut/nginx-dav-ext-module/issues/21#issuecomment-361048897

 

[grigori]

С дефолтной поставкой веселая ситуация.
Официальный репозиторий Nginx дает два варианта, официальные репозитории линуксов - по несколько разных сборок в каждом линуксе.
Чтобы понять, какой пакет ставить в убунте - надо час изучать их состав.

 

[fixxxer]

С официальными nginx-овскими как раз все прекрасно понятно, я их и ставлю, но я стараюсь обходиться без сторонних модулей, пока что получается.

Если они нужны, все сложнее. В этом случае я бы, наверное, свой PPA сделал. У меня один есть, для trusty со статически вкомпиленным свежим openssl для ALPN (манкипатч на официальный nginx-овский). Я-то сам уже везде переехал на Xenial, но билд-машинка собирает, кто-то пользуется, мне не жалко.

 

[флоппик]

Чтобы понять, какой пакет ставить в убунте - надо час изучать их состав.

Я кстати, некоторое время уже пользуюсь https://launchpad.net/~ondrej/+archive/ubuntu/nginx-mainline

 

[fixxxer]

Я кстати, некоторое время уже пользуюсь https://launchpad.net/~ondrej/+archive/ubuntu/nginx-mainline

Давно не смотрел, кстати, а там с появлением динамических модулей уже вынесли всякую стороннюю ересь отдельно?
Когда смотрел, "обычный" был с пачкой модулей сомнительного качества, а в light не было map, который нужен почти всегда.

 

[grigori]

а еще http://openresty.org/

 

[AnrDaemon]

@AnrDaemon, https://github.com/arut/nginx-dav-ext-module/issues/21#issuecomment-361048897

Я в курсе, но…

Чтобы понять, какой пакет ставить в убунте - надо час изучать их состав.

…
Так что сейчас компилю модули сам.