php-fpm正在生成页面时，浏览器刷新后，php-fpm会退出吗？

好久没写博客了，因为没有啥可写。

之所以有此疑问，是因为看了一篇大牛的文章：PHP升级导致系统负载过高问题分析。看完后，其中有些文字触发了我这个想法，也想验证一下。

方案，用tcpdump抓包，用strace获取系统调用

tcpdump port  or port  -i lo -s  -w temp

8080是nginx的服务端口，9000是php-fpm服务的端口，抓这两个端口是想看到浏览器、nginx、php-fpm三者之间的交互。抓完包后，用wireshark分析，如下：

解释如下：

1，46540是浏览器的端口，http-alt是nginx，54352是nginx请求php-fpm的端口，cslistener是php-fpm

2，因为我所有的操作都是在一台机器上，包括浏览器访问，所以所有的IP都是127.0.0.1

3，

A：图中第一部分，代表浏览器和nginx的三次握手的过程。

B：图中第二部分，代表浏览器向nginx请求一个URL。

C：图中第三部分，代表nginx与php-fpm三次握手的过程。

D：图中第四部分，代表nginx将浏览器的请求转发给php-fpm。

E：图中第五部分的11，13，14行，代表浏览器主动关闭了与nginx之间的连接。为什么关闭呢，因为我不断的刷新页面，在第二次刷新的时候，浏览器会关闭上一次的请求。

为什么是三次关闭，而不是四次握手关闭呢？因为第13行其实是两个包合成一个包发送了，这应该算tcp的优化吧。

F：图中第五部分的12，25行，代表nginx将浏览器关闭连接的消息，告诉了php-fpm。

G：图中第六部分，通过左边的时间可以发现，是5秒种之后，php-fpm试图向nginx返回它縇染后的页面，但nginx直接reset掉了这个连接。

为什么是5秒种之后返回呢，因为我在php程序的第一行sleep(5)，用于模拟时间较长的业务逻辑处理。

分析到这里，结论已经很明显了，就是：

浏览器关闭请求后，nginx会通知到php-fpm，但php-fpm忽略了这个通知，继续处理，直到发送处理结果时，才知道了连接已经被关闭。

我想在这里，php-fpm还是有可以优化的空间的。

大家可以看下strace的结果，也可以验证上面的结论。