高发送率场景下关闭UDP套接字后重绑定同地址端口报errno 98地址已占用的原因是什么

UDP为无连接协议，本身不存在类似TCP的TIME_WAIT状态机。高发包率场景下bind报errno 98 (EADDRINUSE)的核心原因是Linux内核的UDP套接字异步回收机制：

• 调用close(fd)后，进程会立刻回收对应的文件描述符，这也是你观察到新建socket返回相同fd的本质原因——该操作仅完成进程侧的文件描述符表回收，不代表内核网络栈已经释放了套接字绑定的地址与端口。
• 10Gb/s级高发包率场景下，套接字发送队列、内核qdisc层、网卡驱动队列会堆积大量待发送数据包。此时内核不会同步等待所有数据包发送完成再销毁sock结构体，而是将sock结构体标记为异步待回收状态，保留其绑定的源IP+端口的哈希表项，直到所有排队数据包发送完毕、套接字内存资源全部释放后，才会将绑定项从inet协议栈的绑定哈希表中移除。
• 从close执行完成到哈希表项被移除的毫秒级窗口内，再次绑定相同地址端口，就会触发EADDRINUSE错误。

低发包率下，调用close()时套接字的发送队列基本为空，内核会同步完成sock结构体销毁、绑定表项移除的全流程，不会留下异步回收的时间窗口，因此bind操作可以立刻成功。

你对SO_REUSEADDR的顾虑可以完全消除，Linux内核中UDP套接字绑定的冲突判断逻辑是分层的：

• 如果绑定的地址端口上存在正在活跃使用的sock结构体，哪怕套接字设置了SO_REUSEADDR，bind依然会返回EADDRINUSE，不会出现“跳过活跃端口占用判断”的问题，完全满足你“准确判断活跃套接字端口占用”的需求。
• 只有当绑定项对应的sock是处于上文提到的异步待回收残留状态时，SO_REUSEADDR才会允许新套接字完成绑定，直接绕过这个毫秒级的回收时间窗口，从根源上解决高发包率下的绑定失败问题。

你之前用netstat无法观测到这类异常条目是正常的：异步待回收的sock不会被归类到常规UDP状态条目里，常规netstat输出不会显示。要观测的话可以使用：

• 运行ss -u -e，待回收的sock会显示为unres状态，这类条目的存在窗口刚好对应绑定失败的时间周期。
• 如果不启用SO_REUSEADDR，也可以在bind失败后增加几毫秒的退避重试，等内核完成sock回收后即可绑定成功，但本质上只是绕开了时间窗口，没有从机制上解决问题。

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