Опубликована тестовая версия модуля HTTP/2 для NGINX / forpes.ru

Главная
Опубликована тестовая версия модуля HTTP/2 для NGINX

Опубликована тестовая версия модуля HTTP/2 для NGINX +30

07.08.2015 14:17

XiM90 24 14590 Источник

Представлена альфа версия патча, обеспечивающего поддержку HTTP/2 для NGINX. Для данного патча необходим NGINX версии 1.9.0 или новее. Полная поддержка протокола HTTP/2 для коммерческой и некоммерческой версий NGINX планируется к концу этого года. Отзывы можно отправить в рассылку nginx-devel.

Так как патч является альфа версией, не рекомендуется его использовать в рабочих проектах. Если есть желание использовать особенности HTTP/2 для рабочих сайтов, следует обратить внимание на NGINX версии 1.5.10 и более новых, в которых реализована полная поддержка протокола SPDY/3.1. Как предшественник HTTP/2, SPDY обладает такими же приемуществами как и HTTP/2, но в то же время имеет более широкую поддержку среди актуальных версий браузеров.

О поддержке HTTP/2 в NGINX

HTTP/2 является новым протоколом, поэтому существуют некоторые опасения и непонимания связанные с ним. Одним из основных опасений является то, что для внедрения поддержки HTTP/2 требуется изменение архитектуры всего приложения. Это опасение и многие другие, связанные с HTTP/2, беспочвенны. На самом деле, для приложений, использующих NGINX, поддержка HTTP/2 реализуется с помощью незначительных изменений архитектуры.

Для облегчения перехода к новому протоколу NGINX действует как “HTTP/2 шлюз”. На стороне клиента NGINX общается с браузерами через HTTP/2 (если для браузера реализована поддержка HTTP/2), а на стороне сервера через HTTP/1.x (или FastCGI, uwsgi, SCGI) как раньше. В промежутке между клиентом и бекендом NGINX преобразует HTTP/2 в HTTP/1.x (или FastCGI, и т.д.). Иными словами, сервера и приложения, проксируемые через NGINX, не требуют изменений для перехода на HTTP/2. Единственным необходимым изменением существующих HTTPS конфигураций будет добавление параметра http2 к директивам listen (ssl параметр также необходим):

listen 443 ssl http2 default_server;

На июнь 2015 года более 50% пользователей используют браузеры с поддержкой HTTP/2. Другими словами, реализация HTTP/2 браузерами довольно высокая и будет увеличиваться с течением времени. Для одновременной работы HTTP/1.x и HTTP/2 в NGINX используется Application Layer Protocol Negotiation (ALPN), являющийся расширением TLS. При подключении браузера к серверу посылается список поддерживаемых протоколов. Если в списке есть h2, то NGINX использует HTTP/2 для соединения. Если в браузере не реализована поддержка ALPN или в списке поддерживаемых протоколов нет h2, то NGINX будет использовать HTTP/1.x.

Как вы могли догадаться, часть оптимизаций для HTTP/1.x теперь являются антипаттернами для HTTP/2. Такие оптимизации как использование спрайтов, объединение или инлайнинг картинок, а также разделение ресурсов между доменами, которые помогали при использовании HTTP/1.x, больше не нужны с HTTP/2. Вы, конечно, можете внедрить HTTP/2 используя эти оптимизации, но мы настоятельно рекомендуем избавиться от них для увеличения производительности.

Сборка NGINX c HTTP/2

Устанавливаем OpenSSL версии 1.0.2 или новее, необходимый для поддержки ALPN.

Скачиваем и распаковываем NGINX версии 1.9.0 или новее:

$ wget http://nginx.org/download/nginx-1.9.3.tar.gz
$ tar zxvf nginx-1.9.3.tar.gz
$ cd nginx-1.9.3

Скачиваем патч:

$ wget http://nginx.org/patches/http2/patch.http2.txt

Проверяем возможность применения патча:
```
$ patch -p1 --dry-run < patch.http2.txt
```
Если ошибок нет – применяем:
```
$ patch -p1 < patch.http2.txt
```

