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

Question

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

问题来了，请问TCP会不会自动关闭套接字

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

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

任何帮助将不胜感激!!

Answer 1

我从未听说过 TCP 套接字会自动关闭，所以我怀疑是不是这种情况。如果发送方无法发送任何数据，它将等待并重试。套接字关闭的唯一原因是，如果发送方多次尝试发送数据但无法发送，然后显式 关闭套接字。如果发送方有足够的带宽发送数据但接收方没有接收数据的带宽，协议(protocol)本身将重新发送数据并确保数据正确到达(参见 Wikipedia )。

至于 #2，同样来自维基百科(如 ott 所述):

When a receiver advertises a window size of 0, the sender stops sending data and starts the persist timer. The persist timer is used to protect TCP from a deadlock situation that could arise if a subsequent window size update from the receiver is lost, and the sender cannot send more data until receiving a new window size update from the receiver. When the persist timer expires, the TCP sender attempts recovery by sending a small packet so that the receiver responds by sending another acknowledgement containing the new window size.

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