RPC:遠程過程調用（分布式、微服務間的方法調用）
HTTP:無狀態，每次請求都要發送一個request，服務器響應之后就斷掉（http header中的keep-alive指的是tcp）
TCP:面向連接，三次握手保證通信可靠
UDP:非面向連接，不可靠，速度快（可以手動對數據收發進行驗證，IM系統多采用，QQ）
Socket:TCP協議的接口實現，面向傳輸層進行網絡編程, socket並不是一種協議，是在程序員層面上對TCP/IP協議的封裝和應用。其實是一個調用接口，方便程序員使用TCP/IP協議棧而已。程序員通過socket來使用tcp/ip協議。但是socket並不是一定要使用tcp/ip協議，Socket編程接口在設計的時候，就希望也能適應其他的網絡協議。
RPC(Remote Procedure Call)是遠程過程調用，比如說現在有兩台服務器A, B，一個在A服務器上的應用想要調用B服務器上的應用提供的某個，由於不在兩個方法不在一個內存空間，不能直接調用，需要通過網絡表達調用的語義和傳達調用的數據。常存在於分布式系統中。
RPC跟HTTP不是對立面，RPC中可以使用HTTP作為通訊協議。RPC是一種設計、實現框架，通訊協議只是其中一部分。
RPC的本質是提供了一種輕量無感知的跨進程通信的方式，在分布式機器上調用其他方法與本地調用無異（遠程調用的過程是透明的，你並不知道這個調用的方法是部署在哪里，通過PRC能夠解耦服務）。RPC是根據語言的API來定義的，而不是基於網絡的應用來定義的，調用更方便，協議私密更安全、內容更小效率更高。
http接口是在接口不多、系統與系統交互較少的情況下，解決信息孤島初期常使用的一種通信手段；優點就是簡單、直接、開發方便。利用現成的http協議 進行傳輸。但是如果是一個大型的網站，內部子系統較多、接口非常多的情況下，RPC框架的好處就顯示出來了，首先（基於TCP協議的情況下）就是長鏈接，不必每次通信都要像http 一樣去3次握手什么的，減少了網絡開銷；其次就是RPC框架一般都有注冊中心，有豐富的監控管理；發布、下線接口、動態擴展等，對調用方來說是無感知、統一化的操作。第三個來說就是安全性。最后就是最近流行的服務化架構、服務化治理，RPC框架是一個強力的支撐。
TCP 三次握手：握手過程中並不傳輸數據，在握手后服務器與客戶端才開始傳輸數據，理想狀態下，TCP 連接一旦建立，在通訊雙方中的任何一方主動斷開連接之前 TCP 連接會一直保持下去。
Socket 是對 TCP/IP 協議的封裝，是針對TCP或UDP的具體接口實現，提供了在傳輸層進行網絡編程的方法, Socket 只是個接口不是協議，通過 Socket 我們才能使用 TCP/IP 協議，除了 TCP，也可以使用 UDP 協議來傳遞數據。
創建 Socket 連接的時候，可以指定傳輸層協議，可以是 TCP 或者 UDP，當用 TCP 連接，該Socket就是個TCP連接，反之。
Socket 原理
Socket 連接,至少需要一對套接字，分為 clientSocket，serverSocket 連接分為3個步驟:
(1) 服務器監聽:服務器並不定位具體客戶端的套接字，而是時刻處於監聽狀態；
(2) 客戶端請求:客戶端的套接字要描述它要連接的服務器的套接字，提供地址和端口號，然后向服務器套接字提出連接請求；
(3) 連接確認:當服務器套接字收到客戶端套接字發來的請求后，就響應客戶端套接字的請求,並建立一個新的線程,把服務器端的套接字的描述發給客戶端。一旦客戶端確認了此描述，就正式建立連接。而服務器套接字繼續處於監聽狀態，繼續接收其他客戶端套接字的連接請求.
Socket為長連接：通常情況下Socket 連接就是 TCP 連接，因此 Socket 連接一旦建立,通訊雙方開始互發數據內容，直到雙方斷開連接。在實際應用中，由於網絡節點過多，在傳輸過程中，會被節點斷開連接，因此要通過輪詢高速網絡，該節點處於活躍狀態。
很多情況下，都是需要服務器端向客戶端主動推送數據，保持客戶端與服務端的實時同步。
若雙方是 Socket 連接，可以由服務器直接向客戶端發送數據。
若雙方是 HTTP 連接，則服務器需要等客戶端發送請求后，才能將數據回傳給客戶端。
因此，客戶端定時向服務器端發送請求，不僅可以保持在線，同時也詢問服務器是否有新數據，如果有就將數據傳給客戶端。
一個完整的RPC架構里面包含了四個核心的組件，分別是Client,Server,Client Stub以及Server Stub，這個Stub大家可以理解為存根。分別說說這幾個組件：
客戶端（Client），服務的調用方。
服務端（Server），真正的服務提供者。
客戶端存根，存放服務端的地址消息，再將客戶端的請求參數打包成網絡消息，然后通過網絡遠程發送給服務方。
服務端存根，接收客戶端發送過來的消息，將消息解包，並調用本地的方法。
RPC主要是用在大型企業里面，因為大型企業里面系統繁多，業務線復雜，而且效率優勢非常重要的一塊，這個時候RPC的優勢就比較明顯了。實際的開發當中是這么做的，項目一般使用maven來管理。比如我們有一個處理訂單的系統服務，先聲明它的所有的接口（這里就是具體指Java中的interface），然后將整個項目打包為一個jar包，服務端這邊引入這個二方庫，然后實現相應的功能，客戶端這邊也只需要引入這個二方庫即可調用了。為什么這么做？主要是為了減少客戶端這邊的jar包大小，因為每一次打包發布的時候，jar包太多總是會影響效率。另外也是將客戶端和服務端解耦，提高代碼的可移植性。
目前流行的開源RPC框架還是比較多的。下面重點介紹三種：
gRPC是Google最近公布的開源軟件，基於最新的HTTP2.0協議，並支持常見的眾多編程語言。 我們知道HTTP2.0是基於二進制的HTTP協議升級版本，目前各大瀏覽器都在快馬加鞭的加以支持。 這個RPC框架是基於HTTP協議實現的，底層使用到了Netty框架的支持。
Thrift是Facebook的一個開源項目，主要是一個跨語言的服務開發框架。它有一個代碼生成器來對它所定義的IDL定義文件自動生成服務代碼框架。用戶只要在其之前進行二次開發就行，對於底層的RPC通訊等都是透明的。不過這個對於用戶來說的話需要學習特定領域語言這個特性，還是有一定成本的。
Dubbo是阿里集團開源的一個極為出名的RPC框架，在很多互聯網公司和企業應用中廣泛使用。協議和序列化框架都可以插拔是及其鮮明的特色。同樣的遠程接口是基於Java Interface，並且依托於spring框架方便開發。可以方便的打包成單一文件，獨立進程運行，和現在的微服務概念一致。