[转]为何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,正因为这样,才使得应用层和链路层可以互不纠缠,独立发展。
       细腰,是足够性感的,无论这腰是谁的!

时间: 2024-10-22 21:36:12

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

OSI模型和TCP/IP协议栈

OSI(Open System Interconnect )开放系统互连参考模型是国际标准化组织(ISO)和国际电报电话咨询委员会(CCITT)联合制定的开放系统互连参考模型,为开放式互连信息系统提供了一种功能结构的框架.这里所说的开放系统,实质上指的是遵循OSI参考模型和相关协议能够实现互连的具有各种应用目的的计算机系统.它从低到高分别是:物理层.数据链路层.网络层.传输层.会话层.表示层和应用层.而TCP/IP协议栈和OSI模型有着对应关系,那么先看一下OSI参考模型.OSI参考模型如下图所

TCP/IP协议栈

TCP/IP协议栈全称是传输控制协议/因特网互联协议,其实是OSI模型的进化版,所以就先解释一下什么是OSI模型,OSI的全称是开放系统互连参考模型,就是为了实现开放系统互连所建立的通信功能分层模型,其目的就是为异种计算机互连提供一个共同的基础和标准框架,并为保持相关标准的一致性和兼容性提供共同的参考.这里的开放系统指的是遵循OSI模型和相关协议能够实现互连的具有各种应用目的的计算机系统.OSI模型一共有七层,TCP模型一共只有四层,分别为应用层,传输层,Internet层,网络访问层.它定义了

TCP/IP协议栈与数据包封装+TCP与UDP区别

ISO制定的OSI参考模型的过于庞大.复杂招致了许多批评.与此对照,由技术人员自己开发的TCP/IP协议栈获得了更为广泛的应用.如图2-1所示,是TCP/IP参考模型和OSI参考模型的对比示意图. TCP/IP参考模型的层次结构 TCP/IP协议栈是美国国防部高级研究计划局计算机网(Advanced Research Projects Agency Network,ARPANET)和其后继因特网使用的参考模型.ARPANET是由美国国防部(U.S.Department of Defense,Do

[转帖]Linux TCP/IP协议栈,数据发送接收流程,TCP协议特点

Linux TCP/IP协议栈,数据发送接收流程,TCP协议特点 http://network.51cto.com/art/201909/603780.htm 可以毫不夸张的说现如今的互联网是基于TCP/IP构建起来的网络.弄懂协议栈的原理,无论对调试网络IO性能还是解决网络问题都是有很大帮助的.本片文章就带领大家来看看内核是如何控制网络数据流的. 作者:底层软件架构来源:今日头条|2019-09-30 09:28 收藏 分享 可以毫不夸张的说现如今的互联网是基于TCP/IP构建起来的网络.弄懂

Linux下TCP/IP协议栈的简单脉络分析

最近在写网络编程方面的一些东西,然后遇到了关于传输上的小问题.由于之前有简单的看过一些TCP/IP详解的一些东西,所以索性就找了本<追踪LinuxTCP/IP代码运行>的书看了一上午,结果发现初次接触这些内核方面的东西,收获甚微.于是又在网上找相关类的大神博客,拿来拜读,虽然依然看的不是太明白,吸收的也不够好,但是我想以博客的形式把它记录下来,也希望能为我以后学这些东西开个好头吧 1.linux的网络协议栈的主要结构 (1)socket层 这层主要处理socket相关的东西,例如其各种结构的初

【转】TCP/IP协议栈及OSI参考模型详解

OSI参考模型 OSI RM:开放系统互连参考模型(open systeminterconnection reference model) OSI参考模型具有以下优点: 简化了相关的网络操作: 提供设备间的兼容性和标准接口: 促进标准化工作: 结构上可以分隔: 易于实现和维护. 20世纪60年代以来,计算机网络得到了飞速增长.各大厂商为了在数据通信网络领域占据主导地    位,纷纷推出了各自的网络架构体系和标准,如IBM公司的SNA,Novell IPX/SPX协议,Apple公司的AppleT

几种开源的TCP/IP协议栈分析

1:BSD TCP/IP协议栈,BSD栈历史上是其他商业栈的起点,大多数专业TCP/IP栈(VxWorks内嵌的TCP/IP栈)是BSD栈派生的.这是因为 BSD栈在BSD许可协议下提供了这些专业栈的雏形,BSD许用证允许BSD栈以修改或未修改的形式结合这些专业栈的代码而无须向创建者付版税.同时, BSD也是许多TCP/IP协议中的创新(如广域网中饿拥塞控制和避免)的开始点.ftp://ftp.FreeBSD.org/pub/FreeBSD-stable/src/sys.netinet 2:uC

C1000k 新思路:用户态 TCP/IP 协议栈

C1000k 新思路:用户态 TCP/IP 协议栈 如今的server支撑上百万个并发 TCP 连接已经不是新闻(余锋2010年的演讲,ideawu 的 iComet 开源项目,WhatsApp 做到了 2.5M).实现 C1000k 的常规做法是调整内核參数,提高文件数,降低每一个连接的内存消耗(參考 ideawu 的博客). 在今年的 BSDCan2014 会议上, Patrick Kelsey 介绍了把 FreeBSD 9.x 的 TCP/IP 协议栈移植到了用户态(slides, git

TCP/IP协议栈及OSI参考模型详解

OSI参考模型 OSI RM:开放系统互连参考模型(open systeminterconnection reference model) OSI参考模型具有以下优点: 简化了相关的网络操作: 提供设备间的兼容性和标准接口: 促进标准化工作: 结构上可以分隔: 易于实现和维护. 20世纪60年代以来,计算机网络得到了飞速增长.各大厂商为了在数据通信网络领域占据主导地    位,纷纷推出了各自的网络架构体系和标准,如IBM公司的SNA,Novell IPX/SPX协议,Apple公司的AppleT