UNIX域套接字使用零长度数据报的原因与适用场景

首先要明确：数据报套接字场景下recv()返回0，仅代表收到了一个零长度的数据报，和流式套接字中对端关闭连接时的返回值0完全没有语义上的关联，这是很多开发者容易踩的认知坑。

• 纯事件类的无载荷通知：跨进程交互里经常出现不需要附带任何参数的信号场景——比如服务进程初始化完成、某批后台计算任务执行结束、临时通知对端释放操作锁，这类场景如果硬要构造带载荷的报文（比如塞个固定字节的"1"当标记），既要额外定义冗余的协议字段，还要做没必要的内存拷贝，直接发零长度数据报，对端recv()拿到0的返回值就可以触发对应的事件处理逻辑。
• 对端存活探测：UNIX域数据报套接字本身走本地内核通信路径，发零长度包做探测的开销极低，只要对端能正常收到这个包并返回0，就说明对端的套接字绑定点、进程状态都是正常的，没有崩溃退出或者被系统回收，比其他探测方式的侵入性小很多。
• 自定义协议的边界标记：如果在基于UNIX数据报套接字的自定义协议里，需要标记一批连续报文的结束点、或是消息的分段边界，又不想专门引入长度字段、转义字符这类额外的协议开销，就可以直接用零长度包当分隔标识——比如连续发10个业务数据包之后，发一个零长度包通知对端"当前这一批数据已经发完，可以统一做批量处理"。

• 核心目的是削减本地IPC的无效开销：很多纯信号类的本地交互本来就不需要载荷，如果协议强制要求每个报文必须带有效数据，开发者往往会硬塞无意义的占位内容，这部分内容的用户态拷贝、内核态传递都是完全不必要的额外开销。零长度数据报的设计就是把这类交互的开销压到最低——发送时不需要拷贝任何用户态数据，内核只需要传递"收到一个空包"的事件，没有任何多余的内存操作。
• 匹配本地IPC的低延迟需求：UNIX域套接字的核心优势就是同主机通信的低延迟，零长度包的处理路径是所有套接字交互里最短的——从发送端调用sendto开始，不需要跨用户态/内核态的载荷拷贝，内核直接把事件挂到接收端的等待队列上，接收端的recv()拿到0的返回值就能立刻触发处理，延迟比带哪怕1字节载荷的报文低一个量级。
• 保持套接字API的一致性：不管是发带载荷的业务数据包，还是发零长度的信号包，应用层调用的sendto、recv接口完全没有区别，不需要为了实现纯信号交互专门引入新的内核原语（比如eventfd、信号量），对于已经在用UNIX数据报套接字搭建IPC通道的场景，不需要重构现有代码，就能直接复用现有通道实现信号类的交互能力。

内容的提问来源于stack exchange，提问作者NK-cell