S.l.e!ep.¢%

像打了激速一样,以四倍的速度运转,开心的工作
简单、开放、平等的公司文化;尊重个性、自由与个人价值;
posts - 1098, comments - 335, trackbacks - 0, articles - 1
  C++博客 :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

关于TCP丢包,断开的疑问

Posted on 2009-08-09 15:24 S.l.e!ep.¢% 阅读(4911) 评论(3)  编辑 收藏 引用 所属分类: IOCP
丢包:以前在局域网内做过这样的试验, A机向B机不断地发 4096Byte的TCP包, 每个包都有序号, 结果有部份包B机收不到
断开:直接拔网线(存在假连接),可能要十几分钟后才检测到

从TCP的机制来看,
TCP的下层会丢包,但经过TCP处理后,提交到应用层的包是正确无误的包
如果包无应答,会重发,理论上不可能出现丢包。

至于上面的丢包实验,那时没细究原因,有可能是没有检测 Send 成功(程序处理不过来的原故),但是否存在那种被路由器过滤掉而造成丢包,或其它原因造成TCP丢包的可能性?有待进一步验证&找资料

而断开,只能通过心跳包来解决了。

Feedback

# re: 关于TCP丢包,断开的疑问  回复  更多评论   

2009-08-10 12:07 by abettor
TCP提供可靠的连接的意义是指他尽力的提供可靠的连接,但并不到等于永远不会失败。
对于丢包重发,TCP是有限度的,而不是不断的重发,重发了X次后仍无响应,TCP就认为中断了。
对于拔网线这种极端的测试方式,OS一般会在某次调用send/recv/select的时候直接通知应用层,而不是继续愚钝的试图继续保障连接。

# re: 关于TCP丢包,断开的疑问  回复  更多评论   

2009-08-10 16:55 by foxriver
楼上说的不错啊。拔网线在用轮训select时很容易就能检测出来。

还有关于丢包,send不是任何时候都可以全部发送成功的,如果window buffer填满了,send会只发送一部分,还有在send前,最好先select一下是否可以write的标志,这样更安全些。

# re: 关于TCP丢包,断开的疑问  回复  更多评论   

2009-08-10 17:17 by abettor
@foxriver
严重同意。
需要补充的一点是,有时候send调用貌似完全成功,也不代表真的成功了,此时数据包只是提交给了OS的协议栈而已。很多时候,虽然socket明显已经断了,app执行send调用却并不知道,而是在调recv的时候才发觉。
select一下还是保险一些(虽然即使这样也并非万无一失)。

只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理