[转]为何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参考模型具有以下优点: 简化了相关的网络操作: 提供设 ...
随机推荐
- Entity Framework 使用
1.EF中Include方法的使用使用Include方法,告诉EF连接查询哪个外键属性,生成Inner join连接 //必须引用using System.Data.Entity;才能用Include ...
- PHP单引号和双引号的区别
单引号和双引号的区别 .双引号 里的东西 输入的时候能判断是否 包含 变量,如果包含 变量 就一起输出 .单引号里的就不一样,不判断是否有变量,就全部当成 字符串 输出 .单引号解析的时间比双引号快 ...
- onSaveInstanceState(Bundle outState)的调用时机
原文摘自: http://handsomeliuyang.iteye.com/blog/1407044 Activity的方法onSaveInstanceState(Bundle outState), ...
- 【HTML5】Server-Sent服务器发送事件
Server-Sent 事件 - 单向消息传递 Server-Sent 事件指的是网页自动获取来自服务器的更新. 以前也可能做到这一点,前提是网页不得不询问是否有可用的更新.通过服务器发送事件,更新能 ...
- LoadRunner之自定义HTTP请求
LoadRunner之自定义HTTP请求 性能测试开发脚本时使用的都是同样的模式.对在性能测试规划时指定的典型业务逻辑场景进行录制,形成基本的脚本骨架. 录制脚本后需要对脚本进行编辑,以满足性能测试需 ...
- cmd.ExecuteNonQuery();和cmd.ExecuteScalar();
C#...cmd.ExecuteNonQuery();是返回执行命令后影响的参数 返回符合你条件的所有语句,如果你要数据库里某张表的数据,说执行这个命令后他返回的是就是这张表的全部数据cmd.Exec ...
- C#将DataTable转换成list的方法
本文实例讲述了C#将DataTable转换成list及数据分页的方法.分享给大家供大家参考.具体如下: /// <summary> /// 酒店评论列表-分页 /// </su ...
- 简单几何(线段相交) POJ 2826 An Easy Problem?!
题目传送门 题意:两条线段看成两块木板,雨水从上方往下垂直落下,问能接受到的水的体积 分析:恶心的分类讨论题,考虑各种情况,尤其是入口被堵住的情况,我的方法是先判断最高的两个点是否在交点的同一侧,然后 ...
- 水题 Codeforces Round #300 A Cutting Banner
题目传送门 /* 水题:一开始看错题意,以为是任意切割,DFS来做:结果只是在中间切出一段来 判断是否余下的是 "CODEFORCES" :) */ #include <cs ...
- Win7系统删除微软拼音
微软拼音会在使用Office时偷偷的安装,都找不到删除的地方.在网上找了很多方法都不灵光,最后用下面的方法成功删除. 在语言设置窗口里,重新添加一次这个输入法,确定保存,然后再删除,就行了. 这个 ...