原文地址：http://hi.baidu.com/qianjian21/item/2f712dd4c1e81cbb33db90b1

總體性能比較：
Socket(BIO/NIO)>RMI>HTTPInvoker>=Hessian>REST>>Burlap>EJB>>Web Service

1.socket

如 果協議設計的比較好，Socket性能毫無疑問是最高，同時靈活性和復雜度也最高，如果采用高效的網絡框架如:Mina、Netty等可以降低開發復雜 度，一般在對性能有非常苛刻的條件下使用。

2.RMI

RMI的性能相對略低，但是與Socket還在同1個數量級，同時只能在Java系統間通信，如果是基于互聯網使用，還存在穿越防火墻的問題。采用 Spring封裝的方式使用比原始RMI方式性能略高，主要原因是：Spring采用了代理和緩存機制，節省了對象重新獲取的時間。

3.HTTPInvoker

HTTPInvoker是Spring特有的，只能在客戶端和服務器端都采用Spring框架下使用，與RMI本質相同，使用java的序列化技術傳輸對 象，兩者性能差別較小。

4.Hessian

Hessian在數據量較小時性能表現出眾，甚至比RMI還高，在數據結構復雜的對象或者大量數據對象時，較RMI要慢20%左右；

Hessian的優點 是精簡高效，同時可以跨語言使用，目前支持Java,C++, .net, python, ruby等語言。

另外Hessian可以充分利用web容器的成熟功能，在處理大量用戶訪問時很有優勢，在資源分配、線程排隊、異常處理等方面都可以由 web容器保證，而RMI本身不提供多線程的服務器。

5.REST

REST架構也是一種比較簡單、高效的Web服務架構，相對于Hessian性能略低，但還在同一個數量級，同時也是基于HTTP協議，目前也有比較多的 成功案例。

6.Burlap

Burlap在數據量非常小時性能尚可，同時性能隨著數據量的增加急劇降低，通常性能耗時是RMI的3倍左右，主要原因是：Hessian采用二進制傳輸 數據，而Burlap采用XML格式，而XML描述內容太多，同樣的結構，其傳輸量要大很多，同時，XML的解析是比較耗資源的，尤其大數據量情況下更是 如此。

7.EJB

EJB基于RMI協議，性能不高，同時只能在Java系統內使用，不能跨語言，目前使用越來越少，目前阿里巴巴內部已經完全放棄EJB。

8.Web Service

在這些遠程調用協議中，Web Service的性能是最低的，一般情況下，Web Service的性能相對于Hessian性能要慢10~20倍左右，同時，對于同樣的訪問請求，Web Service的傳輸數據量約為Hessian的6倍左右，對網絡帶寬消耗非常大，同時XML的解碼器普遍性能不高，XML<->Java Bean的編碼、解碼非常耗費資源，對于并發和負載比較高的網站不是一個好的選擇。同時，Web Service的使用也不太方便。

總結：Hessian和REST架構個人認為是比較優秀的高性能通信協議，如果對性能要求特別苛刻可以直接采用Socket方式，目前，阿里巴巴內部的遠程調用主要采用Hessian和Dubbo(基于Mina框架)，經受了苛刻的高并發、高負載考驗。

主要幾種協議遠程調用消耗大致時間(小數據量)：
Socket/RMI/Hessian: 0.5ms
REST:0.7ms
Web Service(Axis): 約10ms，其中如果采用wsdl2java的方式，效率更低些。

Socket/RMI/Hessian/REST之間選擇還需要在傳輸數據量，性能要求等各方面考量，合適的場景選擇合適的協議

轉載于:https://www.cnblogs.com/davidwang456/archive/2013/04/02/2995420.html

總結

以上是生活随笔為你收集整理的主要几种通信协议的性能比较(转载)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。