周末随笔:说一些反直觉的事情

最近发生了很多这样的反直觉的事情,觉得特好玩跟大家分享一下。
大家在学很多计算机网络的课程的时候,都会讲到主机和网络的解耦,主机不必需要知道路由信息,因为全网的状态传递需要大量的带宽,主机也没有太多的计算能力去算拓扑和规划路由。
工程上的实现都有它的历史背景,但是不顾历史生搬硬套那就有些问题了。当然你不可否认很多人一辈子都靠类比活着,把新学到的知识和已有的知识类比,通常会说:”这不就是xxxx么“,然而这些自然而然地直觉般的类比可以很快的学习一些东西,实现一些东西,却永远无法创造一些东西。例如做路由器设计的时候,很多人对LPM算法都有研究,从最早的二叉树到Trie , Radix, 到后面TBM。而如今呢?有了HBM以后,容量加大了直接暴力hash就好了。但是很多靠着类比活着的人,可能还在做着靠TCAM查路由表的路由器。



1. 从一个招标测试说起:路由器真的就只看pps/bps和端口密度么?
记得去年某一个XX保险集团SDWAN招标测试,某两个X厂和某Y厂都去了。有个X厂采用类似于Openflow的方式,第一个包查表,然后到flowtable cache。结果某个性能测试项我让仪表厂商试一下源目的IP流利用随机UDP端口打一下,65535*65535 自然就把那家的流表打爆了。而另一个X厂家还在使用TCAM做路由表查询,自然无法用到很多资源平衡ACL和路由条目数,那么随便设计一个测试例就又把它家打出问题来了。Y厂是发明路由器的某大厂,在很多设计细节中都有很多反直觉的设计,这些都来自于大量工程实践上的取舍。你可以看到它pps不强,带宽不大,端口密度也小,但很多时候就是最好用的。当我们衡量一个路由器还在采用带宽吞吐端口密度的时候,你没想到会有这样的一出戏?第一个X厂100Gbps的路由器在随机端口测试例下千兆都到不了。第二个整机有很大的容量,却在单端口ACL和路由条目上输的很惨。所以我们的直觉会带来大量的偏差。



2.SDN本来就是错的:SDWAN谁也做不好的根本原因
把分布式控制平面集中到一地后又发现容量不够又用分布式软件架构堆?
第二个反直觉的事情是,当前分布式软件架构这么牛逼,我可以把数据尽可能多的采集丢给控制器处理, 控制器拥有上帝视角可以干很多事情。但网络本身的Scale是远大于很多互联网公司的数据架构的。例如一套高性能的流式计算引擎能够处理每秒1M的事件已经基本满足很大规模日活的需求了。而网络遥测(Telemetry)的处理能力起码需要10M event /s,例如一个超大规模的数据中心为了处理交换机产生的各种硬件Telemetry,例如INT/IPT/IFA等,通常需要数百台服务器的集群来支撑,C厂当年在Tetration上犯的错后来看样子还有无数人会接着犯。所以分布式不一定真的能够解决这些问题,除非你真的钱多了没地方花。

紧接着另一个问题又来了,为什么每一家SDWAN的产品都做的烂,没有一家做的好的。其实本质上就是SDN的问题,想通过集中式的控制平面来解决一些问题,必然会带来其它的问题。整个行业被Nick牵着走,搞烂了Openflow又搞P4,却没有人想到另一个反直觉的问事情:
SDN是不是本身就错了
。大多数的SDN最终做成的无非就是一个更贴近业务的网管运维系统罢了。
SDN错在一个最简单的事情上, 你见过哪个政府只需要中央政府并不停的扩展部委而不搞地方政府的?
所以分布式系统有着它存在的价值,而把它集中到某地然后再构建分布式集群就属于扯淡了。广域网链路的不稳定性,遥测技术受到大量的限制,你需要大量精妙的算法来做归纳汇总然后分布式进行决策。而我们就莫名其妙的上了Nick教,枉费了十多年的光景。如今还有一些项目要把P4编译到BPF…
P4最大的问题就是
只能解决一些小问题。
。语法的完备性极大的局限了它的使用场景,甚至很多场景都是伪命题。



