Использование nginx как reverse-proxy для увеличения производительности сервера

вообще ничего нового, меня со всеми этими фронтендами только один вопрос волнует: как access-логи разгребать более-менее вменяемо? в апаче прописал для virtualhost name и alias, и он все валит в один лог, а тут на все виртуалхосты один лог файл, причем туда еще левые CONNECT и пр. попадают.

баян, всё в нативной доке можно самому найти

Была уже такая новость здесь пару месяцев назад. Память тренируйте,
господа страдающие склерозом.

> Была уже такая новость здесь пару месяцев назад. Память тренируйте, господа страдающие склерозом.

Posted 18 May. Ты с какога времени мальчик?

Вы мне таки скажите, nginx по-прежнему наплевательски относится к версиям протокола HTTP (1.0/1.1) в заголовках или это наконец-то пофиксили ?

Да, и есть ли (или будет ли наконец) возможность убрать из заголовков:
Server: nginx/...
вообще в принципе и оставить только оригинальный заголовок апача, как это делает например apache с mod_proxy или squid ?

а что за траблы с HTTP (1.0/1.1)? не зачмечал... что делать с Server: nginx/... обсуждалось сотни раз, если вы сами не догодались, что с этим сделать специально для вас сделана опция... хотя напитьса скрипт в пару строк не сложней чем прописать опцию

Конфигурация не подходит для серьезных серверов, где много разных клиентов;
Например url вида
http://domain.ru/index.php?x=a.jpg
будет обрабатывать nginx а не апач. Хотя нужно, чтоб обработал апач
чтобы этого избежать, а также других сложностей приходится дорабатывать
ngix или (в лучшем случае) извращаться с rewrite.

пердоньте, опция которая начинает выдавать в 2 строчки Server: ngnix Server: apache нафиг не нужна. Каждому перечитавшему rfc пыхпыхщику затрахаешься объяснять что это и зачем. Нужно просто чтобы выдавалось одной строкой: Server: backend's_server_name и всё.

А с версией http грабли признает сам Сысоев. Читай: http://www.lexa.ru/nginx-ru/msg05103.html

> пердоньте, опция которая начинает выдавать в 2 строчки Server: ngnix Server: apache нафиг не нужна. Каждому перечитавшему rfc пыхпыхщику затрахаешься объяснять что это и зачем. Нужно просто чтобы выдавалось одной строкой: Server: backend's_server_name и всё.

proxy_pass_header server;

> А с версией http грабли признает сам Сысоев. Читай: http://www.lexa.ru/nginx-ru/msg05103.html

а чем эти грабли чреваты по-твоему ?

> Например url вида http://domain.ru/index.php?x=a.jpg будет обрабатывать nginx а не апач. Хотя нужно, чтоб обработал апач

Вызывающе неверная информация. QUERY_STRING не учитывается в location.

> чтобы этого избежать, а также других сложностей приходится дорабатывать ngix или (в лучшем случае) извращаться с rewrite.

До начала извращений неплохо бы ознакомиться с документацией.

> как access-логи разгребать более-менее вменяемо? в апаче прописал для virtualhost name и alias, и он все валит в один лог, а тут на все виртуалхосты один лог файл, причем туда еще левые CONNECT и пр. попадают.

Кто мешает на каждый virtual host прописать свой log file ?

Левые HTTP методы ограничиваются директивой limit_except, если не изменяет память.

> Да, и есть ли (или будет ли наконец) возможность убрать из заголовков:
> Server: nginx/...
> вообще в принципе и оставить только оригинальный заголовок апача, как > это делает например apache с mod_proxy или squid ?

Если можно, хотя бы в двух словах, чем Вам мешает Server: nginx/... ?

>QUERY_STRING не учитывается в location
как это не учитывается, а с какой версии? то есть Вы хотите сказать, что указанный мной url попадет на апач??

>До начала извращений неплохо бы ознакомиться с документацией.
почти наизусть выучил :)

и еще вдогонку:
есть ли способ красиво реализовать антилич, (без патчей, и реврайтов)?

http://domain.php/file/file.avi
(такого url не существует и срабатывает file.php, который формирует ссылку на реальный file.avi)

в апаче это делалось опцией MultiViews
кто знаком, делитесь

>>QUERY_STRING не учитывается в location >как это не учитывается, а с какой версии? то есть Вы хотите сказать, что указанный мной url попадет на апач??

с самых первых версий. почему бы ему обрабатываться nginx ? расширение .php не перечислено среди статических.

>>До начала извращений неплохо бы ознакомиться с документацией. >почти наизусть выучил :) >и еще вдогонку: >есть ли способ красиво реализовать антилич, (без патчей, и реврайтов)?

Плохо учил, двойка. Оттуда:

valid_referers none blocked server_names *.example.com www.example.info/galleries/;

if ($invalid_referer) { return 403; }

>расширение .php не перечислено среди статических
да вот в том то и дело, что я говорю у расширение в конце всего url (включая query_string). В приведенной в доке конфигурации, url aaa.ru?a=a.jpg перебросится на апач?

>valid_referers none blocked server_names
совсем не то;
как это поможет перевести управление с url
http://aaa.ru/file/file.avi
на file.php ?

