我想起了我剛工作的時(shí)候，第一次接觸RPC協(xié)議，當(dāng)時(shí)就很懵，我HTTP協(xié)議用的好好的，為什么還要用RPC協(xié)議？

于是就到網(wǎng)上去搜。

不少解釋顯得非常官方，我相信大家在各種平臺(tái)上也都看到過(guò)，解釋了又好像沒(méi)解釋，都在用一個(gè)我們不認(rèn)識(shí)的概念去解釋另外一個(gè)我們不認(rèn)識(shí)的概念，懂的人不需要看，不懂的人看了還是不懂。

這種看了，又好像沒(méi)看的感覺(jué)，云里霧里的很難受，我懂。

為了避免大家有強(qiáng)烈的審丑疲勞，今天我們來(lái)嘗試重新?lián)Q個(gè)方式講一講。

從TCP聊起

作為一個(gè)程序員，假設(shè)我們需要在A電腦的進(jìn)程發(fā)一段數(shù)據(jù)到B電腦的進(jìn)程，我們一般會(huì)在代碼里使用socket進(jìn)行編程。

這時(shí)候，我們可選項(xiàng)一般也就TCP和UDP二選一。TCP可靠，UDP不可靠。除非是馬總這種神級(jí)程序員（早期QQ大量使用UDP），否則，只要稍微對(duì)可靠性有些要求，普通人一般無(wú)腦選TCP就對(duì)了。

類(lèi)似下面這樣。

fd?=?socket(AF_INET,SOCK_STREAM,0);

其中SOCK_STREAM，是指使用字節(jié)流傳輸數(shù)據(jù)，說(shuō)白了就是TCP協(xié)議。

在定義了socket之后，我們就可以愉快的對(duì)這個(gè)socket進(jìn)行操作，比如用bind()綁定IP端口，用connect()發(fā)起建連。

握手建立連接流程

在連接建立之后，我們就可以使用send()發(fā)送數(shù)據(jù)，recv()接收數(shù)據(jù)。

光這樣一個(gè)純裸的TCP連接，就可以做到收發(fā)數(shù)據(jù)了，那是不是就夠了？

不行，這么用會(huì)有問(wèn)題。

使用純裸TCP會(huì)有什么問(wèn)題

八股文常背，TCP是有三個(gè)特點(diǎn)，面向連接、可靠、基于字節(jié)流。

TCP是什么

這三個(gè)特點(diǎn)真的概括的非常精辟，這個(gè)八股文我們沒(méi)白背。

每個(gè)特點(diǎn)展開(kāi)都能聊一篇文章，而今天我們需要關(guān)注的是基于字節(jié)流這一點(diǎn)。

字節(jié)流可以理解為一個(gè)雙向的通道里流淌的數(shù)據(jù)，這個(gè)數(shù)據(jù)其實(shí)就是我們常說(shuō)的二進(jìn)制數(shù)據(jù)，簡(jiǎn)單來(lái)說(shuō)就是一大堆 01 串。純裸TCP收發(fā)的這些 01 串之間是沒(méi)有任何邊界的，你根本不知道到哪個(gè)地方才算一條完整消息。

01二進(jìn)制字節(jié)流

正因?yàn)檫@個(gè)沒(méi)有任何邊界的特點(diǎn)，所以當(dāng)我們選擇使用TCP發(fā)送"夏洛"和"特?zé)?的時(shí)候，接收端收到的就是"夏洛特?zé)?，這時(shí)候接收端沒(méi)發(fā)區(qū)分你是想要表達(dá)"夏洛"+"特?zé)?還是"夏洛特"+"煩惱"。

消息對(duì)比

這就是所謂的粘包問(wèn)題，之前也寫(xiě)過(guò)一篇專門(mén)的文章聊過(guò)這個(gè)問(wèn)題。

說(shuō)這個(gè)的目的是為了告訴大家，純裸TCP是不能直接拿來(lái)用的，你需要在這個(gè)基礎(chǔ)上加入一些自定義的規(guī)則，用于區(qū)分消息邊界。

于是我們會(huì)把每條要發(fā)送的數(shù)據(jù)都包裝一下，比如加入消息頭，消息頭里寫(xiě)清楚一個(gè)完整的包長(zhǎng)度是多少，根據(jù)這個(gè)長(zhǎng)度可以繼續(xù)接收數(shù)據(jù)，截取出來(lái)后它們就是我們真正要傳輸?shù)?strong>消息體。

