Comments 25
Радует что NGINX не поддерживает http2 без ssl, как и Google Chrome.
Поддерживает. Это полезно для тестов и когда распаковка TLS осуществляется где-то раньше.
процитирую VBart из листа nginx-ru:
Она есть, мы её для собственных функциональных тестов используем.
В браузерах поддержки нет и, насколько мне известно, пока не планируется.
Тому есть как минимум две причины:
1. Может не работать если пользователь за прокси;
2. Смысла немного, HTTP/2 — это экономия на хэндшейках, которые для TCP
не такие дорогие, как для TCP+TLS.
Очень прошу добавить примечание по
PS: когда за
make install — вместо него необходимо использовать checkinstall, что позволит потом безболезненно удалить пакет.PS: когда за
make install начнут ломать руки?Мир гораздо шире и не ограничивается системами где есть
checkinstall. Вообще для потестировать не нужно ставить nginx в систему. Тут правильнее будет убрать из статьи make install (собственно у меня в README её и нет: nginx.org/patches/http2/README.txt).
Руки начнут ломать, когда не останется дистрибутивов, кроме ответвлений от Debian.
checkinstall -R?makepkg?ebuild?На *BSD, конечно, ничего иного кроме
make install не остается, но там люди сами знают что делать.Ну вот и надо было об этом раньше писать, а то только checkinstall.
Речь о безоговорочном
make install.checkinstall покрывает все .deb (checkinstall -D) и .rpm (checkinstall -R) дистрибутивы — Debian, Ubuntu, RHEL, CentOS, SUSE — основная масса инсталляций.makepkg — ArchLinux и основанные на нём — там люди сами знают что к чему.ebuild — Gentoo, no comment.make install — для тех дистрибутивов и систем, где build-система не предусматривает удобного сбора пакетов (какой-нибудь LFS, *BSD, прочие), но в этом случае пользователь сам знает что и куда.
а какие проблемы make install сделанного в docker контейнере?
Я, честно говоря, пока не добрался до Docker'а, но мне кажется что это не совсем правильно — собирать в контейнере приложение, правильнее будет ставить пакет (возможно предварительно собранный в другом контейнере).
Никаких.
Если кому нужно, обновил свой Dockerfile для nginx с pagespeed, заменив spdy на http2.
Openssl не очень очевидно для меня ставится :)
github.com/cydev/nginx/blob/master/Dockerfile
Openssl не очень очевидно для меня ставится :)
github.com/cydev/nginx/blob/master/Dockerfile
Хмм, как насчет того, что это требует всей обвязки для make install внутри контейнера? Какое-то не логичное использование контейнеров.
> что позволит потом безболезненно удалить пакет.
> PS: когда за make install начнут ломать руки?
Не ранее чем отовсюду исчезнет configure.
Которому можно сказать --prefix=/opt/nginx и делать make install спокойно.
> PS: когда за make install начнут ломать руки?
Не ранее чем отовсюду исчезнет configure.
Которому можно сказать --prefix=/opt/nginx и делать make install спокойно.
Что за бред. А если я свой префикс указал для configure? В чём проблема мне его потом удалить? Руки ломать надо за навязывание абсолютных утверждений и субъективного мнения.
Когда за повторение за другими категоричных утверждений начнут ломать руки?
1) Это моя машина, что хочу, то и делаю.
2) /usr/local
1) Это моя машина, что хочу, то и делаю.
2) /usr/local
Пользователям homebrew: gist.github.com/Anakros/1891d0b4ec3ca2e34d97
У кого нибудь проходит проверка на http/2?
А что же делать если мне не составляет проблем поднять два аналогичных сервера за Nginx — для http и для http2. Но как делить по протоколу мне не ясно. А так получается, я выпилю оптимизацию для стариков и они начнут тормозить ещё сильней. А ведь это не только нагрузка на клиента. Если вместо одного спрайта я буду пихать 50 картинок подряд. У меня каналов не хватит хватит конечно, я же чисто протестировать. Но сама такая возможность интересует. Я не совсем уверен, что я смогу пулять статику как-то иначе, не прибегая к двум серверам одновременно, так, чтобы оптимизация для стариков работала и для HTTP/2, кто поддерживает. SSL в обязаловку.
- Вынесите статику на отдельные домены, пусть у них будет 2 отдельных адреса. Предоложим, что static1.domain.com, static2.domain.com,… указывают на первый ip, а static-h2.domain.com на второй.
- Поднимите на доменах staticN.domain.com, nginx затюненный на http/1.1 раздачу.
- Поднимите на домене static-h2.domain.com отдельный nginx, затюненный на http2 с сертификатом и пр.
- На основном сайте www.domain.com настройте nginx, чтобы он передавал в приложение версию протокола — http/1.1 или http/2, за это отвечает специальная переменная $http2.
- Ваше приложение должно проверять какой клиент к нему пришел. Если от nginx пришел заголовок h2, то такому клиенту отдаете все ссылки на статику вида: https://static-h2.domain.com/… иначе делаете шардинг статики по доменам http://staticN.domain.com
- Profit!
Все можно поднять и на одном сервере. Как вы верно заметили, вопрос скорее в ссылках, которые будут получать клиенты. И они уже сами пойдут на нужный сервер.
Sign up to leave a comment.
Опубликована тестовая версия модуля HTTP/2 для NGINX