именно в file.php происходит весь код антилича

> http://domain.php/file/file.avi > (такого url не существует и срабатывает file.php, который формирует ссылку на реальный file.avi)

location ^~ /file/ { proxy_pass ...; }

location ^~ /download/ { internal; alias /path/to/files/; }

Все что нужно скрипту file.php - выдать правильный заголовок X-Accel-Redirect: /download/file.zip

> да вот в том то и дело, что я говорю у расширение в конце всего url (включая query_string).

Говорить можно все что угодно. nginx не работает так, как говорите Вы.

> В приведенной в доке конфигурации, url aaa.ru?a=a.jpg перебросится на апач?

Третий раз, для тупых: ДА !

вообще file.php сформирует уникальную прямую ссылку на файл, которая будет дейтсвительна в течение некоторго времени. спасибо за пример, но не думаю, что поможет

>Третий раз, для тупых: ДА ! вообще-то это первый :) спасибо, чувствуется у Вас это работает попробую еще раз подолбится

> спасибо за пример, но не думаю, что поможет

Воспользуйтесь списком рассылки ngnix по назначению. Большие шансы что это поможет.

не читал, но осуждаю :)

что не лежачий сайт в рунете попадется - то ngnix

глючная поделка? ;)

> что не лежачий сайт в рунете попадется - то ngnix

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

> что не лежачий сайт в рунете попадется - то ngnix

А ты заметил, что сам nginx (Engine X) продолжает жить? Проблема не в нем.

> глючная поделка? ;)

Как раз он в полном порядке, это глючный бекенд упал от чрезмерной нагрузки. ;)

> > Была уже такая новость здесь пару месяцев назад. Память тренируйте, господа страдающие склерозом.

> Posted 18 May. Ты с какога времени мальчик?

Я, дяденька, с нашего времени. 17 апреля 2006 была подобная статья:
http://www.linux.org.ru/view-message.jsp?msgid=1355740

про mod_rpaf
если бакендом стоит apache 1.3 - то вместо него лучше импользовать mod_realip Сысоева
если же apache 2 - то mod_rpaf-2.0.c стоит пропатчить - во первых чтобы он понимал X-Real-IP, а во вторых чтобы хук вставал в правильное место в цепочке обработки
например так: http://maloletka.ru/patches/rpaf-0.5.patch

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

> Да, и есть ли (или будет ли наконец) возможность убрать из заголовков: Server: nginx/...

http://www.lexa.ru/nginx-ru/msg06145.html

> http://www.lexa.ru/nginx-ru/msg06145.html

О, то есть эту граблю упразднили 1,5 недели назад ... Ок, отлично.

На счет проблемы с версиями HTTP: рекомендую почитать чем 1.0 отличается от 1.1 (подсказка: наличие заголовка Host: - это только одно отличие, а их гораздо больше)

> На счет проблемы с версиями HTTP: рекомендую почитать чем 1.0 отличается от 1.1 (подсказка: наличие заголовка Host: - это только одно отличие, а их гораздо больше)

Еще раз, конкретный вопрос: в чем ты видишь проблему ?

Проблема начинается тогда, когда запрос, изначально пришедший с HTTP/1.1 nginx переделывает в HTTP/1.0 просто перебивая заголовок, а потом какой-то клиентский скрипт основываясь на версии протокола начинает делать вывод о том какие залоговки выдавать, а какие - нет.
Например присловутый ETag. Если ты в курсе, это фича HTTP/1.1, однако ж backend apache _независимо_ от того в какой версии пришел оригинальный запрос, увидит только HTTP/1.0. В итоге информация о клиенте частично теряется. Вот в чем проблема.

> Проблема начинается тогда, когда запрос, изначально
> пришедший с HTTP/1.1 nginx переделывает в HTTP/1.0
> просто перебивая заголовок, а потом какой-то клиентский
> скрипт основываясь на версии протокола начинает делать
> вывод о том какие залоговки выдавать, а какие - нет.

> Например присловутый ETag. Если ты в курсе, это фича
> HTTP/1.1, однако ж backend apache _независимо_ от того
> в какой версии пришел оригинальный запрос, увидит
> только HTTP/1.0. В итоге информация о клиенте частично
> теряется. Вот в чем проблема.

А какие проблемы с пресловутым ETag (даже, если проигнорировать
тот факт, что Апач выдаёт ETag и для HTTP/1.0, и для HTTP/1.1) ?

Ну и ещё хотелось бы услышать пару жизненных примеров.


Игорь Сысоев

Приветствую, Игорь

Проблемы вообще говоря не у меня лично, проблемы у клиентов нашего хостинга. Как только на frontend был поставлен nginx, так почти что сразу начались ньюансы. Вернули назад apache 2 с mod_proxy, ньюансы оказались исчерпаны.
Я лично не силен в RFC, однако один дотошный товарищ из числа наших клиентов, сказал что у него система выдает заголовки по RFC и вот по RFC когда клиент присылает запрос в 1.0, ETag не выдается, потому как не должен, хотя мне лично совершенно очевидно что mass virtual hosting на 1.0 просто бы не работал.

