Tcp 谁负责处理掉电后客户临时端口的重复使用？

我们的客户端在启动时将smb共享映射到FreeNAS服务器上。我们注意到，在断电后，他们有时会出现连接到smb共享的问题

经过一段时间的调试和数据包捕获，问题似乎是客户端选择了一个以前使用过的临时端口，由于电源故障，该端口未正确关闭。当SYN被发送到启动SMB连接的服务器时，服务器会用一个带有非常高ACK号的ACK响应，而不是预期的SYN-ACK

服务器似乎从以前使用的、从未关闭过的临时端口中看到了SYN，并尝试继续旧的对话。这种来回将持续一段时间（超过一分钟），错误/延迟是有问题的

谁负责处理这种情况？客户机还是服务器？任何规格或细节都会非常有用。在这种情况下，谁有不当行为

---

更新：@fendall描述的行为就是Windows本身所做的。但是，这种行为并不恰当。相反，它将尝试新的临时端口，每个后续端口都会得到更多的尝试，直到最终放弃。Win10 1903安装程序附带的winPE版本工作正常在发布的WinPE上，如果您最近在它尝试的相当确定的少数临时端口上建立了连接，那么您就太倒霉了-在服务器决定忘记它们之前，无法建立tcp连接。

根据我的解释，您的问题的答案是客户端负责

作为对服务器ACK的响应，客户机应该检测到“此段没有确认它所确认的任何内容” 已发送，未同步时，会发送重置（RST），因为它已

---

检测到半开连接。“参考：

感谢您的解释和链接；这是有道理的。我唯一无法调和的是，为什么服务器会以如此巨大的ACK值进行响应；也许它只是需要在有效窗口之外的任何东西。无论如何，客户机不会发送规范似乎说它应该发送的重置。@aggieNick02确认号可能是上一次对话结束时的号码，或者可能表明服务器存储的确认号由于电源故障而损坏。我想应该是前者，因为所有服务器都会重新确认当前的序列号（从其角度）。由客户端重新建立看似毫无意义的连接。@fendall-仅供参考，服务器实际上不会断电。从长时间运行的跟踪来看，ACK值也不是对话结束的地方，这很奇怪。相反，它通常是一个较大的值-我猜它在某种程度上有助于指示SYN的无效性质，除了响应是ACK而不使用SYNSee update之外。感谢fendall和Zac67的回答/帮助。发现根本原因是某个版本的windows中存在tcp协议错误有点令人惊讶。我将向Microsoft提交文件。我不确定这是否相关。但我发现，在Windows101607以上的任何winpe版本中，多播的速度大约是8倍。