TCP协议有了拥塞控制机制，为什么还会网络拥塞？

Posted 2021-04-15 车小胖谈网络

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

 

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

 

在小学数学里经常会做这样的算术题：一个蓄水池，一个进水管，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)!

 

WRED看起来很完美，但是真的很完美吗？

 

源主机通常会有两种流量：

 

• TCP流量

• UDP流量

 

TCP对丢包信号非常敏感，路由节点丢一个包，会引起TCP的连锁反应，流量降速立竿见影。

 

UDP对丢包及其不敏感，路由节点丢多少包，UDP该发多少，依然还会发多少，大不了无法到达目的的而已，有啥大不了的。

 

很快，UDP就会占据TCP流量降速让出来的蓄水池空间。

 

TCP是绅士，UDP无疑就是地地道道无赖！

 

对付UDP这种无赖，最有效的方式就是限速，将蓄水池划出一块空间给UDP使用。

 

一旦拥塞时，UDP只能使用自己的专用的蓄水池空间，而不会挤占TCP降速让出来的空间！