dubbo傳輸協議基於自定義報文的tcp協議。
首先要否認一點 http 協議相較於自定義tcp報文協議，增加的開銷在於連接的建立與斷開。http協議是支持連接池複用的，也就是建立一定數量的連接不斷開，並不會頻繁的創建和銷燬連接。
（1）http和rpc的最終差異還是傳輸協議：
通用定義的http1.1協議的tcp報文包含太多廢信息，一個POST協議的格式大致如下
HTTP/1.0 200 OK
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84
this is message
即使編碼協議也就是body是使用二進制編碼協議，報文元數據也就是header頭的鍵值對卻用了文本編碼，非常佔字節數。如上圖所使用的報文中有效字節數僅僅佔約 30%，也就是70%的時間用於傳輸元數據廢編碼。當然實際情況下報文內容可能會比這個長，但是報頭所佔的比例也是非常可觀的。
zookeeper://zkOS:2181/org.apache.dubbo.registry.RegistryService?application=demo-consumer&dubbo=2.0.2&interface=org.apache.dubbo.registry.RegistryService&pid=73783&qos.port=33333×tamp=1590331408270
採用tcp協議的rpc來進行通信相當於節省了多餘的數據，傳輸效率更高
（2）同步調用與異步調用
什麼是同步調用？什麼是異步調用？同步調用就是客戶端等待調用執行完成並返回結果。異步調用就是客戶端不等待調用執行完成返回結果，不過依然可以通過回調函數等接收到返回結果的通知。如果客戶端並不關心結果，則可以變成一個單向的調用。這個過程有點類似於Java中的callable和runnable接口，我們進行異步執行的時候，如果需要知道執行的結果，就可以使用callable接口，並且可以通過Future類獲取到異步執行的結果信息。如果不關心執行的結果，直接使用runnable接口就可以了，因爲它不返回結果，當然啦，callable也是可以的，我們不去獲取Future就可以了。
（3）根據企業的大小去選擇
HTTP服務
其實在很久以前，我對於企業開發的模式一直定性爲HTTP接口開發，也就是我們常說的RESTful風格的服務接口。的確，對於在接口不多、系統與系統交互較少的情況下，解決信息孤島初期常使用的一種通信手段；優點就是簡單、直接、開發方便。利用現成的http協議進行傳輸。我們記得之前本科實習在公司做後臺開發的時候，主要就是進行接口的開發，還要寫一大份接口文檔，嚴格地標明輸入輸出是什麼？說清楚每一個接口的請求方法，以及請求參數需要注意的事項等。比如下面這個例子：
POST http://www.httpexample.com/restful/buyer/info/share
接口可能返回一個JSON字符串或者是XML文檔。然後客戶端再去處理這個返回的信息，從而可以比較快速地進行開發。但是對於大型企業來說，內部子系統較多、接口非常多的情況下，RPC框架的好處就顯示出來了，首先就是長鏈接，不必每次通信都要像http一樣去3次握手什麼的，減少了網絡開銷；其次就是RPC框架一般都有註冊中心，有豐富的監控管理；發佈、下線接口、動態擴展等，對調用方來說是無感知、統一化的操作。
參考：https://blog.csdn.net/wangyunpeng0319/article/details/78651998