<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 19 Mar 2014, at 13:37, Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Hello!<br><br>On Wed, Mar 19, 2014 at 10:42:26AM +0000, Anatoly Mikhailov wrote:<br><br><blockquote type="cite"><br>On 18 Mar 2014, at 15:10, Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>> wrote:<br><br><blockquote type="cite">Hello!<br><br>On Tue, Mar 18, 2014 at 03:08:31PM +0000, Anatoly Mikhailov wrote:<br><br><blockquote type="cite"><br>On 18 Mar 2014, at 13:51, Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>> wrote:<br><br><blockquote type="cite">Hello!<br><br>On Tue, Mar 18, 2014 at 12:28:08PM +0000, Anatoly Mikhailov wrote:<br><br><blockquote type="cite"><br>On 18 Mar 2014, at 11:08, Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>> wrote:<br><br><blockquote type="cite">Hello!<br><br>On Tue, Mar 18, 2014 at 11:04:27AM +0000, Anatoly Mikhailov wrote:<br><br><blockquote type="cite">Добрый день,<br><br>По последнему blog post (<a href="http://nginx.com/blog/load-balancing-with-nginx-plus-part2/">http://nginx.com/blog/load-balancing-with-nginx-plus-part2/</a>)<br>возник вопрос: какой эффект производит proxy_set_header Connection “"?<br><br>Поясню вопрос на примере, имеется следующий конфиг для проксирования<span class="Apple-converted-space"> </span><br>S3 запросов (опущены лишние детали):<br><br>location ~* ^/i/(.*) {<br>proxy_http_version 1.1;<br>proxy_set_header Authorization '';<br>proxy_hide_header Set-Cookie;<br>proxy_ignore_headers "Set-Cookie”;<br>...<br>proxy_pass ...;<br>}<br><br>В данном случае версия http для проксирования установлена в 1.1,<br>то есть ожидаем повторное использование подключения,<br>что в данном случае изменит proxy_set_header Connection “" ?<br></blockquote><br>По умолчанию добавляется "Connection: close"[1], и использование <br>"proxy_set_header Connection ''" нужно, чтобы этого избежать.<br><br><a href="http://nginx.org/r/proxy_set_header/ru">http://nginx.org/r/proxy_set_header/ru</a><br></blockquote><br>Максим, понятно, HTTP подключение закрывается после каждого запроса по умолчанию,<br>но достаточно ли Connection “” для реиспользования HTTP 1.1 подключения? Обязательно ли<br>явно добавлять блок upstream и указывать директиву keepalive?<br></blockquote><br>Нужно и то, и другое. Из заголовков запроса нужно убрать<span class="Apple-converted-space"> </span><br>"Connection: close", чтобы бекенд не закрывал соединение, а сам<span class="Apple-converted-space"> </span><br>nginx - проинструктировать соединения сохранять и использовать<span class="Apple-converted-space"> </span><br>повторно.<br></blockquote><br>Понял, спасибо, Максим! Контекст директивы keepalive для бэкэнда только upstream,<br>если смотреть документацию, но может есть какой-то элегантный способ передать<br>keepalive в proxy_pass сразу, без объявления блока upstream?<br></blockquote><br>Нет.<br></blockquote><br>супер, переписал конфигурацию для проксирования S3 на upstream, получилось очень классно,<br>вопрос - почему бы не сделать keepalive для бэкэнда по умолчанию?<br></blockquote><br>Использование постоянных соединений полезно в основном в тех<span class="Apple-converted-space"> </span><br>случаях, когда до бекенда - далеко. В условиях близких бекендов<span class="Apple-converted-space"> </span><br>оно обычно не нужно. Наоборот, в некоторых ситуациях постоянные<span class="Apple-converted-space"> </span><br>соединения могут повредить - например, если бекенд сильно ограничен по<span class="Apple-converted-space"> </span><br>количеству соединений, которые он может обрабатывать. В<span class="Apple-converted-space"> </span><br>документации даже специально добавлено замечание про это, т.к.<span class="Apple-converted-space"> </span><br>люди периодически наступают, cм.<span class="Apple-converted-space"> </span><a href="http://nginx.org/r/keepalive/ru">http://nginx.org/r/keepalive/ru</a>.<br><br>Так что я к идее сделать keepalive к бекендам поведением по<span class="Apple-converted-space"> </span><br>умолчанию - отношусь скептически.<br><br></div></blockquote><div><br></div><div>Я правильно понимаю, keepalive (в контексте upstream) задает количество</div><div>TCP соединений, которые не будут закрываться, даже при отсутствии будущих запросов?</div><div>Если да, то какой таймаут, такой же как для клиентских TCP подключений, указанных</div><div>через директиву keepalive_timeout?</div><div><br></div><div>Вопрос второй - если известно, что бэкэнд держит, скажем, 50 соединений, </div><div>то keepalive 50 поможет нам повторно их использовать в будущем, без повторных syn+ack?</div><br><blockquote type="cite"><div style="font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">--<span class="Apple-converted-space"> </span><br>Maxim Dounin<br><a href="http://nginx.org/">http://nginx.org/</a><br><br>_______________________________________________<br>nginx-ru mailing list<br><a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br><a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></div></blockquote></div><br></body></html>