分析TCP为什么判定三个冗余ACK后才执行快速重传【计算机网络】(1)

答案很简单:只有当TCP的接收方收到了序号大于它本身期待序号的分组时,才会发送冗余的ACK。

举个简单的栗子,假如分组A、B和C被先后发送到接收方,分组A顺利达到接收方,接收方发送了确认ACK,假定是ACK_A,并顺利地被发送方收到。而分组B很不幸,在中途丢了,没有到达接收方。分组C同A一样顺利到达了接收方,于是接收方看到了C分组的编号,发现缺少了B(因为A-B-C是按顺序的一组编号)的编号的分组,于是它只能再次发送ACK_A给发送方,以此提示发送方:自己此时并没有收到B分组。这是从发送方的角度看问题,同是也是“上帝视角”看问题。(所谓上帝视角,是因为我们已经知道了分组B是在中途丢失了)

于是继续这种情况,我们把视角切换到发送方,发送方这时候收到了第一个冗余的ACK_A,它觉得此时有两种可能性:第一种可能性是B分组丢失了(也即我们的上帝视角);然后还有第二种可能性,这种可能性就是,C分组可能先于B分组到达。这种情况听起来不大可能(因为按理来说B先发送,应当是B先到达),然而在分组传输过程中,其它层可能会改变分组的顺序,也即可能出现B和C的顺序被交换的可能性,于是第二种可能性也是成立的。
所以基于前面的论述,既然C分组可能先到达,那么传回来的冗余ACK就不一定是说明B丢失了,而是可能说明B的位置被切换了。于是TCP的设计者就设计了一个三次机制,也就是说当B被换到C分组后面的时候,第一个冗余ACK到达,先等一等看看B会不会刚好在C的后面

  • 5
    点赞
  • 19
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值