首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >问答首页 >带boost asio的TIME_WAIT

带boost asio的TIME_WAIT
EN

Stack Overflow用户
提问于 2016-01-26 02:55:08
回答 2查看 1.3K关注 0票数 0

我尝试了官方的tcp回送服务器示例服务器客户端。使用netstat -ano | findstr TIME_WAIT,我可以看到客户机每次都会导致一个TIME_WAIT,而服务器却不干净地连接。

无论怎样,是否都要防止TIME_WAIT或CLOSE_WAIT为双方彻底断开连接?

下面是捕获的数据包,似乎最后一次正确发送了ACK,但客户端仍然存在TIME_WAIT

EN

回答 2

Stack Overflow用户

回答已采纳

发布于 2016-01-26 05:34:03

  • CLOSE_WAIT是一个编程错误。本地应用程序已收到传入的关闭,但尚未关闭此端。
  • TIME_WAIT是在双方彻底断开连接之后出现的,它只持续几分钟。避免这种情况的方法是成为接受第一封信的结尾。通常,您希望在服务器上避免这种情况,因此首先关闭客户端。
票数 5
EN

Stack Overflow用户

发布于 2016-01-26 04:44:49

挥之不去的CLOSE_WAIT实际上是编程错误( OS执行连接关闭,但应用程序不记得及时释放套接字--或者根本不记得)。

然而,TIME_WAIT并不是一个特殊的条件。对于可能在正常连接关闭期间丢失了最后一个ACK段的连接,必须提供一个干净的关闭。没有它,FIN+ACK段的重新传输将通过连接重置来响应,一些敏感的应用程序可能不喜欢它。

在TIME_WAIT状态下拥有较少数量的套接字最常见的方法是通过调优全局OS级参数来在全局缩短其持续时间。IIRC,还有一种通过setsockopt()完全在单个套接字上禁用RST的方法(不过,我不记得有什么选择),但是您可能偶尔会向在连接关闭期间丢失数据包的对等端发送可能不需要的RST段。

至于为什么您只在连接的一侧看到它们,可能是在请求先关闭连接的一侧。是它发送第一个鳍,接收FIN+ACK,并发送最后一个ACK。如果最后一个ACK丢失了,它将再次接收FIN+ACK,并且应该重新发送ACK,而不是RST。但是,另一方肯定知道,当最后一个ACK到达时,连接已经完全结束,然后没有必要在该套接字上等待其他任何东西--如果有任何东西到达与刚刚关闭的套接字相同的address+TCP端口端点的主机,那么它应该是一个新的连接请求(在这种情况下,可能会打开一个新的连接),或者是一些TCP状态机违规(并且必须用RST响应,或者可能是一些ICMP禁止的消息)。

票数 2
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/35006324

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档