瀏覽退出之後php還會繼續執行嗎?下面小編就為大家介紹一下究竟覽器退出之後php還會不會繼續執行。希望對大家有幫助。
前提:這裡說的是典型的lnmp結構,nginx+php-fpm的模式
如果我有php程式執行地非常慢,甚至於在程式碼中sleep(),然後瀏覽器連接上服務的時候,會啟動一個php-fpm進程,但這個時候,如果瀏覽器關閉了,那麼請問,這個時候服務端的這個php-fpm進程是否還會繼續運作呢?
今天就是要解決這個問題。
最簡單的實驗
最簡單的方法就是要做實驗,我們寫一個程式:在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還是會繼續運行的?
ignore_user_abort
老王和diogin提醒,這個可能是和php的ignore_user_abort函數相關。
於是我就把程式碼稍微改成這樣的:
<?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為何值,都是會繼續執行的。
但這裡有個疑問: 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 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)
第二次往socket中发送2222的时候显示了Broken pipe。这就是程序告诉我们,这个socket已经不能使用了,顺便php中的connection_status就会被设置为1了。后续的写操作也都不会再执行了。
总结
正常情况下,如果客户端client异常推出了,服务端的程序还是会继续执行,直到与IO进行了两次交互操作。服务端发现客户端已经断开连接,这个 时候会触发一个user_abort,如果这个没有设置ignore_user_abort,那么这个php-fpm的程序才会被中断。
至此,问题结了。
相关推荐:
以上是瀏覽器退出之後php還會繼續執行嗎的深入探究的詳細內容。更多資訊請關注PHP中文網其他相關文章!