浏览器退出以后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的程序才会被中断。

至此，问题结了。