消息邊界長(zhǎng)度標(biāo)志

而這里頭提到的消息頭，還可以放各種東西，比如消息體是否被壓縮過(guò)和消息體格式之類(lèi)的，只要上下游都約定好了，互相都認(rèn)就可以了，這就是所謂的協(xié)議。

每個(gè)使用TCP的項(xiàng)目都可能會(huì)定義一套類(lèi)似這樣的協(xié)議解析標(biāo)準(zhǔn)，他們可能有區(qū)別，但原理都類(lèi)似。

于是基于TCP，就衍生了非常多的協(xié)議，比如HTTP和RPC。

HTTP和RPC

我們回過(guò)頭來(lái)看網(wǎng)絡(luò)的分層圖。

四層網(wǎng)絡(luò)協(xié)議

TCP是傳輸層的協(xié)議，而基于TCP造出來(lái)的HTTP和各類(lèi)RPC協(xié)議，它們都只是定義了不同消息格式的應(yīng)用層協(xié)議而已。

HTTP協(xié)議（Hyper Text Transfer Protocol），又叫做超文本傳輸協(xié)議。我們用的比較多，平時(shí)上網(wǎng)在瀏覽器上敲個(gè)網(wǎng)址就能訪問(wèn)網(wǎng)頁(yè)，這里用到的就是HTTP協(xié)議。

HTTP調(diào)用

而RPC（Remote Procedure Call），又叫做遠(yuǎn)程過(guò)程調(diào)用。它本身并不是一個(gè)具體的協(xié)議，而是一種調(diào)用方式。

舉個(gè)例子，我們平時(shí)調(diào)用一個(gè)本地方法就像下面這樣。

res?=?localFunc(req)

如果現(xiàn)在這不是個(gè)本地方法，而是個(gè)遠(yuǎn)端服務(wù)器暴露出來(lái)的一個(gè)方法remoteFunc，如果我們還能像調(diào)用本地方法那樣去調(diào)用它，這樣就可以屏蔽掉一些網(wǎng)絡(luò)細(xì)節(jié)，用起來(lái)更方便，豈不美哉？

res?=?remoteFunc(req)

RPC可以像調(diào)用本地方法那樣調(diào)用遠(yuǎn)端方法

基于這個(gè)思路，大佬們?cè)斐隽朔浅６嗫钍降腞PC協(xié)議，比如比較有名的gRPC，thrift。

值得注意的是，雖然大部分RPC協(xié)議底層使用TCP，但實(shí)際上它們不一定非得使用TCP，改用UDP或者HTTP，其實(shí)也可以做到類(lèi)似的功能。

基于TCP協(xié)議的HTTP和RPC協(xié)議

到這里，我們回到文章標(biāo)題的問(wèn)題。

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

其實(shí)，TCP是70年代出來(lái)的協(xié)議，而HTTP是90年代才開(kāi)始流行的。而直接使用裸TCP會(huì)有問(wèn)題，可想而知，這中間這么多年有多少自定義的協(xié)議，而這里面就有80年代出來(lái)的RPC。

所以我們?cè)搯?wèn)的不是既然有HTTP協(xié)議為什么要有RPC，而是為什么有RPC還要有HTTP協(xié)議。

那既然有RPC了，為什么還要有HTTP呢？

現(xiàn)在電腦上裝的各種聯(lián)網(wǎng)軟件，比如xx管家，xx衛(wèi)士，它們都作為客戶端（client）需要跟服務(wù)端（server）建立連接收發(fā)消息，此時(shí)都會(huì)用到應(yīng)用層協(xié)議，在這種client/server (c/s)架構(gòu)下，它們可以使用自家造的RPC協(xié)議，因?yàn)樗还苓B自己公司的服務(wù)器就ok了。

但有個(gè)軟件不同，瀏覽器（browser），不管是chrome還是IE，它們不僅要能訪問(wèn)自家公司的服務(wù)器（server），還需要訪問(wèn)其他公司的網(wǎng)站服務(wù)器，因此它們需要有個(gè)統(tǒng)一的標(biāo)準(zhǔn)，不然大家沒(méi)法交流。于是，HTTP就是那個(gè)時(shí)代用于統(tǒng)一 browser/server (b/s) 的協(xié)議。

