[转]为何TCP/IP协议栈设计成沙漏型的

http://m.blog.csdn.net/blog/dog250/18959371

前几天有人回复我的一篇文章问,为何TCP/IP协议栈设计成沙漏型的。这个问题问得好!
我先不谈为何它如此设计,我一个80后根本就没有资格去评论上世纪80年代已经臻于成熟的一个设计,我只是说一下目前的趋势,然后你就会明白当初的这个设计是如此之好,以至于它不但满足了30年前的需求,并且适配到了现在以至于未来!

总体趋势:通信网的退化

网络在退化,我指的是IP网络在退化,所有的逻辑全部在纵向上挤向两端,上端管协议逻辑,下端管实际传输;在横向上挤向中心,所有的控制平面逻辑正在趋向于中心化。因此IP就退化了,最终只剩下一个连接器意义的东西,没有它不行,因此,它就是精化。鉴于此意义,我并不看好IPv6,虽然它解决了IP地址不够用的问题。

趋势1:横向上,网络控制趋于中心化

典型的,比如SDN!控制是中心化的,处理是分布式的,这是我多年以前的想法,当时我问过我的培训老师,为何要分别在不同的地点做相同的配置动作,只是IP地址不同,为何不能在一个地方配置?VPN有两个端点,因此必然要有两帮人处在两个地方,出了差错之后,必然要有两帮人去两个现场,虽然你可以在一个机房,远程连接到两个现场的设备,但是,我想的是,为何不能在协议本身层面上做到单点配置。
       虽然,以Cisco等为代表的传统网络厂商依然在坚持着自己的原则,但是,我并不认可这种原则。在我的学习,工作和生活中,我甚至会严重鄙视这种原则,我坚持自己的原则,以至于从来难以和别人融洽的合作!网络本身就是不对等的,虽然IP并不区分两个端点,但两个端点的平等性并不能阻止中间节点成为它们的控制者。也许,很多人不喜欢“中间人”这种词,认为那是一种攻击,然而很多网络处理不都在扮演类似的角色吗?比如代理,比如NAT,WEB防火墙...不一而足!为何在传输控制层面上不能也是如此呢?
       我向来不喜欢TCP,因为它的职责太多了,它的原本意义上的职责其实就是协议逻辑本身的传输控制,比如排序,比如建立一个连接,它不应该包括流控,拥控的内容,正是因为它包含了这些内容,才会出现可恶的锯齿曲线,长肥管道更多的是一种理想。我以高速公路为例再说几句,为何汽车在高速公路上会匀速行驶,原因在于限速是全局的,全都写在了路边的告示牌上,而不是所谓的自己探测,汽车怎么自己探测呢?很简单,不断加速,然后简单追尾擦碰,之后迅速减速...在SDN年代,TCP就可以抛弃自探测算法了,正是因为TCP的年代是一个分布式协议的年代,没有中心控制,也不可能有中心控制,TCP才自带了流控,拥控机制,这种机制实际上是一种绅士型的自觉控制机制,因此才会出现UDP抢带宽的事情发生,而对于TCP而言,对于UDP的流氓行为,绅士型的行为只会让你的让步成为徒劳的吃亏!在SDN年代,由于存在一个控制中心,也就可以存在一个全局的限速指示牌,至于如何来控制,我们知道SDN拥有丰富的APP接口...你可以实现双11限速,可以实现除夕拜年收费,ETC通道?...所有你能想到的,在SDN年代,UDP的流氓行为被遏制...
       全局控制的复杂度尽量集中在中心节点,而不是所有的端点,这是我的一个信条。

趋势2:纵向上,协议逻辑趋向于上层化

我总喜欢拿TCP开涮,是因为我太恶心这个协议,它太复杂!但在本小节,我想说的是,它复杂,但是它经不起更加复杂,也就是说,它不能再复杂了,然而实际需求是,它需要更复杂,换句话说,它还不够复杂!
       OSI的第5层以及以上目前已经完全被APP领域主导,而目前移动终端,瘦终端等预示的终端轻量化,小型化导致APP可以更加容易的大面积铺开,APP将极大地丰富,在这样的背景下,个人觉得OLPC计划将不可能像当初预想的那样发展下午,它将失去存在的意义。在如今APP以极快的速度衍生的背景下,第4层的协议将不堪重负,与其负担如此大的压力,而不直接将协议控制逻辑转交给APP本身。我可能说错话了,第4层协议的UDP就做的比较好,它仅仅提供了一个协议多路复用的逻辑,可以将多个进程复用到相同的IP层,仅此而已,因此它没有任何负担,虽然SSL协议是基于TCP的,但是你仍然可以在UDP上实现SSL协议,这就是它的灵活性。
       灵活性在于可扩展性,无限的可扩展性,虽然TCP的一些算法也是可插拔的,但是可插拔的位置却是固定的。UDP就没有这样的限制。在APP越来越丰富,越来越复杂的年代,协议控制逻辑也会越来越复杂而无极限,这样要求第4层要提供一个可无限扩展的协议接口,它已经不再适合直接处理复杂的协议逻辑。
       协议逻辑,由APP本身来控制,第4层协议仅仅提供一个端到端的逻辑以及复用逻辑即可。

