網絡中的數據通信

網絡中的數據通信

現在的互聯網中使用的TCP/IP協議是基於OSI（開放系統互聯）的七層參考模型的，（雖然不是完全符合）從上到下分別爲：應用層、表示層、會話層、傳輸層、網絡層、數據鏈路層和物理層。其中數據鏈路層又可是分爲兩個子層，分別爲邏輯鏈路控制層（Logic Link Control，LLC ）和介質訪問控制層（(Media Access Control，MAC )，也就是平常說的MAC層。LLC對兩個節點中的鏈路進行初始化，防止連接中斷，保持可靠的通信。MAC層用來檢驗包含在每個楨中的地址信息。

首先分析一下在同一個網段的情況。假設有兩臺電腦分別命名爲A和B，如果A需要向B發送數據，A主機首先把目標設備B的IP地址與自己的子網掩碼進行“與”操作，以判斷目標設備與自己是否位於同一網段內。如果目標設備在同一網段內，並且A沒有獲得與目標設備B的IP地址相對應的MAC地址信息，則源設備（A）以第二層廣播的形式（目標MAC地址爲全1）發送ARP請求報文，在ARP請求報文中包含了源設備（A）與目標設備（B）的IP地址。同一網段中的所有其他設備都可以收到並分析這個ARP請求報文，如果某設備發現報文中的目標IP地址與自己的IP地址相同，則它向源設備發回ARP響應報文，通過該報文使源設備獲得目標設備的MAC地址信息。爲了減少廣播量，網絡設備通過ARP表在緩存中保存IP與MAC地址的映射信息。在一次 ARP的請求與響應過程中，通信雙方都把對方的MAC地址與IP地址的對應關係保存在各自的ARP表中，以在後續的通信中使用。ARP表使用老化機制，刪除在一段時間內沒有使用過的IP與MAC地址的映射關係。

兩臺計算機通過TCP/IP協議通訊的過程如下：

下面討論兩臺不在同一個網段中的主機，假設網絡中要從主機PC-A發送數據包PAC到PC-C主機中 。 PC-A並不需要獲取遠程主機（PC-C）的MAC地址，而是把IP分組發向缺省網關，由網關IP分組完成轉發過程。如果源主機（PC-A）沒有缺省網 關MAC地址的緩存記錄，則它會通過ARP協議獲取網關的MAC地址，因此在A的ARP表中只觀察到網關的MAC地址記錄，而觀察不到遠程主機的 MAC地址。在以太網(Ethernet)中，一個網絡設備要和另一個網絡設備進行直接通信，除了知道目標設備的網絡層邏輯地址（如IP地址）外，還要知道目標設備的第二層物理地址(MAC地址)。ARP協議的基本功能就是通過目標設備的IP地址，查詢目標設備的MAC地址，以保證通信的順利進行。

上圖對應兩臺計算機在同一網段中的情況，如果兩臺計算機在不同的網段中，那麼數據從一臺計算機到另一臺計算機傳輸過程中要經過一個或多個路由器，如下所示：

鏈路層有以太網、令牌環網等標準，鏈路層負責網卡設備的驅動、幀同步（即從網線上檢測到什麼信號算作新幀的開始）、衝突檢測（如果檢測到衝突就自動重發）、數據差錯校驗等工作。交換機是工作在鏈路層的網絡設備，可以在不同的鏈路層網絡之間轉發數據幀（比如十兆以太網和百兆以太網之間、以太網和令牌環網之間），由於不同鏈路層的幀格式不同，交換機要將進來的數據包拆掉鏈路層首部重新封裝之後再轉發。

網絡層的IP協議是構成Internet的基礎。Internet上的主機通過IP地址來標識，Internet上有大量路由器負責根據IP地址選擇合適的路徑轉發數據包，數據包從Internet上的源主機到目的主機往往要經過十多個路由器。路由器是工作在第三層的網絡設備，同時兼有交換機的功能，可以在不同的鏈路層接口之間轉發數據包，因此路由器需要將進來的數據包拆掉網絡層和鏈路層兩層首部並重新封裝。IP協議不保證傳輸的可靠性，數據包在傳輸過程中可能丟失，可靠性可以在上層協議或應用程序中提供支持。

