這篇文章由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帶來的擴展性了，小過大獲成功！
