在这些情况下TCP会自动关闭套接字吗？
在这些情况下TCP会自动关闭套接字吗？
提问于 2013-01-21 13:19:41
我们正在使用C/S在linux上开发一个网络应用程序，最近我们发现，当大量UDP和TCP数据通过带宽传输时，一些打开和连接的套接字上的写/读可能会失败，看来套接字由于某种未知原因而关闭了。
下面是问题，请告诉我TCP是否会自动关闭套接字。
- 假设有一个发送方和一个接收方，发送方通过TCP非阻塞套接字向接收方发送大量数据。假设应用程序本身和其他应用程序在带宽上有大量的通信量。如果带宽被完全部署，发送方没有任何机会发送数据，那么TCP会在稍后的某个时候自动关闭套接字吗？如果是，时间价值是多少？
- 假设问题1中的带宽没有完全部署，并且发送方可以成功地将数据传递给接收方。但是，如果接收方没有读取数据，过了一段时间缓冲区就会填满，那么TCP会在几小时内自动关闭套接字吗？
任何帮助都将不胜感激！！
Stack Overflow用户
回答已采纳
发布于 2013-01-21 15:08:09
我从未听说过TCP套接字会自动关闭自己，因此我对此表示怀疑。如果发送方无法发送任何数据，则只需等待并再试一次。套接字关闭的唯一原因是，如果发送方多次尝试发送数据，不能，然后显式关闭套接字。如果发送方有足够的带宽发送数据，但接收方缺乏接收数据的带宽，则协议本身将重新发送数据并确保数据正确到达(请参阅维基百科)。
至于#2，也来自维基百科(正如ott提到的)：
当接收方广告窗口大小为0时，发送方停止发送数据并启动持久化计时器。持久化定时器用于防止TCP在接收方丢失后续窗口大小更新时可能出现的死锁情况，并且在从接收方接收到新的窗口大小更新之前，发送方无法发送更多数据。当持久化计时器过期时，TCP发送方通过发送一个小数据包来尝试恢复，以便接收方通过发送另一个包含新窗口大小的确认来响应。
因为TCP具有确定要发送多少数据的系统，所以我假设TCP连接总是可以接受一个更新数据包。在缓冲区仍然满的情况下，接收器将继续广播窗口大小为0的节目。除非一段软件在X重复"0窗口大小“之后显式关闭一个套接字，否则没有理由关闭该套接字。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/14439567
复制相关文章
相似问题
腾讯云开发者