網絡層負責點到點（point-to-point）的傳輸（這裏的“點”指主機或路由器），而傳輸層負責端到端（end-to-end）的傳輸（這裏的“端”指源主機和目的主機）。傳輸層可選擇TCP或UDP協議。

TCP是一種面向連接的、可靠的協議，有點像打電話，雙方拿起電話互通身份之後就建立了連接，然後說話就行了，這邊說的話那邊保證聽得到，並且是按說話的順序聽到的，說完話掛機斷開連接。也就是說TCP傳輸的雙方需要首先建立連接，之後由TCP協議保證數據收發的可靠性，丟失的數據包自動重發，上層應用程序收到的總是可靠的數據流，通訊之後關閉連接。

UDP是無連接的傳輸協議，不保證可靠性，有點像寄信，信寫好放到郵筒裏，既不能保證信件在郵遞過程中不會丟失，也不能保證信件寄送順序。使用UDP協議的應用程序需要自己完成丟包重發、消息排序等工作。

目的主機收到數據包後，如何經過各層協議棧最後到達應用程序呢？其過程如下圖所示：

以太網驅動程序首先根據以太網首部中的“上層協議”字段確定該數據幀的有效載荷（payload，指除去協議首部之外實際傳輸的數據）是IP、ARP還是RARP協議的數據報，然後交給相應的協議處理。假如是IP數據報，IP協議再根據IP首部中的“上層協議”字段確定該數據報的有效載荷是TCP、UDP、ICMP還是IGMP，然後交給相應的協議處理。假如是TCP段或UDP段，TCP或UDP協議再根據TCP首部或UDP首部的“端口號”字段確定應該將應用層數據交給哪個用戶進程。IP地址是標識網絡中不同主機的地址，而端口號就是同一臺主機上標識不同進程的地址，IP地址和端口號合起來標識網絡中唯一的進程。

雖然IP、ARP和RARP數據報都需要以太網驅動程序來封裝成幀，但是從功能上劃分，ARP和RARP屬於鏈路層，IP屬於網絡層。雖然ICMP、IGMP、TCP、UDP的數據都需要IP協議來封裝成數據報，但是從功能上劃分，ICMP、IGMP與IP同屬於網絡層，TCP和UDP屬於傳輸層。

【知識補充】

（1）網關的含義

網關是說這樣一種設備：如果主機要發包，就往這個設備發送。也就是說此設備要有路由功能或有去往外部網絡的路徑。在實際網絡裏，網關一般由路由器或Server充當。

（2）ARP(Address Resolution Protocol)是地址解析協議，ARP是一種將IP地址轉化成物理地址的協議。從IP地址到物理地址的映射有兩種方式：表格方式和非表格方式。ARP 具體說來就是將網絡層（IP層，也就是相當於OSI的第三層）地址解析爲數據鏈接層（MAC層，也就是相當於OSI的第二層）的MAC地址。ARP協議是通過IP地址來獲得MAC地址的。

（3）網絡中需要唯一的MAC地址的理由：

（a）IP地址的分配是根據網絡的拓樸結構，而不是根據誰製造了網絡設置。若將高效的路由選擇方案建立在設備製造商的基礎上而不是網絡所處的拓樸位置基礎上，這種方案是不可行的。

（b）當存在一個附加層的地址尋址時，設備更易於移動和維修。例如，如果一個以太網卡壞了，可以被更換，而無須取得一個新的IP地址。如果一個IP主機從一個網絡移到另一個網絡，可以給它一個新的IP地址，而無須換一個新的網卡。

（c）無論是局域網，還是廣域網中的計算機之間的通信，最終都表現爲將數據包從某種形式的鏈路上的初始節點出發，從一個節點傳遞到另一個節點，最終傳送到目的節點。數據包在這些節點之間的移動都是由ARP，負責將IP地址映射到MAC地址上來完成的。

