于是我上網搜索。

很多解釋都很官方相信大家都在各種平臺看過解釋了一下，好像沒什么解釋的都是在用一個我們不知道的概念去解釋另一個我們不知道的概念懂的不用看不懂的人還是不懂

這種看得到看不到的感覺，在霧里似乎很難受我明白

為了避免大家強烈的審丑疲勞，今天我們試著換一種方式來說。

從TCP開始。

作為程序員，假設我們需要從計算機A的進程向計算機B的進程發送一條數據，我們通常使用socket在代碼中編程。

這個時候我們的選項一般是TCP和UDPTCP可靠，UDP不可靠除非是神級程序員宗，只要對可靠性有一些要求，普通人一般是無腦選擇TCP的

類似這樣的。

fd =插座，

SOCK_STREAM是指使用字節流傳輸數據，這是TCP協議。

定義完socket之后，我們就可以愉快地操作socket了，比如用bind綁定IP端口，用connect發起連接。

握手連接建立過程

連接建立后，我們可以使用send發送數據，使用recv接收數據。

就這么一個赤裸裸的TCP連接就能收發數據，這還不夠嗎。

不會，這種使用會有問題。

使用裸TCP有什么問題。

TCP有三個特點:面向連接，可靠和基于字節流。

什么是TCP。

這三個特點真的總結的非常精辟這個八股文我們沒有白背

每個特性開發可以講一篇文章，今天需要重點講一下字節流。

一個字節可以理解為在雙向通道中流動的數據這個數據其實就是我們常說的二進制數據簡單來說就是很多01串裸TCP收發的這些01字符串之間沒有邊界，你不知道一個完整的消息在哪里

01二進制字節流

因為這種無邊界的特性，當我們選擇通過TCP發送夏洛特和非?？鄲罆r，接收方接收到的是再見失敗者先生，此時接收方并不會告訴你是想表達夏洛特+非常苦惱還是夏洛特

消息比較

這就是所謂的貼袋問題，我之前也專門寫過一篇文章講過這個問題。

這樣做的目的是告訴你，純裸TCP是不能直接使用的您需要在此基礎上添加一些自定義規則來區分消息邊界

所以我們會把每一條要發送的數據打包，比如添加到消息頭消息頭清楚地說明了一個完整數據包的長度按照這個長度，我們可以繼續接收數據截取后，它們才是我們真正要傳遞的消息體

消息邊界長度標志

而且這里說的消息頭也可以放各種東西，比如消息體是否壓縮過，消息體的格式，只要上下游都約定好了，互相認可這就是所謂的協議

每個使用TCP的項目都可能定義一組這樣的協議解析標準它們可能不同，但原理是相似的

讓我們回頭看看網絡的層次圖。

四層網絡協議

和RPC，也稱為遠程過程調用它本身不是一個特定的協議，而是一個調用方法

例如，我們通常像下面這樣調用一個局部方法。

res =局部函數

現在，如果這不是一個本地方法，而是一個遠程服務器暴露的方法remoteFunc，如果我們還能像本地方法一樣調用它，屏蔽掉一些網絡細節，使用起來更方便，豈不是很美好。

res=remoteFunc

RPC可以像調用本地方法一樣調用遠程方法。

基于這種想法，老板們創造了許多風格的RPC協議，如眾所周知的gRPC和thrift。

在這里，讓我們回到文章的標題。

現在電腦上安裝的各種聯網軟件，如xx管家，xx衛士等，都需要作為客戶端與服務器建立連接來收發消息此時，它們都使用應用層協議在這種客戶端/服務器架構下，他們可以使用自己的RPC協議，因為連接自己公司的服務器是可以的

好像又回到文章開頭了，要從兩者的區別說起。

服務發現

首先，要向服務器發出請求，你得建立連接，而建立連接的前提是你得知道IP地址和端口找到這個服務對應的IP端口的過程，其實就是服務發現

另一方面，RPC有些不同一般有專門的中間服務來保存服務名和IP信息，比如consul或者etcd，甚至redis如果您想要訪問某個服務，請轉到這些中間服務來獲取IP和端口信息由于dns也是一種服務發現，所以也有基于dns的服務發現組件，比如CoreDNS

可見服務找到了這一塊兩者有一些區別，但不是很高也不是很低

底部連接形式

連接池

可見兩者沒有太大區別，所以不是關鍵。

傳輸的內容

基于TCP傳輸的消息，說到底無非就是頭和體。

報頭用來標記一些特殊的信息，其中最重要的是消息體的長度。

Body是我們真正需要傳遞的內容，這些內容只能是二進制的01字符串畢竟計算機只知道這些東西所以TCP傳輸字符串和數字問題不大，因為字符串可以轉換成代碼再轉換成01字符串，數字本身可以直接轉換成二進制但是結構，我們得想辦法把它轉換成二進制的01字符串像json，protobuf等現成的方案有很多

將此結構轉換為二進制數組的過程稱為序列化，將二進制數組恢復為結構的過程稱為反序列化。

序列化和反序列化

我們可以拍張照片，看一看。

可以看到這里的內容有很多冗余，非常啰嗦最明顯的是，像頭中的信息，事實上，如果我們同意頭的數字是內容類型的，我們就不需要每次都真正地傳遞內容類型字段類似的情況其實在身體的json結構上特別明顯

RPC原理

那么問題又來了。

摘要

本質上，RPC不是一個協議，而是一個調用方法，而像gRPC和thrift這樣的具體實現就是協議，就是實現RPC調用的協議目的是希望程序員可以像調用本地方法一樣調用遠程服務方法同時，RPC的實現方式有很多種，不一定基于TCP協議

參考數據