瀏覽器退出之后php還會繼續(xù)執(zhí)行么？

好亂非常亂 2016-09-25

展開全文

本文所述環(huán)境為lnmp結構，nginx+php-fpm的模式如果我有個php程序執(zhí)行地非常慢，甚至于在代碼中sleep()，然后瀏覽器連接上服務的時候，會啟動一個php-fpm進程，但是這個時候，如果瀏覽器關閉了，那么請問，這個時候服務端的這個php-fpm進程是否還會繼續(xù)運行呢？

今天咱就來說說這個問題。

先來一個試驗代碼：

在sleep之前和之后都用file_put_contents來寫入日志：

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還是會繼續(xù)運行的?

ignore_user_abort

這個可能是和php的ignore_user_abort函數(shù)相關。于是我就把代碼稍微改成這樣的：

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)并沒有什么卵用，不管設置ignore_user_abort為何值，都是會繼續(xù)執(zhí)行的。

但是這里有一個疑問: user_abort是什么？

文檔對cli模式的abort說的很清楚，當php腳本執(zhí)行的時候，用戶終止了這個腳本的時候，就會觸發(fā)abort了。然后腳本根據(jù)ignore_user_abort來判斷是否要繼續(xù)執(zhí)行。

但是官方文檔對cgi模式的abort并沒有描述清楚。感覺即使客戶端斷開連接了，在cgi模式的php是不會收到abort的。
難道ignore_user_abort在cgi模式下是沒有任何作用的？

我們斷開瀏覽器客戶端，等于在客戶端沒有close而斷開了連接，服務端是需要等待tcp的keepalive到達時長之后才會檢測出來的。

好，需要先排除瀏覽器設置的keepalive問題。

拋棄瀏覽器，簡單寫一個client程序：程序連接上http服務之后，發(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
}

服務端程序：

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還是不管是否設置ignore_user_abort，會繼續(xù)執(zhí)行完成整個腳本?？磥韎gnore_user_abort還是沒有生效。

那該怎么觸發(fā)ignore_user_abort呢？服務端這邊怎么知曉這個socket不能使用了呢？是不是需要服務端主動和socket進行交互，才會判斷出這個socket是否可以使用？另外，我們還發(fā)現(xiàn)，php提供了connection_status和connection_aborted兩個方法，這兩個方法都能檢測出當前的連接狀態(tài)。于是我們的打日志的那行代碼就可以改成：

file_put_contents('/tmp/test.log', '1 connection status: ' . connection_status() . 'abort:' . connection_aborted() . PHP_EOL, FILE_APPEND | LOCK_EX);

根據(jù)手冊連接處理顯示我們可以打印出當前連接的狀態(tài)了。

下面還缺少一個和socket交互的程序，我們使用echo，后面也順帶記得帶上flush，排除了flush的影響。

程序就改成：

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）。

使用wireshark抓包看整個客戶端和服務端交互的過程

這整個過程只有發(fā)送14個包，我們看下服務端第一次發(fā)送22222的時候，客戶端返回的是RST。后面就沒有進行后續(xù)的包請求了。

于是理解了，客戶端和服務端大概的交互流程是：

當服務端在循環(huán)中第一次發(fā)送2222的時候，客戶端由于已經(jīng)斷開連接了，返回的是一個RST，但是這個發(fā)送過程算是請求成功了。直到第二次服務端再次想往這個socket中進行write操作的時候，這個socket就不進行網(wǎng)絡傳輸了，直接返回說connection的狀態(tài)已經(jīng)為abort。所以就出現(xiàn)了上面的情況，第一次222是status為0，第二次的時候才出現(xiàn)abort。

我們也可以使用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中發(fā)送2222的時候顯示了Broken pipe。這就是程序告訴我們，這個socket已經(jīng)不能使用了，順便php中的connection_status就會被設置為1了。后續(xù)的寫操作也都不會再執(zhí)行了。

正常情況下，如果客戶端client異常推出了，服務端的程序還是會繼續(xù)執(zhí)行，直到與IO進行了兩次交互操作。服務端發(fā)現(xiàn)客戶端已經(jīng)斷開連接，這個時候會觸發(fā)一個user_abort，如果這個沒有設置ignore_user_abort，那么這個php-fpm的程序才會被中斷。