From raven_kg на megaline.kg Thu Apr 1 01:53:38 2021 From: raven_kg на megaline.kg (raven_kg на megaline.kg) Date: Thu, 1 Apr 2021 07:53:38 +0600 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQuCDQv9GA0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC4?= =?UTF-8?B?0LggemxpYi1uZw==?= In-Reply-To: <423129039.20210331231816@gmail.com> References: <1786ca22a6e.dea7d9441099487.8984595071426552062@dl.sm.ua> <6e9699c4-acf4-62ca-0837-a94052e53b81@megaline.kg> <06D2F14C-EC83-4F68-90BF-233C36E6D4FF@nginx.com> <03f8371d-280f-2c7a-ca1b-a3e31d17b6d3@megaline.kg> <423129039.20210331231816@gmail.com> Message-ID: <7204fd6d-ff23-d518-dc6c-22d18b47cb9d@megaline.kg> В одном из предыдущих сообщений есть ссылка на патч, подключающий zlib-ng, собранную без совмесимости с zlib 01.04.2021 02:18, izorkin на gmail.com пишет: > Здравствуйте, Maxim. > > Если в сборке zlib-ng отключить совместимость с zlib, то nginx не видит zlib-ng и собирается с zlib 1.2.11. > Или эти патчи работают только в режиме совместимости с zlib? > > Вы писали 29 марта 2021 г., 16:19:47: > >> Hello! >> On Mon, Mar 29, 2021 at 01:00:21PM +0600, raven_kg на megaline.kg wrote: >> [...] >>> Будут-ли эти правки включены в какой-либо из релизов? >> Да, как только пройдут review. > From izorkin на gmail.com Thu Apr 1 06:48:19 2021 From: izorkin на gmail.com (izorkin на gmail.com) Date: Thu, 1 Apr 2021 09:48:19 +0300 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQuCDQv9GA0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC4?= =?UTF-8?B?0LggemxpYi1uZw==?= In-Reply-To: <7204fd6d-ff23-d518-dc6c-22d18b47cb9d@megaline.kg> References: <1786ca22a6e.dea7d9441099487.8984595071426552062@dl.sm.ua> <6e9699c4-acf4-62ca-0837-a94052e53b81@megaline.kg> <06D2F14C-EC83-4F68-90BF-233C36E6D4FF@nginx.com> <03f8371d-280f-2c7a-ca1b-a3e31d17b6d3@megaline.kg> <423129039.20210331231816@gmail.com> <7204fd6d-ff23-d518-dc6c-22d18b47cb9d@megaline.kg> Message-ID: <1688554075.20210401094819@gmail.com> Здравствуйте, raven. Если вы про эту ссылку - https://github.com/zlib-ng/patches/tree/master/nginx , то там неправильные размеры выделяемой памяти. Я сам не знаю, какие там параметры надо исправить. Вы писали 1 апреля 2021 г., 4:53:38: > В одном из предыдущих сообщений есть ссылка на патч, подключающий zlib-ng, собранную без совмесимости с zlib -- С уважением, Izorkin mailto:izorkin на gmail.com From nginx-forum на forum.nginx.org Thu Apr 1 09:19:47 2021 From: nginx-forum на forum.nginx.org (budarin) Date: Thu, 01 Apr 2021 05:19:47 -0400 Subject: =?UTF-8?B?UmU6INCg0LDQt9C90YvQuSDQutC+0L3RgtC10L3RgiDQtNC70Y8g0L/QvtC70Yw=?= =?UTF-8?B?0LfQvtCy0LDRgtC10LvQtdC5INGA0LDQt9C90YvRhSDRgdC10YLQtdC5?= In-Reply-To: References: Message-ID: <3a5f5cbd49c7ddade58c3081e0e2eafb.NginxMailingListRussian@forum.nginx.org> одно поправилось - другое отвалилось ( теперь не резолвится 'host.docker.internal' set $local 'host.docker.internal'; location ~ ^/api/(.*)$ { proxy_pass http://$local:5005/$1; } теперь отваливается с ошибкой: 335#335: *60 no resolver defined to resolve host.docker.internal Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291116,291130#msg-291130 From nginx-forum на forum.nginx.org Thu Apr 1 09:25:17 2021 From: nginx-forum на forum.nginx.org (budarin) Date: Thu, 01 Apr 2021 05:25:17 -0400 Subject: =?UTF-8?B?UmU6INCg0LDQt9C90YvQuSDQutC+0L3RgtC10L3RgiDQtNC70Y8g0L/QvtC70Yw=?= =?UTF-8?B?0LfQvtCy0LDRgtC10LvQtdC5INGA0LDQt9C90YvRhSDRgdC10YLQtdC5?= In-Reply-To: <3a5f5cbd49c7ddade58c3081e0e2eafb.NginxMailingListRussian@forum.nginx.org> References: <3a5f5cbd49c7ddade58c3081e0e2eafb.NginxMailingListRussian@forum.nginx.org> Message-ID: <93d65acaa240a07d1b36002b51d3f7f8.NginxMailingListRussian@forum.nginx.org> решил - нужно было настроить резолвер докера resolver 127.0.0.11 ipv6=off valid=5s; resolver_timeout 5s; Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291116,291131#msg-291131 From red-fox0 на ya.ru Thu Apr 1 09:30:34 2021 From: red-fox0 на ya.ru (fox) Date: Thu, 1 Apr 2021 16:30:34 +0700 Subject: =?UTF-8?B?UmU6INCd0LUg0YPQtNCw0LXRgtGB0Y8g0L/QvtC00LzQtdC90LjRgtGMINC+0Yg=?= =?UTF-8?B?0LjQsdC60Lgg0YHQstC+0LjQvNC4INGB0YLRgNCw0L3QuNGG0LDQvNC4?= In-Reply-To: <885638feaa433b22bca431c55559b3c3.NginxMailingListRussian@forum.nginx.org> References: <885638feaa433b22bca431c55559b3c3.NginxMailingListRussian@forum.nginx.org> Message-ID: <550b729e-39f3-7657-5119-f9a561e0bce3@ya.ru> Уберите эту строку: > root /var/www; 01.04.2021 04:09, budarin пишет: > В папке /var/www лежат файлы > 404.html > 502.html > 503.html > 500.html > > остальные ресурсы лежат в папке /var/www/web > > работающий конфиг: > > http { > > upstream web_app { > least_conn; > server 10.0.1.43:3000; > } > > server { > listen 443; > listen 443 ssl; > server_name localhost; > > root /var/www/web; > > error_page 404 /404.html; > error_page 502 504 /502.html; > error_page 503 /503.html; > error_page 500 501 504 /500.html; > > location ~ [4-5][0-9][0-9].html > { > internal; > root /var/www; > include /etc/nginx/config/disable/access_logs.conf; > } > > location / { > proxy_pass http://web_app; > } > > location ~* \.(?:html|css|js)$ { > etag on; > sendfile on; > tcp_nopush on; > tcp_nodelay on; > add_header Cache-Control "public"; > } > } > > удаляю из конфига описание upstream и жду что вместо стандартного ответа на > клиенте я получу кастомную страницу, но получаю стандартный ответ 404 > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291126,291126#msg-291126 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From chipitsine на gmail.com Thu Apr 1 09:31:51 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 1 Apr 2021 14:31:51 +0500 Subject: =?UTF-8?B?UmU6INCg0LDQt9C90YvQuSDQutC+0L3RgtC10L3RgiDQtNC70Y8g0L/QvtC70Yw=?= =?UTF-8?B?0LfQvtCy0LDRgtC10LvQtdC5INGA0LDQt9C90YvRhSDRgdC10YLQtdC5?= In-Reply-To: <93d65acaa240a07d1b36002b51d3f7f8.NginxMailingListRussian@forum.nginx.org> References: <3a5f5cbd49c7ddade58c3081e0e2eafb.NginxMailingListRussian@forum.nginx.org> <93d65acaa240a07d1b36002b51d3f7f8.NginxMailingListRussian@forum.nginx.org> Message-ID: одни проблемы с докером. чт, 1 апр. 2021 г. в 14:25, budarin : > решил - нужно было настроить резолвер докера > > resolver 127.0.0.11 ipv6=off valid=5s; > resolver_timeout 5s; > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,291116,291131#msg-291131 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Thu Apr 1 13:59:23 2021 From: nginx-forum на forum.nginx.org (budarin) Date: Thu, 01 Apr 2021 09:59:23 -0400 Subject: =?UTF-8?B?UmU6INCd0LUg0YPQtNCw0LXRgtGB0Y8g0L/QvtC00LzQtdC90LjRgtGMINC+0Yg=?= =?UTF-8?B?0LjQsdC60Lgg0YHQstC+0LjQvNC4INGB0YLRgNCw0L3QuNGG0LDQvNC4?= In-Reply-To: <550b729e-39f3-7657-5119-f9a561e0bce3@ya.ru> References: <550b729e-39f3-7657-5119-f9a561e0bce3@ya.ru> Message-ID: не помогает ( Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291126,291134#msg-291134 From nginx-forum на forum.nginx.org Thu Apr 1 14:10:37 2021 From: nginx-forum на forum.nginx.org (budarin) Date: Thu, 01 Apr 2021 10:10:37 -0400 Subject: =?UTF-8?B?UmU6INCd0LUg0YPQtNCw0LXRgtGB0Y8g0L/QvtC00LzQtdC90LjRgtGMINC+0Yg=?= =?UTF-8?B?0LjQsdC60Lgg0YHQstC+0LjQvNC4INGB0YLRgNCw0L3QuNGG0LDQvNC4?= In-Reply-To: <550b729e-39f3-7657-5119-f9a561e0bce3@ya.ru> References: <550b729e-39f3-7657-5119-f9a561e0bce3@ya.ru> Message-ID: <071e4234b6c6bdc9f97008b82cdf7228.NginxMailingListRussian@forum.nginx.org> там root /var/www нужен для location потому что выше определен root /var/www/web - иначе nginx будет искать .html по пути /var/www/web, но они то лежат в /var/www Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291126,291135#msg-291135 From mdounin на mdounin.ru Thu Apr 1 16:38:57 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 1 Apr 2021 19:38:57 +0300 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQuCDQv9GA0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC4?= =?UTF-8?B?0LggemxpYi1uZw==?= In-Reply-To: <423129039.20210331231816@gmail.com> References: <1786ca22a6e.dea7d9441099487.8984595071426552062@dl.sm.ua> <6e9699c4-acf4-62ca-0837-a94052e53b81@megaline.kg> <06D2F14C-EC83-4F68-90BF-233C36E6D4FF@nginx.com> <03f8371d-280f-2c7a-ca1b-a3e31d17b6d3@megaline.kg> <423129039.20210331231816@gmail.com> Message-ID: Hello! On Wed, Mar 31, 2021 at 11:18:16PM +0300, izorkin на gmail.com wrote: > Если в сборке zlib-ng отключить совместимость с zlib, то nginx > не видит zlib-ng и собирается с zlib 1.2.11. > Или эти патчи работают только в режиме совместимости с zlib? Да, nginx умеет работать только с zlib, и если zlib-ng собирать без совместимости с zlib, то nginx его не увидит, это ожидаемое поведение. Не отключайте совместимость, если хотите использовать zlib-ng с nginx'ом. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Thu Apr 1 20:02:20 2021 From: nginx-forum на forum.nginx.org (budarin) Date: Thu, 01 Apr 2021 16:02:20 -0400 Subject: =?UTF-8?B?UmU6INCd0LUg0YPQtNCw0LXRgtGB0Y8g0L/QvtC00LzQtdC90LjRgtGMINC+0Yg=?= =?UTF-8?B?0LjQsdC60Lgg0YHQstC+0LjQvNC4INGB0YLRgNCw0L3QuNGG0LDQvNC4?= In-Reply-To: <550b729e-39f3-7657-5119-f9a561e0bce3@ya.ru> References: <550b729e-39f3-7657-5119-f9a561e0bce3@ya.ru> Message-ID: <0d2a4c4ae3740f4f08c342f172bb5d32.NginxMailingListRussian@forum.nginx.org> коллеги, уже весь интернет перечитал - не могу решить проблему, помогите пожалуйста! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291126,291137#msg-291137 From bgx на protva.ru Thu Apr 1 20:34:21 2021 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Thu, 1 Apr 2021 23:34:21 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0YPQtNCw0LXRgtGB0Y8g0L/QvtC00LzQtdC90LjRgtGMINC+0Yg=?= =?UTF-8?B?0LjQsdC60Lgg0YHQstC+0LjQvNC4INGB0YLRgNCw0L3QuNGG0LDQvNC4?= In-Reply-To: <0d2a4c4ae3740f4f08c342f172bb5d32.NginxMailingListRussian@forum.nginx.org> References: <550b729e-39f3-7657-5119-f9a561e0bce3@ya.ru> <0d2a4c4ae3740f4f08c342f172bb5d32.NginxMailingListRussian@forum.nginx.org> Message-ID: On Thu, Apr 01, 2021 at 04:02:20PM -0400, budarin wrote: > коллеги, уже весь интернет перечитал - не могу решить проблему, помогите > пожалуйста! debug log -- Eugene Berdnikov From nginx-forum на forum.nginx.org Thu Apr 1 21:03:08 2021 From: nginx-forum на forum.nginx.org (budarin) Date: Thu, 01 Apr 2021 17:03:08 -0400 Subject: =?UTF-8?B?UmU6INCd0LUg0YPQtNCw0LXRgtGB0Y8g0L/QvtC00LzQtdC90LjRgtGMINC+0Yg=?= =?UTF-8?B?0LjQsdC60Lgg0YHQstC+0LjQvNC4INGB0YLRgNCw0L3QuNGG0LDQvNC4?= In-Reply-To: <885638feaa433b22bca431c55559b3c3.NginxMailingListRussian@forum.nginx.org> References: <885638feaa433b22bca431c55559b3c3.NginxMailingListRussian@forum.nginx.org> Message-ID: <1b72776f5077d77fef2608f0d61ad30d.NginxMailingListRussian@forum.nginx.org> спасибо, решил проблему - были ошибки в конфиге Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291126,291139#msg-291139 From nginx-forum на forum.nginx.org Thu Apr 1 21:03:45 2021 From: nginx-forum на forum.nginx.org (budarin) Date: Thu, 01 Apr 2021 17:03:45 -0400 Subject: =?UTF-8?B?UmU6INCd0LUg0YPQtNCw0LXRgtGB0Y8g0L/QvtC00LzQtdC90LjRgtGMINC+0Yg=?= =?UTF-8?B?0LjQsdC60Lgg0YHQstC+0LjQvNC4INGB0YLRgNCw0L3QuNGG0LDQvNC4?= In-Reply-To: References: Message-ID: <61984666db1fd4e766214f13327d78bd.NginxMailingListRussian@forum.nginx.org> спасибо - ни разу им не пользовался и не знал о нем Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291126,291140#msg-291140 From auskov на neolabs.kz Wed Apr 7 12:29:05 2021 From: auskov на neolabs.kz (Alexandr Uskov) Date: Wed, 7 Apr 2021 18:29:05 +0600 (ALMT) Subject: geoip module in CentOS8 repo Message-ID: <1136999925.93280.1617798545583.JavaMail.zimbra@neolabs.kz> Добрый день. Подскажите пожалуйста, почему не собирают nginx-module-geoip в официальный репозиторий для CentOS8? Для CentOS7 он на месте. ~~~ wbr, Alexandr Uskov From defan на nginx.com Wed Apr 7 13:07:02 2021 From: defan на nginx.com (Andrei Belov) Date: Wed, 7 Apr 2021 16:07:02 +0300 Subject: geoip module in CentOS8 repo In-Reply-To: <1136999925.93280.1617798545583.JavaMail.zimbra@neolabs.kz> References: <1136999925.93280.1617798545583.JavaMail.zimbra@neolabs.kz> Message-ID: <6D12622A-22EC-4010-BA18-1B271945C1FE@nginx.com> В CentOS / RHEL 8 более нет libgeoip (задеприкейчена в пользу libmaxminddb). > On 7 Apr 2021, at 15:29, Alexandr Uskov wrote: > > Добрый день. > > Подскажите пожалуйста, почему не собирают nginx-module-geoip > в официальный репозиторий для CentOS8? > Для CentOS7 он на месте. > > ~~~ > wbr, Alexandr Uskov From nginx-forum на forum.nginx.org Thu Apr 8 07:28:25 2021 From: nginx-forum на forum.nginx.org (Vladislavik) Date: Thu, 08 Apr 2021 03:28:25 -0400 Subject: Nginx reload + Websockets Message-ID: <755a6423d723b8dc2a3ebc44e5f1bc5f.NginxMailingListRussian@forum.nginx.org> Добрый день, есть 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 From chipitsine на gmail.com Thu Apr 8 09:41:32 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 8 Apr 2021 14:41:32 +0500 Subject: Nginx reload + Websockets In-Reply-To: <755a6423d723b8dc2a3ebc44e5f1bc5f.NginxMailingListRussian@forum.nginx.org> References: <755a6423d723b8dc2a3ebc44e5f1bc5f.NginxMailingListRussian@forum.nginx.org> Message-ID: сокеты штатно убиваются через 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 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From tolmachev.vlad на gmail.com Thu Apr 8 09:44:50 2021 From: tolmachev.vlad на gmail.com (Vl T) Date: Thu, 8 Apr 2021 12:44:50 +0300 Subject: Nginx reload + Websockets In-Reply-To: References: <755a6423d723b8dc2a3ebc44e5f1bc5f.NginxMailingListRussian@forum.nginx.org> Message-ID: 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.vlad на gmail.com skype: vladislaviki ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Thu Apr 8 09:49:48 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 8 Apr 2021 14:49:48 +0500 Subject: Nginx reload + Websockets In-Reply-To: References: <755a6423d723b8dc2a3ebc44e5f1bc5f.NginxMailingListRussian@forum.nginx.org> Message-ID: ну попрут и попрут. а что делать ? насколько я понимаю, штатно предполагается в том или ином виде 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.vlad на gmail.com > skype: vladislaviki > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From tolmachev.vlad на gmail.com Thu Apr 8 09:55:55 2021 From: tolmachev.vlad на gmail.com (Vl T) Date: Thu, 8 Apr 2021 12:55:55 +0300 Subject: Nginx reload + Websockets In-Reply-To: References: <755a6423d723b8dc2a3ebc44e5f1bc5f.NginxMailingListRussian@forum.nginx.org> Message-ID: У 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.vlad на 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.vlad на gmail.com skype: vladislaviki ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From defan на nginx.com Thu Apr 8 10:02:32 2021 From: defan на nginx.com (Andrei Belov) Date: Thu, 8 Apr 2021 13:02:32 +0300 Subject: Nginx reload + Websockets In-Reply-To: References: <755a6423d723b8dc2a3ebc44e5f1bc5f.NginxMailingListRussian@forum.nginx.org> Message-ID: <260B6C9A-EF4D-4D4A-91B5-6F64688DC690@nginx.com> > On 8 Apr 2021, at 12:49, Илья Шипицин wrote: > > ну попрут и попрут. а что делать ? > > > насколько я понимаю, штатно предполагается в том или ином виде abbrevated handshake (либо tls tickets, либо ssl sessions). > но гибкости в управлении этой штукой нет. можно сконфигурировать персистентный на диске, тогда переживете релоад, но сессии будут вечные. > безопасники обычно говорят, что лучше, чтобы при релоаде сессии и тикеты сбрасывались, но в этом случае вас 300к пользователей расстреляют на full handshake. > > мы замеряли, Xeon держит в районе 700-1000 хендшейков в 1 сек на 1 ядро. это если полные хендшейки. А какой конкретно xeon, не пропомните? From chipitsine на gmail.com Thu Apr 8 10:07:35 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 8 Apr 2021 13:07:35 +0300 Subject: Nginx reload + Websockets In-Reply-To: References: <755a6423d723b8dc2a3ebc44e5f1bc5f.NginxMailingListRussian@forum.nginx.org> Message-ID: Гипотетически, немного поможет, если тайм-аут сделать побольше. По крайней мере 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.vlad на 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.vlad на gmail.com > skype: vladislaviki > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Thu Apr 8 10:24:43 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 8 Apr 2021 13:24:43 +0300 Subject: Nginx reload + Websockets In-Reply-To: <260B6C9A-EF4D-4D4A-91B5-6F64688DC690@nginx.com> References: <755a6423d723b8dc2a3ebc44e5f1bc5f.NginxMailingListRussian@forum.nginx.org> <260B6C9A-EF4D-4D4A-91B5-6F64688DC690@nginx.com> Message-ID: Какой-то из ходовых. Отличаются размером кеша, который в данном случае никак не играет. Что играет роль, это шифрсьют. На современных 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 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Thu Apr 8 10:28:03 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 8 Apr 2021 13:28:03 +0300 Subject: Nginx reload + Websockets In-Reply-To: <260B6C9A-EF4D-4D4A-91B5-6F64688DC690@nginx.com> References: <755a6423d723b8dc2a3ebc44e5f1bc5f.NginxMailingListRussian@forum.nginx.org> <260B6C9A-EF4D-4D4A-91B5-6F64688DC690@nginx.com> Message-ID: Штормы цпу на релоаде это известная штука на самом деле. Будет круто, если на уровне 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 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From alex на vorona.com.ua Thu Apr 8 10:36:05 2021 From: alex на vorona.com.ua (Alex Vorona) Date: Thu, 8 Apr 2021 13:36:05 +0300 Subject: Nginx reload + Websockets In-Reply-To: References: <755a6423d723b8dc2a3ebc44e5f1bc5f.NginxMailingListRussian@forum.nginx.org> Message-ID: <96f7e3de-2e9d-b32b-cb1a-15ca17f4714b@vorona.com.ua> Привет, 4/8/21 12:41, Илья Шипицин wrote: > сокеты штатно убиваются через worker_shutdown_timeout Добавить в worker_shutdown_timeout ещё random'ную часть и проблема одновременного выхода будет решена, что позволит растянуть вызванную релоадом нагрузку по времени. Например, измененная директива >worker_shutdown_timeout 600 300; выключает воркера в диапазоне от 600 до 900 секунд с начала релоада. -- Alex Vorona From raven_kg на megaline.kg Thu Apr 8 11:28:16 2021 From: raven_kg на megaline.kg (raven_kg на megaline.kg) Date: Thu, 8 Apr 2021 17:28:16 +0600 Subject: =?UTF-8?B?0J3QuNC30LrQsNGPINGB0LrQvtGA0L7RgdGC0Ywg0L/QtdGA0LXQtNCw0YfQuCA=?= =?UTF-8?B?0LTQsNC90L3Ri9GFINC/0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC90Lg=?= =?UTF-8?B?0LggaHR0cHM=?= Message-ID: Доброго дня! 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; ... } ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Thu Apr 8 11:29:59 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 8 Apr 2021 14:29:59 +0300 Subject: =?UTF-8?B?UmU6INCd0LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINC/0LXRgNC10LTQsNGH?= =?UTF-8?B?0Lgg0LTQsNC90L3Ri9GFINC/0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC9?= =?UTF-8?B?0LjQuCBodHRwcw==?= In-Reply-To: References: Message-ID: Попробуйте stapling включить On Thu, Apr 8, 2021, 2:28 PM raven_kg на 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 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From raven_kg на megaline.kg Thu Apr 8 11:31:53 2021 From: raven_kg на megaline.kg (raven_kg на megaline.kg) Date: Thu, 8 Apr 2021 17:31:53 +0600 Subject: =?UTF-8?B?UmU6INCd0LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINC/0LXRgNC10LTQsNGH?= =?UTF-8?B?0Lgg0LTQsNC90L3Ri9GFINC/0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC9?= =?UTF-8?B?0LjQuCBodHRwcw==?= In-Reply-To: References: Message-ID: <62fd865a-c065-adbb-e671-f35bd7385f2f@megaline.kg> Включен) > ssl_stapling on; 08.04.2021 17:29, Илья Шипицин пишет: > Попробуйте stapling включить > > On Thu, Apr 8, 2021, 2:28 PM raven_kg на 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 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Thu Apr 8 12:04:17 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 8 Apr 2021 15:04:17 +0300 Subject: =?UTF-8?B?UmU6INCd0LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINC/0LXRgNC10LTQsNGH?= =?UTF-8?B?0Lgg0LTQsNC90L3Ri9GFINC/0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC9?= =?UTF-8?B?0LjQuCBodHRwcw==?= In-Reply-To: <62fd865a-c065-adbb-e671-f35bd7385f2f@megaline.kg> References: <62fd865a-c065-adbb-e671-f35bd7385f2f@megaline.kg> Message-ID: Действительно. Я проглядел On Thu, Apr 8, 2021, 2:32 PM raven_kg на megaline.kg wrote: > Включен) > > ssl_stapling on; > > > 08.04.2021 17:29, Илья Шипицин пишет: > > Попробуйте stapling включить > > On Thu, Apr 8, 2021, 2:28 PM raven_kg на 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 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 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From constantine на mellodesign.ru Thu Apr 8 12:18:22 2021 From: constantine на mellodesign.ru (=?utf-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0g0KLQutCw0YfQtdC90LrQvg==?=) Date: Thu, 8 Apr 2021 15:18:22 +0300 Subject: =?UTF-8?B?UmU6INCd0LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINC/0LXRgNC10LTQsNGH?= =?UTF-8?B?0Lgg0LTQsNC90L3Ri9GFINC/0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC9?= =?UTF-8?B?0LjQuCBodHRwcw==?= In-Reply-To: References: <62fd865a-c065-adbb-e671-f35bd7385f2f@megaline.kg> Message-ID: <2E41271E-0C42-4B8F-957D-C8FAF6928A3D@mellodesign.ru> > 8 апр. 2021 г., в 15:04, Илья Шипицин написал(а): > > Действительно. Я проглядел > > On Thu, Apr 8, 2021, 2:32 PM raven_kg на megaline.kg > wrote: > Включен) > > ssl_stapling on; > > > 08.04.2021 17:29, Илья Шипицин пишет: >> Попробуйте stapling включить >> >> On Thu, Apr 8, 2021, 2:28 PM raven_kg на 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 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From raven_kg на megaline.kg Thu Apr 8 12:24:56 2021 From: raven_kg на megaline.kg (raven_kg на megaline.kg) Date: Thu, 8 Apr 2021 18:24:56 +0600 Subject: =?UTF-8?B?UmU6INCd0LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINC/0LXRgNC10LTQsNGH?= =?UTF-8?B?0Lgg0LTQsNC90L3Ri9GFINC/0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC9?= =?UTF-8?B?0LjQuCBodHRwcw==?= In-Reply-To: <2E41271E-0C42-4B8F-957D-C8FAF6928A3D@mellodesign.ru> References: <62fd865a-c065-adbb-e671-f35bd7385f2f@megaline.kg> <2E41271E-0C42-4B8F-957D-C8FAF6928A3D@mellodesign.ru> Message-ID: Это я уже опробовал. Также пробовал сборку с патчем от 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_kg на megaline.kg >> > > wrote: >> >> Включен) >> > ssl_stapling on; >> >> >> 08.04.2021 17:29, Илья Шипицин пишет: >>> Попробуйте stapling включить >>> >>> On Thu, Apr 8, 2021, 2:28 PM raven_kg на 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 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From slw на zxy.spb.ru Thu Apr 8 12:46:45 2021 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Thu, 8 Apr 2021 15:46:45 +0300 Subject: =?UTF-8?B?UmU6INCd0LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINC/0LXRgNC10LTQsNGH?= =?UTF-8?B?0Lgg0LTQsNC90L3Ri9GFINC/0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC9?= =?UTF-8?B?0LjQuCBodHRwcw==?= In-Reply-To: References: Message-ID: <20210408124645.GT1073@zxy.spb.ru> On Thu, Apr 08, 2021 at 05:28:16PM +0600, raven_kg на megaline.kg wrote: > Доброго дня! > > nginx 1.18.0, собран с OpenSSL 1.1.1c FIPS. > > Замечено, что по https отдача первого байта происходит на 200мс дольше. а откуда идея что должно быть иначе? From constantine на mellodesign.ru Thu Apr 8 12:48:38 2021 From: constantine на mellodesign.ru (=?utf-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0g0KLQutCw0YfQtdC90LrQvg==?=) Date: Thu, 8 Apr 2021 15:48:38 +0300 Subject: =?UTF-8?B?UmU6INCd0LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINC/0LXRgNC10LTQsNGH?= =?UTF-8?B?0Lgg0LTQsNC90L3Ri9GFINC/0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC9?= =?UTF-8?B?0LjQuCBodHRwcw==?= In-Reply-To: <20210408124645.GT1073@zxy.spb.ru> References: <20210408124645.GT1073@zxy.spb.ru> Message-ID: <67FE82B6-9CFE-4B84-82B4-2270B6A7A10D@mellodesign.ru> > 8 апр. 2021 г., в 15:46, Slawa Olhovchenkov написал(а): > > On Thu, Apr 08, 2021 at 05:28:16PM +0600, raven_kg на 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 активно пиарит, что первый байт должен быстро приходить вот и сеошники мучают админов. From raven_kg на megaline.kg Thu Apr 8 12:52:44 2021 From: raven_kg на megaline.kg (raven_kg на megaline.kg) Date: Thu, 8 Apr 2021 18:52:44 +0600 Subject: =?UTF-8?B?UmU6INCd0LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINC/0LXRgNC10LTQsNGH?= =?UTF-8?B?0Lgg0LTQsNC90L3Ri9GFINC/0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC9?= =?UTF-8?B?0LjQuCBodHRwcw==?= In-Reply-To: <20210408124645.GT1073@zxy.spb.ru> References: <20210408124645.GT1073@zxy.spb.ru> Message-ID: Я не отрицаю, что ssl требует больше времени на шифрование. Но почему оно более чем в 2 раза для ttfb? 08.04.2021 18:46, Slawa Olhovchenkov пишет: > On Thu, Apr 08, 2021 at 05:28:16PM +0600, raven_kg на 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 From slw на zxy.spb.ru Thu Apr 8 12:55:06 2021 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Thu, 8 Apr 2021 15:55:06 +0300 Subject: =?UTF-8?B?UmU6INCd0LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINC/0LXRgNC10LTQsNGH?= =?UTF-8?B?0Lgg0LTQsNC90L3Ri9GFINC/0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC9?= =?UTF-8?B?0LjQuCBodHRwcw==?= In-Reply-To: <67FE82B6-9CFE-4B84-82B4-2270B6A7A10D@mellodesign.ru> References: <20210408124645.GT1073@zxy.spb.ru> <67FE82B6-9CFE-4B84-82B4-2270B6A7A10D@mellodesign.ru> Message-ID: <20210408125506.GU1073@zxy.spb.ru> 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. From slw на zxy.spb.ru Thu Apr 8 12:56:29 2021 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Thu, 8 Apr 2021 15:56:29 +0300 Subject: =?UTF-8?B?UmU6INCd0LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINC/0LXRgNC10LTQsNGH?= =?UTF-8?B?0Lgg0LTQsNC90L3Ri9GFINC/0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC9?= =?UTF-8?B?0LjQuCBodHRwcw==?= In-Reply-To: References: <20210408124645.GT1073@zxy.spb.ru> Message-ID: <20210408125629.GV1073@zxy.spb.ru> On Thu, Apr 08, 2021 at 06:52:44PM +0600, raven_kg на megaline.kg wrote: топквотинг > Я не отрицаю, что ssl требует больше времени на шифрование. Но почему > оно более чем в 2 раза для ttfb? не > 08.04.2021 18:46, Slawa Olhovchenkov пишет: надо > > On Thu, Apr 08, 2021 at 05:28:16PM +0600, raven_kg на 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 From raven_kg на megaline.kg Thu Apr 8 13:03:19 2021 From: raven_kg на megaline.kg (raven_kg на megaline.kg) Date: Thu, 8 Apr 2021 19:03:19 +0600 Subject: =?UTF-8?B?UmU6INCd0LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINC/0LXRgNC10LTQsNGH?= =?UTF-8?B?0Lgg0LTQsNC90L3Ri9GFINC/0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC9?= =?UTF-8?B?0LjQuCBodHRwcw==?= In-Reply-To: <20210408125629.GV1073@zxy.spb.ru> References: <20210408124645.GT1073@zxy.spb.ru> <20210408125629.GV1073@zxy.spb.ru> Message-ID: <61354348-bc40-150e-be2c-f3c48c08d89e@megaline.kg> По поводу скорости - да, я возможно не совсем корректно охарактеризовал суть в теме, каюсь. А какую смысловую нагрузку несет ваш выпад?) 08.04.2021 18:56, Slawa Olhovchenkov пишет: > On Thu, Apr 08, 2021 at 06:52:44PM +0600, raven_kg на megaline.kg wrote: > > топквотинг > > Сударь использует GPRS?) From slw на zxy.spb.ru Thu Apr 8 13:06:10 2021 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Thu, 8 Apr 2021 16:06:10 +0300 Subject: =?UTF-8?B?UmU6INCd0LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINC/0LXRgNC10LTQsNGH?= =?UTF-8?B?0Lgg0LTQsNC90L3Ri9GFINC/0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC9?= =?UTF-8?B?0LjQuCBodHRwcw==?= In-Reply-To: <61354348-bc40-150e-be2c-f3c48c08d89e@megaline.kg> References: <20210408124645.GT1073@zxy.spb.ru> <20210408125629.GV1073@zxy.spb.ru> <61354348-bc40-150e-be2c-f3c48c08d89e@megaline.kg> Message-ID: <20210408130610.GW1073@zxy.spb.ru> On Thu, Apr 08, 2021 at 07:03:19PM +0600, raven_kg на megaline.kg wrote: > По поводу скорости - да, я возможно не совсем корректно охарактеризовал > суть в теме, каюсь. А какую смысловую нагрузку несет ваш выпад?) > > 08.04.2021 18:56, Slawa Olhovchenkov пишет: > > On Thu, Apr 08, 2021 at 06:52:44PM +0600, raven_kg на megaline.kg wrote: > > > > топквотинг > > > > > Сударь использует GPRS?) > такую, что в топквотинговой переписке я объяснений давать не буду From raven_kg на megaline.kg Thu Apr 8 13:16:06 2021 From: raven_kg на megaline.kg (raven_kg на megaline.kg) Date: Thu, 8 Apr 2021 19:16:06 +0600 Subject: =?UTF-8?B?UmU6INCd0LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINC/0LXRgNC10LTQsNGH?= =?UTF-8?B?0Lgg0LTQsNC90L3Ri9GFINC/0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC9?= =?UTF-8?B?0LjQuCBodHRwcw==?= In-Reply-To: <20210408130610.GW1073@zxy.spb.ru> References: <20210408124645.GT1073@zxy.spb.ru> <20210408125629.GV1073@zxy.spb.ru> <61354348-bc40-150e-be2c-f3c48c08d89e@megaline.kg> <20210408130610.GW1073@zxy.spb.ru> Message-ID: <797f7ad4-ea76-8280-b14d-552aff6a0696@megaline.kg> 08.04.2021 19:06, Slawa Olhovchenkov пишет: > On Thu, Apr 08, 2021 at 07:03:19PM +0600, raven_kg на megaline.kg wrote: > >> По поводу скорости - да, я возможно не совсем корректно охарактеризовал >> суть в теме, каюсь. А какую смысловую нагрузку несет ваш выпад?) >> >> 08.04.2021 18:56, Slawa Olhovchenkov пишет: >>> On Thu, Apr 08, 2021 at 06:52:44PM +0600, raven_kg на megaline.kg wrote: >>> >>> топквотинг >>> >>> >> Сударь использует GPRS?) >> > такую, что в топквотинговой переписке я объяснений давать не буду > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Чтож, это ваше право) From constantine на mellodesign.ru Thu Apr 8 14:06:15 2021 From: constantine на mellodesign.ru (=?utf-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0g0KLQutCw0YfQtdC90LrQvg==?=) Date: Thu, 8 Apr 2021 17:06:15 +0300 Subject: =?UTF-8?B?UmU6INCd0LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINC/0LXRgNC10LTQsNGH?= =?UTF-8?B?0Lgg0LTQsNC90L3Ri9GFINC/0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC9?= =?UTF-8?B?0LjQuCBodHRwcw==?= In-Reply-To: <20210408125506.GU1073@zxy.spb.ru> References: <20210408124645.GT1073@zxy.spb.ru> <67FE82B6-9CFE-4B84-82B4-2270B6A7A10D@mellodesign.ru> <20210408125506.GU1073@zxy.spb.ru> Message-ID: > 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 , однако некоторые сеошники все еще требуют снижать этот показатель. С другой стороны он может влиять на все остальные, так как страница "долго" грузится. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Thu Apr 8 14:19:29 2021 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Thu, 8 Apr 2021 17:19:29 +0300 Subject: =?UTF-8?B?UmU6INCd0LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINC/0LXRgNC10LTQsNGH?= =?UTF-8?B?0Lgg0LTQsNC90L3Ri9GFINC/0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC9?= =?UTF-8?B?0LjQuCBodHRwcw==?= In-Reply-To: References: Message-ID: On Thu, Apr 08, 2021 at 05:28:16PM +0600, raven_kg на megaline.kg wrote: > Замечено, что по https отдача первого байта происходит на 200мс дольше. Сравнение ltrace -S -T -tt -fp с дампом трафика может прояснить ситуацию. По величине задержки похоже на Нагель, хотя он должен быть выключен. -- Eugene Berdnikov From mdounin на mdounin.ru Thu Apr 8 14:48:38 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 8 Apr 2021 17:48:38 +0300 Subject: =?UTF-8?B?UmU6INCd0LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINC/0LXRgNC10LTQsNGH?= =?UTF-8?B?0Lgg0LTQsNC90L3Ri9GFINC/0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC9?= =?UTF-8?B?0LjQuCBodHRwcw==?= In-Reply-To: References: Message-ID: Hello! On Thu, Apr 08, 2021 at 05:28:16PM +0600, raven_kg на 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/ From mdounin на mdounin.ru Thu Apr 8 15:38:46 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 8 Apr 2021 18:38:46 +0300 Subject: Nginx reload + Websockets In-Reply-To: <755a6423d723b8dc2a3ebc44e5f1bc5f.NginxMailingListRussian@forum.nginx.org> References: <755a6423d723b8dc2a3ebc44e5f1bc5f.NginxMailingListRussian@forum.nginx.org> Message-ID: 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/ From gmm на csdoc.com Mon Apr 12 14:47:08 2021 From: gmm на csdoc.com (Gena Makhomed) Date: Mon, 12 Apr 2021 17:47:08 +0300 Subject: proxy_http_version 1.0; gzip_http_version 1.1; Message-ID: <1cf684ad-e247-1349-fbaa-9f8a49362ba8@csdoc.com> Здравствуйте, All! Зачем такие странные настройки по-умолчанию? proxy_http_version 1.0; gzip_http_version 1.1; в результате - если используется цепочка из двох nginx, nginx-frontend <=> nginx-backend, то компрессия будет выключена при настройке по-умолчанию. Что плохого будет например, если переключить по-умолчанию "proxy_http_version 1.1;" вместо "proxy_http_version 1.0;" ? -- Best regards, Gena From chipitsine на gmail.com Mon Apr 12 16:15:27 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 12 Apr 2021 21:15:27 +0500 Subject: proxy_http_version 1.0; gzip_http_version 1.1; In-Reply-To: <1cf684ad-e247-1349-fbaa-9f8a49362ba8@csdoc.com> References: <1cf684ad-e247-1349-fbaa-9f8a49362ba8@csdoc.com> Message-ID: вопрос с настройками по умолчанию поднимался много раз. каждый раз ответ примерно такой, что настройки по умолчанию не трогают, чтобы не поломать тем, кто от них зависит. а тем, кому нужны другие настройки, они могут сами для себя сделать как им надо, не будучи завязанными на дефолт и не затрагивая тех, кто от дефолта зависит. пн, 12 апр. 2021 г. в 19:47, Gena Makhomed : > Здравствуйте, > All! > > Зачем такие странные настройки по-умолчанию? > > proxy_http_version 1.0; > > gzip_http_version 1.1; > > в результате - если используется цепочка из двох nginx, > nginx-frontend <=> nginx-backend, то компрессия > будет выключена при настройке по-умолчанию. > > Что плохого будет например, если переключить по-умолчанию > "proxy_http_version 1.1;" вместо "proxy_http_version 1.0;" ? > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vas на sibptus.ru Tue Apr 13 05:11:46 2021 From: vas на sibptus.ru (Victor Sudakov) Date: Tue, 13 Apr 2021 12:11:46 +0700 Subject: =?UTF-8?B?0KLQvtC90LrQvtGB0YLQuCDRgNCw0LHQvtGC0YsgRmFzdENHSSAocGhwZnBtKQ==?= Message-ID: Коллеги, Есть момент, который я не понимаю, как работает. У nginx есть upstream, который представляет собой хост с php7.4-fpm. Допустим на PHP написали код, который зацикливается, или спит 3 часа, или посылает SQL запрос на 3 часа работы - короче, работать собирается долго или бесконечно. Вот пришел от пользователя HTTP запрос, nginx его передал php-fpm в злополучный код, phpfpm child начал бесконечную работу... Что должно произойти, когда пользователь отменил HTTP запрос, или браузер закрыл? nginx закроет соответствующее соединение с php-fpm ? А PHP-код продолжит работу? Или должен прерваться? Прошу прощения за сумбурное изложение, поправки и указания на неверное понимание логики работы с благодарностью принимаются. -- Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49 на fidonet From greenh на gmail.com Tue Apr 13 04:03:38 2021 From: greenh на gmail.com (greenh) Date: Tue, 13 Apr 2021 07:03:38 +0300 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: References: Message-ID: Nginx закроет соединение, а php код будет работать до того момента, пока не наступит max_time_limit в самом пхп, либо, если он будет установлен в 0 - то безконечно. вт, 13 апр. 2021 г. в 08:11, Victor Sudakov : > Коллеги, > > Есть момент, который я не понимаю, как работает. У nginx есть upstream, > который представляет собой хост с php7.4-fpm. Допустим на PHP написали > код, который зацикливается, или спит 3 часа, или посылает SQL запрос на > 3 часа работы - короче, работать собирается долго или бесконечно. > > Вот пришел от пользователя HTTP запрос, nginx его передал php-fpm в > злополучный код, phpfpm child начал бесконечную работу... Что должно > произойти, когда пользователь отменил HTTP запрос, или браузер закрыл? > nginx закроет соответствующее соединение с php-fpm ? А PHP-код продолжит > работу? Или должен прерваться? > > Прошу прощения за сумбурное изложение, поправки и указания на неверное > понимание логики работы с благодарностью принимаются. > > -- > Victor Sudakov VAS4-RIPE > http://vas.tomsk.ru/ > 2:5005/49 на fidonet > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From sytar.alex на gmail.com Tue Apr 13 07:05:30 2021 From: sytar.alex на gmail.com (Aleksandr Sytar) Date: Tue, 13 Apr 2021 10:05:30 +0300 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: References: Message-ID: вт, 13 апр. 2021 г. в 08:11, Victor Sudakov : > Что должно > произойти, когда пользователь отменил HTTP запрос, или браузер закрыл? > nginx закроет соответствующее соединение с php-fpm ? А PHP-код продолжит > работу? Или должен прерваться? > > Прошу прощения за сумбурное изложение, поправки и указания на неверное > понимание логики работы с благодарностью принимаются. > > > Раз - https://habr.com/ru/post/179399/ Двас - https://www.php.net/manual/ru/function.fastcgi-finish-request.php и крути себе дальше в базе что надо. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vas на sibptus.ru Tue Apr 13 07:46:57 2021 From: vas на sibptus.ru (Victor Sudakov) Date: Tue, 13 Apr 2021 14:46:57 +0700 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: References: Message-ID: greenh wrote: > Nginx закроет соединение, а php код будет работать до того момента, пока не > наступит max_time_limit в самом пхп, либо, если он будет установлен в 0 - > то безконечно. Вот это плохо. А почему так? Ведь обычная программа (не демон), как правило, завершается или хотя бы останавливается, если ей каналы ввода-вывода закрыли. Чтобы этого не происходило, запускают через nohup, daemon и проч. -- Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49 на fidonet From vas на sibptus.ru Tue Apr 13 07:52:00 2021 From: vas на sibptus.ru (Victor Sudakov) Date: Tue, 13 Apr 2021 14:52:00 +0700 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: References: Message-ID: Aleksandr Sytar wrote: > > > Что должно > > произойти, когда пользователь отменил HTTP запрос, или браузер закрыл? > > nginx закроет соответствующее соединение с php-fpm ? А PHP-код продолжит > > работу? Или должен прерваться? > > > > Прошу прощения за сумбурное изложение, поправки и указания на неверное > > понимание логики работы с благодарностью принимаются. > > > > > > > Раз - https://habr.com/ru/post/179399/ > Двас - https://www.php.net/manual/ru/function.fastcgi-finish-request.php и > крути себе дальше в базе что надо. Я наверное плохо сформулировал вопрос, но мне как раз интересно видеть обратное поведение. Закрыли браузер - обслуживавший этот сеанс процесс PHP завершился, что бы ни делал в этот момент. А в приведенных ссылках обратную задачу пытаются решить. Антиоффтопик. nginx-то что делает в момент закрытия соединения клиентским браузером: закрывает ли соответствущее соединение с fastcgi upstream-ом? -- Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49 на fidonet From greenh на gmail.com Tue Apr 13 10:00:00 2021 From: greenh на gmail.com (greenh) Date: Tue, 13 Apr 2021 13:00:00 +0300 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: References: Message-ID: Боюсь ошибиться, но я думаю что он (когда узнает о том, что браузер сдох) просто перестанет ждать ответа на запрос от пхп но: пхп останется жить, его процесс останется запущен, сокет, который он слушает останется активным и процессы внутри его продолжат работу. Уточнить причину такого поведения, я думаю, стоит у разработчиков php-fpm. вт, 13 апр. 2021 г. в 10:52, Victor Sudakov : > Aleksandr Sytar wrote: > > > > > Что должно > > > произойти, когда пользователь отменил HTTP запрос, или браузер закрыл? > > > nginx закроет соответствующее соединение с php-fpm ? А PHP-код > продолжит > > > работу? Или должен прерваться? > > > > > > Прошу прощения за сумбурное изложение, поправки и указания на неверное > > > понимание логики работы с благодарностью принимаются. > > > > > > > > > > > Раз - https://habr.com/ru/post/179399/ > > Двас - https://www.php.net/manual/ru/function.fastcgi-finish-request.php > и > > крути себе дальше в базе что надо. > > Я наверное плохо сформулировал вопрос, но мне как раз интересно видеть > обратное поведение. Закрыли браузер - обслуживавший этот сеанс процесс > PHP завершился, что бы ни делал в этот момент. > > А в приведенных ссылках обратную задачу пытаются решить. > > Антиоффтопик. nginx-то что делает в момент закрытия соединения > клиентским браузером: закрывает ли соответствущее соединение с fastcgi > upstream-ом? > > -- > Victor Sudakov VAS4-RIPE > http://vas.tomsk.ru/ > 2:5005/49 на fidonet > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From greenh на gmail.com Tue Apr 13 10:02:52 2021 From: greenh на gmail.com (greenh) Date: Tue, 13 Apr 2021 13:02:52 +0300 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: References: Message-ID: А какое поведение вы хотите получить? вт, 13 апр. 2021 г., 13:00 greenh : > Боюсь ошибиться, но я думаю что он (когда узнает о том, что браузер сдох) > просто перестанет ждать ответа на запрос от пхп но: пхп останется жить, его > процесс останется запущен, сокет, который он слушает останется активным и > процессы внутри его продолжат работу. Уточнить причину такого поведения, я > думаю, стоит у разработчиков php-fpm. > > вт, 13 апр. 2021 г. в 10:52, Victor Sudakov : > >> Aleksandr Sytar wrote: >> > >> > > Что должно >> > > произойти, когда пользователь отменил HTTP запрос, или браузер закрыл? >> > > nginx закроет соответствующее соединение с php-fpm ? А PHP-код >> продолжит >> > > работу? Или должен прерваться? >> > > >> > > Прошу прощения за сумбурное изложение, поправки и указания на неверное >> > > понимание логики работы с благодарностью принимаются. >> > > >> > > >> > > >> > Раз - https://habr.com/ru/post/179399/ >> > Двас - >> https://www.php.net/manual/ru/function.fastcgi-finish-request.php и >> > крути себе дальше в базе что надо. >> >> Я наверное плохо сформулировал вопрос, но мне как раз интересно видеть >> обратное поведение. Закрыли браузер - обслуживавший этот сеанс процесс >> PHP завершился, что бы ни делал в этот момент. >> >> А в приведенных ссылках обратную задачу пытаются решить. >> >> Антиоффтопик. nginx-то что делает в момент закрытия соединения >> клиентским браузером: закрывает ли соответствущее соединение с fastcgi >> upstream-ом? >> >> -- >> Victor Sudakov VAS4-RIPE >> http://vas.tomsk.ru/ >> 2:5005/49 на fidonet >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vas на sibptus.ru Tue Apr 13 10:18:31 2021 From: vas на sibptus.ru (Victor Sudakov) Date: Tue, 13 Apr 2021 17:18:31 +0700 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: References: Message-ID: greenh wrote: > А какое поведение вы хотите получить? Закрыли браузер - обслуживавший этот сеанс процесс PHP безусловно завершился, что бы ни делал в этот момент. -- Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49 на fidonet From greenh на gmail.com Tue Apr 13 10:23:46 2021 From: greenh на gmail.com (greenh) Date: Tue, 13 Apr 2021 13:23:46 +0300 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: References: Message-ID: Мне кажется, что так оно работать не будет. Да собственно и зачем? ПХП процесс в среднем случае легкий и быстрый. Отработает и умрет. Если Вы запускаете что то очень тяжелое по хттп запросу - это явно ошибка архитектуры. Да и определить закрытие браузера не всегда возможно. Опять таки, боюсь соврать, но момент, когда можно будет точно сказать, что браузер закрыт наступит довольно не скоро (я имею в виду TCP таймауты и пр), и в среднем случае существенно позже, чем скрипт отработает и умрет вт, 13 апр. 2021 г. в 13:18, Victor Sudakov : > greenh wrote: > > А какое поведение вы хотите получить? > > Закрыли браузер - обслуживавший этот сеанс процесс PHP безусловно > завершился, что бы ни делал в этот момент. > > -- > Victor Sudakov VAS4-RIPE > http://vas.tomsk.ru/ > 2:5005/49 на fidonet > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vas на sibptus.ru Tue Apr 13 10:28:12 2021 From: vas на sibptus.ru (Victor Sudakov) Date: Tue, 13 Apr 2021 17:28:12 +0700 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: References: Message-ID: greenh wrote: > Боюсь ошибиться, но я думаю что он (когда узнает о том, что браузер сдох) > просто перестанет ждать ответа на запрос от пхп но: пхп останется жить, его > процесс останется запущен, сокет, который он слушает останется активным и > процессы внутри его продолжат работу. Почему бы сокет останется активным, если nginx закрыл соединение к апстриму? Или nginx не закрывает соединение к апстриму, когда "браузер сдох"? Вообще nginx на каждый запрос открывает новое соединение (TCP или Unix socket) с апстримом, или всё время держит одно соединение с апстримом и все запросы к php-fpm через это одно соединение идут? > Уточнить причину такого поведения, я > думаю, стоит у разработчиков php-fpm. Сперва бы ответить на вопрос выше, а это вопрос по nginx. Судя по наличию параметра max_conns у upstream, всё же имеют место быть одновременно много соединений к одному апстриму. -- Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49 на fidonet From vas на sibptus.ru Tue Apr 13 10:31:58 2021 From: vas на sibptus.ru (Victor Sudakov) Date: Tue, 13 Apr 2021 17:31:58 +0700 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: References: Message-ID: greenh wrote: > Мне кажется, что так оно работать не будет. Да собственно и зачем? ПХП > процесс в среднем случае легкий и быстрый. Отработает и умрет. Если Вы > запускаете что то очень тяжелое по хттп запросу - это явно ошибка > архитектуры. > Да и определить закрытие браузера не всегда возможно. Опять таки, боюсь > соврать, но момент, когда можно будет точно сказать, что браузер закрыт > наступит довольно не скоро (я имею в виду TCP таймауты и пр), и в среднем > случае существенно позже, чем скрипт отработает и умрет В случае таймаута да, а если клиент штатно завершил TCP соединение, зачем тратить ресурсы на поддержание соединения от nginx к upstream? Хоть Wireshark в руки бери, но кто-то же из присутствующих знает теорию? -- Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49 на fidonet From greenh на gmail.com Tue Apr 13 10:39:29 2021 From: greenh на gmail.com (greenh) Date: Tue, 13 Apr 2021 13:39:29 +0300 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: References: Message-ID: вт, 13 апр. 2021 г. в 13:28, Victor Sudakov : > greenh wrote: > > Боюсь ошибиться, но я думаю что он (когда узнает о том, что браузер сдох) > > просто перестанет ждать ответа на запрос от пхп но: пхп останется жить, > его > > процесс останется запущен, сокет, который он слушает останется активным и > > процессы внутри его продолжат работу. > > Почему бы сокет останется активным, если nginx закрыл соединение к > апстриму? Или nginx не закрывает соединение к апстриму, когда "браузер > сдох"? > > Сокет останется открытым, а не соединение > Вообще nginx на каждый запрос открывает новое соединение (TCP или Unix > socket) с апстримом, или всё время держит одно соединение с апстримом и > все запросы к php-fpm через это одно соединение идут? > > > Уточнить причину такого поведения, я > > думаю, стоит у разработчиков php-fpm. > > Сперва бы ответить на вопрос выше, а это вопрос по nginx. Судя по > наличию параметра max_conns у upstream, всё же имеют место быть > одновременно много соединений к одному апстриму. > > -- > Victor Sudakov VAS4-RIPE > http://vas.tomsk.ru/ > 2:5005/49 на fidonet > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From greenh на gmail.com Tue Apr 13 10:40:33 2021 From: greenh на gmail.com (greenh) Date: Tue, 13 Apr 2021 13:40:33 +0300 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: References: Message-ID: вт, 13 апр. 2021 г. в 13:32, Victor Sudakov : > greenh wrote: > > Мне кажется, что так оно работать не будет. Да собственно и зачем? ПХП > > процесс в среднем случае легкий и быстрый. Отработает и умрет. Если Вы > > запускаете что то очень тяжелое по хттп запросу - это явно ошибка > > архитектуры. > > Да и определить закрытие браузера не всегда возможно. Опять таки, боюсь > > соврать, но момент, когда можно будет точно сказать, что браузер закрыт > > наступит довольно не скоро (я имею в виду TCP таймауты и пр), и в среднем > > случае существенно позже, чем скрипт отработает и умрет > > В случае таймаута да, а если клиент штатно завершил TCP соединение, > зачем тратить ресурсы на поддержание соединения от nginx к upstream? > > Хоть Wireshark в руки бери, но кто-то же из присутствующих знает теорию? > Я никогда в логах ФПМ не видел информации о том, что соединение закрыто со стороне nginx. Или не помню ( > > -- > Victor Sudakov VAS4-RIPE > http://vas.tomsk.ru/ > 2:5005/49 на fidonet > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From eugen на grosbein.net Tue Apr 13 11:18:35 2021 From: eugen на grosbein.net (Eugene Grosbein) Date: Tue, 13 Apr 2021 18:18:35 +0700 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: References: Message-ID: <8cd26f0f-3818-ad60-baf9-ee8c18d85b0e@grosbein.net> 13.04.2021 17:31, Victor Sudakov пишет: > greenh wrote: >> Мне кажется, что так оно работать не будет. Да собственно и зачем? ПХП >> процесс в среднем случае легкий и быстрый. Отработает и умрет. Если Вы >> запускаете что то очень тяжелое по хттп запросу - это явно ошибка >> архитектуры. >> Да и определить закрытие браузера не всегда возможно. Опять таки, боюсь >> соврать, но момент, когда можно будет точно сказать, что браузер закрыт >> наступит довольно не скоро (я имею в виду TCP таймауты и пр), и в среднем >> случае существенно позже, чем скрипт отработает и умрет > > В случае таймаута да, а если клиент штатно завершил TCP соединение, > зачем тратить ресурсы на поддержание соединения от nginx к upstream? > > Хоть Wireshark в руки бери, но кто-то же из присутствующих знает теорию? При закрытии TCP-сокета клиентской стороной на запись (или вообще) операционная система клиента отправляет данные из очереди отправки, если она не пуста, дожидается ACK от сервера и отправляет FIN. Это IEEE Std 1003.1g-2000 ("POSIX.1g"), если верить man 2 shutdown. Если FIN дошел, то попытка почитать данные из сокета при помощи recv* должна возвращать ECONNRESET, а мониторинг сокета при помощи poll вернуть POLLHUP, kqueue возвращает EV_EOF и т.п. Будет ли сторона php/fastcgi мониторить свои сокеты - вопрос к ним. Если приложение в конвейере пытается писать или читать в уже закрытый pipe это одно, а вот если оно не пытается - никто не будет его убивать. From slw на zxy.spb.ru Tue Apr 13 12:08:01 2021 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Tue, 13 Apr 2021 15:08:01 +0300 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: References: Message-ID: <20210413120801.GX1073@zxy.spb.ru> On Tue, Apr 13, 2021 at 02:46:57PM +0700, Victor Sudakov wrote: > greenh wrote: > > Nginx закроет соединение, а php код будет работать до того момента, пока не > > наступит max_time_limit в самом пхп, либо, если он будет установлен в 0 - > > то безконечно. > > Вот это плохо. > > А почему так? Ведь обычная программа (не демон), как правило, > завершается или хотя бы останавливается, если ей каналы ввода-вывода > закрыли. да нет же. это твои влажные фантазии. From mdounin на mdounin.ru Tue Apr 13 13:41:48 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 13 Apr 2021 16:41:48 +0300 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: References: Message-ID: Hello! On Tue, Apr 13, 2021 at 02:52:00PM +0700, Victor Sudakov wrote: > Aleksandr Sytar wrote: > > > > > Что должно > > > произойти, когда пользователь отменил HTTP запрос, или браузер закрыл? > > > nginx закроет соответствующее соединение с php-fpm ? А PHP-код продолжит > > > работу? Или должен прерваться? > > > > > > Прошу прощения за сумбурное изложение, поправки и указания на неверное > > > понимание логики работы с благодарностью принимаются. > > > > > > > > > > > Раз - https://habr.com/ru/post/179399/ > > Двас - https://www.php.net/manual/ru/function.fastcgi-finish-request.php и > > крути себе дальше в базе что надо. > > Я наверное плохо сформулировал вопрос, но мне как раз интересно видеть > обратное поведение. Закрыли браузер - обслуживавший этот сеанс процесс > PHP завершился, что бы ни делал в этот момент. > > А в приведенных ссылках обратную задачу пытаются решить. Прямая задача, как я понимаю, нормально решается только в случае, если php-скрипт что-то возвращает клиенту, подробнее тут: https://www.php.net/manual/en/features.connection-handling.php https://www.php.net/manual/en/function.ignore-user-abort.php https://www.php.net/manual/en/function.connection-aborted.php Но я не настоящий сварщик, про php знаю мало. > Антиоффтопик. nginx-то что делает в момент закрытия соединения > клиентским браузером: закрывает ли соответствущее соединение с fastcgi > upstream-ом? В общем случае да. И именно для того, чтобы бэкенд узнал о том, что соединение закрыто клиентом и выполняемая работа больше не нужна. Если этого по каким-то не требуется, то можно использовать директиву fastcgi_ignore_client_abort: http://nginx.org/r/fastcgi_ignore_client_abort Кроме того, соединение не будет закрыто, если используется кэширование или fastcgi_store, так как в этих случаях ответ бэкенда полезен вне зависимости от того, будет ли он отправлен конкретному клиенту. -- Maxim Dounin http://mdounin.ru/ From vovansystems на gmail.com Tue Apr 13 14:02:13 2021 From: vovansystems на gmail.com (VovansystemS) Date: Tue, 13 Apr 2021 17:02:13 +0300 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: References: Message-ID: Добрый день, > Кроме того, соединение не будет закрыто, если используется > кэширование или fastcgi_store, так как в этих случаях ответ > бэкенда полезен вне зависимости от того, будет ли он отправлен > конкретному клиенту. вот это уточнение прямо очень интересное, спасибо за него, Максим! From mdounin на mdounin.ru Tue Apr 13 15:42:01 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 13 Apr 2021 18:42:01 +0300 Subject: nginx-1.19.10 Message-ID: Изменения в nginx 1.19.10 13.04.2021 *) Изменение: в директиве keepalive_requests значение по умолчанию изменено на 1000. *) Добавление: директива keepalive_time. *) Добавление: переменная $connection_time. *) Изменение: при использовании zlib-ng в логах появлялись сообщения "gzip filter failed to use preallocated memory". -- Maxim Dounin http://nginx.org/ From vas на sibptus.ru Wed Apr 14 05:49:53 2021 From: vas на sibptus.ru (Victor Sudakov) Date: Wed, 14 Apr 2021 12:49:53 +0700 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: <20210413120801.GX1073@zxy.spb.ru> References: <20210413120801.GX1073@zxy.spb.ru> Message-ID: Slawa Olhovchenkov wrote: > On Tue, Apr 13, 2021 at 02:46:57PM +0700, Victor Sudakov wrote: > > > greenh wrote: > > > Nginx закроет соединение, а php код будет работать до того момента, пока не > > > наступит max_time_limit в самом пхп, либо, если он будет установлен в 0 - > > > то безконечно. > > > > Вот это плохо. > > > > А почему так? Ведь обычная программа (не демон), как правило, > > завершается или хотя бы останавливается, если ей каналы ввода-вывода > > закрыли. > > да нет же. > это твои влажные фантазии. Слава, грубить-то зачем? Не с той ноги встал? -- Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49 на fidonet From vas на sibptus.ru Thu Apr 15 05:02:31 2021 From: vas на sibptus.ru (Victor Sudakov) Date: Thu, 15 Apr 2021 12:02:31 +0700 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: References: Message-ID: Maxim Dounin wrote: > > On Tue, Apr 13, 2021 at 02:52:00PM +0700, Victor Sudakov wrote: > > > Aleksandr Sytar wrote: > > > > > > > Что должно > > > > произойти, когда пользователь отменил HTTP запрос, или браузер закрыл? > > > > nginx закроет соответствующее соединение с php-fpm ? А PHP-код продолжит > > > > работу? Или должен прерваться? > > > > > > > > Прошу прощения за сумбурное изложение, поправки и указания на неверное > > > > понимание логики работы с благодарностью принимаются. > > > > > > > > > > > > > > > Раз - https://habr.com/ru/post/179399/ > > > Двас - https://www.php.net/manual/ru/function.fastcgi-finish-request.php и > > > крути себе дальше в базе что надо. > > > > Я наверное плохо сформулировал вопрос, но мне как раз интересно видеть > > обратное поведение. Закрыли браузер - обслуживавший этот сеанс процесс > > PHP завершился, что бы ни делал в этот момент. > > > > А в приведенных ссылках обратную задачу пытаются решить. > > Прямая задача, как я понимаю, нормально решается только в случае, > если php-скрипт что-то возвращает клиенту, подробнее тут: > > https://www.php.net/manual/en/features.connection-handling.php Спасибо, Maxim, очень полезная ссылка. Я в первом письме так и предполагал, как должно происходить (см. последнюю строчку цитаты): "If the remote client disconnects, the ABORTED state flag is turned on. A remote client disconnect is usually caused by users hitting their STOP button. [...] You can decide whether or not you want a client disconnect to cause your script to be aborted. Sometimes it is handy to always have your scripts run to completion even if there is no remote browser receiving the output. The default behaviour is however for your script to be aborted when the remote client disconnects. " Другой вопрос, почему в наблюдаемом мной случае это не происходило. Пойду посмотрю код, может там действительно какой-нибудь ignore_user_abort стоит. В php.ini уже проверил, ignore_user_abort => Off => Off > https://www.php.net/manual/en/function.ignore-user-abort.php > https://www.php.net/manual/en/function.connection-aborted.php > > Но я не настоящий сварщик, про php знаю мало. > > > Антиоффтопик. nginx-то что делает в момент закрытия соединения > > клиентским браузером: закрывает ли соответствущее соединение с fastcgi > > upstream-ом? > > В общем случае да. И именно для того, чтобы бэкенд узнал о том, > что соединение закрыто клиентом и выполняемая работа больше не > нужна. Так и предполагал. > Если этого по каким-то не требуется, то можно использовать > директиву fastcgi_ignore_client_abort: > > http://nginx.org/r/fastcgi_ignore_client_abort > > Кроме того, соединение не будет закрыто, если используется > кэширование или fastcgi_store, так как в этих случаях ответ > бэкенда полезен вне зависимости от того, будет ли он отправлен > конкретному клиенту. А может и кэширование причиной. Но стало понятнее, куда копать, спасибо еще раз. -- Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49 на fidonet From vas на sibptus.ru Thu Apr 15 05:02:56 2021 From: vas на sibptus.ru (Victor Sudakov) Date: Thu, 15 Apr 2021 12:02:56 +0700 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: References: Message-ID: greenh wrote: > вт, 13 апр. 2021 г. в 13:28, Victor Sudakov : > > > greenh wrote: > > > Боюсь ошибиться, но я думаю что он (когда узнает о том, что браузер сдох) > > > просто перестанет ждать ответа на запрос от пхп но: пхп останется жить, > > его > > > процесс останется запущен, сокет, который он слушает останется активным и > > > процессы внутри его продолжат работу. > > > > Почему бы сокет останется активным, если nginx закрыл соединение к > > апстриму? Или nginx не закрывает соединение к апстриму, когда "браузер > > сдох"? > > > Сокет останется открытым, а не соединение Не понял поправку, можно пояснить мысль? -- Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49 на fidonet From nginx-forum на forum.nginx.org Thu Apr 15 13:27:34 2021 From: nginx-forum на forum.nginx.org (Trecolom) Date: Thu, 15 Apr 2021 09:27:34 -0400 Subject: =?UTF-8?B?0JLQsNGA0L3QuNC90LPQuCDQv9C+0YHQu9C1INC/0LXRgNC10YXQvtC00LAg0L0=?= =?UTF-8?B?0LAgUEhQIDg=?= Message-ID: Добрый день! После перехода на 8 версию PHP Nginx стал сыпать предупреждениями: *84085 upstream sent more data than specified in "Content-Length" header while reading upstream, client: 66.249.76.60, server: ..... Прчем, предупреждения появляться только после посещения страниц сайта поисковиками (в основном - ботами Google). В сети нашел совет отключить буферизацию: proxy_buffering off; Но не думаю, что это верное решение. Возможно, на этом форуме мне помогут решить эту проблему? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291263,291263#msg-291263 From mdounin на mdounin.ru Thu Apr 15 14:00:13 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 15 Apr 2021 17:00:13 +0300 Subject: =?UTF-8?B?UmU6INCS0LDRgNC90LjQvdCz0Lgg0L/QvtGB0LvQtSDQv9C10YDQtdGF0L7QtNCw?= =?UTF-8?B?INC90LAgUEhQIDg=?= In-Reply-To: References: Message-ID: Hello! On Thu, Apr 15, 2021 at 09:27:34AM -0400, Trecolom wrote: > Добрый день! > После перехода на 8 версию PHP Nginx стал сыпать предупреждениями: > > *84085 upstream sent more data than specified in "Content-Length" header > while reading upstream, client: 66.249.76.60, server: ..... > > Прчем, предупреждения появляться только после посещения страниц сайта > поисковиками (в основном - ботами Google). > > В сети нашел совет отключить буферизацию: > > proxy_buffering off; > > Но не думаю, что это верное решение. Возможно, на этом форуме мне помогут > решить эту проблему? Проблема в вашем бэкенде, который пишет в Content-Length одно, а в реальности пытается вернуть больше данных (или же пытается возвращать данные в ответах с кодами 204 или 304, где тела не должно быть вообще). Соответственно правильное решение - найти, где бэкенд косячит, и исправить. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Thu Apr 15 14:20:48 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 15 Apr 2021 17:20:48 +0300 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: References: Message-ID: Hello! On Thu, Apr 15, 2021 at 12:02:31PM +0700, Victor Sudakov wrote: > Maxim Dounin wrote: > > > > On Tue, Apr 13, 2021 at 02:52:00PM +0700, Victor Sudakov wrote: > > > > > Aleksandr Sytar wrote: > > > > > > > > > Что должно > > > > > произойти, когда пользователь отменил HTTP запрос, или браузер закрыл? > > > > > nginx закроет соответствующее соединение с php-fpm ? А PHP-код продолжит > > > > > работу? Или должен прерваться? > > > > > > > > > > Прошу прощения за сумбурное изложение, поправки и указания на неверное > > > > > понимание логики работы с благодарностью принимаются. > > > > > > > > > > > > > > > > > > > Раз - https://habr.com/ru/post/179399/ > > > > Двас - https://www.php.net/manual/ru/function.fastcgi-finish-request.php и > > > > крути себе дальше в базе что надо. > > > > > > Я наверное плохо сформулировал вопрос, но мне как раз интересно видеть > > > обратное поведение. Закрыли браузер - обслуживавший этот сеанс процесс > > > PHP завершился, что бы ни делал в этот момент. > > > > > > А в приведенных ссылках обратную задачу пытаются решить. > > > > Прямая задача, как я понимаю, нормально решается только в случае, > > если php-скрипт что-то возвращает клиенту, подробнее тут: > > > > https://www.php.net/manual/en/features.connection-handling.php > > Спасибо, Maxim, очень полезная ссылка. Я в первом письме так и > предполагал, как должно происходить (см. последнюю строчку цитаты): > > "If the remote client disconnects, the ABORTED state flag is turned on. > A remote client disconnect is usually caused by users hitting their STOP > button. [...] You can decide whether or not you want a client disconnect > to cause your script to be aborted. Sometimes it is handy to always have > your scripts run to completion even if there is no remote browser > receiving the output. The default behaviour is however for your script > to be aborted when the remote client disconnects. " > > Другой вопрос, почему в наблюдаемом мной случае это не происходило. > Пойду посмотрю код, может там действительно какой-нибудь > ignore_user_abort стоит. В php.ini уже проверил, > ignore_user_abort => Off => Off Отмечу ещё раз, что всё это работает только в том случае, если php-скрипт что-то возвращает клиенту, и даже в этом случае нужны приседания. Об этом, в частности, рассказывается в комментариях к описанию connection_aborted(). То есть исходная задача "скрипт ждёт ответа базы 3 часа" - в php просто так не решается. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Thu Apr 15 15:37:27 2021 From: nginx-forum на forum.nginx.org (Trecolom) Date: Thu, 15 Apr 2021 11:37:27 -0400 Subject: =?UTF-8?B?UmU6INCS0LDRgNC90LjQvdCz0Lgg0L/QvtGB0LvQtSDQv9C10YDQtdGF0L7QtNCw?= =?UTF-8?B?INC90LAgUEhQIDg=?= In-Reply-To: References: Message-ID: <70b6c2e1bd13fcca4903154b0b275fdb.NginxMailingListRussian@forum.nginx.org> Пока не могу сообразить, как подойти к решению этой задачи. До чего докопался - поисковик делает запрос на сайт с заголовком If-Modified-Since или If-None-Match и если контент страницы не изменился, движок отдает код "304 Not Modified" - именно в этом случае возникает ошибка. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291263,291267#msg-291267 From bgx на protva.ru Thu Apr 15 16:09:31 2021 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Thu, 15 Apr 2021 19:09:31 +0300 Subject: =?UTF-8?B?UmU6INCS0LDRgNC90LjQvdCz0Lgg0L/QvtGB0LvQtSDQv9C10YDQtdGF0L7QtNCw?= =?UTF-8?B?INC90LAgUEhQIDg=?= In-Reply-To: <70b6c2e1bd13fcca4903154b0b275fdb.NginxMailingListRussian@forum.nginx.org> References: <70b6c2e1bd13fcca4903154b0b275fdb.NginxMailingListRussian@forum.nginx.org> Message-ID: On Thu, Apr 15, 2021 at 11:37:27AM -0400, Trecolom wrote: > Пока не могу сообразить, как подойти к решению этой задачи. До чего > докопался - поисковик делает запрос на сайт с заголовком If-Modified-Since > или If-None-Match и если контент страницы не изменился, движок отдает код > "304 Not Modified" - именно в этом случае возникает ошибка. Посмотрите трафик, содержимое запроса и что выдаёт в ответ сервер. Ответ с кодом 304 должен иметь тело нулевой длины и "Content-Length: 0". Запрос можно положить в свой скрипт, чтобы выполнять его многократно и таким образом локализовать проблемный участок php-ного кода. Содержимое трафика можно получить с помощью tcpdump/wireshark/etc, но когда есть подозрение на заголовки, достаточно debug log от nginx. -- Eugene Berdnikov From nginx-forum на forum.nginx.org Thu Apr 15 16:33:10 2021 From: nginx-forum на forum.nginx.org (Trecolom) Date: Thu, 15 Apr 2021 12:33:10 -0400 Subject: =?UTF-8?B?UmU6INCS0LDRgNC90LjQvdCz0Lgg0L/QvtGB0LvQtSDQv9C10YDQtdGF0L7QtNCw?= =?UTF-8?B?INC90LAgUEhQIDg=?= In-Reply-To: References: Message-ID: Спасибо, что "ткнули носом"! Общее направление я понял, буду разбираться. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291263,291269#msg-291269 From nginx-forum на forum.nginx.org Thu Apr 15 18:21:27 2021 From: nginx-forum на forum.nginx.org (Trecolom) Date: Thu, 15 Apr 2021 14:21:27 -0400 Subject: =?UTF-8?B?UmU6INCS0LDRgNC90LjQvdCz0Lgg0L/QvtGB0LvQtSDQv9C10YDQtdGF0L7QtNCw?= =?UTF-8?B?INC90LAgUEhQIDg=?= In-Reply-To: References: Message-ID: <633578faf3087129af8e9c2cf1b0def0.NginxMailingListRussian@forum.nginx.org> Вот ответ сервера в сервисе "Проверка ответа сервера" Яндекса при отправке заголовка If-Modified-Since: Код статуса HTTP 304 Not Modified Время ответа сервера 109 мс IP сайта - Размер страницы 0 Б И в логах есть варнинг. А это ответ без заголовка If-Modified-Since (и без варнинга): Код статуса HTTP 200 OK Время ответа сервера 142 мс IP сайта - Кодировка UTF-8(unicode-1-1-utf-8, UTF8) Размер страницы 118,71 КБ Все работает правильно. Попробую дебаг в Nginx включить, посмотреть, что он покажет. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291263,291270#msg-291270 From vas на sibptus.ru Fri Apr 16 05:54:21 2021 From: vas на sibptus.ru (Victor Sudakov) Date: Fri, 16 Apr 2021 12:54:21 +0700 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: References: Message-ID: Maxim Dounin wrote: > > > > Я наверное плохо сформулировал вопрос, но мне как раз интересно видеть > > > > обратное поведение. Закрыли браузер - обслуживавший этот сеанс процесс > > > > PHP завершился, что бы ни делал в этот момент. > > > > > > > > А в приведенных ссылках обратную задачу пытаются решить. > > > > > > Прямая задача, как я понимаю, нормально решается только в случае, > > > если php-скрипт что-то возвращает клиенту, подробнее тут: > > > > > > https://www.php.net/manual/en/features.connection-handling.php > > > > Спасибо, Maxim, очень полезная ссылка. Я в первом письме так и > > предполагал, как должно происходить (см. последнюю строчку цитаты): > > > > "If the remote client disconnects, the ABORTED state flag is turned on. > > A remote client disconnect is usually caused by users hitting their STOP > > button. [...] You can decide whether or not you want a client disconnect > > to cause your script to be aborted. Sometimes it is handy to always have > > your scripts run to completion even if there is no remote browser > > receiving the output. The default behaviour is however for your script > > to be aborted when the remote client disconnects. " > > > > Другой вопрос, почему в наблюдаемом мной случае это не происходило. > > Пойду посмотрю код, может там действительно какой-нибудь > > ignore_user_abort стоит. В php.ini уже проверил, > > ignore_user_abort => Off => Off > > Отмечу ещё раз, что всё это работает только в том случае, если > php-скрипт что-то возвращает клиенту, и даже в этом случае нужны > приседания. А если php-скрипт ничего не возвращает клиенту, а делает sleep(100500) внутри себя, и при этом nginx закрывает соединение со скриптом, connection-status в скрипте не перейдет в состояние ABORTED? Предположим что nginx закрывает TCP-соединение с апстримом штатно (FIN -> FIN+ACK -> ACK). Или оно вообще было через Unix-socket. Таки connection-status в скрипте всё равно останется NORMAL до попытки вернуть клиенту какие-то данные? > Об этом, в частности, рассказывается в комментариях к > описанию connection_aborted(). То есть исходная задача "скрипт > ждёт ответа базы 3 часа" - в php просто так не решается. Исходная как раз чтобы php-скрипт ничего не ждал и помирал побыстрее, если nginx соединение с ним закрыл. -- Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49 на fidonet From bgx на protva.ru Fri Apr 16 06:33:31 2021 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 16 Apr 2021 09:33:31 +0300 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: References: Message-ID: On Fri, Apr 16, 2021 at 12:54:21PM +0700, Victor Sudakov wrote: > А если php-скрипт ничего не возвращает клиенту, а делает sleep(100500) > внутри себя, и при этом nginx закрывает соединение со скриптом, > connection-status в скрипте не перейдет в состояние ABORTED? В скрипте (пользовательском процессе с php) не существует connection-status. Статус коннекции есть в ядре, и для закрытой с одной стороны коннекции он будет "half closed", т.е. на стороне получателя FINa перейдёт в состояние CLOSE_WAIT. Смотрите диаграмму состояний TCP в RFC 793. > Предположим что nginx закрывает TCP-соединение с апстримом штатно (FIN > -> FIN+ACK -> ACK). Или оно вообще было через Unix-socket. Таки > connection-status в скрипте всё равно останется NORMAL до попытки > вернуть клиенту какие-то данные? Повторю: состояние коннекции находится в ядре. Есть интерфейс общения процесса и ядра. Если процесс попытается написать в сокет, для которого другая сторона закрыла коннекцию, то ему ядро вернёт ECONNRESET. > > Об этом, в частности, рассказывается в комментариях к > > описанию connection_aborted(). То есть исходная задача "скрипт > > ждёт ответа базы 3 часа" - в php просто так не решается. > > Исходная как раз чтобы php-скрипт ничего не ждал и помирал побыстрее, если > nginx соединение с ним закрыл. Для мониторинга состояния коннекции есть poll/epoll/kqueue/etc, как уже писали в этом треде. Но делать такой мониторинг непросто: нужно ловить событие "коннекция закрыта с той стороны" и писать его обработчик, возможно искать способы безопасного прерывания кода, работающего 3 часа. -- Eugene Berdnikov From gmm на csdoc.com Fri Apr 16 06:52:54 2021 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 16 Apr 2021 09:52:54 +0300 Subject: =?UTF-8?B?bmdpbng6IHdvcmtlciBwcm9jZXNzYNGLINC90LDQt9GL0LLQsNGO0YLRgdGPIG5n?= =?UTF-8?B?aW54OiBtYXN0ZXIgcHJvY2Vzcw==?= Message-ID: <9a2eceb0-26d4-98ef-d187-897dd7188710@csdoc.com> Здравствуйте, All! После перезапуска сервера htop показывает: └─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf ├─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf ├─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf ├─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf └─ nginx: worker process После ручного systemctl restart nginx все стало нормально: └─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf ├─ nginx: worker process ├─ nginx: worker process ├─ nginx: worker process └─ nginx: worker process Это какая-то ошибка в коде nginx, что переименование процессов не всегда срабатывает? -- Best regards, Gena From nginx-forum на forum.nginx.org Fri Apr 16 07:07:54 2021 From: nginx-forum на forum.nginx.org (Trecolom) Date: Fri, 16 Apr 2021 03:07:54 -0400 Subject: =?UTF-8?B?UmU6INCS0LDRgNC90LjQvdCz0Lgg0L/QvtGB0LvQtSDQv9C10YDQtdGF0L7QtNCw?= =?UTF-8?B?INC90LAgUEhQIDg=?= In-Reply-To: <633578faf3087129af8e9c2cf1b0def0.NginxMailingListRussian@forum.nginx.org> References: <633578faf3087129af8e9c2cf1b0def0.NginxMailingListRussian@forum.nginx.org> Message-ID: Что я выяснил. Скрипт сайта, в ответ на запрос с заголовком "If-Modified-Since" отдает Nginx-су заголовок "Content-Length 0" и не нулевые данные. Отсюда и варнинг. Скрипт делает все верно, и Nginx отвечает верно. Но как убрать это предупреждение? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291263,291278#msg-291278 From bgx на protva.ru Fri Apr 16 07:14:54 2021 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 16 Apr 2021 10:14:54 +0300 Subject: =?UTF-8?B?UmU6INCS0LDRgNC90LjQvdCz0Lgg0L/QvtGB0LvQtSDQv9C10YDQtdGF0L7QtNCw?= =?UTF-8?B?INC90LAgUEhQIDg=?= In-Reply-To: References: <633578faf3087129af8e9c2cf1b0def0.NginxMailingListRussian@forum.nginx.org> Message-ID: On Fri, Apr 16, 2021 at 03:07:54AM -0400, Trecolom wrote: > Что я выяснил. Скрипт сайта, в ответ на запрос с заголовком > "If-Modified-Since" отдает Nginx-су заголовок "Content-Length 0" и не > нулевые данные. Отсюда и варнинг. > Скрипт делает все верно, Нет. При "Content-Length: 0" тело должно содержать ноль байт. То есть никаких данных быть не должно, скрипт работает неправильно. -- Eugene Berdnikov From vovansystems на gmail.com Fri Apr 16 07:16:32 2021 From: vovansystems на gmail.com (VovansystemS) Date: Fri, 16 Apr 2021 10:16:32 +0300 Subject: =?UTF-8?B?UmU6INCS0LDRgNC90LjQvdCz0Lgg0L/QvtGB0LvQtSDQv9C10YDQtdGF0L7QtNCw?= =?UTF-8?B?INC90LAgUEhQIDg=?= In-Reply-To: References: <633578faf3087129af8e9c2cf1b0def0.NginxMailingListRussian@forum.nginx.org> Message-ID: > Скрипт сайта, в ответ на запрос с заголовком > "If-Modified-Since" отдает Nginx-су заголовок "Content-Length 0" и не > нулевые данные. Скрипт делает все верно почему верно? в RFC 2616 написано, что: 14.13 Content-Length The Content-Length entity-header field indicates the size of the entity-body, in decimal number of OCTETs, sent to the recipient or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET. https://tools.ietf.org/html/rfc2616#page-119 если Вы объявляете, что "Content-Length: 0" , то никакого тела в ответе быть не должно. Если тело есть, то в "Content-Length: ХХ" нужно указать его размер. Также допускается опустить этот заголовок, если конкретный размер тела неизвестен на момент начала передачи, насколько я понимаю. From chipitsine на gmail.com Fri Apr 16 07:17:21 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 16 Apr 2021 12:17:21 +0500 Subject: =?UTF-8?B?UmU6INCS0LDRgNC90LjQvdCz0Lgg0L/QvtGB0LvQtSDQv9C10YDQtdGF0L7QtNCw?= =?UTF-8?B?INC90LAgUEhQIDg=?= In-Reply-To: References: <633578faf3087129af8e9c2cf1b0def0.NginxMailingListRussian@forum.nginx.org> Message-ID: Content-Length не обязателен. Можете не передавать его вовсе On Fri, Apr 16, 2021, 12:08 PM Trecolom wrote: > Что я выяснил. Скрипт сайта, в ответ на запрос с заголовком > "If-Modified-Since" отдает Nginx-су заголовок "Content-Length 0" и не > нулевые данные. Отсюда и варнинг. > Скрипт делает все верно, и Nginx отвечает верно. Но как убрать это > предупреждение? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,291263,291278#msg-291278 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vas на sibptus.ru Fri Apr 16 07:27:53 2021 From: vas на sibptus.ru (Victor Sudakov) Date: Fri, 16 Apr 2021 14:27:53 +0700 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: References: Message-ID: Evgeniy Berdnikov wrote: > On Fri, Apr 16, 2021 at 12:54:21PM +0700, Victor Sudakov wrote: > > А если php-скрипт ничего не возвращает клиенту, а делает sleep(100500) > > внутри себя, и при этом nginx закрывает соединение со скриптом, > > connection-status в скрипте не перейдет в состояние ABORTED? > > В скрипте (пользовательском процессе с php) не существует connection-status. А в https://www.php.net/manual/en/features.connection-handling.php написано что существует. > Статус коннекции есть в ядре, и для закрытой с одной стороны коннекции > он будет "half closed", т.е. на стороне получателя FINa перейдёт в > состояние CLOSE_WAIT. Смотрите диаграмму состояний TCP в RFC 793. Это в данном случае не важно. Я говорю о connection status, который доступен в PHP, на уровне приложения, по ссылке выше. > > > Предположим что nginx закрывает TCP-соединение с апстримом штатно (FIN > > -> FIN+ACK -> ACK). Или оно вообще было через Unix-socket. Таки > > connection-status в скрипте всё равно останется NORMAL до попытки > > вернуть клиенту какие-то данные? > > Повторю: состояние коннекции находится в ядре. Есть интерфейс общения > процесса и ядра. Если процесс попытается написать в сокет, для которого > другая сторона закрыла коннекцию, то ему ядро вернёт ECONNRESET. Понятно что php откуда-то узнаёт информацию о состоянии соединения, но с точки зрения php there are 4 possible states: 0 - NORMAL 1 - ABORTED 2 - TIMEOUT 3 - ABORTED and TIMEOUT When a PHP script is running normally, the NORMAL state is active. If the remote client disconnects, the ABORTED state flag is turned on. A remote client disconnect is usually caused by users hitting their STOP button. Вот PHP эти состояния переключает на основе какой-то информации, скорее всего действительно от ядра. Когда состояние становится ABORTED, скрипт должен по идее завершиться. В документации написано, что когда "remote user hits his STOP button, the next time your script tries to output something PHP will detect that the connection has been aborted and the shutdown function is called." Из этого можно заключить, что если не пытаться что-то из скрипта выводить, то ABORTED никогда не наступит. Это верное утверждение? > Для мониторинга состояния коннекции есть poll/epoll/kqueue/etc, как уже > писали в этом треде. Но делать такой мониторинг непросто: нужно ловить > событие "коннекция закрыта с той стороны" и писать его обработчик, Диаграмма состояний TCP и прочие его тонкости в контексте данной беседы без надобности. Можно вообще оговорить, что FastCGI через Unix socket работает, суть вопроса не изменится. > возможно искать способы безопасного прерывания кода, работающего 3 часа. Для этого уже предусмотрели shutdown function, насколько я понимаю. Вопрос не в этом, а в реакции php-fpm на нажатие пользователем кнопки Стоп в браузере - в какой момент это нажатие отразится в состояние ABORTED в скрипте? -- Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49 на fidonet From bgx на protva.ru Fri Apr 16 08:38:29 2021 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 16 Apr 2021 11:38:29 +0300 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: References: Message-ID: On Fri, Apr 16, 2021 at 02:27:53PM +0700, Victor Sudakov wrote: > Evgeniy Berdnikov wrote: > > В скрипте (пользовательском процессе с php) не существует connection-status. > > А в https://www.php.net/manual/en/features.connection-handling.php > написано что существует. ... > В документации написано, что когда "remote user hits his STOP button, > the next time your script tries to output something PHP will detect that > the connection has been aborted and the shutdown function is called." > > Из этого можно заключить, что если не пытаться что-то из скрипта > выводить, то ABORTED никогда не наступит. Это верное утверждение? Это верный признак того, что к тому что написано на этой страничке нужно относиться с большой осторожностью, раз уж там разные абзацы между собой в противоречии. Главное на этой страничке вот что: The default behaviour is however for your script to be aborted when the remote client disconnects. [...] If you do not tell PHP to ignore a user abort and the user aborts, your script will terminate. Теоретически это реализуемо, так что предлагаю проверить утверждение на чистой инсталляции php со скриптом-пустышкой, уходящим в сон на 3 часа, и если написанное выполняется, то разбираться далее с боевыми скриптами. -- Eugene Berdnikov From mdounin на mdounin.ru Fri Apr 16 14:54:37 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 16 Apr 2021 17:54:37 +0300 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: References: Message-ID: Hello! On Fri, Apr 16, 2021 at 12:54:21PM +0700, Victor Sudakov wrote: > Maxim Dounin wrote: > > > > > > Я наверное плохо сформулировал вопрос, но мне как раз интересно видеть > > > > > обратное поведение. Закрыли браузер - обслуживавший этот сеанс процесс > > > > > PHP завершился, что бы ни делал в этот момент. > > > > > > > > > > А в приведенных ссылках обратную задачу пытаются решить. > > > > > > > > Прямая задача, как я понимаю, нормально решается только в случае, > > > > если php-скрипт что-то возвращает клиенту, подробнее тут: > > > > > > > > https://www.php.net/manual/en/features.connection-handling.php > > > > > > Спасибо, Maxim, очень полезная ссылка. Я в первом письме так и > > > предполагал, как должно происходить (см. последнюю строчку цитаты): > > > > > > "If the remote client disconnects, the ABORTED state flag is turned on. > > > A remote client disconnect is usually caused by users hitting their STOP > > > button. [...] You can decide whether or not you want a client disconnect > > > to cause your script to be aborted. Sometimes it is handy to always have > > > your scripts run to completion even if there is no remote browser > > > receiving the output. The default behaviour is however for your script > > > to be aborted when the remote client disconnects. " > > > > > > Другой вопрос, почему в наблюдаемом мной случае это не происходило. > > > Пойду посмотрю код, может там действительно какой-нибудь > > > ignore_user_abort стоит. В php.ini уже проверил, > > > ignore_user_abort => Off => Off > > > > Отмечу ещё раз, что всё это работает только в том случае, если > > php-скрипт что-то возвращает клиенту, и даже в этом случае нужны > > приседания. > > А если php-скрипт ничего не возвращает клиенту, а делает sleep(100500) > внутри себя, и при этом nginx закрывает соединение со скриптом, > connection-status в скрипте не перейдет в состояние ABORTED? > > Предположим что nginx закрывает TCP-соединение с апстримом штатно (FIN > -> FIN+ACK -> ACK). Или оно вообще было через Unix-socket. Таки > connection-status в скрипте всё равно останется NORMAL до попытки > вернуть клиенту какие-то данные? Именно об этом рассказано в комментариях, их стоит почитать. И это логично: чтобы отследить закрытие соединения, нужно явно проверять статус этого самого соединения или ждать событий на нём. Это сложно и малореализуемо в рамках php с блокирующимися вызовами. Могли бы сделать явную проверку через какой-нибудь recv(MSG_PEEK) непосредственно в функции connection_aborted(), но, видимо, не стали. В результате о том, что соединение закрыто, php узнаёт, только когда попытка записи ответа в соединение возвращает ошибку. > > Об этом, в частности, рассказывается в комментариях к > > описанию connection_aborted(). То есть исходная задача "скрипт > > ждёт ответа базы 3 часа" - в php просто так не решается. > > Исходная как раз чтобы php-скрипт ничего не ждал и помирал побыстрее, если > nginx соединение с ним закрыл. Да, именно об этом и речь: если скрипт просто ждёт ответа базы, то php с ним ничего делать не будет и не прибьёт его, что бы не происходило с соединением. Если что-то выводит пользователю - то есть шанс. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Fri Apr 16 15:42:18 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 16 Apr 2021 18:42:18 +0300 Subject: =?UTF-8?B?UmU6IG5naW54OiB3b3JrZXIgcHJvY2Vzc2DRiyDQvdCw0LfRi9Cy0LDRjtGC0YE=?= =?UTF-8?B?0Y8gbmdpbng6IG1hc3RlciBwcm9jZXNz?= In-Reply-To: <9a2eceb0-26d4-98ef-d187-897dd7188710@csdoc.com> References: <9a2eceb0-26d4-98ef-d187-897dd7188710@csdoc.com> Message-ID: Hello! On Fri, Apr 16, 2021 at 09:52:54AM +0300, Gena Makhomed wrote: > Здравствуйте, > All! > > После перезапуска сервера htop показывает: > > └─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > ├─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > ├─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > ├─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > └─ nginx: worker process > > После ручного > systemctl restart nginx все стало > нормально: > > └─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > ├─ nginx: worker process > ├─ nginx: worker process > ├─ nginx: worker process > └─ nginx: worker process > > Это какая-то ошибка в коде nginx, > что переименование процессов не всегда срабатывает? Скорее процессы повисли где-то на запуске. Я такое наблюдал при прикрученном на серверах LDAP'е для пользователей/групп, который не работал, и соответственно запуск рабочих процессов вис где-то в районе setgid() / initgroups() / setuid(). -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Fri Apr 16 17:45:15 2021 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 16 Apr 2021 20:45:15 +0300 Subject: =?UTF-8?B?UmU6IG5naW54OiB3b3JrZXIgcHJvY2Vzc2DRiyDQvdCw0LfRi9Cy0LDRjtGC0YE=?= =?UTF-8?B?0Y8gbmdpbng6IG1hc3RlciBwcm9jZXNz?= In-Reply-To: References: <9a2eceb0-26d4-98ef-d187-897dd7188710@csdoc.com> Message-ID: On 16.04.2021 18:42, Maxim Dounin wrote: >> После перезапуска сервера htop показывает: >> >> └─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf >> ├─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf >> ├─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf >> ├─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf >> └─ nginx: worker process >> >> После ручного systemctl restart nginx все стало нормально: >> >> └─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf >> ├─ nginx: worker process >> ├─ nginx: worker process >> ├─ nginx: worker process >> └─ nginx: worker process >> >> Это какая-то ошибка в коде nginx, >> что переименование процессов не всегда срабатывает? > Скорее процессы повисли где-то на запуске. Я такое наблюдал при > прикрученном на серверах LDAP'е для пользователей/групп, который > не работал, и соответственно запуск рабочих процессов вис где-то > в районе setgid() / initgroups() / setuid(). Там используются бинарные сборки с сайта nginx.org, версия 1.19.10 без сторонних и стандартных модулей. В конфигах nginx тоже нет ничего нетривиального, используется несколько mediawiki сайтов. Если такая ситуация повторится в будущем - что мне следует сделать, для того чтобы найти причину этого глюка с непереименованием процессов? -- Best regards, Gena From mdounin на mdounin.ru Fri Apr 16 20:30:25 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 16 Apr 2021 23:30:25 +0300 Subject: =?UTF-8?B?UmU6IG5naW54OiB3b3JrZXIgcHJvY2Vzc2DRiyDQvdCw0LfRi9Cy0LDRjtGC0YE=?= =?UTF-8?B?0Y8gbmdpbng6IG1hc3RlciBwcm9jZXNz?= In-Reply-To: References: <9a2eceb0-26d4-98ef-d187-897dd7188710@csdoc.com> Message-ID: Hello! On Fri, Apr 16, 2021 at 08:45:15PM +0300, Gena Makhomed wrote: > On 16.04.2021 18:42, Maxim Dounin wrote: > > >> После перезапуска сервера htop показывает: > >> > >> └─ nginx: master process /usr/sbin/nginx -c > >> /etc/nginx/nginx.conf > >> ├─ nginx: master process /usr/sbin/nginx -c > >> /etc/nginx/nginx.conf > >> ├─ nginx: master process /usr/sbin/nginx -c > >> /etc/nginx/nginx.conf > >> ├─ nginx: master process /usr/sbin/nginx -c > >> /etc/nginx/nginx.conf > >> └─ nginx: worker process > >> > >> После ручного systemctl restart nginx все стало нормально: > >> > >> └─ nginx: master process /usr/sbin/nginx -c > >> /etc/nginx/nginx.conf > >> ├─ nginx: worker process > >> ├─ nginx: worker process > >> ├─ nginx: worker process > >> └─ nginx: worker process > >> > >> Это какая-то ошибка в коде nginx, > >> что переименование процессов не всегда срабатывает? > > > Скорее процессы повисли где-то на запуске. Я такое наблюдал > > при прикрученном на серверах LDAP'е для пользователей/групп, > > который не работал, и соответственно запуск рабочих процессов > > вис где-то в районе setgid() / initgroups() / setuid(). > > Там используются бинарные сборки с сайта nginx.org, версия > 1.19.10 без сторонних и стандартных модулей. В конфигах nginx > тоже нет ничего нетривиального, используется несколько mediawiki > сайтов. Если такая ситуация повторится в будущем - что мне > следует сделать, для того чтобы найти причину этого глюка с > непереименованием процессов? > -- Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Fri Apr 16 20:34:08 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 16 Apr 2021 23:34:08 +0300 Subject: =?UTF-8?B?UmU6IG5naW54OiB3b3JrZXIgcHJvY2Vzc2DRiyDQvdCw0LfRi9Cy0LDRjtGC0YE=?= =?UTF-8?B?0Y8gbmdpbng6IG1hc3RlciBwcm9jZXNz?= In-Reply-To: References: <9a2eceb0-26d4-98ef-d187-897dd7188710@csdoc.com> Message-ID: Hello! On Fri, Apr 16, 2021 at 08:45:15PM +0300, Gena Makhomed wrote: > On 16.04.2021 18:42, Maxim Dounin wrote: > > >> После перезапуска сервера htop показывает: > >> > >> └─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > >> ├─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > >> ├─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > >> ├─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > >> └─ nginx: worker process > >> > >> После ручного systemctl restart nginx все стало нормально: > >> > >> └─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > >> ├─ nginx: worker process > >> ├─ nginx: worker process > >> ├─ nginx: worker process > >> └─ nginx: worker process > >> > >> Это какая-то ошибка в коде nginx, > >> что переименование процессов не всегда срабатывает? > > > Скорее процессы повисли где-то на запуске. Я такое наблюдал > > при прикрученном на серверах LDAP'е для пользователей/групп, > > который не работал, и соответственно запуск рабочих процессов > > вис где-то в районе setgid() / initgroups() / setuid(). > > Там используются бинарные сборки с сайта nginx.org, версия > 1.19.10 без сторонних и стандартных модулей. В конфигах nginx > тоже нет ничего нетривиального, используется несколько mediawiki > сайтов. Не важно, откуда сборки nginx'а и что в конфигах, важно - что в настройках системы. Ну то есть для того, чтобы завесить nginx при смене пользователя - вполне хватает настроенного в системе LDAP'а. > Если такая ситуация повторится в будущем - что мне следует > сделать, для того чтобы найти причину этого глюка с > непереименованием процессов? Смотреть дебаггером стек процессов, там будет всё понятно. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Sat Apr 17 14:15:22 2021 From: nginx-forum на forum.nginx.org (Trecolom) Date: Sat, 17 Apr 2021 10:15:22 -0400 Subject: =?UTF-8?B?UmU6INCS0LDRgNC90LjQvdCz0Lgg0L/QvtGB0LvQtSDQv9C10YDQtdGF0L7QtNCw?= =?UTF-8?B?INC90LAgUEhQIDg=?= In-Reply-To: References: Message-ID: Разобрался более детально. Движок сайта заголовок Content-Length не передает вообще. Я добавляю этот заголовок сразу после того места, где отдается заголовок 304 Not Modified и с помощью CURL смотрю заголовки - он появляется в выводе заголовков, котента нет. Но варнинг остается. Я ставлю Content-Length произвольного размера - он появляется в выводе заголовков варнинг не исчезает, котента нет. Но есть одна странность - этот варнинг возникает только тогда, когда версия протокола - HTTP/1.1 и ниже. Если протокол версии HTTP/2.0 - варнинга нет. Можно резюмировать то, что я нарыл: Заголовок Content-Length от движка Nginx-су не передается. Никаких лишних данных движок не передает. Ошибка возникает только в том случае, когда протокол HTTP/1.1 и ниже. Почему Nginx считает, что ему передали этот заголовок? И почему только на HTTP/1.1? Баг Nginx? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291263,291300#msg-291300 From nginx-forum на forum.nginx.org Sat Apr 17 14:43:20 2021 From: nginx-forum на forum.nginx.org (Trecolom) Date: Sat, 17 Apr 2021 10:43:20 -0400 Subject: =?UTF-8?B?UmU6INCS0LDRgNC90LjQvdCz0Lgg0L/QvtGB0LvQtSDQv9C10YDQtdGF0L7QtNCw?= =?UTF-8?B?INC90LAgUEhQIDg=?= In-Reply-To: References: Message-ID: <27f03eaea3d61cc57b0d18781080a14e.NginxMailingListRussian@forum.nginx.org> Разобрался более детально. Движок сайта заголовок Content-Length не передает вообще. Я добавляю этот заголовок сразу после того места, где отдается заголовок 304 Not Modified и с помощью CURL смотрю заголовки - он появляется в выводе заголовков, котента нет. Но варнинг остается. Я ставлю Content-Length произвольного размера - он появляется в выводе заголовков варнинг не исчезает, котента нет. Но есть одна странность - этот варнинг возникает только тогда, когда версия протокола - HTTP/1.1 и ниже. Если протокол версии HTTP/2.0 - варнинга нет. Можно резюмировать то, что я нарыл: Заголовок Content-Length от движка Nginx-су не передается. Никаких лишних данных движок не передает. Ошибка возникает только в том случае, когда протокол HTTP/1.1 и ниже. Почему Nginx считает, что ему передали этот заголовок? И почему только на HTTP/1.1? Баг Nginx? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291263,291302#msg-291302 From bgx на protva.ru Sat Apr 17 17:01:43 2021 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Sat, 17 Apr 2021 20:01:43 +0300 Subject: =?UTF-8?B?UmU6INCS0LDRgNC90LjQvdCz0Lgg0L/QvtGB0LvQtSDQv9C10YDQtdGF0L7QtNCw?= =?UTF-8?B?INC90LAgUEhQIDg=?= In-Reply-To: <27f03eaea3d61cc57b0d18781080a14e.NginxMailingListRussian@forum.nginx.org> References: <27f03eaea3d61cc57b0d18781080a14e.NginxMailingListRussian@forum.nginx.org> Message-ID: On Sat, Apr 17, 2021 at 10:43:20AM -0400, Trecolom wrote: > Можно резюмировать то, что я нарыл: > Заголовок Content-Length от движка Nginx-су не передается. > Никаких лишних данных движок не передает. > Ошибка возникает только в том случае, когда протокол HTTP/1.1 и ниже. Я бы предложил проверить эти выводы на скрипте-однострочнике, выводящем "304 Not Modified" и пустое тело. Для вариантов с Content-Length и без. -- Eugene Berdnikov From nginx-forum на forum.nginx.org Sat Apr 17 20:36:14 2021 From: nginx-forum на forum.nginx.org (Trecolom) Date: Sat, 17 Apr 2021 16:36:14 -0400 Subject: =?UTF-8?B?UmU6INCS0LDRgNC90LjQvdCz0Lgg0L/QvtGB0LvQtSDQv9C10YDQtdGF0L7QtNCw?= =?UTF-8?B?INC90LAgUEhQIDg=?= In-Reply-To: References: Message-ID: <634ae6798e694d10ee151b7204873c07.NginxMailingListRussian@forum.nginx.org> Evgeniy Berdnikov Wrote: ------------------------------------------------------- > Я бы предложил проверить эти выводы на скрипте-однострочнике, > выводящем > "304 Not Modified" и пустое тело. Для вариантов с Content-Length и > без. Спасибо, стоящая идея! Всё-таки движок передавал данные - протестировал кусок кода в простейшем скрипте - все работает правильно. Тогда начал "перелопачивать" код движка и нашёл, что выше функции header() передаются данные. Есть одно echo. Если проверку с выводом header() делать до этого echo - все работает без предупреждений от Nginx. Сам виноват - думал, данные обязательно будут передаваться после header(), а разрабы движка всунули данные до фунции header(). Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291263,291307#msg-291307 From chipitsine на gmail.com Tue Apr 20 11:43:58 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 20 Apr 2021 16:43:58 +0500 Subject: =?UTF-8?B?0LfQsNC/0YPRgdC6INGC0LXRgdGC0L7QsiBodHRwczovL2dpdGh1Yi5jb20vbmdp?= =?UTF-8?B?bngvbmdpbngtdGVzdHMg0YEg0LLQutC70Y7Rh9C10L3QvdGL0LwgQVNBTiAo?= =?UTF-8?B?YWRkcmVzcyBzYW5pdGl6ZXIp?= Message-ID: привет! занимаюсь тестированием 3rd parties модулей. один из вариантов тестирования - штатные тесты https://github.com/nginx/nginx-tests хотелось бы в том числе запускать их с ASAN. но на nginx без модулей сейчас получается вот так (половина тестов разваливается) ==3669==ERROR: LeakSanitizer: detected memory leaks Indirect leak of 221184 byte(s) in 3 object(s) allocated from: #0 0x5049a6 in __interceptor_malloc (/home/ilia/nginx-1.19.10/objs/nginx+0x5049a6) #1 0x5a11ff in ngx_alloc /home/ilia/nginx-1.19.10/src/os/unix/ngx_alloc.c:22:9 #2 0x5b0104 in ngx_worker_process_init /home/ilia/nginx-1.19.10/src/os/unix/ngx_process_cycle.c:900:17 #3 0x5af2c3 in ngx_worker_process_cycle /home/ilia/nginx-1.19.10/src/os/unix/ngx_process_cycle.c:704:5 #4 0x5ad797 in ngx_start_worker_processes /home/ilia/nginx-1.19.10/src/os/unix/ngx_process_cycle.c:344:9 #5 0x53866d in main /home/ilia/nginx-1.19.10/src/core/nginx.c:383:9 #6 0x7f1ec30db554 in __libc_start_main (/lib64/libc.so.6+0x22554) SUMMARY: AddressSanitizer: 221184 byte(s) leaked in 3 allocation(s). скажите, у вас есть практика запуска с asan ? воспроизвести ошибку выше можно примерно так (для CentOS 7) export NGINX_VERSION: 1.19.10 yum install -q -y epel-release yum install -q -y centos-release-scl-rh yum install -q -y devtoolset-9-toolchain devtoolset-9-libasan-devel yum install -q -y which wget make gcc git openssl-devel yum install -q -y "perl(Test::More)" 'perl(IO::Socket::SSL)' 'perl(Net::SSLeay)' 'perl(Protocol::WebSocket)' 'perl(IO::Compress::Gzip)' 'perl(JSON::PP)' groupadd -r nginx useradd -r -g nginx -d /var/cache/nginx nginx usermod -o -u 0 nginx groupmod -o -g 0 nginx wget http://nginx.org/download/nginx-${NGINX_VERSION}.tar.gz tar xf nginx-${NGINX_VERSION}.tar.gz cd nginx-${NGINX_VERSION} . /opt/rh/devtoolset-9/enable ./configure --with-debug --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-O1 -ggdb -fsanitize=address' --with-ld-opt='-fsanitize=address' make git clone https://github.com/nginx/nginx-tests cd nginx-tests TEST_NGINX_BINARY=${CI_PROJECT_DIR}/nginx-${NGINX_VERSION}/objs/nginx prove . ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From pluknet на nginx.com Tue Apr 20 13:27:31 2021 From: pluknet на nginx.com (Sergey Kandaurov) Date: Tue, 20 Apr 2021 16:27:31 +0300 Subject: =?UTF-8?B?UmU6INC30LDQv9GD0YHQuiDRgtC10YHRgtC+0LIgaHR0cHM6Ly9naXRodWIuY29t?= =?UTF-8?B?L25naW54L25naW54LXRlc3RzINGBINCy0LrQu9GO0YfQtdC90L3Ri9C8IEFT?= =?UTF-8?B?QU4gKGFkZHJlc3Mgc2FuaXRpemVyKQ==?= In-Reply-To: References: Message-ID: <8E503B59-F456-43B6-BEAF-0EC3B782AC15@nginx.com> > On 20 Apr 2021, at 14:43, Илья Шипицин wrote: > > привет! > > занимаюсь тестированием 3rd parties модулей. > один из вариантов тестирования - штатные тесты https://github.com/nginx/nginx-tests > > хотелось бы в том числе запускать их с ASAN. > > но на nginx без модулей сейчас получается вот так (половина тестов разваливается) > > ==3669==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 221184 byte(s) in 3 object(s) allocated from: > #0 0x5049a6 in __interceptor_malloc (/home/ilia/nginx-1.19.10/objs/nginx+0x5049a6) > #1 0x5a11ff in ngx_alloc /home/ilia/nginx-1.19.10/src/os/unix/ngx_alloc.c:22:9 > #2 0x5b0104 in ngx_worker_process_init /home/ilia/nginx-1.19.10/src/os/unix/ngx_process_cycle.c:900:17 > #3 0x5af2c3 in ngx_worker_process_cycle /home/ilia/nginx-1.19.10/src/os/unix/ngx_process_cycle.c:704:5 > #4 0x5ad797 in ngx_start_worker_processes /home/ilia/nginx-1.19.10/src/os/unix/ngx_process_cycle.c:344:9 > #5 0x53866d in main /home/ilia/nginx-1.19.10/src/core/nginx.c:383:9 > #6 0x7f1ec30db554 in __libc_start_main (/lib64/libc.so.6+0x22554) > > SUMMARY: AddressSanitizer: 221184 byte(s) leaked in 3 allocation(s). > http://mailman.nginx.org/pipermail/nginx-ru/2020-September/063363.html > скажите, у вас есть практика запуска с asan ? > В линуксе, где LeakSanitizer пристёгивается автоматом, это так: $ export ASAN_OPTIONS=detect_leaks=0 -- Sergey Kandaurov From mdounin на mdounin.ru Tue Apr 20 13:32:06 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 20 Apr 2021 16:32:06 +0300 Subject: =?UTF-8?B?UmU6INC30LDQv9GD0YHQuiDRgtC10YHRgtC+0LIgaHR0cHM6Ly9naXRodWIuY29t?= =?UTF-8?B?L25naW54L25naW54LXRlc3RzINGBINCy0LrQu9GO0YfQtdC90L3Ri9C8IEFT?= =?UTF-8?B?QU4gKGFkZHJlc3Mgc2FuaXRpemVyKQ==?= In-Reply-To: References: Message-ID: Hello! On Tue, Apr 20, 2021 at 04:43:58PM +0500, Илья Шипицин wrote: > привет! > > занимаюсь тестированием 3rd parties модулей. > один из вариантов тестирования - штатные тесты > https://github.com/nginx/nginx-tests > > хотелось бы в том числе запускать их с ASAN. > > но на nginx без модулей сейчас получается вот так (половина тестов > разваливается) > > ==3669==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 221184 byte(s) in 3 object(s) allocated from: > #0 0x5049a6 in __interceptor_malloc > (/home/ilia/nginx-1.19.10/objs/nginx+0x5049a6) > #1 0x5a11ff in ngx_alloc > /home/ilia/nginx-1.19.10/src/os/unix/ngx_alloc.c:22:9 > #2 0x5b0104 in ngx_worker_process_init > /home/ilia/nginx-1.19.10/src/os/unix/ngx_process_cycle.c:900:17 > #3 0x5af2c3 in ngx_worker_process_cycle > /home/ilia/nginx-1.19.10/src/os/unix/ngx_process_cycle.c:704:5 > #4 0x5ad797 in ngx_start_worker_processes > /home/ilia/nginx-1.19.10/src/os/unix/ngx_process_cycle.c:344:9 > #5 0x53866d in main /home/ilia/nginx-1.19.10/src/core/nginx.c:383:9 > #6 0x7f1ec30db554 in __libc_start_main (/lib64/libc.so.6+0x22554) > > SUMMARY: AddressSanitizer: 221184 byte(s) leaked in 3 allocation(s). > > > скажите, у вас есть практика запуска с asan ? Практика есть, но конкретно leak sanitizer бесполезен примерно полностью: реальных утечек в nginx'е он не ловит, так как используются pool allocator'ы, но при этом ругается на любыые аллокации, не освобождённые явно перед выходом. Что делать всегда не обязательно (при выходе процесса вся выделенная память освобождается автоматически), а в некоторых случаях и вообще невозможно (скажем, память, выделенную под какой-нибудь environ, освобождать нельзя, она используется при выходе). Хорошее решение - выключить leak sanitizer и забыть. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Tue Apr 20 14:52:44 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 20 Apr 2021 17:52:44 +0300 Subject: nginx-1.20.0 Message-ID: Изменения в nginx 1.20.0 20.04.2021 *) Стабильная ветка 1.20.x. -- Maxim Dounin http://nginx.org/ From chipitsine на gmail.com Tue Apr 20 16:00:30 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 20 Apr 2021 21:00:30 +0500 Subject: nginx-1.20.0 In-Reply-To: References: Message-ID: А http/3 когда по планам? On Tue, Apr 20, 2021, 7:52 PM Maxim Dounin wrote: > Изменения в nginx 1.20.0 > 20.04.2021 > > *) Стабильная ветка 1.20.x. > > > -- > Maxim Dounin > http://nginx.org/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Apr 20 17:08:18 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 20 Apr 2021 20:08:18 +0300 Subject: nginx-1.20.0 In-Reply-To: References: Message-ID: Hello! On Tue, Apr 20, 2021 at 09:00:30PM +0500, Илья Шипицин wrote: > А http/3 когда по планам? В экспериментальном режиме - в отдельной ветке уже давно, на quic.nginx.org подробности. В mainline планируем втаскивать где-то в 1.21.x, но это, скажем так, очень условные планы. Отмечу, что моё личное мнение состоит в том, что текущий статус даже у HTTP/2 - непригодно к использованию, там масса проблем как на уровне спецификации, так и на уровне отдельных реализаций, включая примерно все браузеры. Улучшения ситуация с HTTP/3 я не ожидаю, скорее наоборот. -- Maxim Dounin http://mdounin.ru/ From alex.hha на gmail.com Tue Apr 20 17:22:12 2021 From: alex.hha на gmail.com (Alex Domoradov) Date: Tue, 20 Apr 2021 20:22:12 +0300 Subject: nginx-1.20.0 In-Reply-To: References: Message-ID: > Улучшения ситуация с HTTP/3 я не ожидаю, скорее наоборот. Маркетологи говорят, что надо срочно инкрементировать версии, чтобы не отставать от других On Tue, Apr 20, 2021 at 8:08 PM Maxim Dounin wrote: > Hello! > > On Tue, Apr 20, 2021 at 09:00:30PM +0500, Илья Шипицин wrote: > > > А http/3 когда по планам? > > В экспериментальном режиме - в отдельной ветке уже давно, на > quic.nginx.org подробности. В mainline планируем втаскивать > где-то в 1.21.x, но это, скажем так, очень условные планы. > > Отмечу, что моё личное мнение состоит в том, что текущий статус > даже у HTTP/2 - непригодно к использованию, там масса проблем как > на уровне спецификации, так и на уровне отдельных реализаций, > включая примерно все браузеры. Улучшения ситуация с HTTP/3 я не > ожидаю, скорее наоборот. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vas на sibptus.ru Wed Apr 21 07:58:21 2021 From: vas на sibptus.ru (Victor Sudakov) Date: Wed, 21 Apr 2021 14:58:21 +0700 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: References: Message-ID: Maxim Dounin wrote: > On Fri, Apr 16, 2021 at 12:54:21PM +0700, Victor Sudakov wrote: > > > Maxim Dounin wrote: > > > > > > > > Я наверное плохо сформулировал вопрос, но мне как раз интересно видеть > > > > > > обратное поведение. Закрыли браузер - обслуживавший этот сеанс процесс > > > > > > PHP завершился, что бы ни делал в этот момент. > > > > > > > > > > > > А в приведенных ссылках обратную задачу пытаются решить. > > > > > > > > > > Прямая задача, как я понимаю, нормально решается только в случае, > > > > > если php-скрипт что-то возвращает клиенту, подробнее тут: > > > > > > > > > > https://www.php.net/manual/en/features.connection-handling.php > > > > > > > > Спасибо, Maxim, очень полезная ссылка. Я в первом письме так и > > > > предполагал, как должно происходить (см. последнюю строчку цитаты): > > > > > > > > "If the remote client disconnects, the ABORTED state flag is turned on. > > > > A remote client disconnect is usually caused by users hitting their STOP > > > > button. [...] You can decide whether or not you want a client disconnect > > > > to cause your script to be aborted. Sometimes it is handy to always have > > > > your scripts run to completion even if there is no remote browser > > > > receiving the output. The default behaviour is however for your script > > > > to be aborted when the remote client disconnects. " > > > > > > > > Другой вопрос, почему в наблюдаемом мной случае это не происходило. > > > > Пойду посмотрю код, может там действительно какой-нибудь > > > > ignore_user_abort стоит. В php.ini уже проверил, > > > > ignore_user_abort => Off => Off > > > > > > Отмечу ещё раз, что всё это работает только в том случае, если > > > php-скрипт что-то возвращает клиенту, и даже в этом случае нужны > > > приседания. > > > > А если php-скрипт ничего не возвращает клиенту, а делает sleep(100500) > > внутри себя, и при этом nginx закрывает соединение со скриптом, > > connection-status в скрипте не перейдет в состояние ABORTED? > > > > Предположим что nginx закрывает TCP-соединение с апстримом штатно (FIN > > -> FIN+ACK -> ACK). Или оно вообще было через Unix-socket. Таки > > connection-status в скрипте всё равно останется NORMAL до попытки > > вернуть клиенту какие-то данные? > > Именно об этом рассказано в комментариях, их стоит почитать. Я их читал. Комментарии к "Connection handling" все очень многолетней давности, и комментаторы больше озабочены обратной задачей: чтобы скрипт доработал после нажатия Стоп в браузере, например закоммитил данные в базу. > > И это логично: чтобы отследить закрытие соединения, нужно явно > проверять статус этого самого соединения или ждать событий на нём. > Это сложно и малореализуемо в рамках php с блокирующимися > вызовами. Тут у меня еще сработали ассоциации с обычным CGI. Там ведь насколько я помню, закрыли stdin CGI-скрипту - и скрипт сразу прекратил выполнение. Или тоже помню неверно? > > Могли бы сделать явную проверку через какой-нибудь recv(MSG_PEEK) > непосредственно в функции connection_aborted(), но, видимо, не > стали. Ну мало ли, может за 10-15 лет (возраст тамошних комментариев) это реализовали. Потому и спросил. > В результате о том, что соединение закрыто, php узнаёт, только > когда попытка записи ответа в соединение возвращает ошибку. Спасибо за однозначный и четкий ответ. В документации не хватает, к сожалению, чтобы этот момент был четко прописан. > > > > Об этом, в частности, рассказывается в комментариях к > > > описанию connection_aborted(). То есть исходная задача "скрипт > > > ждёт ответа базы 3 часа" - в php просто так не решается. > > > > Исходная как раз чтобы php-скрипт ничего не ждал и помирал побыстрее, если > > nginx соединение с ним закрыл. > > Да, именно об этом и речь: если скрипт просто ждёт ответа базы, то > php с ним ничего делать не будет и не прибьёт его, что бы не > происходило с соединением. Если что-то выводит пользователю - то > есть шанс. OK. -- Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49 на fidonet From bgx на protva.ru Wed Apr 21 08:17:44 2021 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Wed, 21 Apr 2021 11:17:44 +0300 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: References: Message-ID: <20210421081744.GC2746@protva.ru> On Wed, Apr 21, 2021 at 02:58:21PM +0700, Victor Sudakov wrote: > Тут у меня еще сработали ассоциации с обычным CGI. Там ведь насколько я > помню, закрыли stdin CGI-скрипту - и скрипт сразу прекратил выполнение. > Или тоже помню неверно? Неверно. И вообще это не имеет отношения к GCI, поскольку CGI как протокол не содержит никаких требований к обработке статуса соединения между клиентом и web-сервером. CGI это интерфейс между сервером и дочерним процессом. А как ведёт себя сервер по отношению изменениям статусов пользовательских коннекций -- это особенности его реализации. > > В результате о том, что соединение закрыто, php узнаёт, только > > когда попытка записи ответа в соединение возвращает ошибку. > > Спасибо за однозначный и четкий ответ. В документации не хватает, к > сожалению, чтобы этот момент был четко прописан. Вы находили в документации по php прямо противоположное утверждение. Но насколько оно верно -- это вопрос, по мне так php это маргинальная субкультура и слепо доверять её грамотам не стоит... -- Eugene Berdnikov From slw на zxy.spb.ru Wed Apr 21 10:45:16 2021 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Wed, 21 Apr 2021 13:45:16 +0300 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: References: Message-ID: <20210421104516.GB13169@zxy.spb.ru> On Wed, Apr 21, 2021 at 02:58:21PM +0700, Victor Sudakov wrote: > Тут у меня еще сработали ассоциации с обычным CGI. Там ведь насколько я > помню, закрыли stdin CGI-скрипту - и скрипт сразу прекратил выполнение. > Или тоже помню неверно? неверно ничего со скриптом не случается пока он не будет читать или писать в закрытый сокет From eugen на grosbein.net Wed Apr 21 12:14:11 2021 From: eugen на grosbein.net (Eugene Grosbein) Date: Wed, 21 Apr 2021 19:14:11 +0700 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: <20210421104516.GB13169@zxy.spb.ru> References: <20210421104516.GB13169@zxy.spb.ru> Message-ID: 21.04.2021 17:45, Slawa Olhovchenkov пишет: > On Wed, Apr 21, 2021 at 02:58:21PM +0700, Victor Sudakov wrote: > >> Тут у меня еще сработали ассоциации с обычным CGI. Там ведь насколько я >> помню, закрыли stdin CGI-скрипту - и скрипт сразу прекратил выполнение. >> Или тоже помню неверно? > > неверно > ничего со скриптом не случается пока он не будет читать или писать в > закрытый сокет С поправкой на общий лимит работы CGI-приложения, для Апача это: CGIScriptTimeout // This directive limits the length of time to wait for more output from the CGI program. If the time is exceeded, the request and CGI are terminated. Default: value of Timeout directive when unset From vas на sibptus.ru Thu Apr 22 04:23:07 2021 From: vas на sibptus.ru (Victor Sudakov) Date: Thu, 22 Apr 2021 11:23:07 +0700 Subject: =?UTF-8?B?UmU6INCi0L7QvdC60L7RgdGC0Lgg0YDQsNCx0L7RgtGLIEZhc3RDR0kgKHBocGZw?= =?UTF-8?B?bSk=?= In-Reply-To: <20210421081744.GC2746@protva.ru> References: <20210421081744.GC2746@protva.ru> Message-ID: Evgeniy Berdnikov wrote: > On Wed, Apr 21, 2021 at 02:58:21PM +0700, Victor Sudakov wrote: > > Тут у меня еще сработали ассоциации с обычным CGI. Там ведь насколько я > > помню, закрыли stdin CGI-скрипту - и скрипт сразу прекратил выполнение. > > Или тоже помню неверно? > > Неверно. И вообще это не имеет отношения к GCI, поскольку CGI как протокол > не содержит никаких требований к обработке статуса соединения между > клиентом и web-сервером. Речь и не шла об обработке статуса соединения между клиентом и web-сервером. Под "закрыли stdin CGI-скрипту" я имел в виду, что веб-сервер закрыл соединение между собой и скриптом. Впрочем, как меня уже поправили, и в случае CGI-скрипта скрипт может остаться работать, даже если веб-сервер закрыл соединение с ним. Я этого не знал. Бывало тестировал их даже руками или через пайп - не помню, чтобы хоть один оставался выполняться где-то в фоне, после того как я прервал общение с ним. Вообще очень познавательный был разговор, спасибо всем ответившим. > CGI это интерфейс между сервером и дочерним > процессом. А как ведёт себя сервер по отношению изменениям статусов > пользовательских коннекций -- это особенности его реализации. > > > > В результате о том, что соединение закрыто, php узнаёт, только > > > когда попытка записи ответа в соединение возвращает ошибку. > > > > Спасибо за однозначный и четкий ответ. В документации не хватает, к > > сожалению, чтобы этот момент был четко прописан. > > Вы находили в документации по php прямо противоположное утверждение. > Но насколько оно верно -- это вопрос, по мне так php это маргинальная > субкультура и слепо доверять её грамотам не стоит... Не то чтобы "прямо противоположное". В документации просто не оговорено, что требуются определенные дополнительные условия (попытка чтения или записи скриптом) для перехода в состояние ABORTED. -- Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49 на fidonet From gmm на csdoc.com Sat Apr 24 19:15:36 2021 From: gmm на csdoc.com (Gena Makhomed) Date: Sat, 24 Apr 2021 22:15:36 +0300 Subject: ssl_early_data Message-ID: <4fe4aa1b-1429-ec57-2c7b-4a992fd797d8@csdoc.com> Здравствуйте, All! Есть в nginx директива ssl_early_data, но как я понял из документации, чтобы ее можно было безопасно включить - необходимо сделать защиту от replay attacks. В документации предлагается делать ее на бекенде, с помощью заголовка proxy_set_header Early-Data $ssl_early_data; Можно ли настроить сам nginx таким способом, чтобы он нормально пропускал на бекенд безопасные запросы GET, HEAD, OPTIONS, TRACE в том случае когда $ssl_early_data установлена в 1 и чтобы он возвращал клиенту 425 (Too Early) status code в том случае, если запрос имеет не безопасный метод POST, PUT, DELETE, PATCH и $ssl_early_data; равно 1. Идеально, если это будет встроенная в nginx функциональность, например, с помощью директивы ssl_early_data_protection. Syntax: ssl_early_data on | off; Default: ssl_early_data off; Context: http, server Syntax: ssl_early_data_protection on | off; Default: ssl_early_data_protection off; Context: http, server Не все бекенды понимают заголовок Early-Data, а ssl_early_data on; было бы полезно включить, для ускорения работы сайта. -- Best regards, Gena From mdounin на mdounin.ru Sun Apr 25 14:56:14 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Sun, 25 Apr 2021 17:56:14 +0300 Subject: ssl_early_data In-Reply-To: <4fe4aa1b-1429-ec57-2c7b-4a992fd797d8@csdoc.com> References: <4fe4aa1b-1429-ec57-2c7b-4a992fd797d8@csdoc.com> Message-ID: Hello! On Sat, Apr 24, 2021 at 10:15:36PM +0300, Gena Makhomed wrote: > Есть в nginx директива ssl_early_data, но как я > понял из документации, > чтобы ее можно > было безопасно включить - необходимо сделать защиту > от replay attacks. > > В документации предлагается делать ее на бекенде, > с помощью заголовка proxy_set_header Early-Data $ssl_early_data; > > Можно ли настроить сам nginx таким способом, чтобы он нормально > пропускал на бекенд безопасные запросы GET, HEAD, OPTIONS, TRACE > в том случае когда $ssl_early_data установлена в 1 и чтобы > он возвращал > клиенту 425 (Too Early) status code в том случае, если запрос имеет > не безопасный > метод POST, PUT, DELETE, PATCH и $ssl_early_data; равно 1. Настроить можно: set $early $ssl_early_data:$request_method; if ($early ~ ^1:(?!GET$|HEAD$)) { return 425; } Однако в соответствии с RFC 8470 клиенты не имеют права посылать небезопасные запросы с использованием early data[1], так что смысла в такой настройке примерно ноль. Использование переменной $ssl_early_data имеет смысл тогда, когда replay-атаки могут представлять опасность для "безопасных запросов". То есть, скажем, если где-то GET-запросы используются небезопасно и имеют сайд-эффекты (хоте и не должны по спецификации), или же если если replay-атаки могут быть использованы для получения какой-то информации[2]. [1] https://tools.ietf.org/html/rfc8470#section-4 [2] https://tools.ietf.org/html/rfc8470#section-6 -- Maxim Dounin http://mdounin.ru/