移动IP技术之我见

写了一篇《 重新设计TCP/IP协议栈以支持设备移动性》,得到了很多回声,CSDN本身的评论,QQ讨论,电话...褒贬不一,都是讨论技术的,甚至还有冒X口的,我一笑而过,顺带着更加鄙视某种技术之外的东西,这个我会另外写一篇文章的。针对那么多的回应,我也进行了进一步的思考,那就是,IP真的要支持移动吗?我把答案先贴在这个,希望能有进一步的讨论。答案可能就是, IP根本就不需要支持移动,移动IP技术在纯技术层面上也许根本就不应该存在。
       为何这么说呢?说实话,所有的应用“连接”都应该由应用程序自己来定义和保持,TCP连接并不能说明是一个应用程序为保持会话而应保持的连接,TCP连接的破坏重连仅仅表明端到端网络层/传输层的五元组被重置,即便这样应用层也能定义一个协议保持应用层本身协议的有效性,再往下,IP连接仅仅表示一种IP地址间的可达性(IP本身并不是基于连接的,但是广义的想,它的连接就是路由可达的意思)。之所以有移动IP这种技术出来,很大的问题来自于应用程序本身而不是TCP/IP协议的缺陷,当然TCP/IP确实存在缺陷,并且在我的那篇文章中所说的那些缺陷也确实真实,然而将应用程序的缺陷加在TCP/IP上面进行数罪并罚的话,也确实有失公允。
       考虑网络购物应用,你进入店铺,登录,购物,然后关机,注意,关机的意思是希望断掉所有的TCP连接,然后开机,打开浏览器,继续购物,你并不需要重新登录,这就是说,在这类应用中,一个连接的保持就是你的购物过程不会因为TCP连接的中端而中断,确实,想HTTP的session起的作用也类似,但是还是有更多更复杂的类似机制。因此,应用程序并不能过分的苛求传输层的所谓TCP连接,而更应该关注事务(Transaction)和会话(Session)。之所以目前的应用程序在移动时代遇到了这么多的问题,就是因为很多的应用程序的设计者将应用层的连接错误的等同于TCP连接。我一直都不十分同意业界的一个说法,那就是TCP/IP模型完胜了OSI模型,这里给出一个理由,其实OSI是一个定义模型而TCP/IP则是一个实现模型, TCP/IP模型中缺失了会话层和表示层,声明二者在应用层自身实现,这意味着什么?
       这意味着TCP/IP模型放弃了会话层和表示层的标准化工作,最终导致应用程序直接把会话和表示这两个本来应该标准化的工作嫁接在了BSD socket之上,BSD socket的INET族直接接在传输层,这说明应用程序偷了懒!即便这两个层没有标准化,应用程序也可以有自己的会话层和表示层,比如典型的HTTPS协议。对于表示层而言,SSL协议可以看做一个实现安全传输的表示层协议,也被标准化了,可是对于会话层,就没有那么简单了,表示层可以根据表示需求热插拔,可是在移动时代,会话在TCP之上需要维持是一个硬需求,应用程序本身积重难返!这正好给了玩基础设施的设备商以及运营商一个绝好的机会。
       如今的APP爆炸式的增长刺激了多少传统产业,催生了多少新产业,真的是应用为王爆炸的全面开花的时代,这个诱惑力是巨大的,笔者一直以为底层网络把戏台子搭好,唱戏的主角是互联网应用,过去的二十年,一直都是搭建戏台子的时间,实际上整个互联网可以看成是一个偌大的工地,戏台子工人在玩了命的施工中,期间有加班加点,拓展创新,也有偷工减料,弥漫着的也包含行贿受贿,一些厂商积累了大量的经验和财富,成了工程界的皎皎者,人们一度认为它们领先于互联网的时代,其中包括Cisco,Juniper,H3C等。如今它们的戏台子好像是搭建完了,然而是不是想留下场地给应用厂商就不得而知了,于是乎它们便主动担当了互联网基础设施的所谓“二期工程”策划者的角色,无非就是想继续占据业界领先的位置,再一次分一杯羹。正是应用“只关注业务,不关注网络”导致了基础设施构建者的上位。
       于是,网络设备厂商也开始玩爆炸,想把地层已经建立好的戏台子炸得遍地开花,然后再搭一个。说白了就是他们不想让位。实际上,它们提出过的很多所谓的新技术,都很牵强,经不起仔细推敲,但是人们已经习惯了它们制定标准的角色,因此很少有人提出什么异议,再说,即便有什么问题,它们也能依靠自己的资源在业内占据的比重给出一个整理的解决方案,即便那是一个又一次修修补补的方案,鉴于人们只要结果不管细节的特性,只要是一个整体方案就行,整个故事中,到此为止我没有提运营商,如果我把设备厂商看做戏台承包商的话,那么运营商扮演的角色就是有权批准谁可以承建戏台的有关部门,其中的合作与博弈我就不多说了,虽然数据中心的重要性也不可小觑,但是 就互联网基础设施来说,谁控制了骨干,谁说了算,至于支端Stub网络,那是应用服务器和存储的天下!
       说了这么多,该下结论了!TCP/IP诞生于实验室,壮大于设备厂商,支持于运营商,后两者有纷繁复杂的利益交织,后两者牵头的网络基础设施改造计划基本都是短视的,是TCP/IP缺失了两个层的标准化导致了厂商和运营商过度参与到了标准的制定中,很大程度上并不是为了真正标准化,而是为了自己利益最大化!然而这是一种双赢局面的利益最大化,我对此持中立态度。
       移动IP技术本质上并不是一个基于全新框架的技术,它无非依靠封装/适配,增加新协议进而增加新设备在满足用户需求的前提下争取自己的利益最大化,当然对于不断增资的互联网产业而言, 这是良性循环。互联网基础设施的用户是应用开发商,应用当然不希望有什么颠覆性的改变,它们早已习惯了即有开发平台,而此时基础设施的改变就是必然,应用厂商可以平滑过度到移动时代的代价就是让应用的最终用户为基础设施的移动化支持买单,而在应用爆炸的年代,成本被海量的用户以及复杂的cross边际效应所稀释(比如广告/公告,微信营销之类的东西),人们反而觉得上网越来越便宜,终端性价比越来越高,这不是良性循环是什么?
       缺失的层总是要弥补,移动化时代,设备厂商和运营商再一次举起了大旗,和上一次构建互联网基础设施依托实验室以及标准化组织做法不同的是,这一次它们不是在纵向插入一个新的标准化的层,而是将协议栈横向拉伸,引入了很多新的协议和设备,这就是双赢的局面,设备厂商/运营商和大学/标准化组织之间关系就是如此的微妙复杂。标准化组织和厂商/运营商的理念非常不同,标准化组织是接口驱动的,只定义标准接口,不管内部实现,而厂商/运营商则是反馈驱动型的,只要有需求就满足,然后接收用户反馈,迭代改进,因此 标准化组织的东西会越做越高,变成细高型的,而厂商/云运营商的东西会越铺越宽,变成扁平状的,二者一结合,就是现如今的TCP/IP局面,一个腰部逐渐撑大变肥的沙漏型的怪异形状,移动时代的TCP/IP不再苗条。
       结论是什么?结论就是移动IP并不是一个标准化的技术,IP在TCP/IP分层意义上并不需要支持移动性,IP只求可达性就可以了。正是由于TCP/IP模型中会话层的不作为才导致了复杂的移动IP技术的出现,本应该由会话层实现的标准技术成了又一个基础设施类的东西,然而好处也是有的,那便是APP以及何其连接的库可以真正做到“只关注业务逻辑”了,像固定IP时代一样,直接嫁接于标准socket接口上。
       以上,纯粹个人的胡思乱想,不辩论,不较真。请不要用个案以及特殊环境下的个例来反驳,在那种或者也许任何情况下,我的所有想法都是大错特错!
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
想象一下,你正要休个长假或要出差一年,由于要离开家很长一段时间,所以必须作出 些安排,以确保你的邮件能随时送到你手中,而你可能每两个星期就会换个地址。在这种情 况下,又如何保证邮件能送到你那里呢? 一种方法是寄明信片给每一位可能给你写信的人,包括公用事业公司、信用卡公司、朋 友和亲戚,通知他们地址变更情况,还要特别小心,千万不能告诉那些可能寄送垃圾邮件的 人。这种方法存在许多问题。首先,每次换地方就要寄一遍明信片。其次,必须给每一位能 想到的、可能给你写信的人寄上明信片,否则等回家时,就可能发现有人在几个月前给你家 寄了一份非常紧急的通知。第三,在这种方式中,没有任何办法来防止恶作剧者以你的名义 发出这种明信片,从而使得你的信件被送到他们手中,或是送到你的商业对手的手中,或是 任何你所不希望的地方。 更好的方法是在你家所在的邮局留下一个转发通知,这样,所有寄来的信件都将被转发 到你当前的新地址。这种方法的好处在于,将新地址只告诉邮局,而无需通知每一位可能给 你写信的人。邮局可以提供一些安全措施,保证用户的真实身份,确保不是别人假冒你,并 且还可以通过认证,确保你确实有改动转发地址的权限。 诚然,如果一些邮件按你先前的地址进行了转发,可当它们在半路上时,你却又换了新 地址,那么,这些邮件就可能会暂时丢失。解决这个问题的方法是:在你离开之前,通知邮 局将信件再转发到你的新地址上。当然,也可以通知给你写信的人,如果在一定的时间内没 有收到回信,就请再给你重发一次。 这里,如果将“信件”改为“因特网数据包”,将“转发”改为“隧道技术”,将“邮局” 改为“具有移动I P功能的路由器”,那么前面所讨论的情况就和移动I P一样了。下面我们将用 整本书来进一步作详尽的描述。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值