利用分布式一致性的算法做多智能体的协同,以及采用声明式的策略引擎,让分布式智能控制平面遵守策略而不是通过YANG什么的直接指挥设备,这才是网络控制面的唯一出路。


3.蜜汁自信的FEC

第三个反直觉的事情是FEC,不知道哪个厂先挑起来的,估计应该是Velo说FEC很管用,然后华为跟了,思科跟了,最近阿里云也跟了。然后最早做FEC的google QUIC把它废了。其实很简单,现在的网络已经不是以前那种误码率高导致的链路持续丢包的场景了,而丢包大多数是因为链路拥塞导致的,一个QoS队列自然很容易对一个流连续的丢包,因此当把四个包通过矩阵构造成5个包时,大概率传递到对端会丢2个包以上,造成这四个原始的包都被废了恢复不回来了。这是QoS Taildrop的原因。

而另一方面,如果你在国内部署SDWAN,用Internet线路,基本上就不怎么丢包。几年前我们可能还会想到电信联通互访很慢什么的, 这些年的带宽扩容基本上国内网络基本上没有什么拥塞了,所谓的FEC就是没事给自己找事。增加了延迟又改变不了问题。


4.继续依赖BGP

当然不可否认BGP有它成功的地方,但是那是在20~30年前。现在逐渐发现一些问题,但因为很多人不懂,或者说根本没有自己徒手写过路由协议,自然只能抄作业咯。数据中心内部继续用BGP EVPN+VXLAN,用IBGP要RR,然后RR冗余又是一个很麻烦的事情,收敛也慢,被迫改成BGP, Leaf—Spine–Leaf又导致AS_PATH出现环路,又有一堆垃圾配置要加进去。然后Calico做CNI也是,也得没事弄个BGP去折磨自己,最后导致Scale并不好。

这些都是我们直觉的惯性,慵懒的类比思维,却总是没有从最根本的地方去想,我们需要什么,如何实现什么?下图是昨天晚上大概9点多的时候,Ruta测量的全球20个VPC互联的链路丢包情况,BGP的缺陷就在这里暴露无遗。腾讯北京到阿里迪拜拥塞的时候(37%的丢包),地球的另一边美国西海岸则是非常空闲的深夜时分,很容易的实现一个SRoU就获得了一条几乎不丢包的线路。

周末随笔:说一些反直觉的事情

BGP的选路规则导致了链路的局部拥塞,但是另一方面你不可否认它是一个很不错的系统至少能把整个网络连起来。但是为什么不在它之上再做点什么呢?无非是分布式一致性的问题,Raft/Paxos都有比BGP更好的解决办法,也更加可信和安全。

说到底,没人敢干只是因为不懂,或者懒罢了,科技狂奔了几十年,奔得很多人忘记了思考,只顾着类比(抄袭)了。

随便吐槽一下,只是偶然看到一个TED,有些感慨,大概18分钟以后:

Well, I do think there’s a good framework for thinking. It‘s physics. You know, the sort of first principles reasoning.
Generally I think there are — what I mean by that is, boil things down to their fundamental truths and reason up from there, as opposed to reasoning by analogy. Physics is really figuring out how to discover new things that are counterintuitive, like quantum mechanics.

像我这样的人,很多人无法看懂我在说什么,我1995年开始写代码,1997年开始就开始接触互联网,1999年就开始写网页当站长创业,到后OI竞赛拿奖保送某个技校,到某技校读数学,后来又在某大厂从语音做到路由还玩过一段时间无线同时又负责某厂Technical Marketing,同时有研发和市场的经历,左手可以自己撸代码,右手又可以和客户扯架构,脑子里还能玩AI/ML,毕竟咋这种好歹也算名校数学系毕业的,所以当过基金经理做过量化交易算法都是手到擒来,都是数十年的经历的沉淀很多事情就像Musk所说的那样,去从最本源的地方开始探索,多收集一些朋友们负面的评价:)







周末随笔:说一些反直觉的事情》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:http://www.hashtobe.com/355.html