您好,登錄后才能下訂單哦!
這篇文章給大家介紹退出瀏覽器后php程序還會(huì)繼續(xù)執(zhí)行嗎,內(nèi)容非常詳細(xì),感興趣的小伙伴們可以參考借鑒,希望對(duì)大家能有所幫助。
最簡(jiǎn)單的方法就是做實(shí)驗(yàn),我們寫一個(gè)程序:在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);
實(shí)際操作的結(jié)果是,我們?cè)?a title="服務(wù)器" target="_blank" href="http://www.kemok4.com/">服務(wù)器sleep的過程中,關(guān)閉客戶端瀏覽器,2222是會(huì)被寫入日志中。
那么就意味著瀏覽器關(guān)閉以后,服務(wù)端的php還是會(huì)繼續(xù)運(yùn)行的?
ignore_user_abort
老王和diogin提醒,這個(gè)可能是和php的ignore_user_abort函數(shù)相關(guān)。
于是我就把代碼稍微改成這樣的:
<?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);
發(fā)現(xiàn)并沒有任何軟用,不管設(shè)置ignore_user_abort為何值,都是會(huì)繼續(xù)執(zhí)行的。
但是這里有一個(gè)疑問: user_abort是什么?
文檔對(duì)cli模式的abort說的很清楚,當(dāng)php腳本執(zhí)行的時(shí)候,用戶終止了這個(gè)腳本的時(shí)候,就會(huì)觸發(fā)abort了。然后腳本根據(jù)ignore_user_abort來判斷是否要繼續(xù)執(zhí)行。
但是官方文檔對(duì)cgi模式的abort并沒有描述清楚。感覺即使客戶端斷開連接了,在cgi模式的php是不會(huì)收到abort的。
難道ignore_user_abort在cgi模式下是沒有任何作用的?
是不是心跳問題呢?
首先想到的是不是心跳問題呢?我們斷開瀏覽器客戶端,等于在客戶端沒有close而斷開了連接,服務(wù)端是需要等待tcp的keepalive到達(dá)時(shí)長(zhǎng)之后才會(huì)檢測(cè)出來的。
好,需要先排除瀏覽器設(shè)置的keepalive問題。
拋棄瀏覽器,簡(jiǎn)單寫一個(gè)client程序:程序連接上http服務(wù)之后,發(fā)送一個(gè)header頭,sleep1秒就主動(dòng)close連接,而這個(gè)程序并沒有帶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 }
服務(wù)端程序:
<?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);
發(fā)現(xiàn)仍然還是一樣,php還是不管是否設(shè)置ignore_user_abort,會(huì)繼續(xù)執(zhí)行完成整個(gè)腳本??磥韎gnore_user_abort還是沒有生效。
如何觸發(fā)ignore_user_abort
那該怎么觸發(fā)ignore_user_abort呢?服務(wù)端這邊怎么知曉這個(gè)socket不能使用了呢?老王和diogin說是不是需要服務(wù)端主動(dòng)和socket進(jìn)行交互,才會(huì)判斷出這個(gè)socket是否可以使用?
另外,我們還發(fā)現(xiàn),php提供了connection_status和connection_aborted兩個(gè)方法,這兩個(gè)方法都能檢測(cè)出當(dāng)前的連接狀態(tài)。于是我們的打日志的那行代碼就可以改成:
file_put_contents('/tmp/test.log', '1 connection status: ' . connection_status() . "abort:" . connection_aborted() . PHP_EOL, FILE_APPEND | LOCK_EX);
根據(jù)手冊(cè)連接處理顯示我們可以打印出當(dāng)前連接的狀態(tài)了。
下面還缺少一個(gè)和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); }
很好,執(zhí)行我們前面寫的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狀態(tài)都是1。
但是這里有個(gè)奇怪的地方,為什么第一個(gè)2 connection status的狀態(tài)還是0呢(NORMAL)。
RST
我們使用wireshark抓包看整個(gè)客戶端和服務(wù)端交互的過程
這整個(gè)過程只有發(fā)送14個(gè)包,我們看下服務(wù)端第一次發(fā)送22222的時(shí)候,客戶端返回的是RST。后面就沒有進(jìn)行后續(xù)的包請(qǐng)求了。
于是理解了,客戶端和服務(wù)端大概的交互流程是:
當(dāng)服務(wù)端在循環(huán)中第一次發(fā)送2222的時(shí)候,客戶端由于已經(jīng)斷開連接了,返回的是一個(gè)RST,但是這個(gè)發(fā)送過程算是請(qǐng)求成功了。直到第二次服務(wù)端再 次想往這個(gè)socket中進(jìn)行write操作的時(shí)候,這個(gè)socket就不進(jìn)行網(wǎng)絡(luò)傳輸了,直接返回說connection的狀態(tài)已經(jīng)為abort。所以 就出現(xiàn)了上面的情況,第一次222是status為0,第二次的時(shí)候才出現(xiàn)abort。
strace進(jìn)行驗(yàn)證
我們也可以使用strace php -S XXX來進(jìn)行驗(yàn)證
整個(gè)過程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轉(zhuǎn)變的地方。 ... 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中發(fā)送2222的時(shí)候顯示了Broken pipe。這就是程序告訴我們,這個(gè)socket已經(jīng)不能使用了,順便php中的connection_status就會(huì)被設(shè)置為1了。后續(xù)的寫操作也都不會(huì)再執(zhí)行了。
總結(jié)
正常情況下,如果客戶端client異常推出了,服務(wù)端的程序還是會(huì)繼續(xù)執(zhí)行,直到與IO進(jìn)行了兩次交互操作。服務(wù)端發(fā)現(xiàn)客戶端已經(jīng)斷開連接,這個(gè) 時(shí)候會(huì)觸發(fā)一個(gè)user_abort,如果這個(gè)沒有設(shè)置ignore_user_abort,那么這個(gè)php-fpm的程序才會(huì)被中斷。
至此,問題結(jié)了。
關(guān)于退出瀏覽器后php程序還會(huì)繼續(xù)執(zhí)行嗎就分享到這里了,希望以上內(nèi)容可以對(duì)大家有一定的幫助,可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò),可以把它分享出去讓更多的人看到。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。