本文主要是介绍谈谈网络拥塞的根源，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
前天发了一则朋友圈：
拥塞的本质原因在于信息差的消除，景点排队，买票排队，餐馆排队，高速公路排队，正是因为更多的人知道了容量有限的服务，动辄百万千万并发的线上系统控制几十上百容量的线下系统，不堵才怪。
延吉，哈尔滨一个菜市场，以前除了本地附近的人正常买菜，没人知道，它的运作很正常，媒体报道消除信息差后全国都知道了，菜市场瞬间沦陷，同理，导航造成了高速拥堵，12306造成了买票难，抖音小红书造成了景点拥堵，迪杰斯特拉算法造成了互联网拥塞，当然，如果拥塞的服务是一个依赖流量的网红，这就意味着源源不断的入账。
互联网之前，布雷斯悖论早就说明了这个问题，开一条新路，你别让所有人都知道，拥塞问题就会缓解，所有人都知道了，反而会更拥塞。
统计复用系统的风险就是你要为拥塞和资源闲置双向买单，并且整体看来某处越拥塞就意味着某处越闲置，所以成本是指数上升的。
我为什么总能避开拥堵，因为我知道越拥塞就越闲置这个道理，全局最优解是有聚合效应的，大家只选第一而鄙视第二，鉴于还有小一半人不在乎被鄙视，选第三就避开拥塞了，综合效用肯定最佳，很简单的道理，只是大多数并不明白。
如今数据中心网络，cdn 网络都卷成什么逼样了，我作为退出这行当的人还得忠告几句，别天天盯着你那一亩三分地瞎卷，你们连整个情况都整不明白就天天自研一上线就挂的所谓算法，能有用吗，如果只为还贷和虚荣，当我没说就是了。
火车站出站，一群人乌央乌央堵在那最近的几个闸机处，旁边闸机空无一人，我老婆发现了去试试，一刷身份证就出去了，这不就是个例子么。教育只教你怎么卷，没教你怎么避开卷。
卷，意思就是拥塞。
有必要再引申一下。主要谈三个点对拥塞的作用以及它们之间相互的作用，一个是网络中达成共识的速度，一个是枢纽节点，一个是选路。
拥塞的根源在于一个非常快的系统在相对数量级差异的时间内让一个相对慢的网络系统达成了共识。
再以哈尔滨旅游为例，媒体是一个很快的信息推送系统，全国人几乎可以同时收到媒体的渲染信息，而飞机，高铁也是相对快速的系统，数万数十万人在小时级时差内几乎一起到达，也就人满为患了。
如果用一个极端的慢速系统做同样的渲染推送，比如媒体派人从一个地方出发步行向全国各地进发，渲染旅游信息，大家也是步行前往哈尔滨旅行，大家到达以及游玩的时间就会被距离散列开，就不会拥堵了。
这就是为什么越到了信息化时代，飞机，高铁等快速交通工具越发达，拥堵的地方越多的原因，曾经的书信，步行，自行车时代，反而哪里都不堵，而人口相比此前并没有量级的增量。
我曾经建议数据中心把光纤剪成参差不齐的长度，大概就能缓解 incast，就是这个道理，让数据到达交换机的时间被距离散列开，但这一招在广域网就不好使，因为几米的距离相对信号传输速率而言，太短了。
再来看一下枢纽对于拥塞的影响。
曾经的超级巨无霸，郑州铁路局在 2010 年代被拆分，武汉铁路局，西安铁路局脱离郑州局而独立，这事在河南看来多少有失颜面，但事后看，这次拆分正是为接下来的高铁时代做铺垫，高铁时代的超级枢纽反而影响效率。
坐过普速火车的都知道，四位数字的绿皮慢车，K 开头的快车，T 开头的特快，Z 开头的直快，全部跑在同一个路网上，慢车经常停在荒山野岭的调度站给快车让道，一停就是好久，跨局火车局间交接还要换火车头，武汉开往哈尔滨的火车开始由 “郑局武段” 车头牵引，进了哈尔滨局的地界就换成了 “哈局三(三棵树站)段” 的车头。
最开始的动车组也跑在这种普速铁路，但它不用换车头，车头是个普通车厢，还坐着人呢，没法换，其它车给动车组让车，让其它车更慢，所以动车组根本跑不起来。
所以所谓的高铁真的在说火车吗？说的是路啊。
高铁时代重建了新的路网，连火车站都是新建的，各种 “xx 东，xx 南，xx 西，xx 北” 都是新建的高铁站。曾经郑州，武汉，西安都在争到底哪里才是枢纽，结果高铁时代它们都不是枢纽，高铁路网的趋势是点对点拓扑，这才能最大化通行效率，但凡有大型枢纽，就必然要引入复杂的调度算法，想高效就要直达。所谓高铁，更大意义上是高速铁路网。
航空运输网也类似。飞机性能的提升让远距离点对点运输成了可能，于是就取消了波音 747 和 A380 这种枢纽到枢纽飞机的必要性，和铁路枢纽需要复杂算法类似，这种大飞机对机场要求极高，还影响其它小飞机起降，其实综合效率并不高。
核心就是，对效率而言，能点对点就点对点，full mesh 最优，所有枢纽节点的引入都来自于节省，而不是效率。
最后看看选路。
不管是 tcp/ip 互联网还是公路网，最为统计复用系统，在选路方面，看上去遵循 “选择最短路径” 就是最优，其实不然。以往没有导航的时代，司机用一种看地图凭记忆的方式选路，肉眼根本量不出几条路之间的细微差别：
这就是越导航越堵的原因。因为导航让大家产生了最短路径的共识。布雷斯悖论的根源也在这种共识，如果有一半人不知道新修了一条更短的路，整个网络的综合效率就会高很多。
这也是我一直反对严格最短路径优先的原因，反而松散的 ecmp 更有效率，系统应该在所有可达的路径上分发流量，路径度量顶多作为一个不那么重要的权重。最短路径优先算法就是一个精确的钟摆，当网络共识把大家引导到同一条路径时，这条路径就成了最劣路径。最短路径优先算法让网络工作在 active-standby 模式，而不是 active-active 负载均衡模式。那么多路径简直就是在最短路径上的路由器坏了重收敛时用的。
这就引入了允不允许乱序的问题，应该是 tcp 给网络惯的毛病，要向大自然学习，婚礼车队都不是完全不能乱序。
综合一下本文的三个点之间的互相影响，最短路径优先算法让网络在极短的时间内产生了共识，而该共识把流量引入所谓枢纽节点，于是在枢纽节点产生拥塞。
让共识达成的慢一点，或干脆不要有共识，就解除了拥塞的根源。
但随着最短路径优先的互联网感染了社会生活的几乎每个方面，它的病也感染了生活的每个方面，无论是旅游还是导航，可以说互联网是现实生活中各种拥塞的主因，主因的背后还是最短路径优先算法。
你家门口就能买到好吃的猪头肉，若不是你在网络上查到距离你 10 公里开外的一家老字号名店，你也不会去买，信息是共享的，共识让所有人都知道了这家店，于是店家过载，开始排队，即使开分店，也还是在分店间排序评分，最高分那家还是会排队。
哈尔滨热度也一样，如果你也相信 “最短路径优先” 不靠谱，相信退而求其次，去趟长春你会发现同样好玩，就算在长春，也没必要非要去冰雪新天地和净月潭，冰雪项目，南湖公园就够了，接地气。
浙江温州皮鞋湿，下雨进水 不会胖。
这篇关于谈谈网络拥塞的根源的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
