TCP拥塞

1. TCP拥塞的原因？什么情况会造成TCP拥塞发生？

当网络传输过程中资源不够用时发生，比如带宽的限制，交换节点的缓存和处理机等，都是网络的资源。

2. 慢启动和拥塞避免

慢启动

发送方维护一个拥塞窗口的状态变量，拥塞窗口的大小根据网络状况动态变化大小。拥塞窗口以字节为单位。

TCP传输首先经历慢启动，慢启动是一个乘法级的增长，A给B传输一个包，B收到，返回2，A收到2，给B传输2个包（2和3），B收到2和3，返回4，A继续给B发送4个包（4，5，6，7）。每一次B只要正确收到所有的包，就会返回下一个包的序号，这个序号也是即将要发送的个数。

image.png

拥塞避免

当数据传输中丢包时，慢启动达到峰值sstresh,会触发拥塞避免。比如A给B传输8，9，10，11，12，13，14，15，B没有收到12，但是收到了13，14，15，那么会触发3次12 的响应，这三次是13，14，15这三个包触发的。实际传输过程中，这些包是以字节的形式传输的。慢启动结束的判断条件就是收到3次重复确认。这时慢启动结束，并且开始快速重传，进入快速恢复阶段。拥塞避免变为加法级别的传输，每次拥塞窗口加1，线性增长。

image.png

上图中显示早期的TCP版本遇到三个重复应答时执行的是从头慢开始，后来改为了快恢复，我认为是随着互联网的发展，带宽不再是很大的问题，所以之前的措施过于保守，因此废弃掉了。

可以根据下图比较彻底丢包和收到3次重复确认时TCP的策略。

image.png

3. 快重传和快恢复

快重传：发送方一旦收到3个连续重复确认，立即重传。
快恢复：发送方认为只要能收到确认网络就没有阻塞，把慢启动峰值降为当前一半，并以此数值作为拥塞窗口的大小开始拥塞避免阶段。

image.png

4. 什么时候重新慢启动，什么情况拥塞避免？

发送方判断网络拥塞的条件是没有收到确认，有可能是其他原因导致确认丢失，但是发送方不做区分全当做拥塞处理。这时拥塞窗口的峰值减小为之前的一半，然后重新开始慢启动阶段。

发送方收到3个相同确认信息，认为网络没有阻塞，开始快速重传和快速恢复。

5. 拥塞避免算法只有TCP拥塞时会触发么？

路由器的丢弃策略 && 全局同步

路由器按照先进先出的规律处理到达的数据包分组。当路由器缓存不下新到来的数据包就会丢掉尾部的分组。这就是尾部丢弃策略。

尾部丢弃策略导致分组丢失，网络中有大量的TCP链接，尾部丢弃策略会影响到许多TCP链接，所有TCP链接一同进入慢启动阶段，会使网络通信量突然下降，这就是全局同步。

路由器随机早期检测（randomEarly detection）

这是为了避免全局同步发生路由器执行的算法。

RED算法的核心就是，计算路由器中队列的平均长度，和新到来的分组大小作对比，将分组加到队列尾部，或者按照某一概率将分组丢弃。这样做的结果也会导致一些TCP重新慢启动，但至少不是全部挂掉。

具体细节：

使路由器的队列维持两个参数，即队列长队最小门限min和最大门限max，每当一个分组到达的时候，RED就计算平均队列长度。然后分情况对待到来的分组：

①平均队列长度小于最小门限——把新到达的分组放入队列排队。

②平均队列长度在最小门限与最大门限之间——则按照某一概率将分组丢弃。

③平均队列长度大于最大门限——丢弃新到达的分组。