也就是說(shuō)在多年以前，HTTP主要用于b/s架構(gòu)，而RPC更多用于c/s架構(gòu)。但現(xiàn)在其實(shí)已經(jīng)沒(méi)分那么清了，b/s和c/s在慢慢融合。很多軟件同時(shí)支持多端，比如某度云盤(pán)，既要支持網(wǎng)頁(yè)版，還要支持手機(jī)端和pc端，如果通信協(xié)議都用HTTP的話，那服務(wù)器只用同一套就夠了。而RPC就開(kāi)始退居幕后，一般用于公司內(nèi)部集群里，各個(gè)微服務(wù)之間的通訊。

那這么說(shuō)的話，都用HTTP得了，還用什么RPC？

仿佛又回到了文章開(kāi)頭的樣子，那這就要從它們之間的區(qū)別開(kāi)始說(shuō)起。

HTTP和RPC有什么區(qū)別

我們來(lái)看看RPC和HTTP區(qū)別比較明顯的幾個(gè)點(diǎn)。

服務(wù)發(fā)現(xiàn)

首先要向某個(gè)服務(wù)器發(fā)起請(qǐng)求，你得先建立連接，而建立連接的前提是，你得知道IP地址和端口。這個(gè)找到服務(wù)對(duì)應(yīng)的IP端口的過(guò)程，其實(shí)就是服務(wù)發(fā)現(xiàn)。

在HTTP中，你知道服務(wù)的域名，就可以通過(guò)DNS服務(wù)去解析得到它背后的IP地址，默認(rèn)80端口。

而RPC的話，就有些區(qū)別，一般會(huì)有專門(mén)的中間服務(wù)去保存服務(wù)名和IP信息，比如consul或者etcd，甚至是redis。想要訪問(wèn)某個(gè)服務(wù)，就去這些中間服務(wù)去獲得IP和端口信息。由于dns也是服務(wù)發(fā)現(xiàn)的一種，所以也有基于dns去做服務(wù)發(fā)現(xiàn)的組件，比如CoreDNS。

可以看出服務(wù)發(fā)現(xiàn)這一塊，兩者是有些區(qū)別，但不太能分高低。

底層連接形式

以主流的HTTP1.1協(xié)議為例，其默認(rèn)在建立底層TCP連接之后會(huì)一直保持這個(gè)連接（keep alive），之后的請(qǐng)求和響應(yīng)都會(huì)復(fù)用這條連接。

而RPC協(xié)議，也跟HTTP類(lèi)似，也是通過(guò)建立TCP長(zhǎng)鏈接進(jìn)行數(shù)據(jù)交互，但不同的地方在于，RPC協(xié)議一般還會(huì)再建個(gè)連接池，在請(qǐng)求量大的時(shí)候，建立多條連接放在池內(nèi)，要發(fā)數(shù)據(jù)的時(shí)候就從池里取一條連接出來(lái)，用完放回去，下次再?gòu)?fù)用，可以說(shuō)非常環(huán)保。

connection_pool

由于連接池有利于提升網(wǎng)絡(luò)請(qǐng)求性能，所以不少編程語(yǔ)言的網(wǎng)絡(luò)庫(kù)里都會(huì)給HTTP加個(gè)連接池，比如go就是這么干的。

可以看出這一塊兩者也沒(méi)太大區(qū)別，所以也不是關(guān)鍵。

傳輸?shù)膬?nèi)容

基于TCP傳輸?shù)南ⅲf(shuō)到底，無(wú)非都是消息頭header和消息體body。

header是用于標(biāo)記一些特殊信息，其中最重要的是消息體長(zhǎng)度。

body則是放我們真正需要傳輸?shù)膬?nèi)容，而這些內(nèi)容只能是二進(jìn)制01串，畢竟計(jì)算機(jī)只認(rèn)識(shí)這玩意。所以TCP傳字符串和數(shù)字都問(wèn)題不大，因?yàn)樽址梢赞D(zhuǎn)成編碼再變成01串，而數(shù)字本身也能直接轉(zhuǎn)為二進(jìn)制。但結(jié)構(gòu)體呢，我們得想個(gè)辦法將它也轉(zhuǎn)為二進(jìn)制01串，這樣的方案現(xiàn)在也有很多現(xiàn)成的，比如json，protobuf。

這個(gè)將結(jié)構(gòu)體轉(zhuǎn)為二進(jìn)制數(shù)組的過(guò)程就叫序列化，反過(guò)來(lái)將二進(jìn)制數(shù)組復(fù)原成結(jié)構(gòu)體的過(guò)程叫反序列化。

序列化和反序列化

