admin管理员组文章数量:1580449
昨天本应该去公司加班的,但我由于不在本地而没去享受这奢华的周末盛宴。不过我要一路上远程值守,有问题要上,这是必须的。无聊的时候,没有问题制造问题也要上?这是贱。所以,在没有问题的时候,我写下一些简单的随笔,苦苦等待深夜的降临,照例每周要写点什么,但我今晚写的东西可能只与心情有关,而与技术无关!
也许吧,我就是那种在别人眼里从来不加班,从来不合群的“坏员工”或者傻逼,但是又有谁能明白,我花了多少夜晚以及周末节假日去默默加班...我多少有点感到不妥,但我是一个加班狂,其实我是为了保护大家。了解我的人自然了解我,不了解我的人自然会误会我,学学我寻找快乐,何必如此辛苦活着...
程序员眼里的网络往往都是这个样子的:
然而,不可否认,如今超大规模的分组交换网络就是从以上最后一个拓扑发展而来的!一直持续发展到现在,整个互联网发展成了今天的模样,如今化身成了经济,政治,思潮,时尚,其原始的自由开放的技术基因反而不再被人重视。
互联网的运作细节远远不是一个程序员盯着TCP发送端的行为就能理解的,而且现在也很难找到一个配置路由器的管理员下班回家后坐在电脑前Hack协议栈的了。所以,二者要结合!
我一直游离于二者之间。我是程序员,但是我非常看不惯TCP,反而钟情于IP,我的第一份工作是网管,随后在过去的三年中无数次解决诸如HSRP,OSPF,IS-IS等问题。事实的情况是,我作为程序员,不是最好的,甚至我总是自黑自己不懂编程,让我去干网管干运维,也是半瓶子,然而我混合了二者,这虽然算不上什么跨界,但也是一种优势。
我站在程序员立场对抗过网管和运维,嘲笑他们不懂协议原理只会操作,我也站在网管的立场对抗过程序员,鄙视他们不懂网络原理只会写代码,我甚至站在程序员和网管,运维统一的立场上蔑视过经理,嘲笑经理只会穿着西装和温州假皮鞋写PPT,还臆想过经理西装和温州皮鞋扛着一台2U的机器在机房上架的宏大场面。
其实,后来我仔细再想一下,上面我说的那些并不是我作为弱者有意为之。如果你是程序员,你真的懂网络吗?如果你作为网管或运维,你真的理解协议原理细节吗?如果你是经理,...我不在乎我得罪多少人,反正我也得罪的很多了,这都无所谓。我只是表达自由的想法,在表达的过程中,多少有点怒其不幸,而哀其不争。
其实我真正鄙视的是程序员只关注本机而完全忽视网络的运作,这完全是一种鸵鸟策略!无论我采用多么激动的方式告诉他们要对网络保持敬畏,他们都是不屑一顾,我说网络就是一个自组织反馈的混沌系统,像是一个生命体一样,他们却把网络单纯的理解成TCP,我说,命运啊,TCP就是Shit of Beast!
这可能是价值观不匹配的原因吧而无关对与错, 我关注的是路,而他们关注的是车,路可以把车引入歧途,然而世界上本没有路,走的人多了,才成了路。 世界上本没有鬼,死的人多了,才有了鬼!如果写一篇关于IBGP,双归CORE之类的文章,可能会有点装逼,也不符合我程序员的身份,所以我不会写那些,我还是用程序员的视角来描述什么是真正的网络吧。
学院派?这是什么玩意儿!一群抑扬顿挫的人罢了!
-----------------------------------
真实的网络,起码也得是这样子的:
我说”起码“的意思是,上图是把真实的网络拓扑过度简化了。我要说我曾经在会议室用几十台机器摞成上面的拓扑你信吗?所以说,真实的网络怎么说也要比我能搭建起来的更复杂!我当时霸占了一间会议室,从此这个会议室就成了我的办公室和实验机房,十分怀念那一两年的美好时光。性情中人,又怎能不念!
我暂且把上面的网络看成是中国电信的Chinanet网络吧,这么做完全是因为本文可能会牵扯到Google,所以说必然要有一些所谓实名在里面,然而也仅仅是借用一下实名而已,请不要将这些拓扑与任何真实的网络对号入座。
既然中国电信可以建造Chinanet骨干网(事实上是上世纪邮电部建造的),理论上任何一家运营商或者财大气粗的企业都可以建设骨干网了。事实上也是这样子的。比如中国联通也建了一张网,所以这两张网看起来会是下面的样子:-----------------------------------
现在,我们已经知道,实际的世界级互联网络是由”各种小骨干网“组成的,整个互联网络的访问模型如下图所示:
1.A的流量能不能到B来,B的流量能不能到A去。
2.A到C的跨境流量能不能经过B。
3.A是否接受B的建议以更新自己的策略。
...
简单来说,针对上图中的几个问题,我给出下面的图试图作答:
-----------------------------------
现在,运营商之间如何通过外交协议BGP构建世界网络的问题解决了。但是在网络世界,AS和自然国家并不是一个一一对应的关系,任何组织,理论上都可以申请一个AS号以及一批IP地址,从而构建自己的”小骨干网“,并且平等接入到世界级网络成为网络世界的一员。
很显然,那些提供海量数据服务的互联网厂商,建造自己骨干网的欲望最为强烈。不管是Google,还是国内的BAT,都有自己的骨干网。与一个大型企业构建自己的骨干网相对的是下图的方式:
加入企业骨干网的世界级网络如下:
这些设施属于国家层面的服务,会以运营商的名义出售给需要的企业的。至于说机房,如果你觉得运营商的机房不够,拿到地块后可以想怎么建就怎么建。如果你的企业大到可以雇人挖设坑道并得到国家同意的地步,事实上自己布线也完全可以。
-----------------------------------
关于骨干网的那些事基本也就这些,我来总结一下这个世界级的网络是怎样一步步嵌套而成的:
-----------------------------------
-----------------------------------
Google网络面临的BufferBloat问题以及解决
我说的是Google的网络。当然也适用于任何使用IGP(一般都是OSPF,IS-IS)进行寻路协议的网络,造成BufferBloat的原因在于,这些网络在IGP收敛之后最终都会把一张网剪枝成一棵树。我们知道树型拓扑有什么特征,那就是主干流量巨大,越接近于根,流量越大,流量在整棵树中非常不均衡,然而这与互联网对等节点的初衷是相违背的:
上面的树型拓扑是一个事实上的全局逻辑拓扑,然而得到这个拓扑的过程是在各个节点分别进行的,每一个节点都是以自己为树根的,所以说,站在B节点或者C节点的视角,其拓扑分别为下面的样子:
我用一个例子来说明一下:
关于SDN的理论和细节,可以自行搜索,我在2013年到2014年期间也写过几篇关于SDN的文章,本文不会介绍SDN的细节,但值得指出,SDN站在一个全局的控制视角,将网络转发节点的控制平面抽离出来,形成了统一的全局控制平面,这样网络转发节点就只剩下了数据平面,承担数据转发任务。
部署了SDN后,上面例子会变成下述情形:
我现在简短说几句关于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的骨干网所要做的,仅仅是在必要的时候把资源调度到北京的节点即可!所以说,一个用户典型的访问模式应该是下面的样子:
由于可以就近提供服务,企业便不用支付大笔的过境流量费用,只需负担用户至企业骨干接入点的费用即可,在企业骨干网内部,使用的运营商服务也仅限于DWDM传输系统以及部分机房的租用资金,这对于大型企业来讲,绝对划算。
-----------------------------------
又到了结束的时间,其实还有无尽的感慨,但我现在最想做的事情就是去睡一觉,然后再起来喝一杯,然而这是奢望,通宵过后并没有机会睡觉,而是要赶路,要当活导航。所以我会继续审视以下这么一个令人遗憾的话题,先看一个tcptrace图:
1.T1到T2之间的重传可能是由于队列被塞满丢包引发的也可能是周期性共振噪声丢包,在T2时刻恢复,ACK线和发送线斜率未变,性能根本没有由于丢包重传而下降!
2.如果在T1和T2期间多发包,会继续Bloat队列或者加强周期性共振噪声造成更多的丢包!
3.基于1和2,多发包实则在赌博,并且,如果赌赢了,与之前的性能持平,没有额外收益,如果赌输了,将会产生新的丢包重传从而占据有效带宽。
以Linux实现的TCP为例,在T1和T2期间,PRR算法已经将窗口恰到好处的有所降低,保证即时是噪声丢包也不会造成性能损失(这是因为突发会积累),这个时候已经处在异常阶段了,就不要再加塞了。明显的事实,却需要历史来评说!
-----------------------------------
发挥导航优势。到家后睡觉去咯!
版权声明:本文标题:骨干网络演化释义以及TCP BBR的部署环境问题 内容由热心网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:https://m.elefans.com/dianzi/1727861860a1134120.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
发表评论