TCP/HTTP與socket
首先回顧下計算機網(wǎng)絡的五(七)層協(xié)議：物理層窍奋、數(shù)據(jù)鏈路層、網(wǎng)絡層、傳輸層费变、(會話層、表示層)和應用層圣贸。那么從協(xié)議上來講：
- TCP是傳輸層協(xié)議挚歧，主要解決數(shù)據(jù)如何在網(wǎng)絡中傳輸
- HTTP 是應用層協(xié)議，主要解決如何包裝數(shù)據(jù)（文本信息）吁峻，是建立在tcp協(xié)議之上的應用滑负。TCP協(xié)議是以二進制數(shù)據(jù)流的形式解決傳輸層的事兒，但對上層的應用開發(fā)極不友好用含，所以面向應用層的開發(fā)又產(chǎn)生了HTTP協(xié)議矮慕。
而socket 是針對TCP或UDP的具體接口實現(xiàn)，提供了在傳輸層進行網(wǎng)絡編程的方法啄骇。
以上內(nèi)容我們應該都聽說的比較多了痴鳄，下面主要來談一談RPC砌溺。
什么是RPC封锉？
RPC(Remote Procedure Call)是遠程過程調(diào)用，比如說現(xiàn)在有兩臺服務器A, B煤痕，一個在A服務器上的應用想要調(diào)用B服務器上的應用提供的某個虽惭，由于不在兩個方法不在一個內(nèi)存空間橡类，不能直接調(diào)用，需要通過網(wǎng)絡表達調(diào)用的語義和傳達調(diào)用的數(shù)據(jù)芽唇。常存在于分布式系統(tǒng)中顾画。
為何有http協(xié)議之后，還要RPC調(diào)用匆笤？
RPC跟HTTP不是對立面研侣，RPC中可以使用HTTP作為通訊協(xié)議。RPC是一種設計疚膊、實現(xiàn)框架义辕，通訊協(xié)議只是其中一部分。
RPC的本質(zhì)是提供了一種輕量無感知的跨進程通信的方式寓盗，在分布式機器上調(diào)用其他方法與本地調(diào)用無異（遠程調(diào)用的過程是透明的灌砖，你并不知道這個調(diào)用的方法是部署在哪里，通過PRC能夠解耦服務）傀蚌。RPC是根據(jù)語言的API來定義的基显，而不是基于網(wǎng)絡的應用來定義的，調(diào)用更方便善炫，協(xié)議私密更安全撩幽、內(nèi)容更小效率更高。
http接口是在接口不多、系統(tǒng)與系統(tǒng)交互較少的情況下窜醉，解決信息孤島初期常使用的一種通信手段宪萄；優(yōu)點就是簡單、直接榨惰、開發(fā)方便拜英。利用現(xiàn)成的http協(xié)議 進行傳輸。但是如果是一個大型的網(wǎng)站琅催，內(nèi)部子系統(tǒng)較多居凶、接口非常多的情況下，RPC框架的好處就顯示出來了藤抡，首先（基于TCP協(xié)議的情況下）就是長鏈接侠碧，不必每次通信都要像http 一樣去3次握手什么的，減少了網(wǎng)絡開銷缠黍；其次就是RPC框架一般都有注冊中心弄兜，有豐富的監(jiān)控管理；發(fā)布嫁佳、下線接口挨队、動態(tài)擴展等，對調(diào)用方來說是無感知蒿往、統(tǒng) 一化的操作盛垦。第三個來說就是安全性。最后就是最近流行的服務化架構(gòu)瓤漏、服務化治理腾夯，RPC框架是一個強力的支撐。
RPC 中要解決的問題：
- 建立通信：在客戶端與服務端建立起數(shù)據(jù)傳輸通道蔬充，大都是TCP連接（gRPC使用了HTTP2）蝶俱。
- 尋址：A服務器上的應用需要告訴RPC框架：B服務器地址、端口饥漫，調(diào)用函數(shù)名稱榨呆。所以必須實現(xiàn)待調(diào)用方法到call ID的映射。
- 序列化與反序列化：由于網(wǎng)絡協(xié)議都是二進制的庸队，所以調(diào)用方法的參數(shù)在進行傳遞時首先要序列化成二進制积蜻，B服務器收到請求后要再對參數(shù)進行反序列化〕瓜恢復為內(nèi)存中的表達方式竿拆，找到對應的方法進行本地調(diào)用，得到返回值宾尚。返回值從B到A的傳輸仍要經(jīng)過序列化與反序列化的過程丙笋。
常見名詞小結(jié)
| 名詞 | 特點 |
|---|---|
| RPC | 遠程過程調(diào)用（分布式谢澈、微服務間的方法調(diào)用） |
| HTTP | 無狀態(tài)，每次請求都要發(fā)送一個request御板，服務器響應之后就斷掉（http header中的keep-alive指的是tcp） |
| TCP | 面向連接锥忿，三次握手保證通信可靠 |
| UDP | 非面向連接，不可靠怠肋，速度快（可以手動對數(shù)據(jù)收發(fā)進行驗證缎谷，IM系統(tǒng)多采用，QQ） |
| socket | TCP協(xié)議的接口實現(xiàn)灶似，面向傳輸層進行網(wǎng)絡編程 |
單獨來談一談gRPC
gRPC是谷歌開源的一個 RPC 框架，面向移動和 HTTP/2 設計瑞你。
- 內(nèi)容交換格式采用ProtoBuf(Google Protocol Buffers)酪惭，開源已久，提供了一種靈活者甲、高效春感、自動序列化結(jié)構(gòu)數(shù)據(jù)的機制，作用與XML虏缸，Json類似鲫懒，但使用二進制，（反）序列化速度快刽辙，壓縮效率高窥岩。
- 傳輸協(xié)議 采用http2，性能比http1.1好了很多
和很多RPC系統(tǒng)一樣宰缤，服務端負責實現(xiàn)定義好的接口并處理客戶端的請求颂翼，客戶端根據(jù)接口描述直接調(diào)用需要的服務】穑客戶端和服務端可以分別使用gPRC支持的不同語言實現(xiàn)朦乏。
ProtoBuf 具有強大的IDL（interface description language，接口描述語言）和相關(guān)工具集（主要是protoc）氧骤。用戶寫好.proto描述文件后呻疹，protoc可以將其編譯成眾多語言的接口代碼。
補充：HTTP/2介紹
新特性：
-
新的二進制格式
HTTP1.X都是基于文本解析筹陵，而因為文本表現(xiàn)形式的多樣性刽锤，基于文本協(xié)議的格式解析天然存在健壯性問題。而采用二進制格式后實現(xiàn)方便且健壯惶翻。
-
多路復用
多個request共享一個連接姑蓝。
-
header壓縮
在HTTP1.x中header信息很多，且每次都會重復發(fā)送吕粗，造成很大浪費纺荧。HTTP2.0使用encoder減少了傳輸?shù)膆eader大小，且通信雙方都緩存一份包含了header信息的表，此后的請求可以只發(fā)送差異數(shù)據(jù)宙暇，避免信息的重復傳輸输枯，進一步減少需要傳輸?shù)膬?nèi)容大小。
-
服務端推送
主要的思想是：當一個客戶端請求資源X占贫，而服務器知道它很可能也需要資源Z的情況下桃熄，服務器可以在客戶端發(fā)送請求前，主動將資源Z推送給客戶端型奥。這個功能幫助客戶端將Z放進緩存以備將來之需瞳收。也遵守同源策略，且客戶端可以拒絕推送過來的資源厢汹。