（4）標識網絡中的一臺計算機，一般至少有三種方法，最常用的是域名地址、IP地址和MAC地址，分別對應應用層、網絡層、物理層。網絡管理一般就是在網絡層針對IP地址進行管理，但由於一臺計算機的IP地址可以由用戶自行設定，管理起來相對困難，MAC地址一般不可更改，所以把IP地址同MAC地址組合到一起管理就成爲常見的管理方式。

（5）交換機和路由器的主要區別

工作層次不同

最初的的交換機是工作在 OSI／RM開放體系結構的數據鏈路層，也就是第二層，而路由器一開始就設計工作在OSI模型的網絡層。由於交換機工作在 OSI的第二層（數據鏈路層），所以它的工作原理比較簡單，而路由器工作在OSI的第三層（網絡層），可以得到更多的協議信息，路由器可以做出更加智能的轉發決策。

數據轉發所依據的對象不同

交換機是利用物理地址或者說MAC地址來確定轉發數據的目的地址。而路由器則是利用不同網絡的ID號（即IP地址）來確定數據轉發的地址。IP地址是在軟件中實現的，描述的是設備所在的網絡，有時第三層的地址也稱爲協議地址或者網絡地址。MAC地址通常是硬件自帶的，由網卡生產商來分配的，而且已經固化到了網卡中去，一般來說是不可更改的。而IP地址則通常由網絡管理員或系統自動分配。

傳統的交換機只能分割衝突域，不能分割廣播域；而路由器可以分割廣播域

由交換機連接的網段仍屬於同一個廣播域，廣播數據包會在交換機連接的所有網段上傳播，在某些情況下會導致通信擁擠和安全漏洞。連接到路由器上的網段會被分配成不同的廣播域，廣播數據不會穿過路由器。雖然第三層以上交換機具有VLAN功能，也可以分割廣播域，但是各子廣播域之間是不能通信交流的，它們之間的交流仍然需要路由器。

路由器提供了防火牆的服務，而交換機則沒有

路由器僅僅轉發特定地址的數據包，不傳送不支持路由協議的數據包傳送和未知目標網絡數據包的傳送，從而可以防止廣播風暴。

各種遠程通信協議分析與比較

基本原理

要實現網絡機器間的通訊，首先得來看看計算機系統網絡通信的基本原理，在底層層面去看，網絡通信需要做的就是將數據流從一臺計算機傳輸到另外一臺計算機，基於傳輸協議和網絡IO來實現，其中傳輸協議比較出名的有HTTP、TCP、UDP等，HTTP、TCP、UDP都是在基於Socket概念上爲某類應用場景而擴展出的傳輸協議，網絡IO，主要有BIO、NIO、AIO三種方式，所有的分佈式應用通訊都基於這個原理而實現，只是爲了應用的易用，各種語言通常都會提供一些更爲貼近應用易用的應用層協議。 

應用級協議

遠程服務通訊，需要達到的目標是在一臺計算機發起請求，另外一臺機器在接收到請求後進行相應的處理並將結果返回給請求端，這其中又會有諸如one way request、同步請求、異步請求等等請求方式，按照網絡通信原理，需要實現這個需要做的就是將請求轉換成流，通過傳輸協議傳輸至遠端，遠端計算機在接收到請求的流後進行處理，處理完畢後將結果轉化爲流，並通過傳輸協議返回給調用端。

但爲了應用方便，業界推出了很多基於此原理之上的應用級協議，使得可以不用去直接操作這麼底層的東西，通常應用級的遠程通信協議會提供： 
1、爲了避免直接做流操作，提供一種更加易用或貼合語言的標準傳輸格式； 
2、網絡通信機制的實現，就是替你完成了將傳輸格式轉化爲流，通過某種傳輸協議傳輸至遠端計算機，遠端計算機在接收到流後轉化爲傳輸格式，並進行存儲或以某種方式通知遠端計算機。 

應用級的遠程通信協議，在java領域中知名的有：RMI、XML-RPC、Binary- RPC、SOAP、CORBA、JMS，下面具體看看這些協議：

RMI

RMI 是個典型的爲java定製的遠程通信協議，我們都知道，在single vm中，我們可以通過直接調用java object instance來實現通信，那麼在遠程通信時，如果也能按照這種方式當然是最好了，這種遠程通信的機制成爲RPC（Remote Procedure Call），RMI正是朝着這個目標而誕生的。

