RPC 和HTTP 的區別
服務發現
- HTTP，知道服務域名，可以透過 DNS 解析 得到 服務的IP地址，從而進行訪問
- RPC 需要一個專門的中間服務去儲存服務名和IP資訊（註冊中心，nacos、consul），想要訪問某個服務，就得同時註冊到 中間服務，然後獲取需要頂用服務的IP 和埠資訊
底層連結形式
- HTTP/1.1 預設在底層建立TCP 連結後，會一直保持這個連結（keep alive），後邊的請求和響應回服用這條連結
- RPC 協議，和http 相同的地方是，透過 建立TCP 長連結進行資料互動，不同的地方是，RPC 一般會再建立一個連結池，大量請求時，會建立多條連結放在連結池中。需要時，從連結池取，不需要時，放回連結池
傳輸內容
- RPC 和HTTP 協議都有請求頭和請求體，但是請求頭裡面放的內容不一致，由於請求體的資料格式不一致，請求頭裡面會儲存請求體的解析方式，為了解決 body 的解析方式，請求體會有差異
- 一般訊息都是結構化的資訊，但是 TCP 傳輸過程中，都是 二進位制 的 01 串（計算機只認識 0，1），所以從應用層將資料傳輸前，將結構體轉換成 二進位制 ，這個過程叫做 序列化， 反過來，從傳輸層傳送的訊息是二進位制的，需要將二進位制的資料轉換成 結構體的過程叫 反序列化
- 一般，HTTP協議為了做到足夠的通用，會在請求頭中新增更多的資訊，所有內容會偏多，整個訊息體 會比RPC 偏大。但是不絕對，如果RPC 底層協議採用 http ，那就相反了
總結
-
TCP 、UDP協議，是傳輸層協議，而 RPC 和 http 都定義了不同的訊息格式，可以認為都是應用層協議
-
HTTP協議： hyper text transfer protocol（超文字傳輸協議）， 由於瀏覽器的誕生衍生出來的協議
-
RPC 協議 ： romote procedure call （遠端過程呼叫協議），他本身不是一種協議，而是一種呼叫方式。 RPC 本身有很多實現方式，底層協議不一定基於TCP，可以是 UDP、http 協議
-
純裸的TCP 能收發資料，但是他它是一個無邊界的資料流，上層（應用層）需要定義訊息格式，用於定義訊息邊界
-
歷史的發展來說，RPC 其實比HTTP 出出現的時間更早， HTTP 主要用於 B/S 架構，RPC 主要用於C/S 架構，現在慢慢的有了融合的跡象。
-
HTTP/2.0 在 HTTP/1.0 上做了最佳化，效能比RPC 都好