趣談網路協議---RPC協議綜述：遠在天邊，近在眼前
RPC 框架
-
客戶端的應用發起一個遠端呼叫時，實際是通過本地呼叫 Stub。Stub 負責將呼叫的介面、方法和引數，通過約定的協議規範進行編碼，並通過本地的 RPCRuntime 進行傳輸，將網路包傳送到伺服器。
-
伺服器的 RPCRuntime 收到請求，交給提供方 Stub 解碼，然後呼叫服務端的方法，服務端執行方法，返回結果。提供方 Stub 將結果編碼，傳送各客戶端。
-
客戶端的 RPCRuntime 收到結果，發給呼叫方 Stub 解碼，返回給客戶端。
RPC 實現
Sun 公司是第一個提供商業化 RPC 庫和 RPC 編譯器的公司，其 RPC 框架在 NFS（Network File System，網路檔案系統）協議中使用。
- mountd，掛載檔案路徑，將一個遠端的目錄 mount 到本地目錄。
- nfsd，讀寫檔案，在掛載的目錄中寫入、讀出任何檔案時，其實操作的是遠端另一臺機器上的檔案。
RPC 的底層是 Socket。
RPC 呼叫過程中，所有資料型別都要封裝成 XDR 格式。XDR（External Data Representation，外部資料表示法）是一個標準的資料壓縮格式，可以表示基本的資料型別，也可表示結構體。
XDR 資料型別：
RPC 的呼叫和結果返回的格式：
- XID 唯一標識一對請求和回覆，請求為 0，回覆為 1。
- RPC 有版本號，兩端不匹配 RPC 版本號，返回 Deny，原因為 RPC_MISMATCH。
- 程式有編號，找不到該程式，返回 PROG_UNAVALI。
- 程式有版本號，版本號不匹配，返回 PROG_MISMATCH。
- 程式中有多個方法，方法有編號，找不到則返回 PROC_UNAVAIL。
- 呼叫需要認證授權，不通過則 Deny。
- 引數列表，無法解析則返回 GABAGE_ARGS。
客戶端和服務端在實現 RPC 時，首先要定義一個雙方都認可的程式、版本、方法、引數等。
ONC RPC 會提供一個工具，根據協議定義檔案生成客戶端和服務端的 Stub 程式。
客戶端呼叫 clnt_create 建立一個連線，然後呼叫 add_1（Stub 函式），如同本地呼叫，該函式發起 RPC 呼叫，通過呼叫 clnt_call 呼叫 ONC RPC 類庫傳送真正的請求。
服務端 Stub 監聽客戶請求，如果是 add，呼叫真正的服務端邏輯，即將兩數相加。
服務端將結果返回服務端 Stub，Stub 將結果傳送給客戶端，客戶端 Stub 將結果返回給客戶端應用程式。
傳輸問題
錯誤、重傳、丟包、效能等問題，由 ONC RPC 類庫解決。
為解決傳輸問題，對於每個客戶端，都會建立一個傳輸管理層，會有佇列機制、擁塞視窗機制等。
網路傳輸時，經常需要等待，同步方式效率較低，為了能非同步處理，往往通過狀態機實現遠端呼叫。不滿足狀態時，不等，而是將資源留出，供其他 RPC 呼叫。
- 進入起始狀態，檢視 RPC 的傳輸佇列中是否滿，如果佇列滿，則直接結束或重試；否則，申請成功，可分配記憶體，獲取服務的埠號，連線伺服器。
- 連線成功，傳送 RPC 請求，等待獲取 RPC 結果；傳送出錯，可重新發送；連線斷開，可重新連線；超時，可重新傳輸；獲取到結果，則解碼，正常結束。
服務發現問題
在 ONC RPC 中，服務發現通過 portmapper 實現。
portmapper 在一個眾所周知的埠上啟動。RPC 程式啟動時，向 portmapper 註冊自己的埠。客戶端要訪問 RPC 服務端時，先查詢 protmapper，獲取 RPC 服務端的埠，然後向該埠建立連線，開始 RPC 呼叫。圖中為 mount 命令的 RPC 呼叫實現。
