我们正在使用 C/S 在 linux 上开发一个网络应用程序，最近我们发现当有大量 UDP 和 TCP 数据通过带宽传输时，一些打开和连接的套接字上的写入/读取可能会失败，看起来套接字是因不明原因关闭。
问题来了，请告诉我TCP是否会自动关闭套接字。
假设有发送方和接收方，发送方通过 TCP 非阻塞套接字向接收方发送大量数据。并假设应用程序本身和其他应用程序在带宽上有大量流量。如果带宽完全部署，发送方没有任何机会发送数据，那么 TCP 会在一段时间后自动关闭套接字吗？如果是，时间价值是多少？
假设问题 1 的带宽没有完全部署，发送方可以成功将数据传递给接收方。但是如果接收方没有读取数据并且在一段时间后缓冲区会填满，那么 TCP 会在几小时内自动关闭套接字吗？
任何帮助将不胜感激！！
我从未听说过 TCP 套接字会自动关闭，所以我怀疑是这种情况。如果发送方无法发送任何数据，它只会等待并重试。套接字关闭的唯一原因是，如果发送方多次尝试发送数据，但不能，然后显式关闭套接字。如果发送方有足够的带宽来发送数据，但接收方缺乏接收数据的带宽，协议本身将重新发送数据并确保数据正确到达（参见Wikipedia）。
至于#2，也来自维基百科（正如 ott 提到的）：
当接收方通告窗口大小为 0 时，发送方停止发送数据并启动持久计时器。持久计时器用于保护 TCP 免受死锁情况的影响，如果来自接收方的后续窗口大小更新丢失，并且发送方在接收到来自接收方的新窗口大小更新之前无法发送更多数据，则可能会出现死锁情况。当持续计时器到期时，TCP 发送方通过发送一个小数据包来尝试恢复，以便接收方通过发送另一个包含新窗口大小的确认来响应。
因为 TCP 有这个系统来确定要发送多少数据，所以我假设 TCP 连接总是可以接受一个更新数据包。在缓冲区仍然满的情况下，接收器将继续广播大小为 0 的窗口。除非某个软件在 X 重复“0 窗口大小”后明确关闭套接字，否则套接字没有理由关闭.
尽管主机的 TCP 实现可能不会使连接超时，即使很长一段时间没有活动（但请注意，存在一些 TCP 选项来处理和控制该行为，例如RFC 5482: TCP User Timeout Option），大多数网络设备（路由器、NAT 盒、防火墙等）有一些超时策略，空闲连接将被终止。某些设备的超时值短至 5 分钟。
因此，如果您使用 UDP 泛洪您的网络连接，则同时的 TCP 连接可能无法获取单个数据包，从而导致路由器终止连接。
虽然 TCP 试图表现良好并防止网络链接泛滥，但 UDP 根本不在乎。因此，如果您可以控制 UDP 流量的行为（在应用程序或我的网络质量控制工具中），那将对您的 TCP 流量有很大帮助。
我在我的案例中看到过（C Linux，非阻塞套接字中的内核 3.2），当在 recv 函数中接收到零字节并且当我在 send -> errno = 对等方重置连接时出现错误时，套接字会自动关闭。我认为还有其他情况（当程序在 recv 和 send 函数中接收到某种特定类型的错误时）。我希望这对你有用。