來看下基於RMI的一次完整的遠程通信過程的原理：

1、客戶端發起請求，請求轉交至RMI 客戶端的stub類； 
2、stub類將請求的接口、方法、參數等信息進行序列化； 
3、基於socket將序列化後的流傳輸至服務器端； 
4、服務器端接收到流後轉發至相應的 skelton類； 
5、skelton類將請求的信息反序列化後調用實際的處理類； 
6、處理類處理完畢後將結果返回給skelton類； 
7、Skelton類將結果序列化，通過socket將流傳送給客戶端的stub； 
8、stub在接收到流後反序列化，將反序列化後的Java Object返回給調用者。

來看jboss-remoting對於此過程的一個更好的圖示：  

根據原理來回答下之前學習應用級協議帶着的幾個問題：

1、傳輸的標準格式是什麼？ 
是Java ObjectStream。 
2、怎麼樣將請求轉化爲傳輸的流？ 
基於Java串行化機制將請求的java object信息轉化爲流。 
3、怎麼接收和處理流？ 
根據採用的協議啓動相應的監聽端口，當有流進入後基於Java串行化機制將流進行反序列化，並根據RMI協議獲取到相應的處理對象信息，進行調用並處理，處理完畢後的結果同樣基於java串行化機制進行返回。 
4、傳輸協議是？ 
Socket。 

 XML-RPC

XML- RPC也是一種和RMI類似的遠程調用的協議，它和RMI的不同之處在於它以標準的xml格式來定義請求的信息(請求的對象、方法、參數等)，這樣的好處是什麼呢，就是在跨語言通訊的時候也可以使用。 
來看下XML-RPC協議的一次遠程通信過程： 
1、客戶端發起請求，按照XML-RPC協議將請求信息進行填充； 
2、填充完畢後將xml轉化爲流，通過傳輸協議進行傳輸； 
3、接收到在接收到流後轉換爲xml，按照XML- RPC協議獲取請求的信息並進行處理； 
4、處理完畢後將結果按照XML-RPC協議寫入xml中並返回。

圖示以上過程： 

同樣來回答問題：

1、傳輸的標準格式是？ 
標準格式的XML。 
2、怎麼樣將請求轉化爲傳輸的流？ 
將XML轉化爲流。 
3、怎麼接收和處理流？ 
通過監聽的端口獲取到請求的流，轉化爲XML，並根據協議獲取請求的信息，進行處理並將結果寫入XML中返回。
4、傳輸協議是？ 
Http。

Binary-RPC

Binary- RPC看名字就知道和XML-RPC是差不多的了，不同之處僅在於傳輸的標準格式由XML轉爲了二進制的格式。 
同樣來回答問題： 
1、傳輸 的標準格式是？ 
標準格式的二進制文件。 
2、怎麼樣將請求轉化爲傳輸的流？ 
將二進制格式文件轉化爲流。 
3、 怎麼接收和處理流？ 
通過監聽的端口獲取到請求的流，轉化爲二進制文件，根據協議獲取請求的信息，進行處理並將結果寫入二進制文件中返回。 
4、 傳輸協議是？ 
Http。  

 SOAP 
SOAP 原意爲Simple Object Access Protocol，是一個用於分佈式環境的、輕量級的、基於XML進行信息交換的通信協議，可以認爲SOAP是XML RPC的高級版，兩者的原理完全相同，都是http+XML，不同的僅在於兩者定義的XML規範不同，SOAP也是Webservice採用的服務調用協議標準，因此在此就不多加闡述了。 

CORBA 
Common Object Request Broker Architecture（公用對象請求代理[調度]程序體系結構），是一組用來定義“分佈式對象系統”的標準，由OMG(Object Menagement Group)作爲發起和標準制定單位。CORBA的目的是定義一套協議，符合這個協議的對象可以互相交互，不論它們是用什麼樣的語言寫的，不論它們運行於什麼樣的機器和操作系統。 
CORBA在我看來是個類似於SOA的體系架構，涵蓋可選的遠程通信協議，但其本身不能列入通信協議這裏來講，而且 CORBA基本淘汰，在此就不進行闡述了。

