UNIX套接字SOCK_DGRAM与SOCK_STREAM单边关闭行为差异问询

为什么SOCK_DGRAM的read不会返回0？ #

核心原因是SOCK_DGRAM属于无连接的数据包协议，和面向连接的SOCK_STREAM有着本质差异：

• SOCK_STREAM是基于双向字节流的连接型协议，当对端主动关闭套接字，会发送FIN包通知本端，本端读取完剩余数据后，后续的read()调用就会返回0，明确表示连接已终止。
• 而SOCK_DGRAM没有真正的“连接”状态——哪怕你调用了connect()固定了发送目标，这也只是让内核帮你默认填充对端地址，并没有建立双向的连接会话。对端关闭套接字时，不会给本端发送任何终止信号，本端内核也不会跟踪对端的存活状态，所以read()会一直等待新的数据包：阻塞模式下无限挂起，非阻塞模式下则会返回EAGAIN/EWOULDBLOCK（你提到的反复EINTR通常是因为有信号中断了系统调用，并非协议本身的行为）。

该行为的规范依据 #

POSIX标准对套接字的read()行为有明确规定：

• 对于SOCK_STREAM类型，当对端关闭连接且所有已发送数据都被读取完毕，read()返回0以指示EOF。
• 对于SOCK_DGRAM类型，read()仅在成功读取到完整数据包时返回字节数；若无可用数据包，阻塞模式下保持等待，非阻塞模式返回EAGAIN或EWOULDBLOCK。不存在返回0的情况，因为无连接协议没有“文件结束”的概念。
• UNIX域套接字的SOCK_DGRAM完全遵循这一通用套接字规范，没有特殊例外。

SOCK_DGRAM场景下如何检测对端关闭？ #

由于内核不会主动通知对端状态变化，需要在应用层实现检测逻辑：

• 心跳机制：定期向对端发送心跳包，若连续多次未收到响应（或发送时收到ECONNREFUSED/EPIPE错误），则判定对端已关闭。UNIX域套接字中，向已关闭的对端地址发送数据时，可能触发EPIPE错误（可以通过忽略SIGPIPE信号，在send()调用中捕获这个错误码）。
• 显式关闭通知：在应用协议中定义专门的“关闭指令”数据包，对端在关闭套接字前主动发送该包，本端收到后即可知晓对端即将断开。
• 结合connect的发送检测：如果已经用connect()绑定了固定的对端地址，当对端关闭套接字后，后续的send()调用可能会返回EPIPE错误，通过这个错误可以推断对端已不存在。

内容的提问来源于stack exchange，提问作者Caulder