Конфигурируем NGINX с необходимыми опциями:

для сборки NGINX вместе с OpenSSL из исходников и статической линковки:

$ ./configure --with-http_ssl_module               --with-http_v2_module               --with-debug               --with-openssl=/path/to/openssl-1.0.2               ...

если OpenSSL установлен как сторонняя библиотека (например в Mac OS X):

$ ./configure --with-http_ssl_module               --with-http_v2_module               --with-debug               --with-cc-opt="-I/opt/local/include"               --with-ld-opt="-L/opt/local/lib"               ...

После этого собираем NGINX:
```
$ make
```

Настройка NGINX

Для включения поддержки HTTP/2 добавьте параметры ssl и http2 к директивам listen:

server {
    listen 443 ssl http2 default_server;

    ssl_certificate     server.crt;
    ssl_certificate_key server.key;
    ...
}

Замечание: параметр ssl является обязательным. На момент написания статьи в браузерах не реализована поддержка HTTP/2 без SSL шифрования.

Для проверки работоспособности HTTP/2 есть неплохие плагины для Google Chrome и Firefox.

Замечания

Как это бывает с ранними релизами, есть некоторое количество проблем:

Патч находится в состоянии ранней альфы и может использоваться только для тестирования. В данное время над модулем ведется активная работа и мы будем благодарны всем, кто примет участие в тестировании (результаты можно прислать в nginx-devel).
'Server Push' не реализован в этой версии патча и не будет поддержан в первой рабочей реализации HTTP/2. Возможно, данный функционал появиться в следующих версиях NGINX.
Патч удаляет модуль SPDY и заменяет его модулем HTTP/2. То есть после применения данного патча настроить NGINX с использованием SPDY не удастся. Это также будет сделано в первой рабочей версии HTTP/2 для коммерческой и некоммерческой версий. SPDY объявят устаревшим в начале 2016 г., поэтому нет необходимости поддерживать обе директивы.

Особые благодарности

NGINX, Inc. выражает благодарность компаниям Dropbox и Automattic, которые являются активными пользователями NGINX и участвуют в спонсировании разработки. Их вклад ускорил создание HTTP/2 модуля и мы надеемся, что у вас в свою очередь будет возможность поддержать их.

UPD: Поддержка HTTP2 уже добавлена в open-source версию NGINX. Все желающие могут скачать исходники.

Комментарии (24)

BuriK666
07.08.2015 17:41
#8529003
Радует что NGINX не поддерживает http2 без ssl, как и Google Chrome.
1. VBart
  07.08.2015 17:53
  #8529019
  +1
  Поддерживает. Это полезно для тестов и когда распаковка TLS осуществляется где-то раньше.
1. dreik
  07.08.2015 17:54
  #8529021
  +5
  процитирую VBart из листа nginx-ru:
  Она есть, мы её для собственных функциональных тестов используем.
  
  В браузерах поддержки нет и, насколько мне известно, пока не планируется.
  Тому есть как минимум две причины:
  
  1. Может не работать если пользователь за прокси;
  
  2. Смысла немного, HTTP/2 — это экономия на хэндшейках, которые для TCP
  не такие дорогие, как для TCP+TLS.

Gendalph
07.08.2015 19:16
#8529127
Очень прошу добавить примечание по make install — вместо него необходимо использовать checkinstall, что позволит потом безболезненно удалить пакет.

PS: когда за make install начнут ломать руки?
1. VBart
  07.08.2015 19:49
  #8529175
  +6
  Мир гораздо шире и не ограничивается системами где есть checkinstall. Вообще для потестировать не нужно ставить nginx в систему. Тут правильнее будет убрать из статьи make install (собственно у меня в README её и нет: nginx.org/patches/http2/README.txt).
  1. Gendalph
    07.08.2015 20:00
    #8529185
    +1
    Я знаю, но заметку нужно делать — очень многие по-прежнему кроме make && make install ничего не знают.
    
    VBart
    07.08.2015 20:06
    #8529193
    Я согласен.
