为什么tcp不采用停等协议_TCP协议有了拥塞控制机制，为什么还会网络拥塞？

这个问题好像在问：有了警察，为何还有小偷？

网络发生拥塞时，毫无疑问是进水管的流量流入速度大于出水管的流量流出的速度。

在小学数学里经常会做这样的算术题：一个蓄水池，一个进水管，4个小时可以放满水。一个出水管，6个小时可以排完水。现在入水管与排水管同时打开，需要几个小时才能放满水？

大家可以轻松地算出，需要12小时。

12小时之后，进水管与出水管依然同时打开，会发生什么？

肯定溢出啊！

溢出的流量会到达目的地吗？

当然不会了！

路由器（节点）如何避免流量白白流失？

从流量的源头下手，让流量的源头减少流量进入网络。

源头是谁？

正在发送流量的源主机。

什么消息通知源主机呢？

• 使用ICMP Type 4 “Quench”消息，让源主机熄火、减少流量的产生

可是，很多源主机往往忽视这个消息，装作没有看见，依旧我行我素。

这种方法往往会失效。所以，路由器往往不会使用这种“出力不讨好”的操作。

• 在返程的流量的IP报文里设置（ECN =1）

朝着源主机流动的流量里，明确告知源主机“网络发生拥堵，请降速”。

但是，不是所有主机都认识“ECN”(Explicit Congestion Notification)，自然无法知道网络其实已经拥堵了。

这种方法同样也会大概率失效。。。

• 路由器无为而治

路由器只是把溢出的流量丢弃处理，其它的什么都不做。

路由器这种消极的态度真的好吗？

路由器双手一摊，很无奈地说，我发的通知消息它们要么不认识，要么认识却忽视，让寡人有什么好的办法？

丢！

源主机的TCP对“丢包”非常敏感，所有源主机TCP能听懂的语言，就是“丢包”！

发现丢包了，源主机TCP会将流量降速差不多一半。

源主机这种“对丢包信号做出流量降速的行为”就是流量拥塞控制。

大家发现没有，是先发生的“路由器（节点）流量溢出（丢包）”，然后才触发了“源主机的流量拥塞控制”。

源主机的流量拥塞控制（Congestion Control）机制，永远都无法避免路由节点的网络拥塞，从而造成的流量溢出（丢包）！

读者可能还听说，流量拥塞避免（Congestion Avoidance）机制，对吗？

拥塞避免

路由器（节点）发现消极被动的“无为而治”似乎效果不好。于是乎，决定采取积极主动的手段来管理流量。

路由节点通常是这么做的：

• 路由节点的蓄水池有两个吃水线，低吃水线、高吃水线。
• 低吃水线通常为蓄水池高度的60%，高吃水线通常为蓄水池高度的90%。
• 蓄水池里的流量低于低吃水线，流量自由通过。
• 蓄水池里的流量高于低吃水线，低于高吃水线，路由节点开始随机丢弃一部分流量，低优先级丢弃概率大，高优先级概率小。
• 蓄水池里的流量高于高吃水线，高出的部分被统统丢弃，不管流量有多么高深的背景。

路由节点“未雨绸缪”的流量管理方式，以主动牺牲小部分流量为代价，将“路由节点即将发生拥塞”的信号传递给所有的源主机，让源主机提前降速，可以避免更多的后续流量溢出而牺牲！

这个拥塞避免机制的名字叫“WRED”(Weighted Random Early Discard)!

更多内容，请继续阅读：

TCP协议有了拥塞控制机制，为什么还会网络拥塞？​mp.weixin.qq.com