什么可能导致活动TCP接近返回而不通知被动端？

Question

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

当TCP连接的末端之间出现故障入侵防御系统（IPS）时，我已经看到过这种行为。 IPS的制造商正在解决这个问题。

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

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

Answer 1

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