好久没写博客了，因为没有啥可写。
之所以有此疑问，是因为看了一篇大牛的文章：PHP升级导致系统负载过高问题分析。看完后，其中有些文字触发了我这个想法，也想验证一下。
方案，用tcpdump抓包，用strace获取系统调用
tcpdump port 8080 or port 9000 -i lo -s 0 -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的结果，也可以验证上面的结论。