對(duì)于主流的HTTP1.1，雖然它現(xiàn)在叫超文本協(xié)議，支持音頻視頻，但HTTP設(shè)計(jì)初是用于做網(wǎng)頁(yè)文本展示的，所以它傳的內(nèi)容以字符串為主。header和body都是如此。在body這塊，它使用json來(lái)序列化結(jié)構(gòu)體數(shù)據(jù)。

我們可以隨便截個(gè)圖直觀看下。

HTTP報(bào)文

可以看到這里面的內(nèi)容非常多的冗余，顯得非常啰嗦。最明顯的，像header里的那些信息，其實(shí)如果我們約定好頭部的第幾位是content-type，就不需要每次都真的把"content-type"這個(gè)字段都傳過(guò)來(lái)，類(lèi)似的情況其實(shí)在body的json結(jié)構(gòu)里也特別明顯。

而RPC，因?yàn)樗ㄖ苹潭雀?，可以采用體積更小的protobuf或其他序列化協(xié)議去保存結(jié)構(gòu)體數(shù)據(jù)，同時(shí)也不需要像HTTP那樣考慮各種瀏覽器行為，比如302重定向跳轉(zhuǎn)啥的。因此性能也會(huì)更好一些，這也是在公司內(nèi)部微服務(wù)中拋棄HTTP，選擇使用RPC的最主要原因。

HTTP原理

RPC原理

當(dāng)然上面說(shuō)的HTTP，其實(shí)特指的是現(xiàn)在主流使用的HTTP1.1，HTTP2在前者的基礎(chǔ)上做了很多改進(jìn)，所以性能可能比很多RPC協(xié)議還要好，甚至連gRPC底層都直接用的HTTP2。

那么問(wèn)題又來(lái)了。

為什么既然有了HTTP2，還要有RPC協(xié)議？

這個(gè)是由于HTTP2是2015年出來(lái)的。那時(shí)候很多公司內(nèi)部的RPC協(xié)議都已經(jīng)跑了好些年了，基于歷史原因，一般也沒(méi)必要去換了。

總結(jié)

純裸TCP是能收發(fā)數(shù)據(jù)，但它是個(gè)無(wú)邊界的數(shù)據(jù)流，上層需要定義消息格式用于定義消息邊界。于是就有了各種協(xié)議，HTTP和各類(lèi)RPC協(xié)議就是在TCP之上定義的應(yīng)用層協(xié)議。

RPC本質(zhì)上不算是協(xié)議，而是一種調(diào)用方式，而像gRPC和thrift這樣的具體實(shí)現(xiàn)，才是協(xié)議，它們是實(shí)現(xiàn)了RPC調(diào)用的協(xié)議。目的是希望程序員能像調(diào)用本地方法那樣去調(diào)用遠(yuǎn)端的服務(wù)方法。同時(shí)RPC有很多種實(shí)現(xiàn)方式，不一定非得基于TCP協(xié)議。

從發(fā)展歷史來(lái)說(shuō)，HTTP主要用于b/s架構(gòu)，而RPC更多用于c/s架構(gòu)。但現(xiàn)在其實(shí)已經(jīng)沒(méi)分那么清了，b/s和c/s在慢慢融合。很多軟件同時(shí)支持多端，所以對(duì)外一般用HTTP協(xié)議，而內(nèi)部集群的微服務(wù)之間則采用RPC協(xié)議進(jìn)行通訊。

RPC其實(shí)比HTTP出現(xiàn)的要早，且比目前主流的HTTP1.1性能要更好，所以大部分公司內(nèi)部都還在使用RPC。

HTTP2.0在HTTP1.1的基礎(chǔ)上做了優(yōu)化，性能可能比很多RPC協(xié)議都要好，但由于是這幾年才出來(lái)的，所以也不太可能取代掉RPC。

最后留個(gè)問(wèn)題吧，大家有沒(méi)有發(fā)現(xiàn)，不管是HTTP還是RPC，它們都有個(gè)特點(diǎn)，那就是消息都是客戶端請(qǐng)求，服務(wù)端響應(yīng)。客戶端沒(méi)問(wèn)，服務(wù)端肯定就不答，這就有點(diǎn)僵了，但現(xiàn)實(shí)中肯定有需要下游主動(dòng)發(fā)送消息給上游的場(chǎng)景，比如打個(gè)網(wǎng)頁(yè)游戲，站在那啥也不操作，怪也會(huì)主動(dòng)攻擊我，這種情況該怎么辦呢？

審核編輯：黃飛