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

最新推荐文章于 2024-10-10 22:13:52 发布

程序员李菲

最新推荐文章于 2024-10-10 22:13:52 发布

阅读量330

点赞数 4

分类专栏： 2024年程序员学习文章标签： tcp/ip 计算机网络网络

本文链接：https://blog.csdn.net/m0_46608024/article/details/137468848

版权

2024年程序员学习专栏收录该内容

188 篇文章 3 订阅

订阅专栏

举个简单的栗子，假如分组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的后面，于是第一次的冗余没有引发立刻重传。然而B也有可能又被D分组（假设C后面有分组D和分组E）交换次序，因而再等一个D分组到达的冗余分组，再等一个E分组到达的冗余分组。当三个B后面的分组都到达了，这时候发送方收到了三个冗余的ACK之后，它终于认定不是因为被交换了次序，而是因为确实是丢了（第一种情况），于是它执行重传。
那么只剩下了最后一个问题，TCP的设计者为什么认定出现了三个冗余ACK，就一定不可能是发生三位的交换呢？（也即为什么这时候不可能是次序交换引起的呢？）我想，这大概是从众多试验中得出的结论吧，毕竟TCP已经有几十年的发展史了，可能在漫长的发展中，这个“三”就被得到了呢？（最后部分仅代表个人猜想，如有不同，可讨论）

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Python工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Python开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。