前言

上一篇提到微服務的興起是RSocket誕生的重要契機，相信有微服務開發經驗的朋友，在微服務切分耦合與實際上的效能問題如何抉擇傷透腦筋，服務間的溝通效率不彰是微服務一大痛點，HTTP協議本身是為了服務與客戶端之間的溝通而誕生，這篇就來探討RSocket與其他協定的差別。

HTTP

我們最熟悉的Http協定，OSI第7層，最初是用來發布或接收Html頁面的方法，定義客戶端與服務端之間的request/response的標準。

HTTP/1.1

建立連線需要成本，1.1提供Connection: keep-alive來幫助持續連接，減少建立與關閉連線的時間延遲。且不需要等待上一次的結果就可以發送下一個請求。並定義了現在常見的GET、POST、PUT...八種Http Medthod。

HTTP/2

在效能方便進一步的加強，增加了伺服器推送功能、壓縮HEAD增加傳輸速度、將多個請求合併在一個TCP(Multiplexing)而不是單獨占用一條TCP connection、改用二進位而非原本的文本格式......等等大幅的增加網頁的載入速度。

websocket

聽到RSocket的時候我其實第一個想到就是websocket，與Http相同是OSI第7層，有別於單向短連接的http協定，websocket提供一個成本較低服務與客戶端互動長連接的方式，相對於http當時可能需要透過Polling輪詢的方式才能辦到，而且又效能低下。

gRPC

建立於HTTP/2之上，為了適用於服務之間多語言的溝通，內文是透過Protobuf一種有效率的二進位訊息格式來傳輸，相對於原本的HTTP提高了效率。相對於常用的RESTful可以更充分的運用HTTP/2的優點。對於長連線與雙向的溝通都有支援。

HTTP VS RSocket

1. HTTP設計用於服務與瀏覽器溝通，RSocket則是為了微服務之間的溝通
2. HTTP是單向，需要升級到Websocket才能建立雙向的溝通，RSocket有效的建立雙向溝通。
3. HTTP並沒有強制規定應用層的格式，雖然有RESTful但並不是強制要求，像是gRPC就是建立於HTTP/2但有強制要求，RSocket定義了兩種應用層得流程控制(flow control)，Reactive Streams request(n) Async Pull & Leasing(註1)
4. HTTP只有一種request response，RSocket有四種，更能應對不同的使用場景。

websocket VS RSocket

1. WebSocket只是一個框架，RSocket更完整。

gRPC VS RSocket

1. gRPC為OSI第7層，RSocket是第5/6層。
2. gRPC有自己特定的payload，RSocket沒有特別指定。
3. gRPC建立於HTTP/2之上只適用HTTP/2的情境，RSocket可以是TCP、檔案或是WebSockets。
4. gRP沒有獲得所有的瀏覽器支援，需要額外的程式碼，RSocket只需要接受WebSockets連線就可以暢行各瀏覽器。

圖片來源：Toshiaki Maki, Staff Cloud Native Architect at VMware

補充說明

註1 Flow Control

1. Reactive Streams request(n) Async Pull ：就是基於我們之前介紹過的Reactive Streams透過Subscription.request(n)來建立訂閱者與發佈者之間的溝通，具體會由Reactor、RxJava或是Akka Streams來實作，可以在應用層去控制資料傳送的速率而不單單靠網路緩衝，適用於服務與服務或是服務與裝置之間。
2. Leasing：適用於服務與服務之間，server端要評估自己能負荷的空間給client端達到控制速率的效果，也就是client端可以使用特定邏輯的負載平衡演算法(load-balancing algorithms)來選擇最佳的server端，範例推薦閱讀簡書。

結語

其實提高效能還有一個顯著的優點，就是可以降低硬體的成本，主管看到雲端服務的帳單比較不會吐血。

資料來源