TCP套接字是否可能出现单向故障：仅无法发送但仍可接收？

作为同样深耕Socket开发多年的同行，碰到这种160万会话里才出现的罕见问题，确实够让人挠头的。先直接给你结论：TCP协议本身不会设计出这种“单向停滞”的情况，但网络链路层面的单向故障完全可能导致你观察到的现象。

一、从TCP机制本身拆解核心逻辑 #

TCP是全双工协议，但它的可靠性完全依赖双向的ACK确认机制：

• 如果客户端到服务器的路径完全中断，客户端发送的所有数据包（包括给服务器消息的ACK、自身的业务消息）都无法抵达服务器，服务器自然收不到客户端的任何内容；
• 但如果服务器到客户端的路径是通的，服务器发送的数据包能正常到达客户端，客户端也能正常接收——这里要注意：客户端给服务器消息的ACK是走「客户端→服务器」的路径，所以如果这条路径断了，服务器收不到ACK会触发超时重传，但服务器的应用层仍然可以继续往套接字写数据（这些数据会先存在发送缓冲区，直到缓冲区满才会阻塞），而客户端能持续收到这些数据。

这和你观察到的现象完全吻合：服务器收不到客户端的消息，但能正常发消息给客户端；客户端持续发送消息（堆积在自己的发送缓冲区，因为收不到服务器的ACK），同时能正常接收服务器的消息。

二、网络层面的单向故障是核心诱因 #

现实网络中，双向路由不对称是非常常见的情况：服务器到客户端的数据包走一条路由链路，客户端到服务器的数据包走另一条完全不同的链路。当其中一条链路（比如客户端→服务器的链路）出现故障时，就会出现这种“单向断连”的现象：

• 可能是ISP的某条单向链路故障（比如跨运营商的 peering 节点只断了一个方向）；
• 可能是中间某台防火墙/路由器的规则配置错误，只阻断了客户端→服务器方向的流量（比如误封了客户端到服务器的端口，却没影响反向）；
• 甚至可能是客户端所在的网络运营商做了单向带宽限制或流量拦截，导致客户端发的数据包根本出不去，但能正常接收外部数据。

三、结合你的场景补充验证点 #

你提到服务器在18秒后因检测到客户端空闲而关闭连接，这里的“空闲检测”应该是应用层的逻辑（比如多久没收到客户端的消息就判定超时）——这也符合单向故障的特征：服务器确实收不到任何客户端的数据包，所以触发应用层超时；而客户端能收到服务器的告别消息，说明服务器→客户端的链路直到最后都是通的。

排查建议 #

如果要进一步确认，可以做这些操作：

• 在服务器端抓包：应该看不到任何来自客户端的数据包（包括ACK和业务消息）；
• 在客户端抓包：能看到自己持续发送消息，但收不到对应的ACK，同时能正常收到服务器发送的消息；
• 双向 traceroute 对比：分别从服务器 traceroute 客户端，和从客户端 traceroute 服务器，看两条路径是否一致，是否在某一跳出现中断。

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