问在这些情况下TCP会自动关闭套接字吗？

EN

我从未听说过TCP套接字会自动关闭自己，因此我对此表示怀疑。如果发送方无法发送任何数据，则只需等待并再试一次。套接字关闭的唯一原因是，如果发送方多次尝试发送数据，不能，然后显式关闭套接字。如果发送方有足够的带宽发送数据，但接收方缺乏接收数据的带宽，则协议本身将重新发送数据并确保数据正确到达(请参阅维基百科)。

至于#2，也来自维基百科(正如ott提到的)：

当接收方广告窗口大小为0时，发送方停止发送数据并启动持久化计时器。持久化定时器用于防止TCP在接收方丢失后续窗口大小更新时可能出现的死锁情况，并且在从接收方接收到新的窗口大小更新之前，发送方无法发送更多数据。当持久化计时器过期时，TCP发送方通过发送一个小数据包来尝试恢复，以便接收方通过发送另一个包含新窗口大小的确认来响应。

因为TCP具有确定要发送多少数据的系统，所以我假设TCP连接总是可以接受一个更新数据包。在缓冲区仍然满的情况下，接收器将继续广播窗口大小为0的节目。除非一段软件在X重复"0窗口大小“之后显式关闭一个套接字，否则没有理由关闭该套接字。

虽然主机的TCP实现可能不会超时连接，即使很长一段时间内没有活动(但是要注意，存在一些TCP选项来处理和控制这种行为，如RFC 5482: TCP用户超时选项)、大多数网络设备(路由器、NAT盒、防火墙等)。有一些超时策略，其中空闲连接将被终止。有些设备的超时值仅为5分钟。

因此，如果您使用UDP淹没您的网络连接，则可能同时的TCP连接甚至无法获取单个数据包，从而导致路由器终止连接。

尽管TCP试图表现良好并防止网络链路泛滥，但UDP根本不在乎。因此，如果您能够控制UDP流量的行为(无论是在应用程序中还是在我的网络质量控制工具中)，这将极大地帮助您的TCP流量。

在我的例子中( closed，内核3.2在非阻塞套接字中)，当在recv函数中接收到零字节时，以及当我在发送-> errno =对等程序重置连接时出错时，套接字会自动关闭。我认为还有其他情况(当程序在recv和send函数中接收特定类型的错误时)。我希望这对你有用。