Ну и попутно вопрос: а почему собственно 1.0, если очевидно что это 1.1 ? Тем более что в оригинальном запросе четко приходит 1.1 ?!

> Проблемы вообще говоря не у меня лично, проблемы у клиентов нашего
> хостинга. Как только на frontend был поставлен nginx, так почти что
> сразу начались ньюансы. Вернули назад apache 2 с mod_proxy, ньюансы
> оказались исчерпаны.
> Я лично не силен в RFC, однако один дотошный товарищ из числа наших
> клиентов, сказал что у него система выдает заголовки по RFC и вот
> по RFC когда клиент присылает запрос в 1.0, ETag не выдается,
> потому как не должен,

Я не понимаю, какие могут появиться ньюансы от того, что в ответе 1.1
нет ETag. Практически все сайты отдают динамические ответы по 1.1
без ETag и никаких ньюансов не наблюдается.

> хотя мне лично совершенно очевидно что
> mass virtual hosting на 1.0 просто бы не работал.

А каким боком ETag имеет отношение к mass virtual hosting ?
Что касается mass virtual hosting на 1.0, то по RFC он, возможно,
бы и не работал, а в жизни прекрасно работает. Я не знаю, ни одного
сколько-нибудь полезного клиента, который бы не передавал Host.

> Ну и попутно вопрос: а почему собственно 1.0, если очевидно
> что это 1.1 ? Тем более что в оригинальном запросе четко
> приходит 1.1 ?!

Проблема в том, что nginx на данный момент не умеет
обрабатывать chunked ответы от бэкенда. Если nginx будет ходить к
нему по 1.1, а бэкенд не знает длины ответа, то ответ будет chunked.
В результате nginx не сможет корректно отпарсить ssi в таком ответе.


Игорь Сысоев

> Я не понимаю, какие могут появиться ньюансы от того, что в ответе 1.1
нет ETag. Практически все сайты отдают динамические ответы по 1.1
без ETag и никаких ньюансов не наблюдается.


Нет, еще раз: у человека сделана какая-то там система которая автоматом генерирует заголовки в зависимости от версии HTTP клиента. Когда _все_ запросы начинают приходить в 1.0, у него перестают выдаваться заголовки ETag (автоматом, поскольку его система считает что раз клиент 1.0, то ETag выдавать смысла нет, т.к. он его по RFC понимать не должен), соответственно ему это не нравится. Он, как клиент, имеет полное право жаловаться на это, а мы, как хостинговая компания, должны эту проблему решить.
Решение было простое - снести nginx с frontend и поставить назад apache 2 с mod_proxy. На сколько я понимаю, на текущий момент эта ситуация с nginx просто не разрешима. Вот и вся суть.

> у человека сделана какая-то там система которая автоматом генерирует
> заголовки в зависимости от версии HTTP клиента. Когда _все_ запросы
> начинают приходить в 1.0, у него перестают выдаваться заголовки
> ETag (автоматом, поскольку его система считает что раз клиент 1.0,
> то ETag выдавать смысла нет, т.к. он его по RFC понимать не должен),
> соответственно ему это не нравится.

То есть, фактически это ньюанс из серии "шашечки или ехать", никак не
влияющий на реальную работоспособность сайта.

А клиента не смущает, что все, кто ходит к нему через Squid'ы тоже
приходят по 1.0 ? Ну и ещё, что Апач всегда спокойно выдаёт ETag
для статики независимо от версии ?


Игорь Сысоев

Да не, понятно что все работает. Просто он упертый и ему надо чтобы было по RFC и всё тут. Скандал устроил целый.
Про Squid'ы аргумент ему был тоже сказан, но он на него никак не отреагировал.

Я конечно могу ошибаться в выводах, но получается что все таки nginx - это не 100% http/1.1 compilant proxy ? В отличие от apache2 с mod_proxy ?

> Я конечно могу ошибаться в выводах, но получается что все
> таки nginx - это не 100% http/1.1 compilant proxy ? В отличие
> от apache2 с mod_proxy ?

nginx не только не 100% http/1.1 compliant proxy, но и не 100%
compliant http/1.1 server. Собственно, я нигде и не заявлял про
100% compliance. И я, кстати, не уверен, что apache2 на 100%
соответствует http/1.1. Вообще же, 100% соответствие - это опять же
из серии "шашечки или ехать" - какие-то части стандарта реально
нигде не используются или используются не так, как планировалось.


Игорь Сысоев

Спасибо за ответы, Игорь. Я понял Вашу позицию и вобщем согласен с нею. Так же понял ситуацию с развитием nginx на текущий момент.

Да, если еще не поздно, хотел спросить: Игорь, можно ли придумать какую-то схему чтобы обходить ошибки типа 502 / Gateway Timeout ? Например backend-апач в данный момент рестартует, nginx получает запрос, пытается зацепиться к апачу и если случается облом, то скажем сделать еще n повторов через m секунд каждый или типа того, прежде чем выдавать Gateway Timeout ? Было бы очень удобно имхо.

Сейчас такой возможности нет, но будет.

Игорь Сысоев

Жду с нетерпением :)
Еще раз спасибо за ответы