JMS

JMS是實現java領域遠程通信的一種手段和方法，基於JMS實現遠程通信時和RPC是不同的，雖然可以做到RPC的效果，但因爲不是從協議級別定義的，因此不認爲JMS是個RPC協議，但它確實是個遠程通信協議，在其他的語言體系中也存在着類似JMS的東西，可以統一的將這類機制稱爲消息機制，而消息機制通常是高併發、分佈式領域推薦的一種通信機制，這裏的主要一個問題是容錯。

來看JMS中的一次遠程通信的過 程： 
1、客戶端將請求轉化爲符合JMS規定的Message； 
2、通過JMS API將Message放入JMS Queue或Topic中； 
3、如爲JMS Queue，則發送中相應的目標Queue中，如爲Topic，則發送給訂閱了此Topic的JMS Queue。 
4、處理端則通過輪訓JMS Queue，來獲取消息，接收到消息後根據JMS協議來解析Message並處理。

回答問題： 
1、傳輸的標準格式是？ 
JMS規定的Message。 
2、怎麼樣將請求轉化爲傳輸的流？ 
將參數信息放入Message中即可。 
3、怎麼接收和處理流？ 
輪訓JMS Queue來接收Message，接收到後進行處理，處理完畢後仍然是以Message的方式放入Queue中發送或Multicast。 
4、傳 輸協議是？ 
不限。 
基於JMS也是常用的實現遠程異步調用的方法之一。 

JBoss-Remoting

Jboss- remoting是由jboss編寫的一個java領域的遠程通訊框架，基於此框架，可以很簡單的實現基於多種傳輸協議的java對象的RPC。

回答問題： 
1、是基於什麼協議實現的？ 
JBoss-Remoting是個通訊框架，因此它支持多種協議方式的通信，例如純粹的socket+io方式、rmi方式、http+io方式等。 
2、 怎麼發起請求？ 
在JBoss-Remoting中，只需將需要發起的請求參數對象傳入jboss-remoting的InvocationRequest對象即可，也可根據協議基於InvocationRequest封裝符合需求的InvocationRequest對象。 
3、怎麼將請求轉化爲符合協議的格式 的？ 
JBoss-Remoting基於Java串行化機制或JBoss自己的串行化實現來將請求轉化爲對象字節流。 
4、使用 什麼傳輸協議傳輸？ 
支持多種傳輸協議，例如Socket、HTTP等。 
5、響應端基於什麼機制來接收請求？ 
響應端只需將自己的處理對象註冊到JBoss-Remoting提供的Server端的Connector對象中即可。 
6、怎麼將流還原爲傳輸格式的？ 
JBoss-Remoting基於java串行化機制或jboss自己的串行化實現來將請求信息還原爲java對象。 
7、處理完畢後怎麼迴應？ 
處理完畢後將結果對象直接返回即可，jboss-remoting會將此對象按照協議進行序列化，返回至調用端。

另外，jboss- remoting支持多種通信方式，例如同步/異步/單向通信等。 

Spring-Remoting

Spring- remoting是Spring提供java領域的遠程通訊框架，基於此框架，同樣也可以很簡單的將普通的spring bean以某種遠程協議的方式來發布，同樣也可以配置spring bean爲遠程調用的bean。

1、是基於什麼協議實現的？ 
和JBoss-Remoting一樣，作爲一個遠程通訊的框架，Spring通過集成多種遠程通訊的Library，從而實現了對多種協議的支持，例如 rmi、http+io、xml-rpc、binary-rpc等。 
2、怎麼發起請求？ 
在Spring中，由於其對於遠程調用的bean採用的是proxy實現，發起請求完全是通過服務接口調用的方式。 
3、怎麼將請求轉化爲符合協議的格式的？ 
Spring按照協議方式將請求的對象信息轉化爲流，例如Spring Http Invoker是基於Spring自己定義的一個協議來實現的，傳輸協議上採用的爲http，請求信息是基於java串行化機制轉化爲流進行傳輸。 
4、使用什麼傳輸協議傳輸？ 
支持多種傳輸協議，例如RMI、HTTP等。 
5、響應端基於什麼機制來接收請求？ 
響應端遵循協議方式來接收請求，對於使用者而言，則只需通過Spring的配置方式將普通的Spring Bean配置爲響應端或者說提供服務端。 
6、 怎麼將流還原爲傳輸格式的？ 
按照協議方式來進行還原。 
7、處理完畢後怎麼迴應？ 
處理完畢後直接返回即可，spring-remoting將根據協議方式來做相應的序列化。 

