Re: Таймауты proxy pass

2020-03-25 Пенетрантность Evgeniy Berdnikov
On Wed, Mar 25, 2020 at 09:48:10AM -0400, opan wrote:
> Добрый день.
> 
> В продолжение изучения проблемы обнаружили что в логе нжинкса
> upstream_response_time - 41ms, а этот же запрос, если смотреть tcpdump,
> время ответа бэка меньше 1ms:
> 
> https://www.dropbox.com/s/04falc2m073jnf5/Screenshot%202020-03-25%2016.38.15.png?dl=0
> 
> 
> Как такое может быть?

 Ответ апстрима не обязательно помещается в один пакет, даже если у него
 установлен флаг PSH. Если бы отображалось содержимое пакетов, то можно
 было бы проверить, передан ли ответ полностью, а при наличии в дампе
 ответных ACKов -- утверждать, что ответ получен сервером.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Таймауты proxy pass

2020-03-25 Пенетрантность opan
Добрый день.

В продолжение изучения проблемы обнаружили что в логе нжинкса
upstream_response_time - 41ms, а этот же запрос, если смотреть tcpdump,
время ответа бэка меньше 1ms:

https://www.dropbox.com/s/04falc2m073jnf5/Screenshot%202020-03-25%2016.38.15.png?dl=0


Как такое может быть?


On 23.03.2020 14:35, Илья Шипицин wrote:
> пара моментов
>
> 1) у вас proxy_pass на https, по крайней мере первоначальный хендшейк
может быть долгим (например, если клиент захочет сделать OCSP проверку).
выглядит так, как будто у вас
> должен быть кипэлайв до бекенда, поэтому это соображение должно касаться
только редких запросов
>
> 2) возможно, у вас работает буферизация запросов-ответов. попробуйте
"proxy_buffering off;" и "proxy_request_buffering off;" ?
>
> пн, 23 мар. 2020 г. в 14:01, opan :
>
> У нас есть одна площадка, нжинкс принимает запросы и проксирует на
бэкенд
> через fcgi_pass. В логах нжинса мы видим upstream_response_time 40мс.
> Появилась вторая площадка, мы принимаем там трафик и отправляем все
на
> первую площадку через proxy_pass. Так же логируем здесь
> upstream_reponse_time и наблюдаем очень большие значения. Мы ожидали,
что
> добавится просто летенси между новой и старой площадкой, плюс
какие-то
> небольшие накладные расходы nginx. Но это не так, в
upstream_response_time
> мы видим 130-150мс ( в 3.5 раз больше, чем на площадке 1). При этом,
если
> замерять время запросов от клиента, то total_time курла примерно
одинаков
> для обоих площадок. Как такое может быть? Почему в логах
> upstream_reponse_time больше в 3-4 раза, а время ответа при этом
практически
> не меняется?
>
> Вот фрагмент конфигурации, в которой проксируем:
>
>  location = /ххх {
>
> proxy_cache off;
> proxy_redirect off;
> proxy_pass_request_body on;
> proxy_pass_request_headers on;
> proxy_next_upstream off;
> proxy_set_header Host $host;
> proxy_set_header X-Real-IP $remote_addr;
> proxy_pass https://second.domain/xxx;
> proxy_http_version 1.1;
> proxy_set_header Connection "";
>
> }
>
> Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,287422,287422#msg-287422
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,287425,287456#msg-287456

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

Re: duplicate Host header

2020-03-25 Пенетрантность Maxim Dounin
Hello!

On Tue, Mar 24, 2020 at 09:29:28PM +0500, Илья Шипицин wrote:

> выглядит это примерно так.
> 
> живешь, живешь, думаешь, что у тебя все ок.
> потом обновляешься до 1.17.9, и по логам идут 400-ки.
> 
> смотришь в error.log - там duplicate Host header (про который ты ранее и
> знать не знал, и без понятия, в чем там вообще прблема, потому что ее нет
> никакой)
> 
> какая-то абстрактная задача запретить такие хедера, задача ради самой задачи

У вас мусор в заголовках запросов, прямо запрещённый RFC и 
потенциально приводящий к security-проблемам.  В рамках очередной 
серии патчей, закрывающих подобные security-проблемы - требования 
были ужесточены, имеющийся мусор - стал приводить к 400 ошибкам.

Есть ровно одно решение - мусор вычистить, но это, как тут 
звучало, не ваша война.  Если очень хочется сохранять 
совместимость с имеющимся мусором - можно продолжать пользоваться 
предыдущими версиями и/или наколхозить локальный патч, некоторое 
время это будет работать.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru