哈嘍大家好，我是鹹魚 隨著互聯網技術的發展，分散式架構越來越被人們所採用。在分散式架構下，**為了實現複雜的業務邏輯，應用程式需要分散式通信實現遠程調用** 而這時候就需要一種協議來支持遠程過程調用，以便實現不同應用程式之間的數據交換和信息傳遞。其中常用的協議包括 HTTP 協議和 RPC 協議 H ...
哈嘍大家好，我是鹹魚
隨著互聯網技術的發展，分散式架構越來越被人們所採用。在分散式架構下，為了實現複雜的業務邏輯，應用程式需要分散式通信實現遠程調用
而這時候就需要一種協議來支持遠程過程調用，以便實現不同應用程式之間的數據交換和信息傳遞。其中常用的協議包括 HTTP 協議和 RPC 協議
HTTP 協議和 RPC 協議都是用於電腦之間進行通信的協議。那麼小伙伴們有沒有想過它們之間有什麼區別呢？有了HTTP為什麼還要RPC呢？
為瞭解答上面的疑問，我們先從這兩個協議的介紹開始
HTTP 和 RPC
- HTTP
學過電腦網路的小伙伴們相信對下麵這段話再熟悉不過了：
HTTP（HyperText Transfer Protocol，超文本傳輸協議）協議，主要用於在 Web 瀏覽器和 Web 伺服器（B/S架構）之間傳輸超文本標記語言（HTML）文件，支持客戶端和伺服器之間的通信
HTTP 協議是網路傳輸協議中應用最為廣泛的一種，HTTP 協議基於請求/響應模型，通過在客戶端和伺服器之間交換請求和響應來傳輸數據。
它簡單、靈活、可擴展，而且最重要的是——它是一種無狀態協議，也就是說，每次客戶端和伺服器之間交換請求和響應時，HTTP協議都是一張白紙，不會記住之前的任何信息
而無狀態協議重要的一點優勢是可靠，即使某個請求失敗或者丟失，也不會影響到其他請求的處理
HTTP 協議使用文本格式進行傳輸，方便開發人員去閱讀和調試，又因具有可跨平臺、可擴展、可緩存、可重用等優點被廣泛應用於 Web 開發中，常用於網頁訪問、圖片載入等場景
看到這裡，小伙伴可能會想，HTTP 這麼神，它真的就一點缺點沒有嗎？當然肯定是有的
前面我們說到 HTTP 協議是無狀態的，也就是說每次請求和響應之間是沒有關聯的，伺服器不會記住之前的任何信息，所以會導致每次請求都要重新建立連接
在處理一些長連接或高併發的場景時，每次請求都需要重新建立連接，而這個過程不但會增加了網路開銷和延遲，還會消耗伺服器的資源，從而降低了效率。如果使用有狀態的協議，伺服器可以記住之前的信息，避免了重覆建立連接的過程
除此之外，因為 HTTP 協議最初設計的目的是為了在客戶端和伺服器之間傳輸 HTML 文檔，即數據傳輸格式是基於文本的
所以說 HTTP 協議不支持類型化的數據傳輸和自定義協議擴展，請求和響應的格式是固定的，這就導致了它不能很好地支持自定義數據結構和複雜邏輯
簡單來說，HTTP 協議有點“死板”
- RPC
RPC（Remote Procedure Call，遠程過程調用）協議是一種進程間通信協議，用於實現分散式應用程式之間的遠程調用，使得不同的應用程式可以像調用本地程式一樣調用遠程程式
RPC 協議基於函數調用模型。在 RPC 協議中，客戶端調用遠程伺服器上的函數時，會將參數打包成消息併發送給伺服器，伺服器接收到消息後，解包參數並執行相應的函數，最後將結果打包成消息併發送回客戶端、
這這個過程對於客戶端來說是透明的，就像調用本地函數一樣，即 RPC 可以實現在不同的進程或不同的機器之間進行函數調用
它具有網路傳輸速度快、協議擴展性好等優點（因為採用了二進位數據傳輸格式，相對於HTTP等基於文本的協議，二進位格式傳輸數據更加高效）。不但如此，RPC 的設計初衷就是支持多種數據格式和傳輸協議，這使得它可以很好地支持複雜的數據結構和邏輯
此外，RPC 協議可以使用更高效的編碼和傳輸協議，還可以使用非同步調用來提高響應速度
我們常說，世上沒有完美的東西，HTTP 如此，RPC 也是如此
與 HTTP 相比，RPC 更加複雜。為了實現 RPC 協議的設計目標（高效、靈活和可擴展），它需要定義更多的介面和協議，同時需要更多的配置和管理。當然這會提高開發和運維的難度
為了支持跨語言、跨平臺的遠程調用，RPC 通常不包含安全機制。如果不採取額外的安全措施，就有可能存在身份偽造、數據篡改、拒絕服務等安全問題
為了保護網路安全，我們可以在 RPC 中實現額外的安全措施：
- 例如使用SSL/TLS協議進行加密通信
- 使用數字證書進行身份驗證
- 使用訪問控制列表進行授權
- 進行安全審計和漏洞掃描
前面我們說到，RPC 通常採用二進位數據傳輸格式，而不是基於文本的格式。二進位格式雖然傳輸效率高，但是需要額外的計算資源來序列化和反序列化參數和返回值
在 RPC 中，客戶端和伺服器之間需要將參數和返回值打包成二進位數據，併在網路上傳輸。這個過程需要將參數和返回值轉換為二進位格式，併進行壓縮和編碼，以減少數據傳輸量
對於接收方，需要將接收到的二進位數據解碼並轉換為原始數據格式。這個過程需要消耗額外的計算資源
因此，RPC需要額外的網路帶寬和計算資源來序列化和反序列化參數和返回值
HTTP 和 RPC 的區別
- 目的不同
HTTP 是一種無狀態的協議，它的主要目的在客戶端和伺服器之間交換請求和響應來傳輸文本內容
RPC 是一種有狀態的協議，它的主要目的是在客戶端和伺服器之間傳遞信息並調用遠程函數
- 傳輸方式不同
HTTP 使用文本（如 HTML、XML、JSON等）作為載體，並且使用明文傳輸
RPC可以使用多種格式傳輸（例如二進位格式），並且可以使用額外的安全加密技術保證傳輸安全性
- 通信方式不同
HTTP 使用的是請求/響應模型，客戶端向伺服器發送請求並等待響應。客戶端發送一個請求，伺服器返回一個響應
RPC 使用的是調用/返回模型，客戶端調用伺服器上的遠程函數並等待返回結果。RPC 支持多種不同的調用方式，如同步調用、非同步調用、流式調用等
有了 HTTP 為什麼還要 RPC？
雖然 HTTP 已經成為了網路通信的重要標準之一而且被廣泛應用於互聯網上的各種場景，但是在某些情況下，它並不能滿足用戶的需求
例如在一些複雜的分散式應用場景下（分散式系統中的服務調用、微服務架構中的服務間通信等），RPC 協議要比 HTTP 協議更適合
鹹魚將從以下幾點來闡述一下 RPC 為什麼更適合複雜的分散式應用場景
從時效性度來看
- HTTP 協議的數據格式有一定的局限性，比如只能傳輸文本，傳輸效率低下
- HTTP協議是基於請求/響應模型，每次請求都需要建立一個新的連接，這樣會增加網路開銷
- 相比於 HTTP 協議，RPC 協議通常使用二進位數據格式進行傳輸，通常具有更高的傳輸效率和更低的網路延遲
- 相比於 HTTP 協議，RRPC協議還支持非同步調用和批量調用等高級特性，可以提高系統的性能和吞吐量
從安全性來看
- HTTP 是一種文本協議，數據傳輸使用的是明文，這樣就容易被中間人竊聽或者篡改數據（不過可以使用SSL/TLS 協議對數據進行加密和認證）
- 相比於 HTTP 協議，RPC 支持傳輸各種類型的數據（比如二進位），可以更快靈活地傳輸大量數據，並且也可以加密傳輸以保證安全性
從場景複雜度來看
- 在複雜的業務邏輯和數據結構場景下，通常需要進行多次請求和響應操作，而 HTTP 作為無狀態協議無法保持會話狀態，每次請求和響應都需要重新建立連接和傳輸數據，這會導致網路延遲和性能下降
- HTTP協議的請求和響應通常是基於文本或二進位數據格式，無法直接支持複雜的數據結構，例如對象、數組、枚舉等
- 相比於 HTTP 協議，RPC 是一種有狀態協議，而且 RPC 可以通過定義介面和方法來封裝業務邏輯，使得客戶端可以通過簡單的調用來完成複雜的操作
- 相比於 HTTP 協議，RPC協議是一種面向對象的協議，它可以直接支持複雜的數據結構，例如對象、數組、枚舉等