1. k0ldbl00d
  07.08.2015 20:58
  #8529225
  +2
  Руки начнут ломать, когда не останется дистрибутивов, кроме ответвлений от Debian.
  1. Gendalph
    07.08.2015 21:22
    #8529235
    checkinstall -R?
    makepkg?
    ebuild?
    На *BSD, конечно, ничего иного кроме make install не остается, но там люди сами знают что делать.
    
    k0ldbl00d
    07.08.2015 22:25
    #8529277
    +3
    Ну вот и надо было об этом раньше писать, а то только checkinstall.
    
    Gendalph
    07.08.2015 22:36
    #8529287
    Речь о безоговорочном 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, прочие), но в этом случае пользователь сам знает что и куда.
    
    Zelgadis
    08.08.2015 00:24
    #8529361
    +4
    Вот не надо. pkg-ng во FreeBSD удобная штука. Порты конечно уже удобнее. Добавить этот модуль в портовый nginx если этого еще не сделали не так уж и сложно.
    
    Gendalph
    08.08.2015 00:31
    #8529365
    Признаю, я тут отстал, но это отличные новости.
1. KAndy
  07.08.2015 21:42
  #8529239
  +2
  а какие проблемы make install сделанного в docker контейнере?
  1. Gendalph
    07.08.2015 21:47
    #8529245
    -2
    Я, честно говоря, пока не добрался до Docker'а, но мне кажется что это не совсем правильно — собирать в контейнере приложение, правильнее будет ставить пакет (возможно предварительно собранный в другом контейнере).
  1. cy-ernado
    08.08.2015 00:16
    #8529357
    +1
    Никаких.
    
    cy-ernado
    08.08.2015 21:08
    #8529713
    Если кому нужно, обновил свой Dockerfile для nginx с pagespeed, заменив spdy на http2.
    Openssl не очень очевидно для меня ставится :)
    
    github.com/cydev/nginx/blob/master/Dockerfile
  1. Zelgadis
    08.08.2015 00:37
    #8529371
    +3
    Хмм, как насчет того, что это требует всей обвязки для make install внутри контейнера? Какое-то не логичное использование контейнеров.
1. edwardspec
  08.08.2015 04:09
  #8529483
  +7
  > что позволит потом безболезненно удалить пакет.
  > PS: когда за make install начнут ломать руки?
  
  Не ранее чем отовсюду исчезнет configure.
  Которому можно сказать --prefix=/opt/nginx и делать make install спокойно.
1. vagran
  08.08.2015 08:08
  #8529507
  +8
  Что за бред. А если я свой префикс указал для configure? В чём проблема мне его потом удалить? Руки ломать надо за навязывание абсолютных утверждений и субъективного мнения.
1. Fr0stb1te
  08.08.2015 14:34
  #8529613
  +3
  Когда за повторение за другими категоричных утверждений начнут ломать руки?
  
  1) Это моя машина, что хочу, то и делаю.
  2) /usr/local

Anakros
15.08.2015 18:25
#8537711
Пользователям homebrew: gist.github.com/Anakros/1891d0b4ec3ca2e34d97

DIvan4ik
31.08.2015 16:44
#8555655
У кого нибудь проходит проверка на http/2?

deep_orange
11.09.2015 02:17
#8568725
А что же делать если мне не составляет проблем поднять два аналогичных сервера за Nginx — для http и для http2. Но как делить по протоколу мне не ясно. А так получается, я выпилю оптимизацию для стариков и они начнут тормозить ещё сильней. А ведь это не только нагрузка на клиента. Если вместо одного спрайта я буду пихать 50 картинок подряд. У меня каналов ~~не хватит~~ хватит конечно, я же чисто протестировать. Но сама такая возможность интересует. Я не совсем уверен, что я смогу пулять статику как-то иначе, не прибегая к двум серверам одновременно, так, чтобы оптимизация для стариков работала и для HTTP/2, кто поддерживает. SSL в обязаловку.