date:20210408

Re: Plain text token in config!

2021-04-08 Thread bouvierh

Thanks for your help!! Are there any other ways that I might have missed?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?2,291202,291205#msg-291205

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

location not working

2021-04-08 Thread uragnorson

On RHEL I have, 

location / {
root /usr/share/nginx.html;
}

location /dist/ { 
alias /usr/share/nginx/html/dist/;
}

I am able to navigate to http://server/dist but in dist the index.html is
looking for http://server/js but it should be http:/server/dist/js is there
a way to add the extra "dist" ?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?2,291204,291204#msg-291204

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

Re: Plain text token in config!

2021-04-08 Thread Sergey A. Osokin

Hi Hugues,

hope you're doing well.

On Thu, Apr 08, 2021 at 02:58:01PM -0400, bouvierh wrote:
> Hello!
> 
> I currently use Nginx as a reverse proxy for my backend services. 
> 
> Nginx authenticates itself to the backend services using a Token that is
> generated by a process every 10 minutes and that process is writing the
> token in the config file and reloading nginx regularly:
> 
> location / {
> proxy_set_headerAuthorization "PLAIN TEXT TOKEN WRITTEN BY PROCESS";
>  
> proxy_pass https://backend;
>  }
> 
> I would like to avoid having a token in plain text. Is there a way to avoid
> that?
> I though of the following options:
> - Use env var: But that is impossible nginx doesn't support it

NGINX does support environment variables, please see details
http://nginx.org/en/docs/ngx_core_module.html#env

> - Query the token by having the process establish a local server. Could work
> but how can the process return the result as a variable to nginx?

That probably depends on how a response looks like.  It's possible to
use NGINX JavaScript module to parse or modify a response.

> - Pass the config in memory instead of writing it to a file. Could be a
> simple option but I didn't find a way to do that.

Some tricks are available with NGINX Plus distribution because of the key-value
module, http://nginx.org/en/docs/http/ngx_http_keyval_module.html.

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

Plain text token in config!

2021-04-08 Thread bouvierh

Hello!

I currently use Nginx as a reverse proxy for my backend services. 

Nginx authenticates itself to the backend services using a Token that is
generated by a process every 10 minutes and that process is writing the
token in the config file and reloading nginx regularly:

location / {
proxy_set_headerAuthorization "PLAIN TEXT TOKEN WRITTEN BY PROCESS";
 
proxy_pass https://backend;
 }

I would like to avoid having a token in plain text. Is there a way to avoid
that?
I though of the following options:
- Use env var: But that is impossible nginx doesn't support it
- Query the token by having the process establish a local server. Could work
but how can the process return the result as a variable to nginx?
- Pass the config in memory instead of writing it to a file. Could be a
simple option but I didn't find a way to do that.

Do you have any idea how I can achieve that?

Thank you!
Hugues

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?2,291202,291202#msg-291202

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

Re: Alert: ignore long locked inactive cache entry

2021-04-08 Thread Sergey A. Osokin

Hi,

thanks for the report.

On Thu, Apr 08, 2021 at 11:37:19AM -0400, anish10dec wrote:
> Hi Team,
> 
> Intermittently there are multiple below errors reported in error.log file.
> 
> [alert] 41456#41456: ignore long locked inactive cache entry
> efcd5613750302a2657fca63c07fc777, count:1
> 
> This comes  momentarily with a spike of 50-90 K such errors in a minute time
> span. 
> 
> During this period server load and cpu utilization increases to Maximum
> dropping all the traffic with 0% Idle CPU and Load rising to more than 100.
> 
> This happens for 5 min after which server comes back into normal state.
> 
> Please help What causes this alert and how to avoid this scenario

