Nginx 为什么要延迟关闭

防止 Nginx处理完后调用close关闭连接后  ，若缓冲区任然接收到客户端发来的内容 ，则服务器会向客户端发送RST包关闭连接，导致客户端由于收到了RST而忽略了  http  response  

                             （当一个进程向某个已收到RST的套接字执行写操作时，内核向该进程发送一个SIGPIPE信号）； 

上面Nginx调用了close 就会同时关闭 服务器端的   读 和 写    此时如果客户段仍然有请求即向Nginx服务器写数据   即第一次服务器会回复一个 RST包  第二次  当一个进程向某个已收到RST的套接字执行写操作时，内核向该进程发送一个SIGPIPE信号  客户段自己会挂掉啊 那就会忽略了   网络中未到达或者已经到达的  http  response 

做一个很简单的通信模块：服务器端监听服务请求并接收数据；客户端连接服务器段并发送数据。考虑到 一种情况：客户端向服务器端连续两次发送数据，而服务器端在accept之后就关闭了连接。

通过在服务器端accept成功之后调用close(fd)模仿这种情形。UNP的5.13节说客户端在第二次发送数据时会接收到第一次发送数据时服务器端返回的RST从而导致内核发出SIGPIPE信号。于是我在客户端程序中使用signal(SIGPIPE, sig_pipe)捕捉SIGPIPE信号，程序调试时证明UNP说得没错，但在运行状态时有时候捕捉不到SIGPIPE信号。

仔细看书，UNP第113面的5.12节中有一小段文字讲RST被客户端收到的时间取决于时序问题，于是猜想第二此调用send函数发送数据时有可能服务器端的RST还未返回。为了验证这个猜想，在第二次发送数据前sleep一下程序，使得RST能在send前返回。测试程序，乖乖，这次都能捕捉到SIPPIPE信号了。

问题是：假如我想100％的捕捉SIGPIPE信号，那么每次的sleep就会影响到程序的效率。

服务器端SIGPIPE信号问题      可以类推到上面Nginx为什么需要延迟关闭了 

客户端进程突然断开（进程被kill掉）时，被kill的进程在终止处理的工作中关闭所有该进程打开的描述符，这导致了一个FIN被发送给了服务器，服务器接收以后回复一个ACK；至此，该过程完成了四次挥手的前半个部分；然而此时在服务器上与客户端保持连接的该进程正在将文件流发往客户端，服务器上的该进程还并未调用close或shutdown函数，因此四次挥手的后一部分尚未完成；
根据上述，由于四次挥手没有完成后一部分，服务器仍然能向客户端发送数据，第一次数据到客户端后，客户端会响应一个RST，服务器接收后仍在向缓冲区发送数据，此时，内核向该进程发送一个SIGPIPE信号；

（当一个进程向某个已收到RST的套接字执行写操作时，内核向该进程发送一个SIGPIPE信号）；

注意：SIGPIPE信号的默认行为是终止进程，因此服务器进程退出；
---------------------