在这些情况下，TCP是否会自动关闭套接字

Question

我们正在使用C / S在linux上开发一个网络应用程序，最近我们发现当有大量的UDP和TCP数据通过带宽传输时，某些打开和连接的套接字上的写入/读取可能会失败，它看起来像插座因某种未知原因而关闭。

以下是问题，请告诉我TCP是否会自动关闭套接字。

1. 假设有发送方和接收方，发送方通过TCP非阻塞套接字向接收方发送大量数据。并且假设应用程序本身和其他应用程序在带宽上有很多流量。 如果带宽完全部署，发送者没有任何机会发送数据，那么TCP会在一段时间后自动关闭套接字吗？如果是的话，时间价值是多少？

2. 假设问题1中的带宽未完全部署，并且发送方可以成功地将数据传送到接收方。但是如果接收器没有读取数据，并且在一段时间后缓冲区将填满，那么TCP会在几小时内自动关闭套接字吗？

非常感谢任何帮助!!

Answer 1

我从未听说过TCP套接字自动关闭，所以我怀疑是这种情况。如果发件人无法发送任何数据，则只需等待并再试一次。套接字关闭的唯一原因是发件人尝试多次发送数据，不能，然后显式关闭套接字。如果发送方有足够的带宽发送数据但接收方缺少接收数据的带宽，则协议本身将重新发送数据并确保其正确到达（请参阅Wikipedia）。

至于＃2，也来自维基百科（如提到的那样）：

  

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

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

Answer 2

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

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

虽然TCP试图保持良好状态并防止网络链路泛滥，但UDP根本不关心。因此，如果您可以控制UDP流量的行为（在应用程序或我的网络质量控制工具中），这将有助于您的TCP流量。

Answer 3

我已经看过我的情况（C Linux，内核3.2在非阻塞套接字中），当在recv函数中接收零字节时以及当我在send中有错误时，套接字会自动关闭 - ＆gt; errno =由peer重置连接。我认为还有其他情况（当程序在recv和send函数中收到某些特定类型的错误时）。我希望这对你有用。