《信息存储》特刊：戏说协议之间的相互作用

    这篇文章由IP SAN和FC SAN引出，逐渐展开，从总体上论述了“协议之间相互作用”这个课题。提出了网络通信协议的4层逻辑结构，提出了协议相互作用的3种方式。将对协议分析领域的研究产生深刻而深远的影响。
  
     无忌“无忌”成大业
     小过“小过”需努力
     江山辈有人才出
     无忌小过顶天地
  
    话说无忌和小过各占一方，谁也不让谁，互相竞争了数年，两者各立门派，势不两立。“夫天下之势，分久必合，合久必分”。

    数年来，两人在市场上的竞争可谓你死我活。无忌仅仅抱着FC SAN的速度和稳定性来炮轰小过的IP SAN，而小过也不甘示弱，处处举着可扩展性和成本的大旗，声讨FC SAN，闹得江湖上风风雨雨。无忌凭借着FC的优势，占据了高端市场，而小过则以成本优势在低端市场占据了一席之地。然而两人谁都想一统天下，把对方彻底驱逐出市场，但是，相持数年了，谁也没能把谁干掉。两人都累了，这么多年的互相攻击，谁也没有取得丝毫胜利，无忌还是稳固地占据高端市场，小过依然驰骋低端。

    终于有一天，无忌和小过决定握手言和，不再投入无谓的人力物力财力来和对方竞争。与其大肆攻击对方，不如多用点精力来提升和发展自己的技术，同时学习对方的技术，取长补短，方为正道啊！！ 无忌和小过彻夜长谈，终于取得了一致的见解，决定双方各取所长，发展自己的技术，共同为江湖做贡献。

    首先，无忌决定由小过入股自己的公司，给FC SAN提供更高的扩展性架构解决方案；同时，无忌也入股小过的公司，给小过提供研发经费，用于其研发出基于以太网的新型的，适合存储区域网络的专用上层协议体系。

    入股无忌公司之后，小过便开始了研究如何将FC协议体系转向一个可扩展的，开放的结构。说到可扩展并且开放，一定非TCP/IP末属。可是FC和TCP/IP是完全两套毫不相干的协议体系，如果将FC全部转为TCP/IP，那岂不是叛变成IP SAN了么？但是如果丝豪不变，那只能是FC SAN，还是不具备开放和扩展性。 

    FC为什么扩展性差？就是因为如果通信双方距离太远的话，需要自己架设光缆，或者租用电信的专线光缆，这两者成本都够高的。并且如果租用电信部门的专线光缆，则FC最低速度为1Gb，1Gb带宽的专线光缆，呵呵，不是不可能，而是一般人承担不起这费用。目前电信提供的专线接入，其骨干网一般采用SDH传输，一般下到终端用户，为2M的E1线路。当然也可以直接从高速骨干下来高速的线路，比如OC3，Oc48等等，但是费用无法直接承受。E1线路有自己的编码格式，不能直接将ISP过来的光纤插到FC设备上，这样是没用的，因为编码都不一样，不能和局端的设备建立连接，所以需要增加一个协议转换设备，将E1协议转换成比如V35串口、以太网等其他协议，好像没有E1转FC的协议转换器。

    目前看来，如果要扩展FC网络，让相隔很远的两地之间跑上FC协议，只能自己架设专用光缆，可是市政部门，让你架设么？不可能的。除非在一个大厂区之内，别人管不着，但是如果是在两个城市，两个省之间，你一点办法也没有。怎么办？首先，要出去，就一定要租用电信部门的线路，电信又提供了两种线路，一种是接到Internet的线路，也就是接入电信的Internet运营网络，通信的双方都接入，并且使用TCP/IP通信。另一种，就是点对点光纤专线，也就是上文所说的那种情况。这条专线端到端的带宽独享。Internet线路，虽然可以最大到100Mb的速率，但是这只是本地带宽，端到端的带宽，以现在的TCP/IP协议体系，除非花钱买ISP的QoS或者MPLS TE服务，否则没有人保证。而点对点专线，虽然保证了带宽，但是通常承受的起的，只有E1这样的低速专线，而且价格相对Internet接入要贵，还有它似乎目前只能承载IP作为网络层协议，因为目前E1协转只能转成V35串口或者以太网，而他们不能承载FC协议。有些路由器不用协转，直接可以连接从光端机出来的G703或者BNC接头，直接编码E1，但是这些也都是IP路由器，和FC丝豪没有关系。可以看出，FC如果脱离了“后端专用”这四个字，到开放领域，显然是无法生存的。而IP SAN，则及其开放，碛餐ǔ裕?只要有IP的地方，就可以部署IP SAN。

    说到这里，租用Internet线路，只能承载IP，而租用点对点专线，也是只能承载IP，可能感觉FC的扩展似乎就是死路一条了。想到这里，小过似乎已经没有什么招数了。他感到非常郁闷。忽然，他想起了iSCSI，当初自己不就是把SCSI协议给封装到了TCP/IP协议中来传输，才扩展了SCSI协议么？是不是可以这么说：将一种协议封装到另一种协议中，就可以使用另一种协议带来相应的好处呢？不妨就这么假设一下，FC不可扩展，TCP/IP扩展性很强，那么如果把FC协议封装到TCP/IP协议中来传输，是不是也可以获得TCP/IP的扩展性呢？这个想法比较大胆，因为FC本身也是作为一种可以传输其他协议的协议，FC甚至可以承载IP，作为IP的链路层，那么为什么现在确反过头来需要被IP来承载呢？Protocol over Protocol，PoP，即一种协议被over到另一种协议上。且听下面分解。

    不能不说的以太网和TCP/IP。我们前面已经对以太网和TCP/IP协议进行了详细的介绍。我们知道，以太网是一个网络通信协议，以太网，并不一定就是HUB，就是交换机，就像某人说过的一句话一样：“网络就是水晶头”。这句话比较有意思，他反映出说这句话的人对网络的不了解。网络就是水晶头，证明他平时所见到的网络，只是以太网而已，青蛙只能看到它头顶上的一片天。但是这句话从某种角度也反映出了以太网在当今的普及程度。前面讲到了以太网是可以寻址的，也就是说它涉及到了OSI第三层的内容，也就是网络层。大家都连接到一个以太网环境中，不需要任何其他上层协议，大家就可以区分开对方，进行通信。既然这样，为什么又需要TCP/IP协议呢？而我们总是说以太网＋TCP/IP协议二元组，而不是仅仅说以太网，或者TCP/IP协议？因为以太网和TCP/IP协议，是逻辑上分开的，他们各自是不同的协议体系，那么为什么总是把他们组合起来说呢？他们之间为什么有着割舍不断，藕断丝连的联系呢？这其中原因，还要从IP讲起。

    前面也说过了，IP就是一个身份标志，一个用来把你区别于其他人的一个ID。以太网的MAC地址，从原理上讲，就足够用来区分各个节点了。但是前面也分析过完全靠MAC来寻址的缺点。一是MAC地址太长，48位，这个理由现在已经不成立了，因为IPv6的地址是128位的，二是世界上并不都用以太网来建立局域网的，那么就有其他的寻址方式，需要一个秦始皇来统一天下，IP就担任了这个任务。不管以太网，或者串口，或者FDDI之类的局域网方式，它给每个节点都分配一个全球唯一的地址：IP地址。那么IP就是它的大名，MAC是它的小名，主机名或者域名，是它的笔名，这么比喻大家应该能理解了。一般大家访问网站之类的，其实就是和提供网站服务的服务器来建立通信，获取他的网页和其他服务，此时我们需要用笔名和他通信，然后你输入笔名在IE浏览器中之后，DNS程序自动把笔名转换成大名，用大名进行通信。那么你的包带着大名到了服务器所在的局域网之后，会由那个局域网的路由器通过发出ARP，来把大名对应成小名，最后通过交换机把你的包发给服务器。为什么要这么麻烦，经过多次转换？首先，把IP转换成域名，是为了我们使用方便，不必记忆那些复杂的IP地址。其次，把MAC转换为IP，是为了天下一统，刚才说过了。其实如果所有人加靡蕴?网联网，那么就可以完全抛弃IP这一层寻址了，但是实际是不可能的，以太网现在还没有一统天下，而且就算一统天下了，人们也似乎不愿意抛弃IP，就像同一个局域网内，还是用IP来直接通信，而不是直接用MAC。如果直接用MAC，则还需要改变程序代码。

    原来，整个Internet，不仅仅都是以太网，以太网适合局域网联网通信，但是不适合广域网情况，广域网的联网协议，比如PPP，HDLC，Frame Relay，x25，ATM等等。他们各自都有各自的寻址体系，都有各自的地址，就像以太网有自己的MAC地址一样，Frame Relay也有自己的寻址地址，就是DLCI地址，x25也有自己的地址，ATM同样有自己的地址。如果在一个Internet上有这么多种地址，相互融合，寻址，那后果将是不堪设想，很难维护，需要在各种地址之间，相互翻译，转换，每遇到一种，就转换一次，这非常麻烦，所以IP出现了IP地址，使得所有联网的节点，不管用的什么方式，以太网也好，Frame Relay也好，统统都分配一个IP地址给他，对外最终以IP地址作为寻址地址，而将IP地址，再映射到自己使用的联网方式所使用的寻址地址上，比如IP映射到以太网的MAC，或者IP映射到Frame Relay的DLCI，IP映射到ATM的ATM地址，等等，用来进行地址映射的一套程序，称为address resolution protocol，ARP。很多人听到ARP，就认为是以太网，其实这也是错误的，ARP不仅仅代表以太网中的IP地址和MAC地址的映射，它同样可以代表IP和DLCI的映射等等。

    IP，统治了OSI的第三层，将原来占据第三层的，比如以太网MAC地址，FR的DLCI等等这些杂乱的寻址体系，给统一了，就像秦始皇统一货币一样。而原来的这些寻址体系，成了在野党。而映射到以太网的IP，称为IPoE，映射到FR的IP，称为IPoFR，映射到ATM的IP，称为IPoA，等等等等。从此，一种新的概念诞生了：PoP，即protocol over protocol。

    IP统一了天下，还不够。各种协议，比如以太网，以太网是一个面向无连接的网络，它不保障数据一定会传送的对方，它是一个不负责任的网络，不管目的地有没有收到，只管发送。而FR，其前身x25，是一个有着很好传输保障的协议，在TCP/IP没有出现之前，x25的传输保障机制，做得非常到位，因为x25其设计初衷，就是为了运行在极其不稳定的链路上。而随着链路质量的不断提高，x25的做法显得越来越因噎废食了，所以其改良版本Frame Relay，就逐渐替代了x25。FR抛弃了x25中很多无谓的传输保障机制，而仅仅留下一些流控机制。相对于以太网的不负责任，FR起码在链路层面，实现了比较好的流控措施。而不管是以太网，还是FR，他们都没有实现端到端的保障，端到端，是相对于“过路”来说的，也就是通信的最终两端无误的收到数据，才能算作真正的保障，而FR做的，只是在过路的时候，也就是在链路传输的时候，保障链路正确传输，但是如果链路正确传输给了终端，但是终端到最终上层的某个环节出错了，那么数据同样也是错误的，这就是端到端发现错误。为了实现这个目的，TCP出现了。TCP的作用，就是运行在通信的两个终点，不管两点之间用什么样的链路连接，以太网也好，FR也好，专门来收发数据，并对终端最终收到的数据做检查，看看是否顺序，是否正确，是否有丢弃，也就是TCP不是运行在链路上的，而是运行在两端的。即使链路保障机制再健全，TCP也是有必要的，因为只有被最最终端正确收到数据，才能算正确的传输。

    所以，在IP之上，又凌驾了一层，TCP层。而FR等等这些联网协议的保障机制，只能保障链路传输无误，不能保障端到端的正确收发，所以只能沦为收据链路层的角色了。

    我们可以体会到，协议之间也是在互相利用，互相排挤，吞并，融合，以适应不同的应用环境，因为不可能为每一种应用环境都设计一种协议，协议之间互相利用，融合，才是最好的解决办法。

    我们现在可以回答上面没有找到答案的那个问题了，为什么以太网偏要和TCP/IP组合成一对呢？因为以太网使用的太广泛了，而OSI的第三层，第四层，也几乎被IP、TCP给统一了，所以以太网＋TCP/IP就成了一对好搭当了。协议和协议之间，各有分工，虽然一个协议可能OSI各个层的功能它都有，就像ATM，但是如果和其他协议合作，那么就要有个分工，ATM目前也是用来承载IP，但不能越权，它只管传输IP包到目的就可以，而不管数据是否出错，是否乱序等等，虽然它可能有这个功能。这就是协议互相融合。以太网虽然自己可以寻址，但是它还是配合IP，进行IP到MAC的映射，统一使用IP寻址，它默默无闻，所有光辉都被TCP/IP所披挂。

    网络通信协议，一般可以分成payload层、交互逻辑层、信息表示层和寻址层。其中最重要的是交互逻辑层，它是一个协议的灵魂。

    payload层，也就是协议所承载的与本协议无关的最终数据，也就是本协议最终需要传送给对方的数据。

    信息表示层，就是附加在payload数据之外的一段数据，也称作协议开销，因为这段数据和最终应用程序无关，是运行在通信双方的通信协议，用来交互信息，从而作出正确动作的一段重要数据。

    交互逻辑层，这一层其实就是运行在通信双方协议系统上的动作代码，逻辑，它根据对方传送过来的信息表示层数据，来作出相应的动作逻辑，生成自己的信息表示层，发送给对方，然后对方再做相同的动作，就这样完成通信双方之间的正确动作逻辑。

    寻址层，就是帮助协议怎么来找到需要通信的目标，比如IP地址，MAC地址，DLCI地址，等等。

    以上的这四层，是任何一个网络通信协议所必须具备的，不管多么简单或者多么复杂的协议。

    寻址层，如果是点对点传输协议，则可以忽略此层，因为不需要寻址。而且不同协议之间的寻址层，可以互相映射翻译，典型的例子，就是IP到MAC，IP到DLCI等等。

    payload层中的数据，既可以是最终应用产生的数据，也可以是另一种协议的信息表示层＋payload数据。如果payload封装的是最终应用产生的数据，则表示这个协议是直接被上层应采用程序来调用，从而完成程序之间的远程网络通信的。如果payload封装的是另一种协议的信息表示层＋payload数据，那么就证明这个协议此时正在承载另一种协议。比如协议A封装了协议B的信息表示层＋payload，则就可以说协议A封装了协议B，或者协议A承载了协议B，或者说协议B is over 协议A。

    交互逻辑层，每种协议都不相同，但是很多都类似，可以说基本思想有些协议是类似的，因为他们所实现的目的都是一样的，就是将数据通过网络传输到目的地。正因为如此，各种协议的交互逻辑层，可以互相融会贯通，将一种协议的逻辑，映射翻译到另一种协议的逻辑,从而将各种协议的优点结合起来,完成目的。

    协议之间相互融合的另一个促成因素，就是协议使用广泛程度不同，而要完成一个目标，不得不借用某种协议。就像TCP/IP协议，TCP/IP协议占领了全球Internet的领地，那么如果有一种其他协议，它想跨越地域，或者国家，来进行通信，但是自己又无能为力，因为它首先就没有专门为它准备的物理线路，其次他的设计，也就不适合大范围，长距离，广域，保障传输的情况下完成端到端的通信。能适合Internet规模的网络通信协议，唯TCP/IP末属！而其他协议想要完成Internet范围的通信，就不得不借助TCP/IP，搭TCP/IP的车，让TCP/IP来承载它们。它们是怎么搭上TCP/IP的快车呢？

    协议和协议之间的相互作用，有三种种基本的思想。一种是use，也就是一种协议完全利用另一种协议，另一种是tunnel，也就是遂道，一种协议将另一种协议遂道封装。还有一种是map，也就是一种协议对另一种协议进行映射翻译。

    Use，使用，也就是一种协议自身没有某些功能，需要使用另一种协议提供的功能。一种协议怎么去使用另一种协议呢？例子太多了，比如TCP使用IP，因为TCP没有寻址功能，所以它利用IP来寻址。而IP又可以使用以太网，因为IP只是一个寻址功能，它没有链路传输的功能，所以它利用以太网交换提供的链路传输。IP使用PPP等等，也就是上层协议为了达到通信目的，使用另一种协议为他自己服务。

    Tunnel，遂道封装，顾名思义，就是将一种协议二话不说直接作为另一种协议的payload来进行封装，打包传输到目的地，然后解开外层协议，露出内存被封装承载的协议，再提交给内层协议处理逻辑模块进行处理。也就是说进行协议转换的设备根本就不需要去理解内层协议到底是什么东西，到底想要干什么，只要你给了我，我就统统打包发出去，完事了。Tunnel的出现，往往是由于被tunnel的协议虽然和外层协议都在某一方面有所实现，但是在这一方面被tunnel协议不如外层协议做的优秀，不适合某种特定的环境，而这种环境，恰恰被外层协议所适合。

    而map，是比tunnel更复杂的，也更有扩展性的一种方式。所谓map，也就是映射，就是说将内层协议的部分或者全部逻辑，映射翻译到外层协议对应的功能相似的逻辑上，而不是仅仅不管三七二十一的简单的封装。map相对于tunnel，是内外层协议的一种最彻底的融合，它将两种协议的优点，融合的天衣无缝。

    我们在这里主要说一下tunnel和map。

    打个比方来说，火车，汽车，这是两种运输方式，他们看似有太大的不同，但是他们的目的都是相同的，即都是为了将货物运送的目的地。而火车呢，它需要跑在铁道上，但汽车需要跑在公路上；火车因为铁轨很平滑，需要用钢铁轮子，而汽车因为公路很颠簸，需要用充气轮胎；火车几乎不需要红绿灯来制约，而汽车跑在公路上，会有很多红绿灯来制约它；火车由于跑在专用的铁轨上，所以他能而且也敢达到很高的时速，而汽车由于跑在共享的公路上，它能，但是不敢达到太高的时速；火车不能跨出国境，而汽车可以方便的穿越国境；火车只能按照他的铁轨来运行，而汽车几乎随处可达……我们一下子列举出了火车和汽车的种种特点，相应的，飞机，轮船，火箭等等都可以拿来对比，这些特点，就像各种通信协议自身的特点一样。同样都是运输货物，为什么各种方式千差万别？因为他们适应了不同的需要。同样的，一个网络通信协议，只不过它运输的不是货物，而是一串0和1，是高低变化的电平，是数据，是信息。通信协议也是千差万别，同样也是为了满足不同的情况，不同的需求。TCP/IP协议，它就满足了Internet范围的网络通信；FC协议，它就满足了后端存储的专用高速这个环境，二者都各自占有自己的领地，谁也取代不了谁，铁路不可能为了和民航竞争，而把铁轨往天上修，航空公司也不可能为了和陆运公司竞争，而让飞机跑在公路上。

    但是，如果某个驾驶汽车出远门的人，需要到国外，并且在国外也需要开自己的车办事，而又很急，赶时间，怎么办？开车东绕西绕，绕到国外么？当然太慢了，那么此时怎么办呢？当然要考虑飞机，但是飞机是运输工具，汽车也是运输工具，怎么把汽车带到国外呢？可能有人说，在国外租一辆车开不就完了么，那另当别论，我们就假设这么一个模型来说明问题。车主考虑飞机托运，也就是用一种能将原先的交通工具所不能实现或者实现不好的另一种交通工具，来托运或者封装，或者承载原先的交通工具，到达目的地之后，再次发挥原先交通工具的作用。我们这个例子，也就是：因为汽车不能很快达到目的，那么我们暂时先将汽车承载于飞机之上，然后达到“快速到达目的”这个目标之后，再将汽车取出来，行使汽车的便利。相反，如果存在这种情况，比如将飞机承载于汽车之上，会不会发生呢？当然理论上可以发生，不过现实中可能很少，考虑这么一种情况：某架飞机需要大修，已经飞不动了，需要到异地去修理，怎么办呢？我们可以将飞机拆卸，然后封装到集装箱汽车中，运输到异地，然后再进行维修，这就是将飞机承载到汽车之上。那么同样，将飞机承载到火车上，或者汽车over火车，甚至：自己over自己，也就是用飞机来运输飞机，闷?车来运输汽车，当然这些都在现实中是存在的?

    咱们还是再把话题拉回来。说完了货运协议，咱们再说说信息通信协议。因为TCP/IP适合整个Internet范围的通信，而SCSI协议不适合，所以如果SCSI协议需要跨越大范围通信，就要将其承载到TCP/IP上，也就形成了iSCSI协议，然而TCP/IP根本就不关心什么是SCSI，更不知道SCSI是怎样一种作用逻辑，它只是负责封装，传输。因为以太网没有认证机制，没有NCP机制（PPP协议中用来协商上层协议参数的机制），而PPP却有这些机制，但是PPP使用程度远远不如以太网广泛，怎么办？Over吧！大家一起来over，于是形成了PPPoE。

    iSCSI和PPPoE，这两个协议，是典型的tunnel模式。我们上面已经给tunnel下过定义了，首先一种PoP的模式被定义为tunnel的前提，就是这两种协议对某一特定的功能，均有自己的实现。我们拿iSCSI来分析，TCP/IP可以实现网络通信，SCSI协议也可以实现网络通信，所以他们具备了这个前提。第二个要说的：什么时候才会被tunnel？需要的时候。因为SCSI通信协议扩展性太差，传输距离太短，而TCP/IP可以扩展到Internet，所以将SCSI tunnel到TCP/IP，形成iSCSI，完毕。我们以后做协议分析，都推荐使用这种因果分析法，来分析一个协议所产生的原因，以及他的发展趋势，是要被淘汰，还是将要被发展壮大。
  Tunnel的另一个作用，就是伪装，有时候虽然两种协议实现的功能，适用环境都相同，但是还是将其中一种tunnel到另一种之上，这是为什么呢？有些情况确实需要这种实现方式，比如IP协议中的GRE，通用路由封装，就是这样一种协议。将IP协议承载到IP协议之上，自己承载自己，这样就可以使得一些不能在公网路由的IP包，封装到可以在公网路由的IP包之中，到达目的后，解开封装，露出原来的IP包，再次路由。这就是伪装。利用这种思想，人们发明了所谓VPN，Vitual Private Network，用来将身隔千里的两个内部网络，通过Internet连接起来，走internet的时候，使用公网地址封装内网的IP包。这是最简单的VPN。在这基础上，又对IP包进行加密，反修改等等措施，形成IPSec体系，将其和原始的VPN结合，形成了带加密和反修改的VPN，真正使得这种PoP，穿越外层协议的时候，能够保障安全。

    我们还是拿一个例子来说明，到底什么是tunnel。邮政系统，目前已经是举步维艰。21世纪之前，网络还没有很普及，除了电话电报，写信似乎是大家长距离通信的唯一选择。寄信人将自己的信件（数据，payload）装入信封，填好收信人地址、邮编、名称（通信协议的信息表示层、寻址层）等等，交给邮局，由邮局进行层层路由转发（协议交互逻辑层），最终到达目的地。IP网络和邮政系统，他们及其相似。而为什么邮政系统目前已经陷入了困境呢？原因就是竞争。进入21世纪之后，物流业快速兴起，他们借助陆路，水路，航路，铁路等等“链路层”，加上自己的一套管理体系，充分利用这些资源，达到物流目的。以前只有邮政一种方式，而现在，物流公司多如牛毛，每个公司都有自己不同的物流体系，但是他们基本思想都是大同小异，都是要将用户的货物运送到目的地。21世纪，虽然网络已经很发达，但是网络只能走信息流，走不了实物流。所以物流公司还是能占据一定市场。我们来看看21世纪，用户是怎么来寄出一封信件或者包裹的。同样寄出一封信，如果还是用古老的“协议”，比如信封＋80分邮票的形式，还是可以的，大街上现在还有邮筒。但是很多快递公司，也提供信件包裹服务，只不过他们用的信封，比普通信封大，结实，而且他们信封上的标签，所包含的信息更加具体，比如增加了收件人电话，发件日期，受理人签字，委托人签字等等。邮政信封具有的，快递信封都具有。我们从这里就可以看出这两种协议的不同之处了。你可以把信件封装到邮政普通信封直接发送，也可以封装到快递公司信封中发送，也就是选用其中一种协议。那么如果我先把信件（最终数据）封装到普通信封中，填好信封头信息（协议信息表示层和寻址层），然后将封装好的普通信封，再封装到快递公司的信封中，并再次填一份快递公司的信封头信息。快递公司按照这些信息，将信件送到目的地，目的收到之后，解开外层信封，然后解读内层信封的信息头，再次转发，或者直接打开。刚才描述的这种情况，就是一个典型的协议tunnel方式的相互作用，把邮政协议，tunnel到快递公司的协议，这种tunnel的目的，就是为了获得快速，优质的服务，因为邮政协议提供不了快速高效的服务。

    我们再来看这种情况，比如，快递公司A，在青岛没有自己的送货机构，但是有人需要向青岛送货，怎么办？此时当然要考虑借助在青岛有送货机构的快递公司，让他们代送，将信件封装到快递公司A的信封，然后再装入快递公司B的信封，让快递公司B做转发，到目的地之后，B的送货员剥开外层信封，最终用户会收到一个快递公司A的信封，客户就认为是快递公司A全程护送过来的，其实不是的。这样就很好的伪装了信件。这是tunnel的另一个目的。

    说完了tunnel，我们再来说说map。Map，抽象来说，就是将一种协议的逻辑，翻译映射成另一种协议的逻辑，达到两种协议部分或者完全融合。

    还是那个快递公司的例子。两个快递公司（两种协议），快递公司A在青岛没有自己的送货机构，但是B有。所以A和B达成协议，A将青岛地区的送货外包给B，凡是A公司在青岛的业务，都由B来运送，但是面上必须保持A的原样，这种方式目前商业已经广泛使用。起初的做法是：先将客户信件装入A信封，然后再封装一层B信封，带着A信封来转发，也就是tunnel。后来，B公司嫌这种方法浪费了人力，因为额外携带了一个A信封，这增加了信件的重量。所以B公司琢磨出一套方法，即先让B公司的取件人了解寄件人所要提供的信息，此时取件人担当A公司的角色，用户认为取件人是A公司的，用户按照A公司的协议，将信封头信息告诉取件人，然后取件人此时并没有将信件装入A公司信封，而是直接装入了B公司信封，但是在填写B公司信封头的时候，取件人将用户提供的针对A公司特有的信封头信息，转换翻译成B公司特有的信封头信息。经过B公司转发后，到达目的之后，送货员再次将B公司的信封头信息，转换翻译成A公司所特有的信封头信息，这样两端的用户，同样也丝毫感觉不出中间环节其实是B公司完成的。但是这种方式相对于tunnel凡是，却节约了B公司的成本，提高了转发效率。这种方式的协议之间的相互作用，就是map。

    我们再从实际情况说起。最简单的map，就是IP和以太网之间的map。IP地址必须映射到MAC地址，才能享受以太网的服务，所以有了ARP，专门用来做IP和MAC的映射关系。上文说过，IP和以太网之间，是use＋tunnel关系，怎么又出来映射关系了呢？实际上，各种协议之间的相互作用，不可能只是其中一种作用方式。寻址体系之间一定需要map，交互逻辑层可以tunnel，也可以map，payload一定需要tunnel。所以针对协议不同的层次，都有相对应的相互作用方式的。我们再来看看交互逻辑上的map，这中map可比寻址层的map，要复杂的多。寻址层的map，或者信息表示层的map，只是维护一张映射表就可以，交互逻辑的map，需要维护一个代码转换逻辑层。比如TCP的流控机制和FC协议的流控机制之间的map，TCP是靠窗口机制实现端到端的流控，FC靠buffer to buffer和end to end两种机制实现流控。如果把FC协议承载到TCP/IP协议之上，那么会出现tunnel模式，和map模式，当然tunnel中也需要map。我们不妨称作：以tunnel为主的模式，和以map为主的模式。如果是tunnel模式，那么TCP/IP根本不管FC协议的交互逻辑是怎么样的，TCP仅仅把FC当成payload来封装并传送，充其量将FC寻址层来映射到IP层。而map模式中，进行map操作的设备或者软件，就需要既了解TCP/IP协议的交互逻辑，又了解FC协议的交互逻辑，因为只有了解了双方的逻辑，才有可能进行map。具体来讲，比如FC协议发出了一个信号，说本方缓存将满，请降低发送速度。则map设备收到这个信号之后，就会map成TCP/IP可识别的信号，即：本方处理受阻，窗口减小至某某数值，这就是FC协议到TCP/IP协议关于流控机制map的一个方法。被承载到IP之上之后，FC协议就可以漂洋过海远隔千里之间被传递了。如果再tunnel模式中，FC协议发出的这个流控信号，也会被TCP/IP给tunnel传送到对方，然后再由对方的FC协议模块来根据这个信号来判断流控机制应该作出的动作，动态调整发送速率，而其中，TCP/IP不参与任何FC协议内部的逻辑。出了流控逻辑的映射，比如登陆机制，连接机制等等的映射，比如，FC发起一个flogin过程，那么map设备会map到TCP/IP的一个握手过程，等等。

    呼啦，呼佟，哎呀！！小过从梦中醒来。刚才做的那场黄梁美梦，在早晨的阳光中，烟消云散。但是仿佛那个梦，就是一场真实。小过按照梦中描述的PoP的规则，鬼使神差的将FC协议果真映射到了IP上。给他做了两种模式，一种是以tunnel为主的模式，称作FCIP，另一种是以map为主的模式，称作iFCP。

    至此，FC协议终于可以享受TCP/IP带来的扩展性了，小过大获成功！

    小过和无忌从此握手言和！

    本文节选自《信息存储》杂志2006年度特刊，点击此处浏览全部文章。
    想要免费申请订阅《信息存储》杂志，请点击此处。

未经允许不得转载：DOIT » 《信息存储》特刊：戏说协议之间的相互作用