Could you please share `nginx -V' output.  There was a fix long time ago,
with 1.1.16 for a similar issue.

Thank you.

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

Re: Nginx reload + Websockets

2021-04-08 Thread Maxim Dounin

Hello!

On Thu, Apr 08, 2021 at 03:28:25AM -0400, Vladislavik wrote:

> Добрый день, есть 200k websocket соединений на проксируемый сервер, после
> изменения в конфиге и попытке reload nginx появляются новые процессы nginx и
> зависают прошлые в статусе "nginx shutting down", которые так и не
> завершаются, тк клиенты могут висеть онлайн долго, эти старые процессы можно
> убить kill -9 pid каждый, но в этом случае nginx продолжает в /nginx_status
> показывать счетчик коннектов с учетом старых соединений из убитых процессов
> плюс заново переподключившиеся (количество коннектов после каждого reload
> растет в геометрической прогрессии), хотя в работе после kill старых nginx
> процессов остаются только новые процессы. Полностью сбросить счетчик
> коннектов получается только через restart nginx, но в этом случае все
> websocket клиенты одновременно начинают заново стучаться на сервер, чего
> тоже не хотелось бы, вопрос: как мягко применять новый конфиг nginx и
> переподключать websocket соединения хотя бы пачками, а не все одним
> моментом?

Самое простое и наиболее правильное решение - периодически 
переоткрывать соединения со стороны клиента и/или закрывать их со 
стороны websocket-сервера.  Такой подход, в частности, гарантирует 
отсутствие race'ов, если внутри websocket-соединений делается 
что-то неидемпотентное.  Это, однако, требуется реализовывать на 
клиенте и/или на стороне websocket-сервера.

Если этого не сделано, то существует ручка 
worker_shutdown_timeout, убивающая все оставшиеся соединения по 
истечении заданного таймаута.

Если при этом нужно ещё и убивать соединения плавно - можно это 
делать руками, то есть смотреть на списки соединений конкретных 
старых процессов и использовать tcpdrop(8).  Вроде бы даже на 
Линуксе сейчас доступен аналог.

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

Alert: ignore long locked inactive cache entry

2021-04-08 Thread anish10dec

Hi Team,

Intermittently there are multiple below errors reported in error.log file.

[alert] 41456#41456: ignore long locked inactive cache entry
efcd5613750302a2657fca63c07fc777, count:1

This comes  momentarily with a spike of 50-90 K such errors in a minute time
span. 

During this period server load and cpu utilization increases to Maximum
dropping all the traffic with 0% Idle CPU and Load rising to more than 100.

This happens for 5 min after which server comes back into normal state.

Please help What causes this alert and how to avoid this scenario

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?2,291199,291199#msg-291199

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

Re: init module callback called twice

2021-04-08 Thread Maxim Dounin

Hello!

On Thu, Apr 08, 2021 at 09:48:41AM -0400, xdrew wrote:

> Thanks Maxim, this makes perfect sense! However the part of the question
> still stands: is there a way from ngx_cycle_t structure or from some global
> structure to figure out in which mode nginx is running - testing the
> configuration or actually starting?

In most casses a properly written module shouldn't care.  If for 
some reason your module should, there is the ngx_test_config 
global variable which makes it possible to check if nginx is 
testing a configuration rather than parsing a new configuration 
when starting or reloading.

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

Re: Низкая скорость передачи данных при использовании https

2021-04-08 Thread Maxim Dounin

Hello!

On Thu, Apr 08, 2021 at 05:28:16PM +0600, raven...@megaline.kg wrote:

> Замечено, что по https отдача первого байта происходит на 200мс дольше.
> 
> 
> # curl -s -o /dev/null -w "Connect: %{time_connect} TTFB: 
> %{time_starttransfer} Total time: %{time_total} \n" 
> https:///robots.txt
> Connect: 0,101801 TTFB: 0,424129 Total time: 0,424269
> # curl -s -o /dev/null -w "Connect: %{time_connect} TTFB: 
> %{time_starttransfer} Total time: %{time_total} \n" 
> http:///robots.txt
> Connect: 0,099435 TTFB: 0,196609 Total time: 0,196732
> 
> 
> Для меня не новость, что SSL требует время для шифрования, но не 
> слишком-ли много? Ниже выдержки из конфига со всем, что касается SSL:

SSL - это не только затраты процессора на шифрование, но ещё и 
пара дополнительных round trip'ов на собственно SSL handshake.  С 
учётом того, что просто коннект у вас занимает 100ms - 
дополнительные 200ms на SSL handshake без кэширования сессий 
выглядят логично.

В случае TLSv1.3 в теории должно добавляться 1 RTT на handshake в 
типичном случае, но тут уже могут быть нюансы.  Во-первых, важна 
поддержка TLSv1.3 всеми сторонами, а во-вторых, важны настройки: 
можно свалиться в запрос HelloRetryRequest и соответственно 2 RTT.

Вот это вот у вас в конфиге:

> ssl_ecdh_curve    secp384r1;

в случае curl'а гарантировано приведёт к HelloRetryRequest и двум 
RTT, то есть к 200 миллисекундам задержки в вашем случае.  
Уберите это из конфига, и проверьте с "curl --tlsv1.3" - и 200 
миллисекунд должны подужаться до где-то 100.

Не надо менять ssl_ecdh_curve с auto на что либо другое без веских 
причин.  Остальные параметры SSL, впрочем, тоже не стоит крутить 
без нужды и понимания того, к чему это ведёт - даже если где-то в 
интернете рекомендуют.

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

Re: Nginx reload + Websockets

2021-04-08 Thread Alex Vorona


Привет,

4/8/21 12:41, Илья Шипицин wrote:

сокеты штатно убиваются через worker_shutdown_timeout


Добавить в worker_shutdown_timeout ещё random'ную часть и проблема 
одновременного выхода будет решена, что позволит растянуть вызванную 
релоадом нагрузку по времени.


Например, измененная директива
>worker_shutdown_timeout 600 300;

выключает воркера в диапазоне от 600 до 900 секунд с начала релоада.

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

Re: Низкая скорость передачи данных при использовании https

2021-04-08 Thread Evgeniy Berdnikov

On Thu, Apr 08, 2021 at 05:28:16PM +0600, raven...@megaline.kg wrote:
>Замечено, что по https отдача первого байта происходит на 200мс дольше.

 Сравнение
 ltrace -S -T -tt -fp 
 с дампом трафика может прояснить ситуацию.

 По величине задержки похоже на Нагель, хотя он должен быть выключен.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Низкая скорость передачи данных при использовании https

2021-04-08 Thread Константин Ткаченко

> 8 апр. 2021 г., в 15:55, Slawa Olhovchenkov  написал(а):
> 
> On Thu, Apr 08, 2021 at 03:48:38PM +0300, Константин Ткаченко wrote:
> 
 nginx 1.18.0, собран с OpenSSL 1.1.1c FIPS.

 Замечено, что по https отдача первого байта происходит на 200мс дольше.
>>> 
>>> а откуда идея что должно быть иначе?
>> 
>> Google активно пиарит, что первый байт должен быстро приходить вот и 
>> сеошники мучают админов.
> 
> покажи цитату из которой следует что первый байт в случае https должен
> приходить так же быстро или быстрее как в случае http.
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

Гугл топит за https. Без https он может пометить сайт как небезопасный и тогда 
все, приплыли. При этом, гугл говорит "Optimizing the server to do work like 
this as quickly as possible is one way to reduce the time that users spend 
waiting for pages to load."
https://web.dev/time-to-first-byte/ 
Хотя сейчас это вроде как устарело 
https://developers.google.com/speed/docs/insights/Server 
 , однако некоторые 
сеошники все еще требуют снижать этот показатель. С другой стороны он может 
влиять на все остальные, так как страница "долго" грузится.___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: init module callback called twice

2021-04-08 Thread xdrew

Thanks Maxim, this makes perfect sense! However the part of the question
still stands: is there a way from ngx_cycle_t structure or from some global
structure to figure out in which mode nginx is running - testing the
configuration or actually starting?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?2,291171,291194#msg-291194

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

Re: Низкая скорость передачи данных при использовании https

2021-04-08 Thread raven...@megaline.kg


08.04.2021 19:06, Slawa Olhovchenkov пишет:

On Thu, Apr 08, 2021 at 07:03:19PM +0600, raven...@megaline.kg wrote:


По поводу скорости - да, я возможно не совсем корректно охарактеризовал
суть в теме, каюсь. А какую смысловую нагрузку несет ваш выпад?)

08.04.2021 18:56, Slawa Olhovchenkov пишет:

On Thu, Apr 08, 2021 at 06:52:44PM +0600, raven...@megaline.kg wrote:

топквотинг



Сударь использует GPRS?)


такую, что в топквотинговой переписке я объяснений давать не буду

___
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

Re: init module callback called twice

2021-04-08 Thread Maxim Dounin

Hello!

On Thu, Apr 08, 2021 at 05:54:42AM -0400, xdrew wrote:

> Hello,
> 
> I'm developing a little custom module for nginx, and I need to execute some
> user code once my module is loaded. I do this by attaching to the hook in
> ngx_module_t structure:
> 
> ngx_module_t  ngx_http_hello_world_module = {
> ...
> NULL,  /* init master */
> init_module, /* init module */
> NULL,  /* init process */
> ...
> }
> 
> static ngx_int_t init_module(ngx_cycle_t *cycle) {
> ngx_log_stderr (0, "Initializing module") ; }
> 
> Surprisingly my callback is called twice. First time it follows log message
> 
> nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
> nginx: Initializing module
> 
> and then 
> 
> nginx: configuration file /etc/nginx/nginx.conf test is successful
> nginx: Initializing module
> 
> Is there a way to recognize that I'm called in some different context (e.g.
> some value from ngx_cycle_t structure)?
> Or may be I'm doing something completely wrong?

What you observe is perfectly expected: the module initialization 
callback is called once per configuration parsing, and your output 
seems to be from running a startup script which does something 
like "nginx -t; nginx", which starts nginx twice: once to test the 
configuration, and again to actually start nginx.

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

Re: Низкая скорость передачи данных при использовании https

2021-04-08 Thread Slawa Olhovchenkov

On Thu, Apr 08, 2021 at 07:03:19PM +0600, raven...@megaline.kg wrote:

> По поводу скорости - да, я возможно не совсем корректно охарактеризовал 
> суть в теме, каюсь. А какую смысловую нагрузку несет ваш выпад?)
> 
> 08.04.2021 18:56, Slawa Olhovchenkov пишет:
> > On Thu, Apr 08, 2021 at 06:52:44PM +0600, raven...@megaline.kg wrote:
> >
> > топквотинг
> >
> >
> Сударь использует GPRS?)
> 

такую, что в топквотинговой переписке я объяснений давать не буду

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

Re: Fwd: Capturing Encoded Location Variable Data

2021-04-08 Thread Maxim Dounin

Hello!

On Wed, Apr 07, 2021 at 05:16:20PM -0700, Demitrious Kelly wrote:

> Thanks very much.  It was not an easy thing to google to get 
> from symptom to bug report :) From the text in the ticket it 
> sounds like the named capture functions as intended and if this 
> bug gets fixed the numeric capture example will be made to work 
> the same as named does?

Yes.

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

Re: Низкая скорость передачи данных при использовании https

2021-04-08 Thread raven...@megaline.kg

По поводу скорости - да, я возможно не совсем корректно охарактеризовал 
суть в теме, каюсь. А какую смысловую нагрузку несет ваш выпад?)


08.04.2021 18:56, Slawa Olhovchenkov пишет:

On Thu, Apr 08, 2021 at 06:52:44PM +0600, raven...@megaline.kg wrote:

топквотинг



Сударь использует GPRS?)


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

Re: Низкая скорость передачи данных при использовании https

2021-04-08 Thread Slawa Olhovchenkov

On Thu, Apr 08, 2021 at 06:52:44PM +0600, raven...@megaline.kg wrote:

топквотинг

> Я не отрицаю, что ssl требует больше времени на шифрование. Но почему 
> оно более чем в 2 раза для ttfb?

не

> 08.04.2021 18:46, Slawa Olhovchenkov пишет:

надо

> > On Thu, Apr 08, 2021 at 05:28:16PM +0600, raven...@megaline.kg wrote:

использовать

> >> Доброго дня!
> >>
> >> nginx 1.18.0, собран с OpenSSL 1.1.1c FIPS.

и время до первого байта

> >> Замечено, что по https отдача первого байта происходит на 200мс дольше.
> > а откуда идея что должно быть иначе?
> > ___
> > 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
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Низкая скорость передачи данных при использовании https

2021-04-08 Thread Slawa Olhovchenkov

On Thu, Apr 08, 2021 at 03:48:38PM +0300, Константин Ткаченко wrote:

> >> nginx 1.18.0, собран с OpenSSL 1.1.1c FIPS.
> >> 
> >> Замечено, что по https отдача первого байта происходит на 200мс дольше.
> > 
> > а откуда идея что должно быть иначе?
> 
> Google активно пиарит, что первый байт должен быстро приходить вот и сеошники 
> мучают админов.

покажи цитату из которой следует что первый байт в случае https должен
приходить так же быстро или быстрее как в случае http.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Низкая скорость передачи данных при использовании https

2021-04-08 Thread raven...@megaline.kg

Я не отрицаю, что ssl требует больше времени на шифрование. Но почему 
оно более чем в 2 раза для ttfb?


08.04.2021 18:46, Slawa Olhovchenkov пишет:

On Thu, Apr 08, 2021 at 05:28:16PM +0600, raven...@megaline.kg wrote:


Доброго дня!

nginx 1.18.0, собран с OpenSSL 1.1.1c FIPS.

Замечено, что по https отдача первого байта происходит на 200мс дольше.

а откуда идея что должно быть иначе?
___
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

Re: Низкая скорость передачи данных при использовании https

2021-04-08 Thread Константин Ткаченко

> 8 апр. 2021 г., в 15:46, Slawa Olhovchenkov  написал(а):
> 
> On Thu, Apr 08, 2021 at 05:28:16PM +0600, raven...@megaline.kg wrote:
> 
>> Доброго дня!
>> 
>> nginx 1.18.0, собран с OpenSSL 1.1.1c FIPS.
>> 
>> Замечено, что по https отдача первого байта происходит на 200мс дольше.
> 
> а откуда идея что должно быть иначе?
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

Google активно пиарит, что первый байт должен быстро приходить вот и сеошники 
мучают админов.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Низкая скорость передачи данных при использовании https

2021-04-08 Thread Slawa Olhovchenkov

On Thu, Apr 08, 2021 at 05:28:16PM +0600, raven...@megaline.kg wrote:

> Доброго дня!
> 
> nginx 1.18.0, собран с OpenSSL 1.1.1c FIPS.
> 
> Замечено, что по https отдача первого байта происходит на 200мс дольше.

а откуда идея что должно быть иначе?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Низкая скорость передачи данных при использовании https

2021-04-08 Thread raven...@megaline.kg

Это я уже опробовал. Также пробовал сборку с патчем от Cloudflare 
(динамический размер записей TLS) с дефолтными настройками:


ssl_dyn_rec_enable    on;
ssl_dyn_rec_size_lo   1369;
ssl_dyn_rec_size_hi   4229;
ssl_dyn_rec_threshold 20;
ssl_dyn_rec_timeout   10;

получил даже небольшую регрессию)

08.04.2021 18:18, Константин Ткаченко пишет:



8 апр. 2021 г., в 15:04, Илья Шипицин > написал(а):


Действительно. Я проглядел

On Thu, Apr 8, 2021, 2:32 PM raven...@megaline.kg 
 > wrote:


Включен)
> ssl_stapling on;


08.04.2021 17:29, Илья Шипицин пишет:

Попробуйте stapling включить

On Thu, Apr 8, 2021, 2:28 PM raven...@megaline.kg
 mailto:raven...@megaline.kg>> wrote:

Доброго дня!

nginx 1.18.0, собран с OpenSSL 1.1.1c FIPS.

Замечено, что по https отдача первого байта происходит на
200мс дольше.


# curl -s -o /dev/null -w "Connect: %{time_connect} TTFB:
%{time_starttransfer} Total time: %{time_total} \n"
https:///robots.txt
Connect: 0,101801 TTFB: 0,424129 Total time: 0,424269
# curl -s -o /dev/null -w "Connect: %{time_connect} TTFB:
%{time_starttransfer} Total time: %{time_total} \n"
http:///robots.txt
Connect: 0,099435 TTFB: 0,196609 Total time: 0,196732


Для меня не новость, что SSL требует время для шифрования,
но не слишком-ли много? Ниже выдержки из конфига со всем,
что касается SSL:


ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

ssl_ciphers

ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA;

ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSLCache:16m;
ssl_session_timeout   10m;
ssl_session_tickets   off;
ssl_dhparam /etc/nginx/ssl/dh1024.pem;
ssl_ecdh_curve    secp384r1;
ssl_buffer_size   16k;

server {

listen :80 fastopen=256;

listen :443 fastopen=256 ssl; #http2

ssl_certificate_key /etc/nginx/ssl/.key;
ssl_certificate /etc/nginx/ssl/.pem;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/ssl/.pem;

...

}


___
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  




___
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


Можно уменьшить ssl_buffer_size до 4k;
Об этом в доках тоже есть
https://nginx.org/ru/docs/http/ngx_http_ssl_module.html#ssl_buffer_size 



___
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

Re: Низкая скорость передачи данных при использовании https

2021-04-08 Thread Константин Ткаченко



> 8 апр. 2021 г., в 15:04, Илья Шипицин  написал(а):
> 
> Действительно. Я проглядел
> 
> On Thu, Apr 8, 2021, 2:32 PM raven...@megaline.kg 
>   > wrote:
> Включен)
> > ssl_stapling on; 
> 
> 
> 08.04.2021 17:29, Илья Шипицин пишет:
>> Попробуйте stapling включить
>> 
>> On Thu, Apr 8, 2021, 2:28 PM raven...@megaline.kg 
>>  > > wrote:
>> Доброго дня!
>> 
>> nginx 1.18.0, собран с OpenSSL 1.1.1c FIPS. 
>> Замечено, что по https отдача первого байта происходит на 200мс дольше. 
>> 
>> # curl -s -o /dev/null -w "Connect: %{time_connect} TTFB: 
>> %{time_starttransfer} Total time: %{time_total} \n" 
>> https:///robots.txt
>> Connect: 0,101801 TTFB: 0,424129 Total time: 0,424269 
>> # curl -s -o /dev/null -w "Connect: %{time_connect} TTFB: 
>> %{time_starttransfer} Total time: %{time_total} \n" 
>> http:///robots.txt
>> Connect: 0,099435 TTFB: 0,196609 Total time: 0,196732 
>> 
>> Для меня не новость, что SSL требует время для шифрования, но не слишком-ли 
>> много? Ниже выдержки из конфига со всем, что касается SSL:
>> 
>> ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
>> 
>> ssl_ciphers   
>> ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA;
>> 
>> ssl_prefer_server_ciphers off;
>> ssl_session_cache shared:SSLCache:16m;
>> ssl_session_timeout   10m;
>> ssl_session_tickets   off;
>> ssl_dhparam   /etc/nginx/ssl/dh1024.pem;
>> ssl_ecdh_curvesecp384r1;
>> ssl_buffer_size   16k;
>> 
>> server {
>> 
>> listen :80 fastopen=256;
>> 
>> listen :443 fastopen=256 ssl; #http2
>> ssl_certificate_key /etc/nginx/ssl/.key;
>> ssl_certificate /etc/nginx/ssl/.pem;
>> ssl_stapling on;
>> ssl_stapling_verify on;
>> ssl_trusted_certificate /etc/nginx/ssl/.pem;
>> 
>> ...
>> }
>> 
>> ___
>> 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 
>> 
> ___
> 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

Можно уменьшить ssl_buffer_size до 4k; 
Об этом в доках тоже есть
https://nginx.org/ru/docs/http/ngx_http_ssl_module.html#ssl_buffer_size___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Низкая скорость передачи данных при использовании https

2021-04-08 Thread Илья Шипицин

Действительно. Я проглядел

On Thu, Apr 8, 2021, 2:32 PM raven...@megaline.kg 
wrote:

> Включен)
> > ssl_stapling on;
>
>
> 08.04.2021 17:29, Илья Шипицин пишет:
>
> Попробуйте stapling включить
>
> On Thu, Apr 8, 2021, 2:28 PM raven...@megaline.kg 
> wrote:
>
>> Доброго дня!
>>
>> nginx 1.18.0, собран с OpenSSL 1.1.1c FIPS.
>>
>> Замечено, что по https отдача первого байта происходит на 200мс дольше.
>>
>>
>> # curl -s -o /dev/null -w "Connect: %{time_connect} TTFB:
>> %{time_starttransfer} Total time: %{time_total} \n" https://
>> /robots.txt
>> Connect: 0,101801 TTFB: 0,424129 Total time: 0,424269
>> # curl -s -o /dev/null -w "Connect: %{time_connect} TTFB:
>> %{time_starttransfer} Total time: %{time_total} \n" http://
>> /robots.txt
>> Connect: 0,099435 TTFB: 0,196609 Total time: 0,196732
>>
>>
>> Для меня не новость, что SSL требует время для шифрования, но не
>> слишком-ли много? Ниже выдержки из конфига со всем, что касается SSL:
>>
>>
>> ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
>>
>> ssl_ciphers
>> ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA;
>>
>> ssl_prefer_server_ciphers off;
>> ssl_session_cache shared:SSLCache:16m;
>> ssl_session_timeout   10m;
>> ssl_session_tickets   off;
>> ssl_dhparam   /etc/nginx/ssl/dh1024.pem;
>> ssl_ecdh_curvesecp384r1;
>> ssl_buffer_size   16k;
>>
>> server {
>>
>> listen :80 fastopen=256;
>>
>> listen :443 fastopen=256 ssl; #http2
>>
>> ssl_certificate_key /etc/nginx/ssl/.key;
>> ssl_certificate /etc/nginx/ssl/.pem;
>> ssl_stapling on;
>> ssl_stapling_verify on;
>> ssl_trusted_certificate /etc/nginx/ssl/.pem;
>>
>> ...
>>
>> }
>>
>>
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
> ___
> nginx-ru mailing 
> listnginx-ru@nginx.orghttp://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
> ___
> 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

Re: Низкая скорость передачи данных при использовании https

2021-04-08 Thread raven...@megaline.kg


Включен)
> ssl_stapling on;


08.04.2021 17:29, Илья Шипицин пишет:

Попробуйте stapling включить

On Thu, Apr 8, 2021, 2:28 PM raven...@megaline.kg 
 > wrote:


Доброго дня!

nginx 1.18.0, собран с OpenSSL 1.1.1c FIPS.

Замечено, что по https отдача первого байта происходит на 200мс
дольше.


# curl -s -o /dev/null -w "Connect: %{time_connect} TTFB:
%{time_starttransfer} Total time: %{time_total} \n"
https:///robots.txt
Connect: 0,101801 TTFB: 0,424129 Total time: 0,424269
# curl -s -o /dev/null -w "Connect: %{time_connect} TTFB:
%{time_starttransfer} Total time: %{time_total} \n"
http:///robots.txt
Connect: 0,099435 TTFB: 0,196609 Total time: 0,196732


Для меня не новость, что SSL требует время для шифрования, но не
слишком-ли много? Ниже выдержки из конфига со всем, что касается SSL:


ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

ssl_ciphers

ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA;

ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSLCache:16m;
ssl_session_timeout   10m;
ssl_session_tickets   off;
ssl_dhparam   /etc/nginx/ssl/dh1024.pem;
ssl_ecdh_curve    secp384r1;
ssl_buffer_size   16k;

server {

listen :80 fastopen=256;

listen :443 fastopen=256 ssl; #http2

ssl_certificate_key /etc/nginx/ssl/.key;
ssl_certificate /etc/nginx/ssl/.pem;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/ssl/.pem;

...

}


___
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



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

Re: Низкая скорость передачи данных при использовании https

2021-04-08 Thread Илья Шипицин

Попробуйте stapling включить

On Thu, Apr 8, 2021, 2:28 PM raven...@megaline.kg 
wrote:

> Доброго дня!
>
> nginx 1.18.0, собран с OpenSSL 1.1.1c FIPS.
>
> Замечено, что по https отдача первого байта происходит на 200мс дольше.
>
>
> # curl -s -o /dev/null -w "Connect: %{time_connect} TTFB:
> %{time_starttransfer} Total time: %{time_total} \n" https://
> /robots.txt
> Connect: 0,101801 TTFB: 0,424129 Total time: 0,424269
> # curl -s -o /dev/null -w "Connect: %{time_connect} TTFB:
> %{time_starttransfer} Total time: %{time_total} \n" http://
> /robots.txt
> Connect: 0,099435 TTFB: 0,196609 Total time: 0,196732
>
>
> Для меня не новость, что SSL требует время для шифрования, но не
> слишком-ли много? Ниже выдержки из конфига со всем, что касается SSL:
>
>
> ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
>
> ssl_ciphers
> ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA;
>
> ssl_prefer_server_ciphers off;
> ssl_session_cache shared:SSLCache:16m;
> ssl_session_timeout   10m;
> ssl_session_tickets   off;
> ssl_dhparam   /etc/nginx/ssl/dh1024.pem;
> ssl_ecdh_curvesecp384r1;
> ssl_buffer_size   16k;
>
> server {
>
> listen :80 fastopen=256;
>
> listen :443 fastopen=256 ssl; #http2
>
> ssl_certificate_key /etc/nginx/ssl/.key;
> ssl_certificate /etc/nginx/ssl/.pem;
> ssl_stapling on;
> ssl_stapling_verify on;
> ssl_trusted_certificate /etc/nginx/ssl/.pem;
>
> ...
>
> }
>
>
> ___
> 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

Низкая скорость передачи данных при использовании https

2021-04-08 Thread raven...@megaline.kg


Доброго дня!

nginx 1.18.0, собран с OpenSSL 1.1.1c FIPS.

Замечено, что по https отдача первого байта происходит на 200мс дольше.


# curl -s -o /dev/null -w "Connect: %{time_connect} TTFB: 
%{time_starttransfer} Total time: %{time_total} \n" 
https:///robots.txt

Connect: 0,101801 TTFB: 0,424129 Total time: 0,424269
# curl -s -o /dev/null -w "Connect: %{time_connect} TTFB: 
%{time_starttransfer} Total time: %{time_total} \n" 
http:///robots.txt

Connect: 0,099435 TTFB: 0,196609 Total time: 0,196732


Для меня не новость, что SSL требует время для шифрования, но не 
слишком-ли много? Ниже выдержки из конфига со всем, что касается SSL:



   ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

   ssl_ciphers
   
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA;

   ssl_prefer_server_ciphers off;
   ssl_session_cache shared:SSLCache:16m;
   ssl_session_timeout   10m;
   ssl_session_tickets   off;
   ssl_dhparam   /etc/nginx/ssl/dh1024.pem;
   ssl_ecdh_curve    secp384r1;
   ssl_buffer_size   16k;

   server {

   listen :80 fastopen=256;

   listen :443 fastopen=256 ssl; #http2

   ssl_certificate_key /etc/nginx/ssl/.key;
   ssl_certificate /etc/nginx/ssl/.pem;
   ssl_stapling on;
   ssl_stapling_verify on;
   ssl_trusted_certificate /etc/nginx/ssl/.pem;

   ...

   }


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

Re: Nginx reload + Websockets

2021-04-08 Thread Илья Шипицин

Штормы цпу на релоаде это известная штука на самом деле. Будет круто, если
на уровне nginx inc этим заинтересуются

По количеству хендшейков и сьютам можно совместно поднять стенд и собрать
цифры для разных процов

Про то, что на ovh ещё антиддос срабатывает, это мило. Не сталкивался, но
думаю, вопрос времени

On Thu, Apr 8, 2021, 1:02 PM Andrei Belov  wrote:

>
> > On 8 Apr 2021, at 12:49, Илья Шипицин  wrote:
> >
> > ну попрут и попрут. а что делать ?
> >
> >
> > насколько я понимаю, штатно предполагается в том или ином виде
> abbrevated handshake (либо tls tickets, либо ssl sessions).
> > но гибкости в управлении этой штукой нет. можно сконфигурировать
> персистентный на диске, тогда переживете релоад, но сессии будут вечные.
> > безопасники обычно говорят, что лучше, чтобы при релоаде сессии и тикеты
> сбрасывались, но в этом случае вас 300к пользователей расстреляют на full
> handshake.
> >
> > мы замеряли, Xeon держит в районе 700-1000 хендшейков в 1 сек на 1 ядро.
> это если полные хендшейки.
>
> А какой конкретно xeon, не пропомните?
>
>
> ___
> 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

Re: Nginx reload + Websockets

2021-04-08 Thread Илья Шипицин

Какой-то из ходовых. Отличаются размером кеша, который в данном случае
никак не играет.

Что играет роль, это шифрсьют. На современных pfs сьютах за счёт ecdhe все
и проседает. ecdhe занимает 95% процессора и это сугубо вычислительная
нагрузка

Я делал таким образом, брал самые ходовые сьюты на tls1.2 и tls1.3, собирал
стенд, на котором ограничивал число воркеров единицей. Оставлял ровно один
сьют и стрелял полными хендшейками

On Thu, Apr 8, 2021, 1:02 PM Andrei Belov  wrote:

>
> > On 8 Apr 2021, at 12:49, Илья Шипицин  wrote:
> >
> > ну попрут и попрут. а что делать ?
> >
> >
> > насколько я понимаю, штатно предполагается в том или ином виде
> abbrevated handshake (либо tls tickets, либо ssl sessions).
> > но гибкости в управлении этой штукой нет. можно сконфигурировать
> персистентный на диске, тогда переживете релоад, но сессии будут вечные.
> > безопасники обычно говорят, что лучше, чтобы при релоаде сессии и тикеты
> сбрасывались, но в этом случае вас 300к пользователей расстреляют на full
> handshake.
> >
> > мы замеряли, Xeon держит в районе 700-1000 хендшейков в 1 сек на 1 ядро.
> это если полные хендшейки.
>
> А какой конкретно xeon, не пропомните?
>
>
> ___
> 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

Re: Nginx reload + Websockets

2021-04-08 Thread Илья Шипицин

Гипотетически, немного поможет, если тайм-аут сделать побольше. По крайней
мере http ( не вебсокеты) успеют доработать и аккуратно завершиться
(убийство воркеров их рвет). То, что на дистанции 30 мин какие-то вебсокеты
умрут и переподключатся (к новым воркерам), я бы сказал, что в районе
погрешности. Сокеты очень живучи

On Thu, Apr 8, 2021, 12:56 PM Vl T  wrote:

> У ovh при реконекте 200к-300к websocket клиентов включается antiddos, и то
> время, пока он включен к серверу не могут достучаться другие сервисы. (Пока
> websocket клиенты мучают сервер подключениями - другие сервисы отваливаются
> из за antiddos) Поэтому хотелось бы плавно эти websocket переподключать
> как-то.
>
> Чт, 8 апр. 2021 г. в 12:50, Илья Шипицин :
>
>> ну попрут и попрут. а что делать ?
>>
>>
>> насколько я понимаю, штатно предполагается в том или ином виде
>> abbrevated handshake (либо tls tickets, либо ssl sessions).
>> но гибкости в управлении этой штукой нет. можно сконфигурировать
>> персистентный на диске, тогда переживете релоад, но сессии будут вечные.
>> безопасники обычно говорят, что лучше, чтобы при релоаде сессии и тикеты
>> сбрасывались, но в этом случае вас 300к пользователей расстреляют на full
>> handshake.
>>
>> мы замеряли, Xeon держит в районе 700-1000 хендшейков в 1 сек на 1 ядро.
>> это если полные хендшейки.
>>
>>
>> кажется, было бы совсем по хорошему, чтобы сессии переживали релоад, но
>> можно было бы указать время жизни сессии. и безопасники оргазмировали бы, и
>> расстрелов на релоаде бы не было.
>>
>> если я что-то упустил, и так настроить можно, буду рад ошибиться
>>
>>
>> чт, 8 апр. 2021 г. в 14:45, Vl T :
>>
>>> Nginx последний, 1.19.9, worker_shutdown_timeout не установлен,
>>> установить его? В принципе если установить 5 минут - то через 5 минут все
>>> 300к клиентов все равно попрут толпой на сервер?
>>>
>>> Чт, 8 апр. 2021 г. в 12:41, Илья Шипицин :
>>>
 сокеты штатно убиваются через worker_shutdown_timeout

 второй вопрос - какая у вас версия nginx ? где-то в районе 3-4 летней
 давности был баг, который приводил к тому, что несмотря на указанный
 worker_shutdown_timeout, воркеры все равно не останавливались

 чт, 8 апр. 2021 г. в 12:28, Vladislavik :

> Добрый день, есть 200k websocket соединений на проксируемый сервер,
> после
> изменения в конфиге и попытке reload nginx появляются новые процессы
> nginx и
> зависают прошлые в статусе "nginx shutting down", которые так и не
> завершаются, тк клиенты могут висеть онлайн долго, эти старые процессы
> можно
> убить kill -9 pid каждый, но в этом случае nginx продолжает в
> /nginx_status
> показывать счетчик коннектов с учетом старых соединений из убитых
> процессов
> плюс заново переподключившиеся (количество коннектов после каждого
> reload
> растет в геометрической прогрессии), хотя в работе после kill старых
> nginx
> процессов остаются только новые процессы. Полностью сбросить счетчик
> коннектов получается только через restart nginx, но в этом случае все
> websocket клиенты одновременно начинают заново стучаться на сервер,
> чего
> тоже не хотелось бы, вопрос: как мягко применять новый конфиг nginx и
> переподключать websocket соединения хотя бы пачками, а не все одним
> моментом?
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,291167,291167#msg-291167
>
> ___
> 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
>>>
>>> --
>>>
>>> С уважением Толмачев Владислав.
>>> tolmachev.v...@gmail.com
>>> skype: vladislaviki
>>> ___
>>> 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
>
> --
>
> С уважением Толмачев Владислав.
> tolmachev.v...@gmail.com
> skype: vladislaviki
> ___
> 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

Re: Nginx reload + Websockets

2021-04-08 Thread Andrei Belov


> On 8 Apr 2021, at 12:49, Илья Шипицин  wrote:
> 
> ну попрут и попрут. а что делать ?
> 
> 
> насколько я понимаю, штатно предполагается в том или ином виде abbrevated 
> handshake (либо tls tickets, либо ssl sessions).
> но гибкости в управлении этой штукой нет. можно сконфигурировать 
> персистентный на диске, тогда переживете релоад, но сессии будут вечные.
> безопасники обычно говорят, что лучше, чтобы при релоаде сессии и тикеты 
> сбрасывались, но в этом случае вас 300к пользователей расстреляют на full 
> handshake.
> 
> мы замеряли, Xeon держит в районе 700-1000 хендшейков в 1 сек на 1 ядро. это 
> если полные хендшейки.

А какой конкретно xeon, не пропомните?


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

Re: Nginx reload + Websockets

2021-04-08 Thread Vl T

У ovh при реконекте 200к-300к websocket клиентов включается antiddos, и то
время, пока он включен к серверу не могут достучаться другие сервисы. (Пока
websocket клиенты мучают сервер подключениями - другие сервисы отваливаются
из за antiddos) Поэтому хотелось бы плавно эти websocket переподключать
как-то.

Чт, 8 апр. 2021 г. в 12:50, Илья Шипицин :

> ну попрут и попрут. а что делать ?
>
>
> насколько я понимаю, штатно предполагается в том или ином виде
> abbrevated handshake (либо tls tickets, либо ssl sessions).
> но гибкости в управлении этой штукой нет. можно сконфигурировать
> персистентный на диске, тогда переживете релоад, но сессии будут вечные.
> безопасники обычно говорят, что лучше, чтобы при релоаде сессии и тикеты
> сбрасывались, но в этом случае вас 300к пользователей расстреляют на full
> handshake.
>
> мы замеряли, Xeon держит в районе 700-1000 хендшейков в 1 сек на 1 ядро.
> это если полные хендшейки.
>
>
> кажется, было бы совсем по хорошему, чтобы сессии переживали релоад, но
> можно было бы указать время жизни сессии. и безопасники оргазмировали бы, и
> расстрелов на релоаде бы не было.
>
> если я что-то упустил, и так настроить можно, буду рад ошибиться
>
>
> чт, 8 апр. 2021 г. в 14:45, Vl T :
>
>> Nginx последний, 1.19.9, worker_shutdown_timeout не установлен,
>> установить его? В принципе если установить 5 минут - то через 5 минут все
>> 300к клиентов все равно попрут толпой на сервер?
>>
>> Чт, 8 апр. 2021 г. в 12:41, Илья Шипицин :
>>
>>> сокеты штатно убиваются через worker_shutdown_timeout
>>>
>>> второй вопрос - какая у вас версия nginx ? где-то в районе 3-4 летней
>>> давности был баг, который приводил к тому, что несмотря на указанный
>>> worker_shutdown_timeout, воркеры все равно не останавливались
>>>
>>> чт, 8 апр. 2021 г. в 12:28, Vladislavik :
>>>
 Добрый день, есть 200k websocket соединений на проксируемый сервер,
 после
 изменения в конфиге и попытке reload nginx появляются новые процессы
 nginx и
 зависают прошлые в статусе "nginx shutting down", которые так и не
 завершаются, тк клиенты могут висеть онлайн долго, эти старые процессы
 можно
 убить kill -9 pid каждый, но в этом случае nginx продолжает в
 /nginx_status
 показывать счетчик коннектов с учетом старых соединений из убитых
 процессов
 плюс заново переподключившиеся (количество коннектов после каждого
 reload
 растет в геометрической прогрессии), хотя в работе после kill старых
 nginx
 процессов остаются только новые процессы. Полностью сбросить счетчик
 коннектов получается только через restart nginx, но в этом случае все
 websocket клиенты одновременно начинают заново стучаться на сервер, чего
 тоже не хотелось бы, вопрос: как мягко применять новый конфиг nginx и
 переподключать websocket соединения хотя бы пачками, а не все одним
 моментом?

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

 ___
 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
>>
>> --
>>
>> С уважением Толмачев Владислав.
>> tolmachev.v...@gmail.com
>> skype: vladislaviki
>> ___
>> 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

-- 

С уважением Толмачев Владислав.
tolmachev.v...@gmail.com
skype: vladislaviki
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

init module callback called twice

2021-04-08 Thread xdrew

Hello,

I'm developing a little custom module for nginx, and I need to execute some
user code once my module is loaded. I do this by attaching to the hook in
ngx_module_t structure:

ngx_module_t  ngx_http_hello_world_module = {
...
NULL,  /* init master */
init_module, /* init module */
NULL,  /* init process */
...
}

static ngx_int_t init_module(ngx_cycle_t *cycle) {
ngx_log_stderr (0, "Initializing module") ; }

Surprisingly my callback is called twice. First time it follows log message

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: Initializing module

and then 

nginx: configuration file /etc/nginx/nginx.conf test is successful
nginx: Initializing module

Is there a way to recognize that I'm called in some different context (e.g.
some value from ngx_cycle_t structure)?
Or may be I'm doing something completely wrong?

Thanks
Andrew

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?2,291171,291171#msg-291171

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

Re: Nginx reload + Websockets

2021-04-08 Thread Илья Шипицин

ну попрут и попрут. а что делать ?


насколько я понимаю, штатно предполагается в том или ином виде
abbrevated handshake (либо tls tickets, либо ssl sessions).
но гибкости в управлении этой штукой нет. можно сконфигурировать
персистентный на диске, тогда переживете релоад, но сессии будут вечные.
безопасники обычно говорят, что лучше, чтобы при релоаде сессии и тикеты
сбрасывались, но в этом случае вас 300к пользователей расстреляют на full
handshake.

мы замеряли, Xeon держит в районе 700-1000 хендшейков в 1 сек на 1 ядро.
это если полные хендшейки.


кажется, было бы совсем по хорошему, чтобы сессии переживали релоад, но
можно было бы указать время жизни сессии. и безопасники оргазмировали бы, и
расстрелов на релоаде бы не было.

если я что-то упустил, и так настроить можно, буду рад ошибиться


чт, 8 апр. 2021 г. в 14:45, Vl T :

> Nginx последний, 1.19.9, worker_shutdown_timeout не установлен,
> установить его? В принципе если установить 5 минут - то через 5 минут все
> 300к клиентов все равно попрут толпой на сервер?
>
> Чт, 8 апр. 2021 г. в 12:41, Илья Шипицин :
>
>> сокеты штатно убиваются через worker_shutdown_timeout
>>
>> второй вопрос - какая у вас версия nginx ? где-то в районе 3-4 летней
>> давности был баг, который приводил к тому, что несмотря на указанный
>> worker_shutdown_timeout, воркеры все равно не останавливались
>>
>> чт, 8 апр. 2021 г. в 12:28, Vladislavik :
>>
>>> Добрый день, есть 200k websocket соединений на проксируемый сервер, после
>>> изменения в конфиге и попытке reload nginx появляются новые процессы
>>> nginx и
>>> зависают прошлые в статусе "nginx shutting down", которые так и не
>>> завершаются, тк клиенты могут висеть онлайн долго, эти старые процессы
>>> можно
>>> убить kill -9 pid каждый, но в этом случае nginx продолжает в
>>> /nginx_status
>>> показывать счетчик коннектов с учетом старых соединений из убитых
>>> процессов
>>> плюс заново переподключившиеся (количество коннектов после каждого reload
>>> растет в геометрической прогрессии), хотя в работе после kill старых
>>> nginx
>>> процессов остаются только новые процессы. Полностью сбросить счетчик
>>> коннектов получается только через restart nginx, но в этом случае все
>>> websocket клиенты одновременно начинают заново стучаться на сервер, чего
>>> тоже не хотелось бы, вопрос: как мягко применять новый конфиг nginx и
>>> переподключать websocket соединения хотя бы пачками, а не все одним
>>> моментом?
>>>
>>> Posted at Nginx Forum:
>>> https://forum.nginx.org/read.php?21,291167,291167#msg-291167
>>>
>>> ___
>>> 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
>
> --
>
> С уважением Толмачев Владислав.
> tolmachev.v...@gmail.com
> skype: vladislaviki
> ___
> 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

Re: Nginx reload + Websockets

2021-04-08 Thread Vl T

Nginx последний, 1.19.9, worker_shutdown_timeout не установлен, установить
его? В принципе если установить 5 минут - то через 5 минут все 300к
клиентов все равно попрут толпой на сервер?

Чт, 8 апр. 2021 г. в 12:41, Илья Шипицин :

> сокеты штатно убиваются через worker_shutdown_timeout
>
> второй вопрос - какая у вас версия nginx ? где-то в районе 3-4 летней
> давности был баг, который приводил к тому, что несмотря на указанный
> worker_shutdown_timeout, воркеры все равно не останавливались
>
> чт, 8 апр. 2021 г. в 12:28, Vladislavik :
>
>> Добрый день, есть 200k websocket соединений на проксируемый сервер, после
>> изменения в конфиге и попытке reload nginx появляются новые процессы
>> nginx и
>> зависают прошлые в статусе "nginx shutting down", которые так и не
>> завершаются, тк клиенты могут висеть онлайн долго, эти старые процессы
>> можно
>> убить kill -9 pid каждый, но в этом случае nginx продолжает в
>> /nginx_status
>> показывать счетчик коннектов с учетом старых соединений из убитых
>> процессов
>> плюс заново переподключившиеся (количество коннектов после каждого reload
>> растет в геометрической прогрессии), хотя в работе после kill старых nginx
>> процессов остаются только новые процессы. Полностью сбросить счетчик
>> коннектов получается только через restart nginx, но в этом случае все
>> websocket клиенты одновременно начинают заново стучаться на сервер, чего
>> тоже не хотелось бы, вопрос: как мягко применять новый конфиг nginx и
>> переподключать websocket соединения хотя бы пачками, а не все одним
>> моментом?
>>
>> Posted at Nginx Forum:
>> https://forum.nginx.org/read.php?21,291167,291167#msg-291167
>>
>> ___
>> 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

-- 

С уважением Толмачев Владислав.
tolmachev.v...@gmail.com
skype: vladislaviki
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Nginx reload + Websockets

2021-04-08 Thread Илья Шипицин

сокеты штатно убиваются через worker_shutdown_timeout

второй вопрос - какая у вас версия nginx ? где-то в районе 3-4 летней
давности был баг, который приводил к тому, что несмотря на указанный
worker_shutdown_timeout, воркеры все равно не останавливались

чт, 8 апр. 2021 г. в 12:28, Vladislavik :

> Добрый день, есть 200k websocket соединений на проксируемый сервер, после
> изменения в конфиге и попытке reload nginx появляются новые процессы nginx
> и
> зависают прошлые в статусе "nginx shutting down", которые так и не
> завершаются, тк клиенты могут висеть онлайн долго, эти старые процессы
> можно
> убить kill -9 pid каждый, но в этом случае nginx продолжает в /nginx_status
> показывать счетчик коннектов с учетом старых соединений из убитых процессов
> плюс заново переподключившиеся (количество коннектов после каждого reload
> растет в геометрической прогрессии), хотя в работе после kill старых nginx
> процессов остаются только новые процессы. Полностью сбросить счетчик
> коннектов получается только через restart nginx, но в этом случае все
> websocket клиенты одновременно начинают заново стучаться на сервер, чего
> тоже не хотелось бы, вопрос: как мягко применять новый конфиг nginx и
> переподключать websocket соединения хотя бы пачками, а не все одним
> моментом?
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,291167,291167#msg-291167
>
> ___
> 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

Nginx reload + Websockets

2021-04-08 Thread Vladislavik

Добрый день, есть 200k websocket соединений на проксируемый сервер, после
изменения в конфиге и попытке reload nginx появляются новые процессы nginx и
зависают прошлые в статусе "nginx shutting down", которые так и не
завершаются, тк клиенты могут висеть онлайн долго, эти старые процессы можно
убить kill -9 pid каждый, но в этом случае nginx продолжает в /nginx_status
показывать счетчик коннектов с учетом старых соединений из убитых процессов
плюс заново переподключившиеся (количество коннектов после каждого reload
растет в геометрической прогрессии), хотя в работе после kill старых nginx
процессов остаются только новые процессы. Полностью сбросить счетчик
коннектов получается только через restart nginx, но в этом случае все
websocket клиенты одновременно начинают заново стучаться на сервер, чего
тоже не хотелось бы, вопрос: как мягко применять новый конфиг nginx и
переподключать websocket соединения хотя бы пачками, а не все одним
моментом?

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

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

39 matches

Mail list logo