要想弄清楚rpc與http,首先得了解一下OSI的七層網路結構模型

OSI網路結構的七層模型

各層的具體描述如下：

　　第七層：應用層     定義了用於在網路中進行通訊和資料傳輸的介面 - 使用者程式；提供標準服務，比如虛擬終端、檔案以及任務的傳輸 和處理； 
　　第六層：表示層     掩蓋不同系統間的資料格式的不同性； 指定獨立結構的資料傳輸格式； 資料的編碼和解碼；加密和解密；壓縮和 解壓縮 
　　第五層：會話層     管理使用者會話和對話； 控制使用者間邏輯連線的建立和結束通話；報告上一層發生的錯誤 
　　第四層：傳輸層     管理網路中端到端的資訊傳送； 通過錯誤糾正和流控制機制提供可靠且有序的資料包傳送； 提供面向無連線的數 據包的傳送； 
　　第三層：網路層     定義網路裝置間如何傳輸資料； 根據唯一的網路裝置地址路由資料包；提供流和擁塞控制以防止網路資源的損耗 
　　第二層：資料鏈路層 定義操作通訊連線的程式； 封裝資料包為資料幀； 監測和糾正資料包傳輸錯誤 
　　第一層：物理層      定義通過網路裝置傳送資料的物理方式； 作為網路媒介和裝置間的介面；定義光學、電氣以及機械特性。

在上述7層中，http協議是應用層協議。HTTP協議是超文字傳送協議(HyperText Transfer Protocol)的縮寫，它是全球資訊網(World Wide Web,www,也簡稱為Web)的基礎。HTTP協議設計之初就是為了實現Web的想法。HTTP協議位於TCP/IP協議棧的應用層。基於HTTP協議的客戶/伺服器模式的資訊交換過程，分四個過程：建立連線、傳送請求資訊、傳送響應資訊、關閉連線。

下面是RPC的官方說明：

一種通過網路從遠端計算機程式上請求服務，而不需要了解底層網路技術的協議。RPC協議假定某些傳輸協議的存在，如TCP或UDP，為通訊程式之間攜帶資訊資料。在OSI網路通訊模型中，RPC跨越了傳輸層和應用層。RPC使得開發包括網路分散式多程式在內的應用程式更加輕易。

RPC架構

一個完整的RPC架構裡面包含了四個核心的元件，分別是Client ,Server,Client Stub以及Server Stub，這個Stub大家可以理解為存根。分別說說這幾個元件：

• 客戶端（Client），服務的呼叫方。
• 服務端（Server），真正的服務提供者。
• 客戶端存根，存放服務端的地址訊息，再將客戶端的請求引數打包成網路訊息，然後通過網路遠端傳送給服務方。
• 服務端存根，接收客戶端傳送過來的訊息，將訊息解包，並呼叫本地的方法

RPC採用客戶機/伺服器模式。請求程式就是一個客戶機，而服務提供程式就是一個伺服器。首先，呼叫程序傳送一個有程序引數的呼叫資訊到服務程序，然後等待應答資訊。在伺服器端，程序保持睡眠狀態直到呼叫資訊的到達為止。當一個呼叫資訊到達，伺服器獲得程序引數，計算結果，傳送答覆資訊，然後等待下一個呼叫資訊，最後，客戶端呼叫過程接收答覆資訊，獲得程序結果，然後呼叫執行繼續進行。
RPC資訊協議由兩個不同結構組成：呼叫資訊和答覆資訊。

流行的RPC框架

目前流行的開源RPC框架還是比較多的。下面重點介紹三種：

1. gRPC是Google最近公佈的開源軟體，基於最新的HTTP2.0協議，並支援常見的眾多程式語言。 我們知道HTTP2.0是基於二進位制的HTTP協議升級版本，目前各大瀏覽器都在快馬加鞭的加以支援。 這個RPC框架是基於HTTP協議實現的，底層使用到了Netty框架的支援。
2. Thrift是Facebook的一個開源專案，主要是一個跨語言的服務開發框架。它有一個程式碼生成器來對它所定義的IDL定義檔案自動生成服務程式碼框架。使用者只要在其之前進行二次開發就行，對於底層的RPC通訊等都是透明的。不過這個對於使用者來說的話需要學習特定領域語言這個特性，還是有一定成本的。
3. Dubbo是阿里集團開源的一個極為出名的RPC框架，在很多網際網路公司和企業應用中廣泛使用。協議和序列化框架都可以插拔是及其鮮明的特色。同樣 的遠端介面是基於Java Interface，並且依託於spring框架方便開發。可以方便的打包成單一檔案，獨立程序執行，和現在的微服務概念一致。

下面是rpc與socket的對比

RPC和Socket的區別

http://blog.163.com/fanning_7213/blog/static/249650520113124540501/

RPC是建立在Socket之上的,出於一種類比的願望,在一臺機器上執行的主程式,可以呼叫另一臺機器上準備好的子程式,就像LPC(本地過程呼叫).

    越底層，程式碼越複雜、靈活性越高、效率越高；越上層，抽象封裝的越好、程式碼越簡單、效率越差。Socket和RPC的區別再次說明了這點。

不論是程式設計師在編寫基於C/S(客戶端伺服器)的程式時,還是網路工程師在處理RPC問題時,他們問的最多的就是RPC和Socket有什麼區別和聯絡? 
　 　RPC是建立在Socket之上的,出於一種類比的願望,在一臺機器上執行的主程式,可以呼叫另一臺機器上準備好的子程式,就像 LPC(本地過程呼叫).RPC帶來了開發C/S程式的簡單可靠的手段,它通過一種叫XDR的資料表達方法描述資料,程式設計師書寫虛擬碼,然後由 rpcgen程式翻譯為真正的可編譯的C語言原始碼,再編譯成真正的Client端和Server端程式。 
　　RPC作為普遍的C/S開發方 法,開發效率高效,可靠.但RPC方法的基本原則是－－以模組呼叫的簡單性忽略通訊的具體細節,以便程式設計師不用關心C/S之間的通訊協議,集中精力對付實 現過程.這就決定了 RPC生成的通訊包不可能對每種應用都有最恰當的處理辦法,與Socket方法相比,傳輸相同的有效資料,RPC佔用更多的網路頻寬. 
　　RPC是在Socket的基礎上實現的,它比socket需要更多的網路和系統資源.另外,在對程式優化時,程式設計師雖然可以直接修改由rpcgen產生的令人費解的源程式,但對於追求程式設計高效率的RPC而言,獲得的簡單性則被大大削弱. 
RPC與是Socket的類比

參考：https://www.cnblogs.com/leenuxqt/p/3202527.html

https://blog.csdn.net/wangyunpeng0319/article/details/78651998