協(xié)議介紹
協(xié)議是兩個(gè)網(wǎng)絡(luò)實(shí)體進(jìn)行通信的基礎(chǔ)，數(shù)據(jù)在網(wǎng)絡(luò)上從一個(gè)實(shí)體傳輸?shù)搅硪粋€(gè)實(shí)體，以字節(jié)流的形式傳遞到對(duì)端。在這個(gè)字節(jié)流的世界里，如果沒有協(xié)議，就無法將這個(gè)一維的字節(jié)流重塑成為二維或者多維的數(shù)據(jù)結(jié)構(gòu)以及領(lǐng)域?qū)ο蟆?/p>
在通信過程中，不同的服務(wù)等級(jí)一般對(duì)應(yīng)著不同的服務(wù)質(zhì)量，那么選擇合適的協(xié)議便是一件非常重要的事情。你可以根據(jù)你應(yīng)用的創(chuàng)建來選擇。例如，使用RMI協(xié)議，一般會(huì)受到防火墻的限制，所以對(duì)于外部與內(nèi)部進(jìn)行通信的場(chǎng)景，就不要使用RMI協(xié)議，而是基于HTTP協(xié)議或者Hessian協(xié)議。
常見的協(xié)議模式
應(yīng)用層協(xié)議一般的形式有三種：定長協(xié)議、特殊結(jié)束符和協(xié)議頭+payload模式。
從網(wǎng)絡(luò)上以流的形式進(jìn)行數(shù)據(jù)的讀取，需要確定的是一次有意義的傳輸內(nèi)容在讀到何時(shí)結(jié)束，因?yàn)橐粋€(gè)一個(gè)byte傳輸過來，需要有一個(gè)結(jié)束。而且數(shù)據(jù)在網(wǎng)絡(luò)上的傳輸，存在粘包和半包的情況，能夠應(yīng)對(duì)這個(gè)問題的辦法就是協(xié)議能夠準(zhǔn)確的識(shí)別，當(dāng)粘包發(fā)生時(shí)不會(huì)多讀，當(dāng)半包發(fā)生時(shí)會(huì)繼續(xù)讀取。
定長協(xié)議
定長的協(xié)議是指協(xié)議內(nèi)容的長度是固定的，比如協(xié)議byte長度是50，當(dāng)從網(wǎng)絡(luò)上讀取50個(gè)byte后，就進(jìn)行decode解碼操作。定長協(xié)議在讀取或者寫入時(shí)，效率比較高，因?yàn)閿?shù)據(jù)緩存的大小基本都確定了，就好比數(shù)組一樣，缺陷就是適應(yīng)性不足，以RPC場(chǎng)景為例，很難估計(jì)出定長的長度是多少。
可以參考Netty的FixedLengthFrameDecoder
特殊結(jié)束符
相比定長協(xié)議，如果能夠定義一個(gè)特殊字符作為每個(gè)協(xié)議單元結(jié)束的標(biāo)示，就能夠以變長的方式進(jìn)行通信，從而在數(shù)據(jù)傳輸和高效之間取得平衡，比如用特殊字符\n。
特殊結(jié)束符方式的問題是過于簡單的思考了協(xié)議傳輸?shù)倪^程，對(duì)于一個(gè)協(xié)議單元必須要全部讀入才能夠進(jìn)行處理，除此之外必須要防止用戶傳輸?shù)臄?shù)據(jù)不能同結(jié)束符相同，否則就會(huì)出現(xiàn)紊亂。
可以參考Netty的DelimiterBasedFrameDecoder
變長協(xié)議（協(xié)議頭+payload）
一般是自定義協(xié)議，會(huì)以定長加不定長的部分組成，其中定長的部分需要描述不定長的內(nèi)容長度。
+———+
|定長|
+———+
|內(nèi)容|
+———+
可以參考Netty的LengthFieldBasedFrameDecoder
Dubbo支持的協(xié)議
- Dubbo協(xié)議
- Hessian協(xié)議
- HTTP協(xié)議
- RMI協(xié)議
- WebService協(xié)議
- Thrift協(xié)議
- Memcached協(xié)議
- Redis協(xié)議
Dubbo 協(xié)議
Dubbo缺省協(xié)議采用單一長連接和NIO異步通訊，適合于小數(shù)據(jù)量大并發(fā)的服務(wù)調(diào)用，以及服務(wù)消費(fèi)者機(jī)器數(shù)遠(yuǎn)大于服務(wù)提供者機(jī)器數(shù)的情況。Dubbo缺省協(xié)議不適合傳送大數(shù)據(jù)量的服務(wù)，比如傳文件，傳視頻等，除非請(qǐng)求量很低
缺省協(xié)議，使用基于mina1.1.7+hessian3.2.1的tbremoting交互。
連接個(gè)數(shù)：單連接
連接方式：長連接
傳輸協(xié)議：TCP
傳輸方式：NIO異步傳輸
序列化：Hessian二進(jìn)制序列化
適用范圍：傳入傳出參數(shù)數(shù)據(jù)包較小（建議小于100K），消費(fèi)者比提供者個(gè)數(shù)多，單一消費(fèi)者無法壓滿提供者，盡量不要用dubbo協(xié)議傳輸大文件或超大字符串。
適用場(chǎng)景：常規(guī)遠(yuǎn)程服務(wù)方法調(diào)用
Hessian 協(xié)議
Hessian協(xié)議用于集成Hessian的服務(wù)，Hessian底層采用Http通訊，采用Servlet暴露服務(wù)，Dubbo缺省內(nèi)嵌Jetty作為服務(wù)器實(shí)現(xiàn)基于Hessian的遠(yuǎn)程調(diào)用協(xié)議。
連接個(gè)數(shù)：多連接
連接方式：短連接
傳輸協(xié)議：HTTP
傳輸方式：同步傳輸
序列化：Hessian二進(jìn)制序列化
適用范圍：傳入傳出參數(shù)數(shù)據(jù)包較大，提供者比消費(fèi)者個(gè)數(shù)多，提供者壓力較大，可傳文件
適用場(chǎng)景：頁面?zhèn)鬏敚募鬏敚蚺c原生hessian服務(wù)互操作
HTTP 協(xié)議
采用Spring的HttpInvoker實(shí)現(xiàn)
基于http表單的遠(yuǎn)程調(diào)用協(xié)議
連接個(gè)數(shù)：多連接
連接方式：短連接
傳輸協(xié)議：HTTP
傳輸方式：同步傳輸
序列化：表單序列化（JSON）
適用范圍：傳入傳出參數(shù)數(shù)據(jù)包大小混合，提供者比消費(fèi)者個(gè)數(shù)多，可用瀏覽器查看，可用表單或URL傳入?yún)?shù)，暫不支持傳文件
適用場(chǎng)景：需同時(shí)給應(yīng)用程序和瀏覽器JS使用的服務(wù)。
RMI 協(xié)議
RMI協(xié)議采用JDK標(biāo)準(zhǔn)的java.rmi.*實(shí)現(xiàn)，采用阻塞式短連接和JDK標(biāo)準(zhǔn)序列化方式
Java標(biāo)準(zhǔn)的遠(yuǎn)程調(diào)用協(xié)議
連接個(gè)數(shù)：多連接
連接方式：短連接
傳輸協(xié)議：TCP
傳輸方式：同步傳輸
序列化：Java標(biāo)準(zhǔn)二進(jìn)制序列化
適用范圍：傳入傳出參數(shù)數(shù)據(jù)包大小混合，消費(fèi)者與提供者個(gè)數(shù)差不多，可傳文件。
適用場(chǎng)景：常規(guī)遠(yuǎn)程服務(wù)方法調(diào)用，與原生RMI服務(wù)互操作
WebService 協(xié)議
基于CXF的frontend-simple和transports-http實(shí)現(xiàn)
基于WebService的遠(yuǎn)程調(diào)用協(xié)議
連接個(gè)數(shù)：多連接
連接方式：短連接
傳輸協(xié)議：HTTP
傳輸方式：同步傳輸
序列化：SOAP文本序列化
適用場(chǎng)景：系統(tǒng)集成，跨語言調(diào)用。
Thrift 協(xié)議
Thrift是一個(gè)輕量級(jí)、跨語言的遠(yuǎn)程服務(wù)調(diào)用框架，最初由Facebook開發(fā)，后面進(jìn)入Apache開源項(xiàng)目。它通過自身的IDL中間語言, 并借助代碼生成引擎生成各種主流語言的RPC服務(wù)端/客戶端模板代碼。
當(dāng)前 dubbo 支持的 thrift 協(xié)議是對(duì) thrift 原生協(xié)議的擴(kuò)展，在原生協(xié)議的基礎(chǔ)上添加了一些額外的頭信息，比如service name，magic number等。
