深入剖析瀏覽器退出之后php還會繼續(xù)執(zhí)行么
前提：這里說的是典型的lnmp結(jié)構(gòu)，nginx+php-fpm的模式
如果我有個php程序執(zhí)行地非常慢，甚至于在代碼中sleep()，然后瀏覽器連接上服務(wù)的時候，會啟動一個php-fpm進(jìn)程，但是這個時候，如果瀏覽器關(guān)閉了，那么請問，這個時候服務(wù)端的這個php-fpm進(jìn)程是否還會繼續(xù)運(yùn)行呢？
今天就是要解決這個問題。
最簡單的實(shí)驗(yàn)
最簡單的方法就是做實(shí)驗(yàn)，我們寫一個程序：在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é)果是，我們在服務(wù)器sleep的過程中，關(guān)閉客戶端瀏覽器，2222是會被寫入日志中。
那么就意味著瀏覽器關(guān)閉以后，服務(wù)端的php還是會繼續(xù)運(yùn)行的?
ignore_user_abort
老王和diogin提醒，這個可能是和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為何值，都是會繼續(xù)執(zhí)行的。
但是這里有一個疑問: user_abort是什么？
文檔對cli模式的abort說的很清楚，當(dāng)php腳本執(zhí)行的時候，用戶終止了這個腳本的時候，就會觸發(fā)abort了。然后腳本根據(jù)ignore_user_abort來判斷是否要繼續(xù)執(zhí)行。
但是官方文檔對cgi模式的abort并沒有描述清楚。感覺即使客戶端斷開連接了，在cgi模式的php是不會收到abort的。
難道ignore_user_abort在cgi模式下是沒有任何作用的？
是不是心跳問題呢？
首先想到的是不是心跳問題呢？我們斷開瀏覽器客戶端，等于在客戶端沒有close而斷開了連接，服務(wù)端是需要等待tcp的keepalive到達(dá)時長之后才會檢測出來的。
好，需要先排除瀏覽器設(shè)置的keepalive問題。
拋棄瀏覽器，簡單寫一個client程序：程序連接上http服務(wù)之后，發(fā)送一個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
}
服務(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，會繼續(xù)執(zhí)行完成整個腳本。看來ignore_user_abort還是沒有生效。
如何觸發(fā)ignore_user_abort
那該怎么觸發(fā)ignore_user_abort呢？服務(wù)端這邊怎么知曉這個socket不能使用了呢？老王和diogin說是不是需要服務(wù)端主動和socket進(jìn)行交互，才會判斷出這個socket是否可以使用？
另外，我們還發(fā)現(xiàn)，php提供了connection_status和connection_aborted兩個方法，這兩個方法都能檢測出當(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ù)手冊連接處理顯示我們可以打印出當(dāng)前連接的狀態(tài)了。
下面還缺少一個和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。
但是這里有個奇怪的地方，為什么第一個2 connection status的狀態(tài)還是0呢（NORMAL）。
RST
我們使用wireshark抓包看整個客戶端和服務(wù)端交互的過程
這整個過程只有發(fā)送14個包，我們看下服務(wù)端第一次發(fā)送22222的時候，客戶端返回的是RST。后面就沒有進(jìn)行后續(xù)的包請求了。
于是理解了，客戶端和服務(wù)端大概的交互流程是：
當(dāng)服務(wù)端在循環(huán)中第一次發(fā)送2222的時候，客戶端由于已經(jīng)斷開連接了，返回的是一個RST，但是這個發(fā)送過程算是請求成功了。直到第二次服務(wù)端再 次想往這個socket中進(jìn)行write操作的時候，這個socket就不進(jìn)行網(wǎng)絡(luò)傳輸了，直接返回說connection的狀態(tài)已經(jīng)為abort。所以 就出現(xiàn)了上面的情況，第一次222是status為0，第二次的時候才出現(xiàn)abort。
strace進(jìn)行驗(yàn)證
我們也可以使用strace php -S XXX來進(jìn)行驗(yàn)證
整個過程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的時候顯示了Broken pipe。這就是程序告訴我們，這個socket已經(jīng)不能使用了，順便php中的connection_status就會被設(shè)置為1了。后續(xù)的寫操作也都不會再執(zhí)行了。
總結(jié)
正常情況下，如果客戶端client異常推出了，服務(wù)端的程序還是會繼續(xù)執(zhí)行，直到與IO進(jìn)行了兩次交互操作。服務(wù)端發(fā)現(xiàn)客戶端已經(jīng)斷開連接，這個 時候會觸發(fā)一個user_abort，如果這個沒有設(shè)置ignore_user_abort，那么這個php-fpm的程序才會被中斷。
至此，問題結(jié)了。
以上這篇深入剖析瀏覽器退出之后php還會繼續(xù)執(zhí)行么就是小編分享給大家的全部內(nèi)容了，希望能給大家一個參考，也希望大家多多支持腳本之家。
相關(guān)文章
通過PHP的Wrapper無縫遷移原有項(xiàng)目到新服務(wù)的實(shí)現(xiàn)方法
這篇文章主要介紹了通過PHP的Wrapper無縫遷移原有項(xiàng)目到新服務(wù)的實(shí)現(xiàn)方法，本文給大家介紹的非常詳細(xì)，對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值,需要的朋友可以參考下2020-04-04
PHP程序員簡單的開展服務(wù)治理架構(gòu)操作詳解(三)
這篇文章主要介紹了PHP程序員簡單的開展服務(wù)治理架構(gòu)操作,總結(jié)分析了PHP開展服務(wù)治理架構(gòu)SOA服務(wù)相關(guān)概念、原理與操作注意事項(xiàng),需要的朋友可以參考下2020-05-05
PHP獲取IP地址所在地信息的實(shí)例(使用純真IP數(shù)據(jù)庫qqwry.dat)
下面小編就為大家?guī)硪黄狿HP獲取IP地址所在地信息的實(shí)例(使用純真IP數(shù)據(jù)庫qqwry.dat)。小編覺得挺不錯的，現(xiàn)在就分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2016-11-11
總結(jié)PHP如何獲取當(dāng)前主機(jī)、域名、網(wǎng)址、路徑、端口和參數(shù)等
這篇文章給大家分享了利用php如何獲取當(dāng)前域名或主機(jī)地址、網(wǎng)頁地址、網(wǎng)址參數(shù)、用戶代理、完整的url、包含端口號的完整url以及只取路徑等信息，有需要的朋友們可以參考借鑒。2016-09-09
PHP htmlspecialchars() 函數(shù)實(shí)例代碼及用法大全
這篇文章主要介紹了PHP htmlspecialchars() 函數(shù)實(shí)例代碼及用法大全,需要的朋友可以參考下2018-09-09
對于PHP程序設(shè)計(jì)語言來說。每個人的學(xué)習(xí)方式不同，寫這篇文章的目的是分享一下自己的學(xué)習(xí)過程，僅供參考，不要一味的用別人的學(xué)習(xí)方法，找對自己有用的學(xué)習(xí)方式2014-04-04
下面小編就為大家?guī)硪黄猵hp簡單中獎算法(實(shí)例)。小編覺得挺不錯的，現(xiàn)在就分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2017-08-08
這篇文章主要介紹了Yii框架上傳圖片用法,結(jié)合實(shí)例形式總結(jié)分析了Yii框架上傳圖片的相關(guān)注意事項(xiàng)與使用技巧,需要的朋友可以參考下2016-03-03
這篇文章主要介紹了WordPress中對訪客評論功能的一些優(yōu)化,包括顯示評論上的歡迎信息等功能,需要的朋友可以參考下2015-11-11
CentOS下搭建PHP環(huán)境與WordPress博客程序的全流程總結(jié)
這篇文章主要介紹了CentOS下搭建PHP環(huán)境與WordPress博客程序的全流程總結(jié),這里我們以Apache服務(wù)器程序和MySQL數(shù)據(jù)庫程序?yàn)槔M(jìn)行講解,需要的朋友可以參考下2016-05-05