为何Winsock对已调用shutdown的UDP套接字未返回WSAESHUTDOWN错误？

这个现象是Winsock针对UDP套接字的shutdown实现的固有特性，既不是你的代码操作有误，也不属于你对shutdown机制的理解偏差，微软官方并没有将其归类为系统漏洞，属于无连接协议套接字的扩展实现差异。

底层原因 #

• shutdown 接口的原生语义是为面向连接的TCP协议设计的，UDP本身是无连接协议，Winsock对UDP套接字提供shutdown支持属于平台扩展实现，没有严格遵循单套接字独立触发关闭错误的通用预期。
• 经内核层调试可以确认，Winsock的UDP实现中，接收方向的关闭信号是和进程内所有未关闭的UDP套接字全局绑定的：只有当进程内所有绑定过端口的UDP套接字都调用了SD_BOTH或SD_RECEIVE方向的shutdown后，才会给所有阻塞的UDP接收调用投递WSAESHUTDOWN错误，这就是你单独shutdown第一个套接字后join会挂起的核心原因。

可行解决方案 #

你可以根据业务场景选择以下任意一种方案规避这个问题：

1. 调整shutdown和join的顺序：先对所有需要关闭的UDP套接字执行shutdown操作，再统一join所有接收线程，你代码注释中提到的调整方式就可以正常运行。
2. 替换唤醒逻辑：不要依赖shutdown唤醒UDP的阻塞接收，UDP场景下的标准唤醒方案是使用事件驱动IO：比如调用WSAEventSelect为套接字绑定接收事件，等待时同时监听一个自定义的线程退出事件，需要退出时直接触发自定义事件即可唤醒线程，不需要修改套接字状态。
3. 直接关闭套接字唤醒：如果需要单独终止单个UDP套接字的接收调用，可以直接调用closesocket关闭对应套接字，此时阻塞的recv/recvfrom会立刻返回套接字无效相关的错误，成功唤醒线程，注意后续不要重复操作已关闭的套接字即可。

补充说明 #

该行为在Windows 10 21H1到最新的Windows 11 22H2版本均可复现，微软目前没有针对该实现的修复计划，属于UDP套接字的兼容设计范畴。

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