深入剖析浏览器退出之后php还会继续执行么_php实例
前提:这里说的是典型的lnmp结构,nginx+php-fpm的模式
如果我有个php程序执行地非常慢,甚至于在代码中sleep(),然后浏览器连接上服务的时候,会启动一个php-fpm进程,但是这个时候,如果浏览器关闭了,那么请问,这个时候服务端的这个php-fpm进程是否还会继续运行呢?
今天就是要解决这个问题。
最简单的实验
最简单的方法就是做实验,我们写一个程序:在sleep之前和之后都用file_put_contents来写入日志:
<?php file_put_contents('/tmp/test.log', '11111' . PHP_EOL, FILE_APPEND | LOCK_EX); sleep(3); file_put_contents('/tmp/test.log', '2222' . PHP_EOL, FILE_APPEND | LOCK_EX);
实际操作的结果是,我们在服务器sleep的过程中,关闭客户端浏览器,2222是会被写入日志中。
那么就意味着浏览器关闭以后,服务端的php还是会继续运行的?
ignore_user_abort
老王和diogin提醒,这个可能是和php的ignore_user_abort函数相关。
于是我就把代码稍微改成这样的:
<?php ignore_user_abort(false); file_put_contents('/tmp/test.log', '11111' . PHP_EOL, FILE_APPEND | LOCK_EX); sleep(3); file_put_contents('/tmp/test.log', '2222' . PHP_EOL, FILE_APPEND | LOCK_EX);
发现并没有任何软用,不管设置ignore_user_abort为何值,都是会继续执行的。
但是这里有一个疑问: user_abort是什么?
文档对cli模式的abort说的很清楚,当php脚本执行的时候,用户终止了这个脚本的时候,就会触发abort了。然后脚本根据ignore_user_abort来判断是否要继续执行。
但是官方文档对cgi模式的abort并没有描述清楚。感觉即使客户端断开连接了,在cgi模式的php是不会收到abort的。
难道ignore_user_abort在cgi模式下是没有任何作用的?
是不是心跳问题呢?
首先想到的是不是心跳问题呢?我们断开浏览器客户端,等于在客户端没有close而断开了连接,服务端是需要等待tcp的keepalive到达时长之后才会检测出来的。
好,需要先排除浏览器设置的keepalive问题。
抛弃浏览器,简单写一个client程序:程序连接上http服务之后,发送一个header头,sleep1秒就主动close连接,而这个程序并没有带http的keepalive头。
程序如下:
package main import "net" import "fmt" import "time" func main() { conn, _ := net.Dial("tcp", "192.168.33.10:10011") fmt.Fprintf(conn, "GET /index.php HTTP/1.0\r\n\r\n") time.Sleep(1 * time.Second) conn.Close() return }
服务端程序:
<?php ignore_user_abort(false); file_put_contents('/tmp/test.log', '11111' . PHP_EOL, FILE_APPEND | LOCK_EX); sleep(3); file_put_contents('/tmp/test.log', '2222' . PHP_EOL, FILE_APPEND | LOCK_EX);
发现仍然还是一样,php还是不管是否设置ignore_user_abort,会继续执行完成整个脚本。看来ignore_user_abort还是没有生效。
如何触发ignore_user_abort
那该怎么触发ignore_user_abort呢?服务端这边怎么知晓这个socket不能使用了呢?老王和diogin说是不是需要服务端主动和socket进行交互,才会判断出这个socket是否可以使用?
另外,我们还发现,php提供了connection_status和connection_aborted两个方法,这两个方法都能检测出当前的连接状态。于是我们的打日志的那行代码就可以改成:
file_put_contents('/tmp/test.log', '1 connection status: ' . connection_status() . "abort:" . connection_aborted() . PHP_EOL, FILE_APPEND | LOCK_EX);
根据手册连接处理显示我们可以打印出当前连接的状态了。
下面还缺少一个和socket交互的程序,我们使用echo,后面也顺带记得带上flush,排除了flush的影响。
程序就改成
<?php ignore_user_abort(true); file_put_contents('/tmp/test.log', '1 connection status: ' . connection_status() . "abort:" . connection_aborted() . PHP_EOL, FILE_APPEND | LOCK_EX); sleep(3); for($i = 0; $i < 10; $i++) { echo "22222"; flush(); sleep(1); file_put_contents('/tmp/test.log', '2 connection status: ' . connection_status() . "abort:" . connection_aborted(). PHP_EOL, FILE_APPEND | LOCK_EX); }
很好,执行我们前面写的client。观察日志:
1 connection status: 0abort:0 2 connection status: 0abort:0 2 connection status: 1abort:1 2 connection status: 1abort:1 2 connection status: 1abort:1 2 connection status: 1abort:1 2 connection status: 1abort:1 2 connection status: 1abort:1 2 connection status: 1abort:1 2 connection status: 1abort:1 2 connection status: 1abort:1
终于制造出了abort。日志也显示后面几次的abort状态都是1。
但是这里有个奇怪的地方,为什么第一个2 connection status的状态还是0呢(NORMAL)。
RST
我们使用wireshark抓包看整个客户端和服务端交互的过程
这整个过程只有发送14个包,我们看下服务端第一次发送22222的时候,客户端返回的是RST。后面就没有进行后续的包请求了。
于是理解了,客户端和服务端大概的交互流程是:
当服务端在循环中第一次发送2222的时候,客户端由于已经断开连接了,返回的是一个RST,但是这个发送过程算是请求成功了。直到第二次服务端再 次想往这个socket中进行write操作的时候,这个socket就不进行网络传输了,直接返回说connection的状态已经为abort。所以 就出现了上面的情况,第一次222是status为0,第二次的时候才出现abort。
strace进行验证
我们也可以使用strace php -S XXX来进行验证
整个过程strace的日志如下:
close(5) = 0 lstat("/tmp/test.log", {st_mode=S_IFREG|0644, st_size=49873651, ...}) = 0 open("/tmp/test.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 5 fstat(5, {st_mode=S_IFREG|0644, st_size=49873651, ...}) = 0 lseek(5, 0, SEEK_CUR) = 0 lseek(5, 0, SEEK_CUR) = 0 flock(5, LOCK_EX) = 0 write(5, "1 connection status: 0abort:0\n", 30) = 30 close(5) = 0 sendto(4, "HTTP/1.0 200 OK\r\nConnection: clo"..., 89, 0, NULL, 0) = 89 sendto(4, "111111111", 9, 0, NULL, 0) = 9 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 nanosleep({3, 0}, 0x7fff60a40290) = 0 sendto(4, "22222", 5, 0, NULL, 0) = 5 open("/tmp/test.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 5 fstat(5, {st_mode=S_IFREG|0644, st_size=49873681, ...}) = 0 lseek(5, 0, SEEK_CUR) = 0 lseek(5, 0, SEEK_CUR) = 0 flock(5, LOCK_EX) = 0 write(5, "2 connection status: 0abort:0\n", 30) = 30 close(5) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 nanosleep({1, 0}, 0x7fff60a40290) = 0 sendto(4, "22222", 5, 0, NULL, 0) = -1 EPIPE (Broken pipe) --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=2819, si_uid=0} --- open("/tmp/test.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 5 fstat(5, {st_mode=S_IFREG|0644, st_size=49873711, ...}) = 0 lseek(5, 0, SEEK_CUR) = 0 lseek(5, 0, SEEK_CUR) = 0 flock(5, LOCK_EX) = 0 write(5, "2 connection status: 1abort:1\n", 30) = 30 close(5) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 nanosleep({1, 0}, 0x7fff60a40290) = 0 open("/tmp/test.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 5 fstat(5, {st_mode=S_IFREG|0644, st_size=49873741, ...}) = 0 lseek(5, 0, SEEK_CUR) = 0 lseek(5, 0, SEEK_CUR) = 0 flock(5, LOCK_EX) = 0 write(5, "2 connection status: 1abort:1\n", 30) = 30 close(5) 。。。我们照中看status从0到1转变的地方。 ... sendto(4, "22222", 5, 0, NULL, 0) = 5 ... write(5, "2 connection status: 0abort:0\n", 30) = 30 close(5) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 nanosleep({1, 0}, 0x7fff60a40290) = 0 sendto(4, "22222", 5, 0, NULL, 0) = -1 EPIPE (Broken pipe) --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=2819, si_uid=0} --- open("/tmp/test.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 5 fstat(5, {st_mode=S_IFREG|0644, st_size=49873711, ...}) = 0 lseek(5, 0, SEEK_CUR) = 0 lseek(5, 0, SEEK_CUR) = 0 flock(5, LOCK_EX) = 0 write(5, "2 connection status: 1abort:1\n", 30) = 30 close(5)
第二次往socket中发送2222的时候显示了Broken pipe。这就是程序告诉我们,这个socket已经不能使用了,顺便php中的connection_status就会被设置为1了。后续的写操作也都不会再执行了。
总结
正常情况下,如果客户端client异常推出了,服务端的程序还是会继续执行,直到与IO进行了两次交互操作。服务端发现客户端已经断开连接,这个 时候会触发一个user_abort,如果这个没有设置ignore_user_abort,那么这个php-fpm的程序才会被中断。
至此,问题结了。
以上这篇深入剖析浏览器退出之后php还会继续执行么就是小编分享给大家的全部内容了,希望能给大家一个参考,也希望大家多多支持脚本之家。

热AI工具

Undresser.AI Undress
人工智能驱动的应用程序,用于创建逼真的裸体照片

AI Clothes Remover
用于从照片中去除衣服的在线人工智能工具。

Undress AI Tool
免费脱衣服图片

Clothoff.io
AI脱衣机

AI Hentai Generator
免费生成ai无尽的。

热门文章

热工具

记事本++7.3.1
好用且免费的代码编辑器

SublimeText3汉化版
中文版,非常好用

禅工作室 13.0.1
功能强大的PHP集成开发环境

Dreamweaver CS6
视觉化网页开发工具

SublimeText3 Mac版
神级代码编辑软件(SublimeText3)

Coinbase安全登录指南:如何避免钓鱼网站和诈骗? 网络钓鱼和诈骗日益猖獗,安全访问Coinbase官方登录入口至关重要。本文提供实用指南,帮助用户安全地找到并使用Coinbase最新官方登录入口,保护数字资产安全。我们将介绍如何识别钓鱼网站,以及如何通过官方网站、移动应用或可信第三方平台安全登录,并提供加强账户安全的建议,例如使用强密码和启用双重验证。 避免因错误登录导致资产损失,请务必仔细阅读本文!

欧易OKX作为全球领先的数字资产交易平台,以其丰富的交易产品、强大的安全保障和便捷的用户体验吸引众多投资者。然而,网络安全风险日益严峻,如何安全注册欧易OKX官方账户至关重要。本文将提供欧易OKX官方网站最新注册入口,并详细讲解安全注册的步骤和注意事项,包括如何识别官方网站、设置强密码、开启双重验证等,帮助您安全便捷地开启数字资产投资之旅。请注意,数字资产投资存在风险,请谨慎决策。

本文提供国内安全下载欧易OKX App的详细指南。由于国内应用商店限制,建议用户通过欧易OKX官方网站下载App,或使用官网提供的二维码扫描下载。下载过程中,务必核实官网地址,检查应用权限,安装后进行安全扫描,并启用双重验证。 使用过程中,请遵守当地法律法规,使用安全网络环境,保护账户安全,警惕诈骗,理性投资。 本文仅供参考,不构成投资建议,数字资产交易风险自负。

本文提供安全可靠的指南,帮助用户访问BitMEX交易所的最新官方网站,并提升交易安全。由于监管和网络安全威胁,识别BitMEX官方网站至关重要,避免钓鱼网站窃取账户信息和资金。文章介绍了通过可信加密货币平台、官方社交媒体、新闻媒体以及订阅官方邮件等方法查找官方网站入口,并强调了核对域名、使用HTTPS连接、检查安全证书等安全提示,以及启用双重验证、定期更改密码的重要性。 记住,加密货币交易高风险,请谨慎投资。

本文提供安全可靠的币安交易所App下载指南,帮助用户解决在国内下载币安App的难题。由于国内应用商店限制,文章推荐优先从币安官网下载APK安装包,并详细介绍了官网下载、第三方应用商店下载以及朋友分享等三种方法,同时强调了下载过程中的安全注意事项,例如验证官网地址、检查应用权限、使用安全软件扫描等。此外,文章还提醒用户了解当地法律法规,注意网络安全,保护个人信息,谨防诈骗,理性投资,安全交易。 文章最后再次强调,下载和使用币安App需遵守当地法律法规,风险自负,不构成任何投资建议。

Coinbase交易所网页版因其便捷性广受欢迎,但安全访问至关重要。本文旨在指导用户安全登录Coinbase官方网页版,避免钓鱼网站和黑客攻击。 我们将详解如何通过搜索引擎、可信第三方平台及官方社交媒体验证官方入口,并强调检查地址栏安全锁、启用双重验证、避免公共Wi-Fi、定期更改密码及警惕钓鱼邮件等安全措施,保障您的数字资产安全。 正确访问Coinbase官方网站是保护您的数字货币的第一步,本文将助您安全开启数字货币交易之旅。

本文提供国内安全下载币安App的指南,由于国内应用商店限制,直接下载较为困难。推荐通过币安官方网站下载APK安装包或扫描官网二维码下载App,务必仔细核对官方域名,检查应用权限,安装后进行安全扫描,并启用双重验证(2FA)。 下载及使用前请务必了解并遵守当地法律法规,数字资产交易风险较高,请谨慎操作。本文仅供参考,不构成投资建议,所有风险由用户自行承担。 关键词:币安, Binance, 下载, App, 国内, 安全, 教程, 数字货币, 加密货币

BitMEX作为老牌加密货币衍生品交易平台,其官方网站入口的准确性至关重要。由于钓鱼网站猖獗,误入假冒网站可能导致账户被盗和资金损失。本文旨在指导用户安全访问BitMEX官方网站,提供通过可信加密货币信息平台(如CoinMarketCap、CoinGecko)、官方社交媒体、验证现有地址及官方支持渠道等多种方法,并强调启用双重验证、定期更改密码及使用安全软件等安全措施,帮助用户有效规避风险,保障账户安全。
