tcp - 什么可能导致主动 TCP 关闭返回而不通知被动端？

Question

我对使用 TCP 的应用程序的行为感到困惑。当 Internet 范围的 TCP 连接一端的应用程序在套接字上调用 close() 时，close() 返回。然而，在另一端，套接字上的 write() 并不表示 TCP 连接已关闭。AFAIK，这种行为与 TCP 规范不一致：主动 close() 不应该返回，除非它收到来自 TCP 连接另一端的确认（具体来说，主动端的 TCP 状态不能转换出来TIME_WAIT_1 除非它从另一端收到适当的响应——此时另一端的 write() 应该返回错误）。

当故障入侵防御系统 (IPS) 在 TCP 连接的两端之间时，我已经看到了这种行为。IPS 的制造商正在解决这个问题。

是否还有其他可能发生此行为的情况？

我的环境是 Unix、C、ONC RPC 和套接字。

Answer 1

您将协议状态转换和 API 行为混为一谈。RFC 中没有任何内容表明 close() API 不能返回到应用程序并且协议操作异步进行，而这正是 Sockets API 默认情况下发生的情况。如果在套接字发送缓冲区中有待发送的数据并且接收器很慢，则发送 FIN 可能需要任意时间。您可以通过使用套接字选项 SO_LINGER 设置延迟超时来更改它，这会导致 close 阻塞，直到所有数据都被刷新或超时到期，但它在实践中几乎从未使用过。