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

前几天有人回复我的一篇文章问，为何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，正因为这样，才使得应用层和链路层可以互不纠缠，独立发展。
细腰，是足够性感的，无论这腰是谁的！