對dubbo的協議的學習，可以知道目前主流RPC通信大概是什么情況，本文參考dubbo官方文檔
http://dubbo.io/User+Guide-zh.htm
dubbo共支持如下幾種通信協議：
dubbo://
rmi://
hessian://
http://
webservice://
thrift://
memcached://
redis://
部分協議的特點和使用場景如下：
1、dubbo協議
Dubbo缺省協議采用單一長連接和NIO異步通訊，適合于小數據量大并發的服務調用，以及服務消費者機器數遠大于服務提供者機器數的情況。
缺省協議，使用基于mina1.1.7+hessian3.2.1的tbremoting交互。連接個數：單連接連接方式：長連接傳輸協議：TCP傳輸方式：NIO異步傳輸序列化：Hessian二進制序列化適用范圍：傳入傳出參數數據包較小（建議小于100K），消費者比提供者個數多，單一消費者無法壓滿提供者，盡量不要用dubbo協議傳輸大文件或超大字符串。適用場景：常規遠程服務方法調用
為什么要消費者比提供者個數多：因dubbo協議采用單一長連接，假設網絡為千兆網卡(1024Mbit=128MByte)，根據測試經驗數據每條連接最多只能壓滿7MByte(不同的環境可能不一樣，供參考)，理論上1個服務提供者需要20個服務消費者才能壓滿網卡。為什么不能傳大包：因dubbo協議采用單一長連接，如果每次請求的數據包大小為500KByte，假設網絡為千兆網卡(1024Mbit=128MByte)，每條連接最大7MByte(不同的環境可能不一樣，供參考)，單個服務提供者的TPS(每秒處理事務數)最大為：128MByte / 500KByte = 262。單個消費者調用單個服務提供者的TPS(每秒處理事務數)最大為：7MByte / 500KByte = 14。如果能接受，可以考慮使用，否則網絡將成為瓶頸。為什么采用異步單一長連接：因為服務的現狀大都是服務提供者少，通常只有幾臺機器，而服務的消費者多，可能整個網站都在訪問該服務，比如Morgan的提供者只有6臺提供者，卻有上百臺消費者，每天有1.5億次調用，如果采用常規的hessian服務，服務提供者很容易就被壓跨，通過單一連接，保證單一消費者不會壓死提供者，長連接，減少連接握手驗證等，并使用異步IO，復用線程池，防止C10K問題。
2、RMI
RMI協議采用JDK標準的java.rmi.*實現，采用阻塞式短連接和JDK標準序列化方式
Java標準的遠程調用協議。連接個數：多連接連接方式：短連接傳輸協議：TCP傳輸方式：同步傳輸序列化：Java標準二進制序列化適用范圍：傳入傳出參數數據包大小混合，消費者與提供者個數差不多，可傳文件。適用場景：常規遠程服務方法調用，與原生RMI服務互操作
3、hessian
Hessian協議用于集成Hessian的服務，Hessian底層采用Http通訊，采用Servlet暴露服務，Dubbo缺省內嵌Jetty作為服務器實現
基于Hessian的遠程調用協議。連接個數：多連接連接方式：短連接傳輸協議：HTTP傳輸方式：同步傳輸序列化：Hessian二進制序列化適用范圍：傳入傳出參數數據包較大，提供者比消費者個數多，提供者壓力較大，可傳文件。適用場景：頁面傳輸，文件傳輸，或與原生hessian服務互操作
4、http
采用Spring的HttpInvoker實現
基于http表單的遠程調用協議。連接個數：多連接連接方式：短連接傳輸協議：HTTP傳輸方式：同步傳輸序列化：表單序列化（JSON）適用范圍：傳入傳出參數數據包大小混合，提供者比消費者個數多，可用瀏覽器查看，可用表單或URL傳入參數，暫不支持傳文件。適用場景：需同時給應用程序和瀏覽器JS使用的服務。
5、webservice
基于CXF的frontend-simple和transports-http實現
基于WebService的遠程調用協議。連接個數：多連接連接方式：短連接傳輸協議：HTTP傳輸方式：同步傳輸序列化：SOAP文本序列化適用場景：系統集成，跨語言調用。
6、thrif
Thrift是Facebook捐給Apache的一個RPC框架，當前 dubbo 支持的 thrift 協議是對 thrift 原生協議的擴展，在原生協議的基礎上添加了一些額外的頭信息，比如service name，magic number等。
