瀏覽器退出以後php還會繼續執行麼

時間 2019-12-02

原文原文鏈接

瀏覽器退出以後php還會繼續執行麼？

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

若是我有個php程序執行地很是慢，甚至於在代碼中sleep()，而後瀏覽器鏈接上服務的時候，會啓動一個php-fpm進程，可是這個時候，若是瀏覽器關閉了，那麼請問，這個時候服務端的這個php-fpm進程是否還會繼續運行呢？nginx

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

最簡單的實驗

最簡單的方法就是作實驗，咱們寫一個程序：在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仍是會繼續運行的?socket

ignore_user_abort

老王和diogin提醒，這個多是和php的ignore_user_abort函數相關。tcp

因而我就把代碼稍微改爲這樣的：函數
<?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爲什麼值，都是會繼續執行的。php-fpm

可是這裏有一個疑問: user_abort是什麼？ui

文檔對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)                                = 0
第二次往socket中發送2222的時候顯示了Broken pipe。這就是程序告訴咱們，這個socket已經不能使用了，順便php中的connection_status就會被設置爲1了。後續的寫操做也都不會再執行了。

總結

正常狀況下，若是客戶端client異常推出了，服務端的程序仍是會繼續執行，直到與IO進行了兩次交互操做。服務端發現客戶端已經斷開鏈接，這個時候會觸發一個user_abort，若是這個沒有設置ignore_user_abort，那麼這個php-fpm的程序纔會被中斷。

至此，問題結了。