骨干网络演化释义以及TCP BBR的部署环境问题
作者：互联网
昨天本应该去公司加班的，但我由于不在本地而没去享受这奢华的周末盛宴。不过我要一路上远程值守，有问题要上，这是必须的。无聊的时候，没有问题制造问题也要上？这是贱。所以，在没有问题的时候，我写下一些简单的随笔，苦苦等待深夜的降临，照例每周要写点什么，但我今晚写的东西可能只与心情有关，而与技术无关！
也许吧，我就是那种在别人眼里从来不加班，从来不合群的“坏员工”或者傻逼，但是又有谁能明白，我花了多少夜晚以及周末节假日去默默加班...我多少有点感到不妥，但我是一个加班狂，其实我是为了保护大家。了解我的人自然了解我，不了解我的人自然会误会我，学学我寻找快乐，何必如此辛苦活着...
本文中不会过多渲染任何关于“网络技术”的术语，这里的术语说的是比较专业的那种技术术语，并不是什么TCP，IP，Socket之类的，而是那种比如IS-IS，Cisco 4507，Full-Mesh，IBGP，EBGP，双归技术等，因为这些术语总会让大家觉得我有点不入流(感谢宋老湿，先教会了我这些东西，然后我才有勇气去学习Java和C之类的)...所以说，像往常一样，我还是用通俗的方式去阐述这些东西。程序员眼里的网络往往都是这个样子的：
这对于理解TCP/IP协议原理是够了，但是却无法让你理解诸如路由协议，传输系统等。想要了解这些系统，以上的拓扑是不够的。
然而，不可否认，如今超大规模的分组交换网络就是从以上最后一个拓扑发展而来的！一直持续发展到现在，整个互联网发展成了今天的模样，如今化身成了经济，政治，思潮，时尚，其原始的自由开放的技术基因反而不再被人重视。
互联网的运作细节远远不是一个程序员盯着TCP发送端的行为就能理解的，而且现在也很难找到一个配置路由器的管理员下班回家后坐在电脑前Hack协议栈的了。所以，二者要结合！
我一直游离于二者之间。我是程序员，但是我非常看不惯TCP，反而钟情于IP，我的第一份工作是网管，随后在过去的三年中无数次解决诸如HSRP，OSPF，IS-IS等问题。事实的情况是，我作为程序员，不是最好的，甚至我总是自黑自己不懂编程，让我去干网管干运维，也是半瓶子，然而我混合了二者，这虽然算不上什么跨界，但也是一种优势。
我站在程序员立场对抗过网管和运维，嘲笑他们不懂协议原理只会操作，我也站在网管的立场对抗过程序员，鄙视他们不懂网络原理只会写代码，我甚至站在程序员和网管，运维统一的立场上蔑视过经理，嘲笑经理只会穿着西装和温州假皮鞋写PPT，还臆想过经理西装和温州皮鞋扛着一台2U的机器在机房上架的宏大场面。
其实，后来我仔细再想一下，上面我说的那些并不是我作为弱者有意为之。如果你是程序员，你真的懂网络吗？如果你作为网管或运维，你真的理解协议原理细节吗？如果你是经理，...我不在乎我得罪多少人，反正我也得罪的很多了，这都无所谓。我只是表达自由的想法，在表达的过程中，多少有点怒其不幸，而哀其不争。
其实我真正鄙视的是程序员只关注本机而完全忽视网络的运作，这完全是一种鸵鸟策略！无论我采用多么激动的方式告诉他们要对网络保持敬畏，他们都是不屑一顾，我说网络就是一个自组织反馈的混沌系统，像是一个生命体一样，他们却把网络单纯的理解成TCP，我说，命运啊，TCP就是Shit of Beast！
这可能是价值观不匹配的原因吧而无关对与错，我关注的是路，而他们关注的是车，路可以把车引入歧途，然而世界上本没有路，走的人多了，才成了路。世界上本没有鬼，死的人多了，才有了鬼！如果写一篇关于IBGP，双归CORE之类的文章，可能会有点装逼，也不符合我程序员的身份，所以我不会写那些，我还是用程序员的视角来描述什么是真正的网络吧。
学院派？这是什么玩意儿！一群抑扬顿挫的人罢了！
-----------------------------------
真实的网络，起码也得是这样子的：
我说”起码“的意思是，上图是把真实的网络拓扑过度简化了。我要说我曾经在会议室用几十台机器摞成上面的拓扑你信吗？所以说，真实的网络怎么说也要比我能搭建起来的更复杂！我当时霸占了一间会议室，从此这个会议室就成了我的办公室和实验机房，十分怀念那一两年的美好时光。性情中人，又怎能不念！
我暂且把上面的网络看成是中国电信的Chinanet网络吧，这么做完全是因为本文可能会牵扯到Google，所以说必然要有一些所谓实名在里面，然而也仅仅是借用一下实名而已，请不要将这些拓扑与任何真实的网络对号入座。
既然中国电信可以建造Chinanet骨干网(事实上是上世纪邮电部建造的)，理论上任何一家运营商或者财大气粗的企业都可以建设骨干网了。事实上也是这样子的。比如中国联通也建了一张网，所以这两张网看起来会是下面的样子：
我们看到，黑色和红色线连接的两张网，并且它们之间还有跨运营商的互联。可以看出，跨运营商的互联程度绝对没有运营商内部的互联程度更高，因为这涉及到各种利益，不属于技术层面，本文不谈。之所以要跨运营商互联，完全是站在ISP服务质量以及有关政策(比如国家政策，AS规定等)方面考虑的。如果一个资源在电信网中，要是没有跨运营商互联，联通网的用户岂不是访问不到了吗？
-----------------------------------
现在，我们已经知道，实际的世界级互联网络是由”各种小骨干网“组成的，整个互联网络的访问模型如下图所示：
看似简单的两个选择，带来的问题则更多！我们看下面的图：
既然每一个骨干网都是自己自主搭建的，由于”某种原因“才要跟外界互联，因此绝不能假设世界上任何网络都采用同一套标准，事实上都是各行其是，以路由协议为例，每个网络都可以使用不同的路由协议。为了解决各个自行其是的”小骨干网“合并成整个世界网络的问题，BGP协议被设计了出来。所有的”小骨干网“被分成了一个个的自治域，即AS，每一个AS类似世界网络中一个”国家“，简单的说，BGP协议就是这些互联网国际中所有国家间的外交协议。BGP协议作为外交协议，试图解决：
1.A的流量能不能到B来，B的流量能不能到A去。
2.A到C的跨境流量能不能经过B。
3.A是否接受B的建议以更新自己的策略。
...
简单来说，针对上图中的几个问题，我给出下面的图试图作答：
这个答案也许太过简单，但是足以说明问题了。可以说这么说，如果说AS内部的寻址规则是基于简单的最短路径算法的寻址规则的话，那么BGP就是一种更加策略化的寻址规则，因为AS内部的节点在AS内是可信的，而AS外部则不然，所以说必须要加以更加严格的约束。
-----------------------------------
现在，运营商之间如何通过外交协议BGP构建世界网络的问题解决了。但是在网络世界，AS和自然国家并不是一个一一对应的关系，任何组织，理论上都可以申请一个AS号以及一批IP地址，从而构建自己的”小骨干网“，并且平等接入到世界级网络成为网络世界的一员。
很显然，那些提供海量数据服务的互联网厂商，建造自己骨干网的欲望最为强烈。不管是Google，还是国内的BAT，都有自己的骨干网。与一个大型企业构建自己的骨干网相对的是下图的方式：
即接入到已有运营商的网络。这会给自己带来很大的负担，不仅仅是钱的负担，还有更重要的，即流量满足不了公司发展所需的负担。所以说，财大气粗且有实力再存在10年+的企业都迫不及待地构建了自己骨干网，即世界级网络中的”小骨干网“。它们都有自己的AS号，可能甚至还不止一个！
加入企业骨干网的世界级网络如下：
现在的问题来了。难道这些企业都要挖坑布线建机房吗？现在，这种底层基础设施往往都是不需要自己搞的，当年中国电信，联通挖坑布线的时候，埋了很多的光缆，
这些设施属于国家层面的服务，会以运营商的名义出售给需要的企业的。至于说机房，如果你觉得运营商的机房不够，拿到地块后可以想怎么建就怎么建。如果你的企业大到可以雇人挖设坑道并得到国家同意的地步，事实上自己布线也完全可以。
-----------------------------------
关于骨干网的那些事基本也就这些，我来总结一下这个世界级的网络是怎样一步步嵌套而成的：
这里面比较复杂的是接入网。事实上接入网往往是作为一个适配层存在的，由于时间精力以及个人能力有限，本文不谈接入网。对于骨干网，MPLS也是非常重要的，这个可以参见我在2012-2015年关于VPN的文章，如今有点厌倦了。
-----------------------------------
-----------------------------------
Google网络面临的BufferBloat问题以及解决
我说的是Google的网络。当然也适用于任何使用IGP(一般都是OSPF，IS-IS)进行寻路协议的网络，造成BufferBloat的原因在于，这些网络在IGP收敛之后最终都会把一张网剪枝成一棵树。我们知道树型拓扑有什么特征，那就是主干流量巨大，越接近于根，流量越大，流量在整棵树中非常不均衡，然而这与互联网对等节点的初衷是相违背的：
可见，站在节点A的视角，其它节点都是渐行渐远，按照单源最短路径算法的结果，流量必然在其本身汇聚。这是造成带宽利用率低的根源，因此就出现了诸如流量工程(TE-Traffic Engineering)等均衡措施，其目的在于”提高网络带宽的利用率“，但是传统TE是分布式TE，此类的工程化措施仅仅是补救措施。
上面的树型拓扑是一个事实上的全局逻辑拓扑，然而得到这个拓扑的过程是在各个节点分别进行的，每一个节点都是以自己为树根的，所以说，站在B节点或者C节点的视角，其拓扑分别为下面的样子：
这是由”最短路径算法“所决定的！不管是距离向量算法还是链路状态算法，其结果都是一致的。因此，我们可以说，之所以去往同一目的的流量在最后一跳会收敛到同一路径，这是缺乏全局观的体现。那么传统分布式TE只能是一个补充的措施，并不能从根本上解决问题。如果每一个节点公平对待每一处分支，而不仅仅是将自己作为根主干，才可以让流量变得在网络中均衡，避免单一路径的BufferBloat！
我用一个例子来说明一下：
怎么解决这个问题？这也是Google B4网络曾经面临的问题。解决之道就是部署SDN，采用一种集中化的TE方案，从全局视角来均衡流量！
关于SDN的理论和细节，可以自行搜索，我在2013年到2014年期间也写过几篇关于SDN的文章，本文不会介绍SDN的细节，但值得指出，SDN站在一个全局的控制视角，将网络转发节点的控制平面抽离出来，形成了统一的全局控制平面，这样网络转发节点就只剩下了数据平面，承担数据转发任务。
部署了SDN后，上面例子会变成下述情形：
Google的B4骨干就是一个部署了SDN的网络，这是在今年部署TCP BBR算法之前的一个大动作，从SDN的效果上看，事实上SDN化的B4为BBR算法的测试结果加了不少分。如果这一点理解不了，那么国内所有关于BBR的测试都是极其盲目的测试！
我现在简短说几句关于BBR和Google B4网络的结合性问题。
-----------------------------------
BBR旨在减少填充队列缓存，然而在基于IGP的传统网络中，这种奢望终将是一厢情愿，因为即便BBR流不填充缓存，也无法阻止Loss-Based的流填充缓存，最终的结果是BBR只能被迫排队！和BBR最初的初衷多少有点违背的是，它采取了ProbeBW来试图去抢一些带宽回来，然而如果Loss-Based流已经将缓存填充到了一个比较均衡的程度，那么BBR抢来的并不是带宽容量，而是缓存！所以说，Loss-Based流传染了BBR流。这又是一个劣币驱良币的典型例子！
比如，在基于IGP的网络上，去往同一网络的流量几乎会收敛到同一条路径(千万不要指望什么分布式TE)，共享同一个出口队列，CUBIC总是会占用队列，多个CUBIC流几乎不可能让出一个空闲的队列缓存出来的，因此结果就是，即便是BBR，也要被迫排队，只是它们和平共处在一个均衡的状态。
然而，B4网络上部署BBR算法完全没有这个问题！
首先，B4网络在BBR之前已经部署了SDN，”去往同一网络的流量几乎会收敛到同一条路径(千万不要指望什么分布式TE)，共享同一个出口队列“这个问题解决了，次优路径以及次次优路径也会被充分利用。其次，即便是BBR流占据了队列缓存，其ProbeRTT状态也会使其自主清空缓存的。为了防止劣币驱良币，Google B4几乎全量部署了BBR算法。
没有SDN这个背景，单纯的去迷信什么一个TCP算法就能预测并解决拥塞，都是扯淡！在Google B4网络上，BBR流承载的几乎都是数据中心之间的同步流量，所以说，这完全是SDN搭台，BBR唱戏的局面！而我，对这出戏是全程表示极其厌恶的！
-----------------------------------
一般情况下，作为非运营性质的企业骨干网，类似Google，百度，腾讯，阿里这种公司自行建设的骨干网，其实是在内部想怎么玩就怎么玩的，这也是为什么B4网络部署了SDN，而中国电信没有部署SDN的原因。
其实，不光是Google B4网络部署了SDN，国内熟知的BAT其实也不同程度的部署了SDN，你知道这是为什么吗？
BAT几乎不约而同地在做同一件事，就是建设以及优化自己的骨干网。相对运营商网络，BAT的网络流量更为单一，它们均无需(没有必要，也没有权力...)对外提供接入服务，在这种类型的骨干网上，带宽几乎被数据中心间的调度流量完全占据。“不让链路空闲”显得尤其重要，因此次优路径要作为负载均衡模式存在，而不是备份模式存在。流量类型的单一以及业务的固定，使得BAT可以像Google一样在自己的骨干网上部署SDN。
现在，我们来看一下BAT之流的骨干网是如何与其它的骨干网互联互通的。
非常简单，使用BGP协议！只要有钱，自己建设机房即可，然后把这些机房连接起来，申请一个AS号以及一批IP地址，就是自己的骨干网了，然后根据规定与其它骨干网用BGP互联，如果有必要，可以私用防火墙，至于说布线，可以租用别人早就已经铺设好的DWDM即可(运营商提供这种租用服务)。说实话，这种大型互联网企业建设的骨干网很大意义上其实是为了支撑自己的CDN系统，只需要内置一个调度系统，它们就可以随时随地提供优质服务。
按照传统思路，深圳的一家互联网公司A在提供服务，北京的用户U只有千里迢迢访问深圳公司A的机房里的服务器才可以获得服务，然而公司A自己建设了骨干网，在北京设立了骨干节点，效果怎么样呢？不用说，北京的用户直接接入公司A的骨干网在背景的节点即可！公司A的骨干网所要做的，仅仅是在必要的时候把资源调度到北京的节点即可！所以说，一个用户典型的访问模式应该是下面的样子：
我们把企业骨干网放大来看：
是不是类似京东的仓储物流系统呢？企业骨干网相比运营商骨干网，结构更加单一，流量更加固定，比如说它没有复杂的接入系统，适配系统以及管理计费系统，只需要处理好与运营商网络的对接即可。这是一个典型的CDN拓扑，实现了就近提供服务，一方面提高了企业提供的服务体验，另一方面通过一次性投资建网大大减少了持续经营所必须支付给运营商的费用。
由于可以就近提供服务，企业便不用支付大笔的过境流量费用，只需负担用户至企业骨干接入点的费用即可，在企业骨干网内部，使用的运营商服务也仅限于DWDM传输系统以及部分机房的租用资金，这对于大型企业来讲，绝对划算。
-----------------------------------
又到了结束的时间，其实还有无尽的感慨，但我现在最想做的事情就是去睡一觉，然后再起来喝一杯，然而这是奢望，通宵过后并没有机会睡觉，而是要赶路，要当活导航。所以我会继续审视以下这么一个令人遗憾的话题，先看一个tcptrace图：
你觉得在T1和T2之间多发点数据包会带来性能提升吗？我觉得：
结论如下：
1.T1到T2之间的重传可能是由于队列被塞满丢包引发的也可能是周期性共振噪声丢包，在T2时刻恢复，ACK线和发送线斜率未变，性能根本没有由于丢包重传而下降！
2.如果在T1和T2期间多发包，会继续Bloat队列或者加强周期性共振噪声造成更多的丢包！
3.基于1和2，多发包实则在赌博，并且，如果赌赢了，与之前的性能持平，没有额外收益，如果赌输了，将会产生新的丢包重传从而占据有效带宽。
以Linux实现的TCP为例，在T1和T2期间，PRR算法已经将窗口恰到好处的有所降低，保证即时是噪声丢包也不会造成性能损失(这是因为突发会积累)，这个时候已经处在异常阶段了，就不要再加塞了。明显的事实，却需要历史来评说！
-----------------------------------
发挥导航优势。到家后睡觉去咯！
再分享一下我老师大神的人工智能教程吧。零基础！通俗易懂！风趣幽默！还带黄段子！希望你也加入到我们人工智能的队伍中来！https://blog.csdn.net/jiangjunshow
标签：Google,骨干网,网络,TCP,流量,释义,SDN,BBR 来源： https://www.cnblogs.com/ksiwnhiwhs/p/10389318.html