深入剖析瀏覽器退出之后php還會(huì)繼續(xù)執(zhí)行么

更新時(shí)間：2016年05月17日 10:13:51 投稿：jingxian

覽器退出之后php還會(huì)繼續(xù)執(zhí)行么？下面小編就為大家介紹一下究竟覽器退出之后php還會(huì)不會(huì)繼續(xù)執(zhí)行。一起跟隨小編過(guò)來(lái)看看吧

前提：這里說(shuō)的是典型的lnmp結(jié)構(gòu)，nginx+php-fpm的模式

如果我有個(gè)php程序執(zhí)行地非常慢，甚至于在代碼中sleep()，然后瀏覽器連接上服務(wù)的時(shí)候，會(huì)啟動(dòng)一個(gè)php-fpm進(jìn)程，但是這個(gè)時(shí)候，如果瀏覽器關(guān)閉了，那么請(qǐng)問(wèn)，這個(gè)時(shí)候服務(wù)端的這個(gè)php-fpm進(jìn)程是否還會(huì)繼續(xù)運(yùn)行呢？

今天就是要解決這個(gè)問(wèn)題。

最簡(jiǎn)單的實(shí)驗(yàn)

最簡(jiǎn)單的方法就是做實(shí)驗(yàn)，我們寫一個(gè)程序：在sleep之前和之后都用file_put_contents來(lái)寫入日志：

<?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è)诜?wù)器sleep的過(guò)程中，關(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)并沒(méi)有任何軟用，不管設(shè)置ignore_user_abort為何值，都是會(huì)繼續(xù)執(zhí)行的。

但是這里有一個(gè)疑問(wèn): user_abort是什么？

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

但是官方文檔對(duì)cgi模式的abort并沒(méi)有描述清楚。感覺(jué)即使客戶端斷開(kāi)連接了，在cgi模式的php是不會(huì)收到abort的。

難道ignore_user_abort在cgi模式下是沒(méi)有任何作用的？

是不是心跳問(wèn)題呢？

首先想到的是不是心跳問(wèn)題呢？我們斷開(kāi)瀏覽器客戶端，等于在客戶端沒(méi)有close而斷開(kāi)了連接，服務(wù)端是需要等待tcp的keepalive到達(dá)時(shí)長(zhǎng)之后才會(huì)檢測(cè)出來(lái)的。

好，需要先排除瀏覽器設(shè)置的keepalive問(wèn)題。

拋棄瀏覽器，簡(jiǎn)單寫一個(gè)client程序：程序連接上http服務(wù)之后，發(fā)送一個(gè)header頭，sleep1秒就主動(dòng)close連接，而這個(gè)程序并沒(méi)有帶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è)腳本?？磥?lái)ignore_user_abort還是沒(méi)有生效。

如何觸發(fā)ignore_user_abort

那該怎么觸發(fā)ignore_user_abort呢？服務(wù)端這邊怎么知曉這個(gè)socket不能使用了呢？老王和diogin說(shuō)是不是需要服務(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ù)端交互的過(guò)程

這整個(gè)過(guò)程只有發(fā)送14個(gè)包，我們看下服務(wù)端第一次發(fā)送22222的時(shí)候，客戶端返回的是RST。后面就沒(méi)有進(jìn)行后續(xù)的包請(qǐng)求了。

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

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

strace進(jìn)行驗(yàn)證

我們也可以使用strace php -S XXX來(lái)進(jìn)行驗(yàn)證

整個(gè)過(guò)程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)斷開(kāi)連接，這個(gè) 時(shí)候會(huì)觸發(fā)一個(gè)user_abort，如果這個(gè)沒(méi)有設(shè)置ignore_user_abort，那么這個(gè)php-fpm的程序才會(huì)被中斷。

至此，問(wèn)題結(jié)了。

以上這篇深入剖析瀏覽器退出之后php還會(huì)繼續(xù)執(zhí)行么就是小編分享給大家的全部?jī)?nèi)容了，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

您可能感興趣的文章: