[转]为何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,正因为这样,才使得应用层和链路层可以互不纠缠,独立发展。
细腰,是足够性感的,无论这腰是谁的!
[转]为何TCP/IP协议栈设计成沙漏型的的更多相关文章
- 渣渣小本求职复习之路每天一博客系列——TCP/IP协议栈(5)
前情回顾:一篇短短的博客明显不能满足TCP和UDP这两个饥渴的汉子,而且还被应用协议占了一小半的篇幅.在昨天结束之后,相信大家都基本对TCP/IP协议栈的轮廓有一个大概的印象了,能够对整体有所把握. ...
- TCP/IP协议栈概述
TCP/IP协议栈概述 这篇文章虽然只是很粗浅的介绍了ISO/OSI 网络模型,但确实把握住了关键点,某种意义上,简单回顾一下就可以加深对TCP/IP协议栈的理解. 原作者:阮一峰 链接: http: ...
- TCP/IP协议栈与数据包封装+TCP与UDP区别
ISO制定的OSI参考模型的过于庞大.复杂招致了许多批评.与此对照,由技术人员自己开发的TCP/IP协议栈获得了更为广泛的应用.如图2-1所示,是TCP/IP参考模型和OSI参考模型的对比示意图. T ...
- TCP/IP协议——TCP/IP协议栈及框架
TCP/IP协议同ISO/OSI模型一样,也可以安排成栈形式.但这个栈不同于ISO/OSI版本,比ISO/OSI栈少,所以又称之为短栈.另外,需要知道的是:TCP/IP协议栈只是许多支持ISO/OSI ...
- [转帖]Linux TCP/IP协议栈,数据发送接收流程,TCP协议特点
Linux TCP/IP协议栈,数据发送接收流程,TCP协议特点 http://network.51cto.com/art/201909/603780.htm 可以毫不夸张的说现如今的互联网是基于TC ...
- TCP/IP协议栈在Linux内核中的运行时序分析
网络程序设计调研报告 TCP/IP协议栈在Linux内核中的运行时序分析 姓名:柴浩宇 学号:SA20225105 班级:软设1班 2021年1月 调研要求 在深入理解Linux内核任务调度(中断处理 ...
- 【转】TCP/IP协议栈及OSI参考模型详解
OSI参考模型 OSI RM:开放系统互连参考模型(open systeminterconnection reference model) OSI参考模型具有以下优点: 简化了相关的网络操作: 提供设 ...
- C1000k 新思路:用户态 TCP/IP 协议栈
现在的服务器支撑上百万个并发 TCP 连接已经不是新闻(余锋2010年的演讲,ideawu 的 iComet 开源项目,WhatsApp 做到了 2.5M).实现 C1000k 的常规做法是调整内核参 ...
- TCP/IP协议栈及OSI参考模型详解
OSI参考模型 OSI RM:开放系统互连参考模型(open systeminterconnection reference model) OSI参考模型具有以下优点: 简化了相关的网络操作: 提供设 ...
随机推荐
- PowerDesigner12逆向生成oracle数据表时,错误解决
1.用PowerDesigner12建模,在Database—>Generate Database (或者用Ctrl+G快捷键)来生产sql语句,却提示“Generation aborted d ...
- C#实现UTC时间与Datetime转换
为了便于传输,通信过程中传输的都是:当前时间跟标准时间相隔的秒数,并且是以16进制字节的形式传输的. public double ConvertDateTimeInt(System.DateTime ...
- hive复杂类型与java类型的对应
因为要往自定义的UDF传入复杂类型,所以需要对于这块的对应简单做一下总结 string java.lang.String, org.apache.hadoop.io.Text int int, jav ...
- loadrunner关联数组后拼凑字符串
loadrunner拼接关联数组的元素 int arrSize=0; int index=1; int len=0; char arryStartString[1024]=""; ...
- jpg图片转eps 用于LaTeX
好用的网上在线转,使用的sam2p 可以方便地将jpg或jpeg转为eps,pdf http://www.tlhiv.org/rast2vec/ windows下.jpg转.eps for latex ...
- [LintCode] Word Break
Given a string s and a dictionary of words dict, determine if s can be break into a space-separated ...
- Google地图接口API之地图控件集(五)
1.默认控件集 当使用一个标准的google地图,它的控件默认设置如下: (1). Zoom-显示一个滑动条来控制map的Zoom级别,如下所示:
- 数学 ACdream 1196 KIDx's Triangle
题目传送门 /* 这道题花了好长时间AC,思路有,但是表达式少写了括号一直乱码,囧! 注意:a==0时要特判:) */ #include <cstdio> #include <alg ...
- ural 1272. Non-Yekaterinburg Subway
1272. Non-Yekaterinburg Subway Time limit: 1.0 secondMemory limit: 64 MB A little town started to co ...
- codevs 1507酒厂选址
#include<cstdio> #include<cstdlib> using namespace std; int n; int dis[10010],a[10010],x ...