Hessian

Hessian 是由caucho提供的一個基於binary-RPC實現的遠程通訊Library。 
1、是基於什麼協議實現的？ 
基於Binary-RPC協議實現。 
2、怎麼發起請求？ 
需通過Hessian本身提供的API來發起請求。 
3、怎麼將請求轉化爲符合協議的格式的？ 
Hessian通過其自定義的串行化機制將請求信息進行序列化，產生二進制流。 
4、使用什麼傳輸協議傳輸？ 
Hessian基於HTTP協議進行傳輸。 
5、響應端基於什麼機制來接收請求？ 
響應端根據Hessian提供的API來接收請求。 
6、怎麼將流還原爲傳輸格式的？ 
Hessian根據其私有的串行化機制來將請求信息進行反序列化，傳遞給使用者時已是相應的請求信息對象了。 
7、處理完畢後怎麼迴應？ 
處理完畢後直接返回，Hessian將結果對象進行序列化，傳輸至調用端。 

Burlap

Burlap 也是有caucho提供，它和hessian的不同在於，它是基於XML-RPC協議的。 
1、是基於什麼協議實現的？ 
基於XML-RPC協議實現。 
2、怎麼發起請求？ 
根據Burlap提供的API。 
3、怎麼將請求轉化爲符合協議的格 式的？ 
將請求信息轉化爲符合協議的XML格式，轉化爲流進行傳輸。 
4、使用什麼傳輸協議傳輸？ 
Http協議。 
5、響應端基於什麼機制來接收請求？ 
監聽Http請求。 
6、怎麼將流還原爲傳輸格式的？ 
根據XML-RPC協議進行還原。 
7、處理完畢後怎麼迴應？ 
返回結果寫入XML中，由Burlap返回至調用端。 

XFire、 Axis

XFire、Axis是Webservice的實現框架，WebService可算是一個完整的SOA架構實現標準了，因此採用 XFire、Axis這些也就意味着是採用webservice方式了。 
1、是基於什麼協議實現的？ 
基於SOAP協議。 
2、 怎麼發起請求？ 
獲取到遠端service的proxy後直接調用。 
3、怎麼將請求轉化爲符合協議的格式的？ 
將請求信息轉化爲遵循SOAP協議的XML格式，由框架轉化爲流進行傳輸。 
4、使用什麼傳輸協議傳輸？ 
HTTP協議。 
5、 響應端基於什麼機制來接收請求？ 
監聽HTTP請求。 
6、怎麼將流還原爲傳輸格式的？ 
根據SOAP協議進行還原。 
7、處理完畢後怎麼迴應？ 
返回結果寫入XML中，由框架返回至調用端。 

ActiveMQ

ActiveMQ 是JMS的實現，基於JMS這類消息機制實現遠程通訊是一種不錯的選擇，畢竟消息機制本身的功能使得基於它可以很容易的去實現同步/異步/單向調用等，而且消息機制從容錯角度上來說也是個不錯的選擇，這是Erlang能夠做到容錯的重要基礎。 
1、是基於什麼協議實現的？ 
基於JMS協議。 
2、怎麼發起請求？ 
遵循JMS API發起請求。 
3、怎麼將請求轉化爲符合協議的格式的？ 
應該是二進制流（不確定）。 
4、使用什麼傳輸協議傳輸？ 
支持多種傳輸協議，例如socket、http等等。 
5、 響應端基於什麼機制來接收請求？ 
監聽符合協議的端口。 
6、怎麼將流還原爲傳輸格式的？ 
同問題3。 
7、 處理完畢後怎麼迴應？ 
遵循JMS API生成消息，並寫入JMS Queue中。 、

