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 это одно,
а вот если оно не пытается - никто не будет его убивать.

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