OSI網絡七層模型
- 第一層：應用層。定義了用於在網絡中進行通信和傳輸數據的接口；
- 第二層：表示層。定義不同的系統中數據的傳輸格式，編碼和解碼規范等；
- 第三層：會話層。管理用戶的會話，控制用戶間邏輯連接的建立和中斷；
- 第四層：傳輸層。管理着網絡中的端到端的數據傳輸；
- 第五層：網絡層。定義網絡設備間如何傳輸數據；
- 第六層：鏈路層。將上面的網絡層的數據包封裝成數據幀，便於物理層傳輸；
- 第七層：物理層。這一層主要就是傳輸這些二進制數據
實際應用過程中，五層協議結構里面是沒有表示層和會話層的。應該說它們和應用層合並了。我們應該將重點放在應用層和傳輸層這兩個層面，因為RPC主要是基於TCP/IP協議（傳輸層協議），HTTP主要是基於HTTP協議（應用層協議）。
1、什么是REST？
REST是一種架構風格，指的是一組架構約束條件和原則。滿足這些約束條件和原則的應用程序或設計就是 RESTful。REST規范把所有內容都視為資源，網絡上一切皆資源。REST並沒有創造新的技術，組件或服務，只是使用Web的現有特征和能力。 可以完全通過HTTP協議實現，使用 HTTP 協議處理數據通信。REST架構對資源的操作包括獲取、創建、修改和刪除資源的操作正好對應HTTP協議提供的GET、POST、PUT和DELETE方法。
HTTP動詞與REST風格CRUD對應關系：
2、什么是RPC
Remote Procedure Call，遠程過程調用，就是像調用本地方法一樣調用遠程方法。RPC架構圖：
RPC框架包含4個核心的組件，分別是Client ,Server,Client Stub以及Server Stub，這個Stub大家可以理解為存根
- 客戶端（Client），服務的調用方。
- 服務端（Server），真正的服務提供者。
- 客戶端存根，存放服務端的地址消息，再將客戶端的請求參數打包成網絡消息，然后通過網絡遠程發送給服務方。
- 服務端存根，接收客戶端發送過來的消息，將消息解包，並調用本地的方法
RPC框架要做到最基本的3件事情：
1）服務端如何確定客戶端要調用的函數；
在遠程調用中，客戶端和服務端分別維護一個【ID->函數】的對應表， ID在所有進程中都是唯一確定的。客戶端在做遠程過程調用時，附上這個ID，服務端通過查表，來確定客戶端需要調用的函數，然后執行相應函數的代碼。
2）如何進行序列化和反序列化；
客戶端和服務端交互時將參數或結果轉化為字節流在網絡中傳輸，那么數據轉化為字節流的或者將字節流轉換成能讀取的固定格式時就需要進行序列化和反序列化，序列化和反序列化的速度也會影響遠程調用的效率。
3）如何進行網絡傳輸
多數RPC框架選擇TCP作為傳輸協議，也有部分選擇HTTP。如gRPC使用HTTP2。不同的協議各有利弊。TCP更加高效，而HTTP在實際應用中更加的靈活
3、REST與RPC比較
4、REST與RPC應用場景
REST和RPC都常用於微服務架構中。
1）HTTP相對更規范，更標准，更通用，無論哪種語言都支持http協議。如果你是對外開放API，例如開放平台，外部的編程語言多種多樣，你無法拒絕對每種語言的支持，現在開源中間件，基本最先支持的幾個協議都包含RESTful。
2）RPC 框架作為架構微服務化的基礎組件，它能大大降低架構微服務化的成本，提高調用方與服務提供方的研發效率，屏蔽跨進程調用函數（服務）的各類復雜細節。讓調用方感覺就像調用本地函數一樣調用遠端函數、讓服務提供方感覺就像實現一個本地函數一樣來實現服務
5、流行的RPC框架
1）gRPC是Google最近公布的開源軟件，基於最新的HTTP2.0協議，並支持常見的眾多編程語言。 我們知道HTTP2.0是基於二進制的HTTP協議升級版本，目前各大瀏覽器都在快馬加鞭的加以支持。 這個RPC框架是基於HTTP協議實現的，底層使用到了Netty框架的支持。
2）Thrift是Facebook的一個開源項目，主要是一個跨語言的服務開發框架。它有一個代碼生成器來對它所定義的IDL定義文件自動生成服務代碼框架。用戶只要在其之前進行二次開發就行，對於底層的RPC通訊等都是透明的。不過這個對於用戶來說的話需要學習特定領域語言這個特性，還是有一定成本的。
3）Dubbo是阿里集團開源的一個極為出名的RPC框架，在很多互聯網公司和企業應用中廣泛使用。協議和序列化框架都可以插拔是及其鮮明的特色。同樣 的遠程接口是基於Java Interface，並且依托於spring框架方便開發。可以方便的打包成單一文件，獨立進程運行，和現在的微服務概念一致