瀏覽器退出之後php還會繼續執行嗎的深入探究

瀏覽退出之後php還會繼續執行嗎？下面小編就為大家介紹一下究竟覽器退出之後php還會不會繼續執行。希望對大家有所協助。

前提：這裡說的是典型的lnmp結構，nginx+php-fpm的模式

如果我有個php程式執行地非常慢，甚至於在代碼中sleep()，然後瀏覽器串連上服務的時候，會啟動一個php-fpm進程，但是這個時候，如果瀏覽器關閉了，那麼請問，這個時候服務端的這個php-fpm進程是否還會繼續運行呢？

今天就是要解決這個問題。

最簡單的實驗

最簡單的方法就是做實驗，我們寫一個程式：在sleep之前和之後都用file_put_contents來寫入日誌：

<?phpfile_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函數相關。

於是我就把代碼稍微改成這樣的：

<?phpignore_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 mainimport "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}

服務端程式：

<?phpignore_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的影響。

程式就改成

<?phpignore_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:02 connection status: 0abort:02 connection status: 1abort:12 connection status: 1abort:12 connection status: 1abort:12 connection status: 1abort:12 connection status: 1abort:12 connection status: 1abort:12 connection status: 1abort:12 connection status: 1abort:12 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)                = 0lstat("/tmp/test.log", {st_mode=S_IFREG|0644, st_size=49873651, ...}) = 0open("/tmp/test.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 5fstat(5, {st_mode=S_IFREG|0644, st_size=49873651, ...}) = 0lseek(5, 0, SEEK_CUR)          = 0lseek(5, 0, SEEK_CUR)          = 0flock(5, LOCK_EX)            = 0write(5, "1 connection status: 0abort:0\n", 30) = 30close(5)                = 0sendto(4, "HTTP/1.0 200 OK\r\nConnection: clo"..., 89, 0, NULL, 0) = 89sendto(4, "111111111", 9, 0, NULL, 0)  = 9rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0nanosleep({3, 0}, 0x7fff60a40290)    = 0sendto(4, "22222", 5, 0, NULL, 0)    = 5open("/tmp/test.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 5fstat(5, {st_mode=S_IFREG|0644, st_size=49873681, ...}) = 0lseek(5, 0, SEEK_CUR)          = 0lseek(5, 0, SEEK_CUR)          = 0flock(5, LOCK_EX)            = 0write(5, "2 connection status: 0abort:0\n", 30) = 30close(5)                = 0rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0nanosleep({1, 0}, 0x7fff60a40290)    = 0sendto(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) = 5fstat(5, {st_mode=S_IFREG|0644, st_size=49873711, ...}) = 0lseek(5, 0, SEEK_CUR)          = 0lseek(5, 0, SEEK_CUR)          = 0flock(5, LOCK_EX)            = 0write(5, "2 connection status: 1abort:1\n", 30) = 30close(5)                = 0rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0nanosleep({1, 0}, 0x7fff60a40290)    = 0open("/tmp/test.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 5fstat(5, {st_mode=S_IFREG|0644, st_size=49873741, ...}) = 0lseek(5, 0, SEEK_CUR)          = 0lseek(5, 0, SEEK_CUR)          = 0flock(5, LOCK_EX)            = 0write(5, "2 connection status: 1abort:1\n", 30) = 30close(5) 。。。我們照中看status從0到1轉變的地方。...sendto(4, "22222", 5, 0, NULL, 0)    = 5...write(5, "2 connection status: 0abort:0\n", 30) = 30close(5)                = 0rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0nanosleep({1, 0}, 0x7fff60a40290)    = 0sendto(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) = 5fstat(5, {st_mode=S_IFREG|0644, st_size=49873711, ...}) = 0lseek(5, 0, SEEK_CUR)          = 0lseek(5, 0, SEEK_CUR)          = 0flock(5, LOCK_EX)            = 0write(5, "2 connection status: 1abort:1\n", 30) = 30close(5)

第二次往socket中發送2222的時候顯示了Broken pipe。這就是程式告訴我們，這個socket已經不能使用了，順便php中的connection_status就會被設定為1了。後續的寫操作也都不會再執行了。

總結

正常情況下，如果用戶端client異常推出了，服務端的程式還是會繼續執行，直到與IO進行了兩次互動操作。服務端發現用戶端已經中斷連線，這個 時候會觸發一個user_abort，如果這個沒有設定ignore_user_abort，那麼這個php-fpm的程式才會被中斷。

至此，問題結了。

相關推薦：

PHP 底層的運行機制與原理

php cgi與fpm關係

PHP簡單實現socks5Proxy 伺服器