ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HTTP проксирование 1.1




On 19 Mar 2014, at 13:37, Maxim Dounin <mdounin@xxxxxxxxxx> wrote:

Hello!

On Wed, Mar 19, 2014 at 10:42:26AM +0000, Anatoly Mikhailov wrote:


On 18 Mar 2014, at 15:10, Maxim Dounin <mdounin@xxxxxxxxxx> wrote:

Hello!

On Tue, Mar 18, 2014 at 03:08:31PM +0000, Anatoly Mikhailov wrote:


On 18 Mar 2014, at 13:51, Maxim Dounin <mdounin@xxxxxxxxxx> wrote:

Hello!

On Tue, Mar 18, 2014 at 12:28:08PM +0000, Anatoly Mikhailov wrote:


On 18 Mar 2014, at 11:08, Maxim Dounin <mdounin@xxxxxxxxxx> wrote:

Hello!

On Tue, Mar 18, 2014 at 11:04:27AM +0000, Anatoly Mikhailov wrote:

Добрый день,

По последнему blog post (http://nginx.com/blog/load-balancing-with-nginx-plus-part2/)
возник вопрос: какой эффект производит proxy_set_header Connection ?"?

Поясню вопрос на примере, имеется следующий конфиг для проксирования 
S3 запросов (опущены лишние детали):

location ~* ^/i/(.*) {
proxy_http_version     1.1;
proxy_set_header       Authorization '';
proxy_hide_header      Set-Cookie;
proxy_ignore_headers   "Set-Cookie?;
...
proxy_pass             ...;
}

В данном случае версия http для проксирования установлена в 1.1,
то есть ожидаем повторное использование подключения,
что в данном случае изменит proxy_set_header Connection ?" ?

По умолчанию добавляется "Connection: close"[1], и использование  
"proxy_set_header Connection ''" нужно, чтобы этого избежать.

http://nginx.org/r/proxy_set_header/ru

Максим, понятно, HTTP подключение закрывается после каждого запроса по умолчанию,
но достаточно ли Connection ?? для реиспользования HTTP 1.1 подключения? Обязательно ли
явно добавлять блок upstream и указывать директиву keepalive?

Нужно и то, и другое.  Из заголовков запроса нужно убрать 
"Connection: close", чтобы бекенд не закрывал соединение, а сам 
nginx - проинструктировать соединения сохранять и использовать 
повторно.

Понял, спасибо, Максим! Контекст директивы keepalive для бэкэнда только upstream,
если смотреть документацию, но может есть какой-то элегантный способ передать
keepalive в proxy_pass сразу, без объявления блока upstream?

Нет.

супер, переписал конфигурацию для проксирования S3 на upstream, получилось очень классно,
вопрос - почему бы не сделать keepalive для бэкэнда по умолчанию?

Использование постоянных соединений полезно в основном в тех 
случаях, когда до бекенда - далеко.  В условиях близких бекендов 
оно обычно не нужно.  Наоборот, в некоторых ситуациях постоянные 
соединения могут повредить - например, если бекенд сильно ограничен по 
количеству соединений, которые он может обрабатывать.  В 
документации даже специально добавлено замечание про это, т.к. 
люди периодически наступают, cм. http://nginx.org/r/keepalive/ru.

Так что я к идее сделать keepalive к бекендам поведением по 
умолчанию - отношусь скептически.


Я правильно понимаю, keepalive (в контексте upstream) задает количество
TCP соединений, которые не будут закрываться, даже при отсутствии будущих запросов?
Если да, то какой таймаут, такой же как для клиентских TCP подключений, указанных
через директиву keepalive_timeout?

Вопрос второй - если известно, что бэкэнд держит, скажем, 50 соединений, 
то keepalive 50 поможет нам повторно их использовать в будущем, без повторных syn+ack?

-- 
Maxim Dounin
http://nginx.org/

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.