Linux SIGPIPE信号-不念博客

在 TCP 通信双方中，为了描述方便，以下将通信双方用 A 和 B 代替。

当 A “关闭”连接时，若 B 继续给 A 发数据，根据 TCP 协议的规定，B 会收到 A 的一个 RST 报文响应，如 B 继续再往这个服务器发送数据，系统会产生一个 SIGPIPE 信号给该 B 进程，告诉该进程这个连接已经断开了，不要再写了。

系统对 SIGPIPE 信号的默认处理行为是让 B 进程退出。

操作系统对 SIGPIPE 信号的这种默认处理行为非常不友好，让我们来分析一下。

上图是 TCP 通信四次挥手的示意图，TCP 通信是全双工的信道，可以看作两条单工信道， TCP 连接两端的两个端点各负责一条。

当对端“关闭”时, 虽然本意是关闭整个两条信道，但本端只是收到 FIN 包。

按照 TCP 协议规定的语义，表示对端只是关闭了其所负责的那一条单工信道，虽然不再发送数据，但仍然可以继续接收数据。

也就是说，因为 TCP 协议的限制，通信一方无法获知对端的 socket 是调用了 close 还是 shutdown。

int shutdown(int socket, int how);

shutdown 函数的参数 how 可以设置为关闭 SHUT_RD、SHUT_WR 或 SHUT_RDWR 用于表示关闭收、发单个通道或者同时关闭收发通道。

对一个已经收到 FIN 包的 socket 调用 read/recv 方法，如果接收缓冲已空，则返回 0，这就是常说的表示连接关闭。但第一次对其调用 write/send 方法时，如果发送缓冲没问题，会返回正确写入（即 write/send 函数返回值大于 0），但发送的报文会导致对端回应 RST 报文。因为上一次程序调用 write/send 是正常的，再次尝试调用 write/send 函数时因产生 SIGPIPE 信号导致进程退出。

这种默认行为对于我们开发程序，尤其是对于后端服务，需要同时对许多客户端服务，不能因为与某一个客户端的连接出问题了而导致整个进程退出不能继续为其他客户端服务。

为了避免这种现象出现, 可以捕获 SIGPIPE 信号并对其进行处理或者忽略该信号，忽略该信号代码如下：