哈嘍大家好，我是鹹魚
隨著網際網路技術的發展，分散式架構越來越被人們所採用。在分散式架構下，為了實現複雜的業務邏輯，應用程式需要分散式通訊實現遠端呼叫
而這時候就需要一種協議來支援遠端過程呼叫，以便實現不同應用程式之間的資料交換和資訊傳遞。其中常用的協議包括 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協議是一種物件導向的協議，它可以直接支援複雜的資料結構，例如物件、陣列、列舉等