基於JMS此類機制實現遠程通訊的例子有 Spring-Intergration、Mule、Lingo等等。 

Mina

Mina 是Apache提供的通訊框架，在之前一直沒有提到網絡IO這塊，之前提及的框架或Library基本都是基於BIO的，而Mina是採用NIO 的，NIO在併發量增長時對比BIO而言會有明顯的性能提升，而java性能的提升，與其NIO這塊與OS的緊密結合是有不小的關係的。

1、是基於什麼協議實現的？ 
基於純粹的Socket+NIO。 
2、怎麼發起請求？ 
通過Mina提供的Client API。 
3、怎麼將請求轉化爲符合協議的格式的？ 
Mina遵循java串行化機制對請求對象進行序列化。 
4、使用什麼傳輸協議傳輸？ 
支持多種傳輸協議，例如Socket、HTTP等等。 
5、響應端基於什麼機制來接收請求？ 
以NIO的方式監聽協議端口。 
6、 怎麼將流還原爲傳輸格式的？ 
遵循Java串行化機制對請求對象進行反序列化。 
7、處理完畢後怎麼迴應？ 
遵循Mina API進行返回。 
MINA是NIO方式的，因此支持異步調用是毫無懸念的。 

EJB

EJB 最突出的在於其分佈式，EJB採用的是ORMI協議，和RMI協議是差不多的，但EJB在分佈式通訊的安全控制、transport pool、smart proxy等方面的突出使得其在分佈式領域是不可忽視的力量。 
1、是基於什麼協議實現的？ 
基於ORMI協議。 
2、怎麼發起請求？ 
EJB調用。 
3、怎麼將請求轉化爲符合協議的格式的？ 
遵循java串行化機制對請求對象進行序列化。 
4、使用什麼傳輸協議傳輸？ 
Socket。 
5、響應端基於什麼機制來接收請求？ 
監聽協議端口。 
6、怎麼將流還原爲傳輸格式的？ 
遵循java串行化機制對請求對象進行反序列化。 
7、處理完畢後怎麼迴應？ 
直接返回處理對象即可。 

【JBOSS的JNDI的實現】

在將對象實例綁定到jboss jnp server後，當遠程端採用context.lookup()方式獲取遠程對象實例並開始調用時，jboss jndi的實現方法是從jnp server上獲取對象實例，將其序列化回本地，然後在本地進行反序列化，之後在本地進行類調用。

通過這個機制就可以知道，本地其實是必須有綁定到jboss上的對象實例的class的，否則反序列化的時候肯定就失敗了，而遠程通訊需要做到的是在遠程執行某動作，並獲取到相應的結果，可見純粹基於JNDI是無法實現遠程通訊的。

但JNDI也是實現分佈式服務框架一個很關鍵的技術點，因爲可以通過它來實現透明化的遠端和本地調用，就像 EJB，另外它也是個很好的隱藏實際部署機制（就像datasource）等的方案。

總結

由上一系列的分析可知，在遠程通訊領域中，涉及的知識點還是相當的多的，例如有：通信協議(Socket/tcp/http/udp /rmi/xml-rpc etc.)、消息機制、網絡IO（BIO/NIO/AIO）、MultiThread、本地調用與遠程調用的透明化方案（涉及java classloader、Dynamic Proxy、Unit Test etc.）、異步與同步調用、網絡通信處理機制（自動重連、廣播、異常、池處理等）、Java Serialization (各種協議的私有序列化機制等)、各種框架的實現原理（傳輸格式、如何將傳輸格式轉化爲流的、如何將請求信息轉化爲傳輸格式的、如何接收流的、如何將流還原爲傳輸格式的等等），要精通其中的哪些東西，得根據實際需求來決定，只有在瞭解了原理的情況下才能很容易的做出選擇，甚至可以根據需求做私有的遠程通訊協議。

參考鏈接1：https://blog.csdn.net/zxy131072/article/details/90373442

參考鏈接2：https://www.cnblogs.com/cyruswang/p/4577295.html

參考鏈接3：https://www.cnblogs.com/zkwarrior/p/5939213.html