為什么有了HTTP，還需要RPC協(xié)議？

為什么有了HTTP，還需要RPC協(xié)議呢？在進(jìn)行說明之前，首先我們需要了解什么是HTTP協(xié)議，什么是RPC協(xié)議。

什么是HTTP協(xié)議？

HTTP是一種廣泛使用的網(wǎng)絡(luò)傳輸協(xié)議，它定義了客戶端（如瀏覽器， 手機(jī)用戶APP等）和服務(wù)器（網(wǎng)站等提供服務(wù)的，服務(wù)端）之間的通信格式和通信方法，它是基于請求—響應(yīng)這樣一種通信模型，即服務(wù)端根據(jù)請求返回一個(gè)響應(yīng)，在請求和響應(yīng)中，都包含了兩端（客戶端和服務(wù)端）之間進(jìn)行交互的一些信息，如方法、頭部、正文等。

圖1 HTTP交互基本流程圖

HTTP具有很多優(yōu)點(diǎn)，它支持多種數(shù)據(jù)格式和編碼方式，可以實(shí)現(xiàn)跨平臺(tái)和跨語言的通信，通信簡單、靈活、易于擴(kuò)展。但是同時(shí)它也有一些缺點(diǎn)：

（1）HTTP是無狀態(tài)的，每次請求都需要重新建立連接，這會(huì)增加網(wǎng)絡(luò)開銷和延遲。

（2）數(shù)據(jù)傳輸是基于文本的，這會(huì)導(dǎo)致數(shù)據(jù)量較大，解析效率較低。

（3）安全性較差，因此容易受到中間人攻擊、重放攻擊等。

（4）語義較弱，HTTP只能表達(dá)基本的增刪改查操作，不能滿足復(fù)雜的業(yè)務(wù)邏輯。

什么是RPC協(xié)議？

RPC即Remote Procedure Call（遠(yuǎn)程程序調(diào)用），它是一種遠(yuǎn)程過程調(diào)用協(xié)議，它允許客戶端像調(diào)用本地函數(shù)一樣調(diào)用遠(yuǎn)程服務(wù)器上的函數(shù)。

圖2 RPC協(xié)議交互流程

RPC的優(yōu)點(diǎn)是高效、強(qiáng)大、易于使用，但是它也有一些缺點(diǎn)，比如：

（1）與HTTP相反，RPC是有狀態(tài)的，需要維護(hù)客戶端和服務(wù)器之間的連接狀態(tài)，這會(huì)增加系統(tǒng)的復(fù)雜度和資源消耗。

（2）RPC的數(shù)據(jù)傳輸是基于二進(jìn)制的，這會(huì)導(dǎo)致數(shù)據(jù)不易閱讀和調(diào)試。

（3）RPC的兼容性較差，不同的RPC框架之間可能存在協(xié)議和接口的不一致性。

（4）RPC的可擴(kuò)展性較差，難以支持動(dòng)態(tài)服務(wù)發(fā)現(xiàn)和負(fù)載均衡等功能。

二者的選擇使用

基于TCP建立的HTTP和各類RPC協(xié)議，只是定義了不同消息格式的應(yīng)用層協(xié)議。HTTP協(xié)議是超文本傳輸協(xié)議，而RPC本身并不是一個(gè)具體的協(xié)議，而是一種調(diào)用方式。

雖然HTTP現(xiàn)在叫超文本協(xié)議，支持音頻視頻，但HTTP設(shè)計(jì)初主要是用做展示網(wǎng)頁文本，所以它傳輸?shù)膬?nèi)容以字符串為主，內(nèi)容存在非常多的冗余。而RPC協(xié)議定制化程度更高，可以采用體積更小的protobuf或其他序列化協(xié)議去保存結(jié)構(gòu)體數(shù)據(jù)，同時(shí)也不需要像HTTP那樣考慮各種瀏覽器行為，性能更好。因此在公司內(nèi)部微服務(wù)中拋棄HTTP，轉(zhuǎn)而使用RPC協(xié)議。雖然后來HTTP得到了很大的改進(jìn)，但由于很多公司內(nèi)部已經(jīng)用了多年的RPC協(xié)議，基于歷史原因，一般沒有選擇更換成HTTP。

在實(shí)際運(yùn)用中，不論是HTTP還是RPC，它們都有各自的優(yōu)缺點(diǎn)，沒有絕對(duì)的好壞之分。針對(duì)不同的使用場景選擇合適的協(xié)議。比如：

（1）在微服務(wù)架構(gòu)中，服務(wù)之間需要頻繁地進(jìn)行內(nèi)部調(diào)用，RPC可以提供更高的性能和可靠性。

（2）在分布式計(jì)算中，需要將大量的計(jì)算任務(wù)分發(fā)到不同的節(jié)點(diǎn)上執(zhí)行，RPC可以實(shí)現(xiàn)更靈活的負(fù)載均衡和容錯(cuò)機(jī)制。

（3）而在實(shí)時(shí)通信中，需要實(shí)現(xiàn)低延遲和高并發(fā)的數(shù)據(jù)交換，RPC可以支持多種傳輸協(xié)議和通信模式。

而假如你需要實(shí)現(xiàn)跨平臺(tái)和跨語言的通信，或者需要支持多種數(shù)據(jù)格式和編碼方式，或者需要利用現(xiàn)有的HTTP基礎(chǔ)設(shè)施和工具，可以選擇HTTP協(xié)議。

當(dāng)然這樣不是絕對(duì)固定的組合，也可以結(jié)合兩個(gè)協(xié)議來實(shí)現(xiàn)更好的網(wǎng)絡(luò)，例如：

（1）我們可以在HTTP協(xié)議上封裝RPC協(xié)議，使得RPC請求可以通過HTTP代理或者網(wǎng)關(guān)來轉(zhuǎn)發(fā)和處理。

（2）可以在RPC協(xié)議上使用HTTP協(xié)議作為傳輸層，使得RPC請求可以利用HTTP的特性來實(shí)現(xiàn)緩存、壓縮、加密等功能。

所以總的來說，RPC的出現(xiàn)是為了應(yīng)對(duì)HTTP協(xié)議滿足不了的對(duì)性能有所要求的網(wǎng)絡(luò)場景。它們并不是互斥的，而是可以根據(jù)不同的場景和需求進(jìn)行選擇和組合的。