趋势3:纵向上,传输逻辑趋向于底层化

IP可以传输数据包吗?胡扯!IP仅仅是一个指路人而已。因此IP当然是越简单越好,甚至在SDN年代,它的指路人角色也将意义不在,它更多的角色责任落实到了编址上,因此它将更加简化。
       在整个协议栈,传输的逻辑应该在链路层,自从IP夺取第三层协议主宰以来,以前的第三层协议,比如ATM,X.25等都已经退化到了链路层,事实上,网络层根本就不应该负责任何数据包的传输逻辑。第三层的意义在于整合异构网络,向上层提供统一视图。异构网络在本质上是存在的,因为存在厂商之间的竞争,但是标准也是必要的,这就是链路层标准。只要符合标准,实现技术是多样的,这就产生了诸如以太网,点到点网络等,我们应该注意到,虽然实现方式可以多样,但是现在也在走向统一,骨干网总有一天会走向全光传输网,Stub网络在技术上也在经历“秦王扫六合”的过程,函谷正东开,诸侯尽西来!
       在分层模型的上层越来越异样华,多样化,复杂化的同时,链路层正在经历统一化,但是技术上却是越来越复杂,记住,统一并不意味着简单,统一指的是接口统一,复杂指的是实现技术复杂,要做到实现技术复杂,接口统一是必然的要求,这一点上,链路层和应用层的发展方向正好相反。传输链路在硬件上趋向于简单化,标准化,而把复杂的控制逻辑交给软件完成,这个趋势和本文的趋势1:横向上,网络控制趋于中心化,二者是殊途(横向和纵向)同归(SDN)的。
       应用是异构的,传输链路软件层面是复杂的,应用协议逻辑纯软件实现,拥有无限的可扩展性,复杂的底层和复杂的上层必然无法直接接口,必须通过一个简单的适配层提供统一简单的接口族进行适配,该适配层就是IP!

趋势4:横向上,存储趋向于边缘化

这不就是CDN吗?它实际上是一个网中网,是一个SUB network。我想起了京东的模式,那就是控制仓储加物流,这就是CDN,反观淘宝,它就不是CDN,它有点像TCP socket的p2p模式,不管要收发什么,你都要自己写一个socket程序,然后发送,验证错误码,一旦有什么错误,又要TMD抓包!
       知道我想说什么吗?通信传输逻辑和内容的关系!它们二者到底要结合呢还是要分离呢?我比较倾向于分离,这样就可以方便“建立仓库”,建立什么仓库呢?京东的模式在于,它可以在物流和仓储两个方面分别发力,这是它实现CDN的根本!京东可以把内容集中在一个任意它可以决定的地方,这个地方当然是离客户最近的地方,实现这种内容和传输的分离,靠的就是有一个中间适配层,我们不妨把内容称为APP,传输叫做链路层,而这个适配层就是IP。但是淘宝就很难做到这一点,它更像一种P2P的模式,它的内容和传输是无法分离的。
       至于说为何在仓储和物流之间的适配层必须要简单,我们可以从仓储以及物流的复杂性来理解。目前的网络正在走向内容中心化,即内容比IP路由更重要,而内容的存储地就要特别讲究,存在哪里,即仓库建立在哪里必然要有一定的依据,该依据是在大数据时代的数据挖掘下被采集的,而该过程是十分复杂的,以实际仓库+物流模式而言,京东肯定不会在回民区的仓库放置大量的猪肉制品以及酒类。再说物流,物流需要核算成本,需要保鲜,需要送货人员...等等这一切如何规划,都是复杂的,和趋势3一样,两个复杂层中间的接口必须是简单的。
       有时候,一个模式的区别,带来的是巨大的差异。

沙漏模型

我不妨把网络分为两部分,一部分是传输逻辑,一部分是APP协议逻辑,对于传输逻辑而言,我更侧重于硬件标准,对于不管是APP协议逻辑还是控制平面逻辑而言,我更侧重于软件。软件控制通过传输机制而起作用,这就是网络的本质,而把控制逻辑和传输逻辑粘合起来的,就是IP!它理所当然设计成了沙漏的细腰的部分!IP对上提供了一个简单清爽的复用层,对下展现的是一个简单清爽的发送/接收SPI,正因为这样,才使得应用层和链路层可以互不纠缠,独立发展。
       细腰,是足够性感的,无论这腰是谁的!

上一篇:chrome插件开发.在content_script异步加载页面后, 如何进行JS通信与调用的问题


下一篇:python(一):python语言基础