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