11 TCP套接字之SIGPIPE信号

最新推荐文章于 2025-06-20 21:23:03 发布

Function_18

最新推荐文章于 2025-06-20 21:23:03 发布

阅读量759

点赞数 2

CC 4.0 BY-SA版权

分类专栏：网络编程网络编程学习文章标签： tcp通信 tcp套接字 SIGPIPE信号

本文链接：https://blog.youkuaiyun.com/Function_Dou/article/details/89914018

网络编程同时被 2 个专栏收录

56 篇文章

订阅专栏

网络编程学习

55 篇文章

订阅专栏

本文介绍了在TCP通信中，当服务端主动关闭连接后，客户端可能出现的阻塞问题，该问题由SIGPIPE信号引起。通过分析抓包情况，发现客户端在服务端关闭后仍尝试发送数据，导致阻塞。解决方法是捕捉SIGPIPE信号并退出进程，但此方法并不完美，尤其在多任务环境中。文章还提到了半打开连接的概念，即一方异常终止连接，另一方仍保持连接状态，只有在尝试发送数据时才能发现连接已关闭。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

文章目录

前面我们解决了并发服务端的问题, 但是还是没有解决掉客服端的bug.

问题重现

我们以上一节的代码为例浮现这个bug.

完整代码 : fork_SIGCHLD.c

在这里插入图片描述

可能你已经忘了客服端的问题了, 这里在重新说明一下 : 当建立连接后, 服务端主动关闭后, 客服端并没有立即退出, 而是处于阻塞状态直到有输入才会退出.

问题分析

分析问题的时, 应该先来看一下抓包的情况.

在这里插入图片描述

问题基本也能分析出来.

服务端关闭时向客服端发送FIN, 根据四次挥手的原则, 此时客服端还能够向服务端发送数据, 也就解释了客服端没有发送FIN而是阻塞在read函数等待输入数据, 但服务端其实发送FIN后就被关闭了, 等待客服端发送数据后因为对端已经完全关闭了所以发送RST.
客服进程看不到RST, 因为在调用read之后立即调用write并且收到服务端的FIN后返回0, 进程继续阻塞在第二次的read函数.

解决办法

其实当进程接收到RST的套接字执行的写操作时, 内核会向该进程发送SIGPIPE信号. 该信号默认行为是为了终止进程, 但是该信号默认是被忽略的, 所以解决这个问题就需要客服端捕捉该信号然后退出才行.

有了这个办法接下来在客服端捕捉SIGPIPE信号即可.

void sighandler(int signo)
{
    if(signo == SIGPIPE){
	fprintf(stderr, "server close\n");
    }
}
int main(){
    if(sigaction(SIGPIPE, &action, NULL) != 0)
		EXIT("sigaction SIGPIPE");
}