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协议栈设计成沙漏型的的更多相关文章

  1. 渣渣小本求职复习之路每天一博客系列——TCP/IP协议栈(5)

    前情回顾:一篇短短的博客明显不能满足TCP和UDP这两个饥渴的汉子,而且还被应用协议占了一小半的篇幅.在昨天结束之后,相信大家都基本对TCP/IP协议栈的轮廓有一个大概的印象了,能够对整体有所把握. ...

  2. TCP/IP协议栈概述

    TCP/IP协议栈概述 这篇文章虽然只是很粗浅的介绍了ISO/OSI 网络模型,但确实把握住了关键点,某种意义上,简单回顾一下就可以加深对TCP/IP协议栈的理解. 原作者:阮一峰 链接: http: ...

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

    ISO制定的OSI参考模型的过于庞大.复杂招致了许多批评.与此对照,由技术人员自己开发的TCP/IP协议栈获得了更为广泛的应用.如图2-1所示,是TCP/IP参考模型和OSI参考模型的对比示意图. T ...

  4. TCP/IP协议——TCP/IP协议栈及框架

    TCP/IP协议同ISO/OSI模型一样,也可以安排成栈形式.但这个栈不同于ISO/OSI版本,比ISO/OSI栈少,所以又称之为短栈.另外,需要知道的是:TCP/IP协议栈只是许多支持ISO/OSI ...

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

    Linux TCP/IP协议栈,数据发送接收流程,TCP协议特点 http://network.51cto.com/art/201909/603780.htm 可以毫不夸张的说现如今的互联网是基于TC ...

  6. TCP/IP协议栈在Linux内核中的运行时序分析

    网络程序设计调研报告 TCP/IP协议栈在Linux内核中的运行时序分析 姓名:柴浩宇 学号:SA20225105 班级:软设1班 2021年1月 调研要求 在深入理解Linux内核任务调度(中断处理 ...

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

    OSI参考模型 OSI RM:开放系统互连参考模型(open systeminterconnection reference model) OSI参考模型具有以下优点: 简化了相关的网络操作: 提供设 ...

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

    现在的服务器支撑上百万个并发 TCP 连接已经不是新闻(余锋2010年的演讲,ideawu 的 iComet 开源项目,WhatsApp 做到了 2.5M).实现 C1000k 的常规做法是调整内核参 ...

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

    OSI参考模型 OSI RM:开放系统互连参考模型(open systeminterconnection reference model) OSI参考模型具有以下优点: 简化了相关的网络操作: 提供设 ...

随机推荐

  1. 计数排序算法——时间复杂度O(n+k)

    计数排序 计数排序是一个非基于比较的排序算法,该算法于1954年由 Harold H. Seward 提出.它的优势在于在对一定范围内的整数排序时,它的复杂度为Ο(n+k)(其中k是整数的范围),快于 ...

  2. 如何在Eclipse中查看Android源码或者第三方组件包源码

    文章出处:http://blog.csdn.net/cjjky/article/details/6535426 在学习过程中如果经常阅读源码,理解程度会比较深,学习效率也会比较高,那么如何方便快捷的阅 ...

  3. 电赛菜鸟营培训(五)——OLED屏幕的使用

    一.取模软件的使用 首先进行设置 然后可以生成显示这个字母的代码,列优先,先按列画8行,然后再继续画下一列.汉字为16*16,字母为8*8,对应生成相应个数的ox代码. 二.STM32烤写OLED # ...

  4. SQL Server:在事务中回滚TRUNCATE操作

    我们一般都认为TRUNCATE是一种不可回滚的操作,它会删除表中的所有数据以及重置Identity列. 如果你在事务中进行TRUNCATE操作,就能回滚.反之,它就不会从日志文件文件恢复数据.它不会在 ...

  5. Android,visibility属性

    Android,visibility属性 1) 可见(visible)XML文件:android:visibility="visible"Java代码:view.setVisibi ...

  6. SU Demos-02Filtering-03Sudipfilt

    不足之处,欢迎各位博友批评指正. 进入目录,依照惯例先看Readme, 第一个脚本, 下面是运行结果: 第二个脚本: 运行结果如下: 第三个脚本: 运行结果:

  7. BZOJ1770 : [Usaco2009 Nov]lights 燈

    设$f[i]$表示$i$点按下开关后会影响到的点的集合,用二进制表示. 不妨设$n$为偶数,令$m=\frac{n}{2}$,对于前一半暴力$2^m$搜索所有方案,用map维护每种集合的最小代价. 对 ...

  8. BZOJ2093 : [Poi2010]Frog

    从左往右维护两个指针l,r表示离i最近的k个点的区间,预处理出每个点出发的后继,然后倍增. #include<cstdio> typedef long long ll; const int ...

  9. 从Apache Storm学到的经验教训 —— storm的由来(转)

    阅读目录 Storm来源 初探 再探 构建第一个版本 被Twitter收购 开源的Storm 发布之后 Storm的技术演进 构建开发者社区版 离开Twitter 提交到Apache Apache孵化 ...

  10. KMP算法(转载)

    转载http://blog.csdn.net/yutianzuijin/article/details/11954939 kmp算法又称“看毛片”算法,是一个效率非常高的字符串匹配算法.不过由于其难以 ...