一、HTTP與RPC基本介紹
- HTTP協(xié)議（Hyper Text Transfer Protocol）超文本傳輸協(xié)議：
- 一個(gè)用于在網(wǎng)絡(luò)上交換信息的標(biāo)準(zhǔn)協(xié)議，它定義了客戶端(例如瀏覽器)和服務(wù)器之間的通信方式。如平時(shí)上網(wǎng)在瀏覽器上敲個(gè)網(wǎng)址url就能訪問網(wǎng)頁，這里用到的就是HTTP協(xié)議。
- 明確 HTTP 是一個(gè)協(xié)議，是一個(gè)超文本傳輸協(xié)議，不是運(yùn)輸通道。它基于 TCP/IP 來傳輸文本、圖片、視頻、音頻等。HTTP 不提供數(shù)據(jù)包的傳輸功能，也就是數(shù)據(jù)包從瀏覽器到服務(wù)端再來回的傳輸和HTTP沒關(guān)系。
- HTTP最早版本在1989年提出,經(jīng)過多年發(fā)展,到1996年發(fā)布的HTTP/1.1版本一直沿用至今，而在2015年也出現(xiàn)了HTTP/2.0。
- RPC（Remote Procedure Call）遠(yuǎn)程過程調(diào)用：
- 能夠調(diào)用位于另一個(gè)地址空間(通常是網(wǎng)絡(luò)上的另一臺計(jì)算機(jī))中的函數(shù),而對程序員來說是透明的。僅僅是遠(yuǎn)程調(diào)用，還不算是RPC，因?yàn)镽PC強(qiáng)調(diào)的是過程調(diào)用，調(diào)用的過程對用戶而言是應(yīng)該是透明的，用戶不應(yīng)該關(guān)心調(diào)用的細(xì)節(jié)，可以像調(diào)用本地服務(wù)一樣調(diào)用遠(yuǎn)程服務(wù)。所以RPC一定要對調(diào)用的過程進(jìn)行封裝。
- 它本身并不是一個(gè)具體的協(xié)議，只是一種協(xié)議的規(guī)范，明確的說是概念、機(jī)制或者思想，它并沒有具體實(shí)現(xiàn)，只有按照RPC通信協(xié)議規(guī)范實(shí)現(xiàn)的通信框架，也就是RPC框架，才是協(xié)議的具體實(shí)現(xiàn)，比如Dubbo、gRPC等。它包括了：接口規(guī)范+序列化反序列化規(guī)范+通信協(xié)議等
- RPC的概念可以追溯到1970年代,但真正流行起來是1980年代中后期,隨著分布式計(jì)算的興起。1984年發(fā)布的ONC RPC和1986年的DCE RPC是最早的RPC實(shí)現(xiàn)。
在面試題中可能會看到為什么有了HTTP，還需要RPC，但由上述介紹可知，RPC的提出及使用時(shí)間均比HTTP要早，故首先需要思考第一個(gè)問題——為什么有RPC還要有HTTP協(xié)議？
二、為什么有了RPC，還需要HTTP
2.1 歷史追溯——B/S與C/S架構(gòu)
首先，我們需要先了解 B/S 和 C/S 指的是兩種常見的軟件架構(gòu)模型:
- C/S:Client/Server,即客戶端/服務(wù)器架構(gòu)。
- 這種架構(gòu)中,客戶端和服務(wù)器是獨(dú)立的兩個(gè)程序,通過某種網(wǎng)絡(luò)協(xié)議進(jìn)行通信。
- 客戶端需要安裝專用的軟件來訪問服務(wù)器提供的服務(wù)。服務(wù)器提供各種功能給客戶端調(diào)用。典型的 C/S 架構(gòu)應(yīng)用如QQ、迅雷、游戲客戶端等各種需要安裝對應(yīng)軟件的服務(wù)
- C/S架構(gòu)的概念可以追溯到20世紀(jì)60年代隨著分布式計(jì)算的興起開始出現(xiàn)，但真正流行開來是80年代中后期。
- B/S:Browser/Server,即瀏覽器/服務(wù)器架構(gòu)。
- 這種架構(gòu)中,客戶端只需要使用 web 瀏覽器來訪問 web 服務(wù)器提供的服務(wù)。web 服務(wù)器提供 HTML、JavaScript、CSS 等頁面,瀏覽器負(fù)責(zé)展現(xiàn)。
- 典型的 B/S 架構(gòu)應(yīng)用就是 web 應(yīng)用。用戶只需要一個(gè)瀏覽器就可以訪問服務(wù)，而不需要安裝任何客戶端軟件。
- B/S架構(gòu)是與萬維網(wǎng)、HTTP協(xié)議同時(shí)出現(xiàn)的，大約出現(xiàn)于1989年。
因此由上可知，在剛開始C/S架構(gòu)流行時(shí)，對于C/S架構(gòu)下的軟件,如聊天軟件、辦公軟件等，它們只需要與自己公司的服務(wù)器通信,所以可以使用自家定制的RPC協(xié)議進(jìn)行遠(yuǎn)程調(diào)用即可。但隨著萬維網(wǎng)與B/S架構(gòu)的出現(xiàn)，瀏覽器產(chǎn)生了，而瀏覽器需要訪問來自不同公司的很多網(wǎng)站，這不能通過RPC進(jìn)行訪問，所以需要一個(gè)統(tǒng)一的標(biāo)準(zhǔn)來與這些網(wǎng)站服務(wù)器通信。這就是HTTP協(xié)議發(fā)揮作用的地方。HTTP為B/S架構(gòu)(瀏覽器/服務(wù)器架構(gòu))提供了一個(gè)統(tǒng)一的標(biāo)準(zhǔn),讓不同網(wǎng)站的服務(wù)器能夠與瀏覽器交互。
2.2 RPC與HTTP主流應(yīng)用場景
由以上分析可知，在多年前，RPC與HTTP有對應(yīng)的主流應(yīng)用場景
- RPC 更多用于 C/S 架構(gòu),即客戶端(Client)和服務(wù)器(Server)之間的通信。因?yàn)?C/S 架構(gòu)通常是 within an organization(一個(gè)組織內(nèi)部),所以可以使用自家定制的 RPC 協(xié)議來實(shí)現(xiàn)客戶端和服務(wù)器之間的通信。
- HTTP 主要用于 B/S 架構(gòu),即瀏覽器(Browser)和服務(wù)器(Server)之間的通信。因?yàn)闉g覽器需要一個(gè)統(tǒng)一的標(biāo)準(zhǔn)來訪問不同網(wǎng)站的服務(wù)器,所以 HTTP 成為了 B/S 架構(gòu)的標(biāo)準(zhǔn)協(xié)議。而HTTP發(fā)明的場景是用于web架構(gòu)，而不是分布式系統(tǒng)間通信，這導(dǎo)致了在很長一段時(shí)間內(nèi)，HTTP是瀏覽器程序和后端web系統(tǒng)通信用的東西，傳輸?shù)奈臋n格式是繁瑣的HTML格式，因此沒有人把HTTP作為分布式系統(tǒng)通信的協(xié)議。
但是隨著用戶需要，許多軟件同時(shí)支持多端，現(xiàn)在情況已經(jīng)變化，B/S 架構(gòu)和 C/S 架構(gòu)在慢慢融合。越來越多的應(yīng)用同時(shí)支持 Web 端、手機(jī)端和 PC 端。
- 隨著前端技術(shù)的發(fā)展，AJAX技術(shù)和JSON文檔在前端界逐漸成為主流，HTTP調(diào)用擺脫HTML，開始使用JSON這一相對簡潔的文檔格式。之后隨著RESTFUL思潮的興起，越來越多系統(tǒng)用HTTP來提供服務(wù)。因此為了簡化架構(gòu)，現(xiàn)在很多應(yīng)用選擇使用 HTTP 作為統(tǒng)一的通信協(xié)議，來支持多端通信。這使服務(wù)器端只需要實(shí)現(xiàn)一次 HTTP 接口，就可以支持所有客戶端。
- 而 RPC 協(xié)議則主要用于 within an organization(一個(gè)組織內(nèi)部),比如公司內(nèi)部的微服務(wù)(Microservices)之間的通信。
- 所以總的趨勢是:HTTP 作為公用的標(biāo)準(zhǔn)協(xié)議不斷普及，而自家定制的 RPC 協(xié)議則主要用于內(nèi)部集群(Cluster)。
而由上介紹，我們可以知道HTTP既可以用于B/S端，也可以用于C/S端，那這樣為什么不全部使用HTTP協(xié)議呢，即引出了接下來的經(jīng)典面試問題——為什么有了HTTP，還需要RPC
3. 為什么有了HTTP，還需要RPC
3.1 HTTP與RPC對比分析
HTTP通常指的是HTTP1.1版本，在對HTTP1.1與RPC進(jìn)行分析時(shí)，一般會從以下方面進(jìn)行分析：
| 特點(diǎn) | HTTP 1.1 | RPC |
|---|---|---|
| 協(xié)議用途 | 對外的異構(gòu)環(huán)境，瀏覽器接?調(diào)?，APP接?調(diào)?，第三?接?調(diào)?等 | 公司內(nèi)部的服務(wù)調(diào)?，性能消耗低，傳輸效率?，服務(wù)治理 |
| 通信方式 | 請求-響應(yīng)模型，獨(dú)立連接 | 調(diào)用-返回模型，長連接 |
| 傳輸協(xié)議 | 通過HTTP1.1傳輸，報(bào)文體積大 | 自定義TCP協(xié)議傳輸，也可以基于HTTP協(xié)議 |
| 序列化 | 文本或二進(jìn)制 ，大多使用json ，也可以使用 protobuf 二進(jìn)制編碼 | 文本或二進(jìn)制 |
| 通信效率 | 可支持連接池復(fù)用 | 多次調(diào)用在同一連接中，通信效率較高 |
| 數(shù)據(jù)格式 | 使用通用的數(shù)據(jù)格式，如JSON、XML等 | 可以使用自定義的IDL來定義接口 |
| 接口定義和調(diào)用 | 使用URL標(biāo)識資源和進(jìn)行請求與響應(yīng) | 使用接口描述語言定義接口和方法 |
| 安全性和認(rèn)證 | 可使用TLS/SSL | 身份驗(yàn)證、加密和授權(quán) |
如上所示， HTTP 1.1和RPC確實(shí)存在差異。
- 通信方式：RPC 是長鏈接，不必每次通信都要像 HTTP 一樣去進(jìn)行 3 次握手，減少了網(wǎng)絡(luò)開銷。
- 傳輸協(xié)議差異：HTTP 1.1使用文本協(xié)議，傳輸時(shí)必須包括報(bào)文頭部與報(bào)文體，報(bào)文頭部包含大量元數(shù)據(jù)，這使得每次通信的開銷較高。相比之下，RPC可以使用自定義的傳輸協(xié)議，報(bào)文頭部較小，不需要像HTTP那樣考慮各種瀏覽器行為，如302重定向跳轉(zhuǎn)，只含有必要的元數(shù)據(jù)，在遠(yuǎn)程調(diào)用時(shí)減少了通信的開銷。
- 序列化差異：HTTP 1.1常用的序列化格式是文本格式，如JSON、XML等。盡管可以使用二進(jìn)制編碼協(xié)議如Protobuf對內(nèi)容進(jìn)行編碼，但由于二進(jìn)制編碼的可讀性較差，使用較少，且在打開網(wǎng)頁時(shí)進(jìn)行序列化json等文本格式的時(shí)間也可忽略不計(jì)，故通常在HTTP應(yīng)用中，文本格式更為普遍。而在RPC中，由于通常用于服務(wù)間通信如游戲服務(wù)器，性能和效率更為重要，因此更常使用二進(jìn)制編碼協(xié)議。
3.2 HTTP 2.0
隨著HTTP的發(fā)展，出現(xiàn)了HTTP 2.0和HTTP 3.0。 HTTP/2和HTTP/3在傳輸協(xié)議和性能方面都對HTTP/1.1進(jìn)行了重要改進(jìn)。它們都采用了二進(jìn)制協(xié)議格式，可以更高效地傳輸數(shù)據(jù)。同時(shí)，它們都支持多路復(fù)用，可以同時(shí)在一個(gè)連接上發(fā)送多個(gè)請求和響應(yīng)，減少了網(wǎng)絡(luò)延遲和資源浪費(fèi)。HTTP/2還引入了頭部壓縮技術(shù)，可以減小報(bào)文頭的大小，提高傳輸效率。而HTTP/3則采用了QUIC協(xié)議和UDP傳輸，可以更快地建立連接并傳輸數(shù)據(jù)，提高了實(shí)時(shí)性和可靠性。
1. 回顧 Http1.x協(xié)議
Http1.0協(xié)議 請求響應(yīng)的模式 短連接協(xié)議（無狀態(tài)協(xié)議） 傳輸數(shù)據(jù)文本結(jié)構(gòu) 單工 無法實(shí)現(xiàn)服務(wù)端推送 變相實(shí)現(xiàn)推動（客戶端輪訓(xùn)的方式）
Http1.1協(xié)議 請求響應(yīng)的模式 有限的長連接（可升級為WebSocket） 傳輸數(shù)據(jù)文本結(jié)構(gòu) 雙工 實(shí)現(xiàn)服務(wù)器向客戶端推送。
總結(jié)Http1.x協(xié)議 共性
1. 傳輸數(shù)據(jù)文本格式 可讀性好的但是效率差。
2. 本質(zhì)上Http1.x協(xié)議無法實(shí)現(xiàn)雙工通信。
3. 資源的請求。需要發(fā)送多次請求，建立多個(gè)連接才可以完成，如請求頁面需要html，js，css，則需要建立3次連接。
2. HTTP2.0協(xié)議
1. Http2.0協(xié)議是一個(gè)二進(jìn)制協(xié)議，效率高于Http1.x協(xié)議，可讀性差。
2. 可以實(shí)現(xiàn)雙工通信。
3. 一個(gè)請求 一個(gè)連接 可以請求多個(gè)數(shù)據(jù)。【多路復(fù)用】
3. Http2.0協(xié)議的三個(gè)概念
1. 數(shù)據(jù)流 stream
2. 消息 message
3. 幀 frame 參看圖
4. 其他的相關(guān)概念
1. 數(shù)據(jù)流的優(yōu)先級，可以通過為不同的stream設(shè)置權(quán)重，來限制不同流的傳輸順序。
2. 流控 client發(fā)送的數(shù)據(jù)太快了，server處理不過來，通知client暫停數(shù)據(jù)的發(fā)送。
總結(jié)來說，HTTP/1.1相對于RPC在傳輸協(xié)議和性能方面有一些不足，但是隨著HTTP/2和HTTP/3的出現(xiàn)，HTTP協(xié)議在這些方面得到了很大的改進(jìn)，使得它在某些場景下可以替代RPC來進(jìn)行高效的數(shù)據(jù)傳輸。如當(dāng)前流行的gRPC框架底層就使用HTTP2.0 協(xié)議進(jìn)行通信。
當(dāng)然2015年才出現(xiàn)HTTP 2.0，因此在2015年之前使用RPC可以從效率方面進(jìn)行考慮，但如今已經(jīng)出現(xiàn)了效率一樣的HTTP2.0，為什么還需要繼續(xù)使用RPC呢？
3.3 為什么還需要使用RPC
根據(jù)上述對比分析，可以發(fā)現(xiàn)HTTP2.0協(xié)議已經(jīng)優(yōu)化編碼效率問題，像 grpc 這種 rpc 庫使用的就是 http2.0協(xié)議，那么為什么還需要使用RPC進(jìn)行遠(yuǎn)程調(diào)用呢？
首先是歷史原因，HTTP2.0在2015年才出現(xiàn)，因此許多公司內(nèi)部已經(jīng)使用了很久的PPC，更換需要很大的成本。
而之前說過，RPC并不是一個(gè)具體的協(xié)議，只是一種協(xié)議的規(guī)范，明確的說是概念、機(jī)制或者思想，它并沒有具體實(shí)現(xiàn)，只有按照RPC通信協(xié)議規(guī)范實(shí)現(xiàn)的通信框架，也就是RPC框架，才是協(xié)議的具體實(shí)現(xiàn)，它包括了：接口規(guī)范+序列化反序列化規(guī)范+通信協(xié)議等。現(xiàn)在狹義的RPC一般指一些用IDL(Inteface Description Language)描述接口， 然后生成stub的框架, 比如grpc,thrift,dubbo等，其中g(shù)rpc,dubbo3.0的傳輸用的都是HTTP2.0，也已經(jīng)屬于RPC和HTTP的融合體了，這種融合體的設(shè)計(jì)使得開發(fā)人員可以享受到HTTP的廣泛支持，同時(shí)獲得更好的性能和功能。
當(dāng)我們使用比較成熟的RPC庫時(shí)，RPC庫通常提供了更多面向服務(wù)的高級特性，如服務(wù)發(fā)現(xiàn)、負(fù)載均衡和熔斷降級等。
- 服務(wù)發(fā)現(xiàn)：RPC庫可以提供服務(wù)注冊和發(fā)現(xiàn)的機(jī)制，使得服務(wù)之間的通信更加靈活和可靠。通過服務(wù)發(fā)現(xiàn)，服務(wù)可以自動注冊自己的地址和狀態(tài)，并且客戶端可以動態(tài)地發(fā)現(xiàn)可用的服務(wù)實(shí)例。這樣，當(dāng)服務(wù)實(shí)例發(fā)生變化時(shí)，客戶端可以自動適應(yīng)并調(diào)用可用的服務(wù)。
建立連接的前提是，你得知道IP地址和端口。這個(gè)找到服務(wù)對應(yīng)的IP端口的過程，其實(shí)就是服務(wù)發(fā)現(xiàn)。在HTTP中，你知道服務(wù)的域名，就可以通過DNS服務(wù)去解析得到它背后的IP地址，默認(rèn)80端口。而RPC的話，就有些區(qū)別，一般會有專門的中間服務(wù)去保存服務(wù)名和IP信息，比如consul或者etcd，甚至是redis。想要訪問某個(gè)服務(wù)，就去這些中間服務(wù)去獲得IP和端口信息。由于dns也是服務(wù)發(fā)現(xiàn)的一種，所以也有基于dns去做服務(wù)發(fā)現(xiàn)的組件，比如CoreDNS。文章來源：http://www.zghlxwxcb.cn/news/detail-567885.html
- 負(fù)載均衡：RPC庫可以支持負(fù)載均衡算法，用于將請求動態(tài)地分配到不同的服務(wù)實(shí)例上。負(fù)載均衡可以根據(jù)實(shí)際情況，如服務(wù)實(shí)例的負(fù)載情況、網(wǎng)絡(luò)延遲等，來決定將請求發(fā)送到哪個(gè)服務(wù)實(shí)例上，以實(shí)現(xiàn)請求的均衡分配和提高系統(tǒng)的性能和可伸縮性。
- 熔斷降級：RPC庫可以實(shí)現(xiàn)熔斷降級機(jī)制，用于處理服務(wù)不可用或響應(yīng)時(shí)間過長的情況。當(dāng)某個(gè)服務(wù)出現(xiàn)故障或性能下降時(shí)，熔斷降級可以自動切換到備用服務(wù)或返回默認(rèn)值，以保證系統(tǒng)的穩(wěn)定性和可用性。熔斷降級還可以防止故障的擴(kuò)散，避免整個(gè)系統(tǒng)崩潰。
總的來說，RPC框架對比HTTP協(xié)議多了更高級的封裝，它提供了服務(wù)發(fā)現(xiàn)、負(fù)載均衡和熔斷降級等面向服務(wù)的高級特性。這些特性使得RPC框架在構(gòu)建分布式微服務(wù)系統(tǒng)時(shí)更加方便和可靠，能夠提供更好的性能、可伸縮性和容錯(cuò)能力。文章來源地址http://www.zghlxwxcb.cn/news/detail-567885.html
到了這里，關(guān)于網(wǎng)絡(luò)編程——RPC與HTTP基本介紹、歷史追溯、主流應(yīng)用場景、對比分析、為什么還需要使用RPC的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
