身為 ?Java Web 開發(fā)我發(fā)現(xiàn)很多人一些 Web 基礎(chǔ)問題都答不上來。

上周我面試了一個三年經(jīng)驗的小伙子，一開始我問他 HTTP/1、HTTP/2相關(guān)的他到是能答點東西出來。

后來我問他：你知道 HTTP 的本質(zhì)是什么嗎？

他支支吾吾答不出來。

我接著問那你知道什么是 HTTP 和 RPC 的關(guān)系嗎？

為什么要有 RPC？

他眼睛盯著桌上的水，額了半天。

最后我跟他說回家等通知吧（當(dāng)然還有很多都答不上來哈，多方位我都問了）。

面完試之后我回去問了同事相同的問題，我發(fā)現(xiàn)答的也不夠好，有些地方有點混淆。

所以今兒我就整理一波來說說這類問題，相信看完文章之后你會有進(jìn)一步的認(rèn)識。

HTTP 的本質(zhì)

首先你要明確 HTTP 是一個協(xié)議，是一個超文本傳輸協(xié)議。

它基于 TCP/IP 來傳輸文本、圖片、視頻、音頻等。

重點來了。

HTTP 不提供數(shù)據(jù)包的傳輸功能，也就是數(shù)據(jù)包從瀏覽器到服務(wù)端再來回的傳輸和它沒關(guān)系。

這是 TCP/IP 干的。

那 HTTP 有啥用？我們來分析一波。

我們上網(wǎng)要么就是獲取一些信息來看，要么就是修改一些信息。

比如你用瀏覽器刷微博就是獲取信息，發(fā)微博就是修改信息。

所以說瀏覽器需要告知服務(wù)器它需要什么，這次的請求是要獲取哪些信息？發(fā)怎么樣的微博。

這就涉及到瀏覽器和服務(wù)器之間的通信交互。

而交互就需要一種格式。

像你我之間的談話就用中文，你要突然換成俄語我聽不懂那不就 GG 了。

所以說 HTTP 它規(guī)定了一種格式，一種通信格式，大家都用這個格式來交談。

這樣不論你是什么服務(wù)器、什么瀏覽器都能順利的交流，減少交互的成本。

就像全世界如果都講中文，那我們不就不需要學(xué)英文了，那不就較少交互的成本了。

不像現(xiàn)在我們還得學(xué)英文，不然就看不懂文檔等等。

萬一之后俄語又起來了，咱還得對接俄文，這交互成本是不是就上來了。

而網(wǎng)絡(luò)世界還好，咱們現(xiàn)在的 Web 交互基本上就是 HTTP 了。

其實 HTTP 協(xié)議的格式很像我們信封，有個固定的格式。

左上角寫郵編，右上角貼郵票，然后地址姓名啥的依次來。

因為計算機(jī)是很死板的，不像我們?nèi)艘粯佑幸环N立體掃描感，所以要規(guī)定先寫頭、再寫尾。

你要是先寫尾，再寫頭計算機(jī)就認(rèn)不出來了。

所以 HTTP 就規(guī)定了請求先搞請求行、再搞請求報頭、再搞請求體。

響應(yīng)就狀態(tài)行、響應(yīng)報頭、響應(yīng)體。

所以 HTTP 的本質(zhì)是什么？

就是客戶端和服務(wù)端約定好的一種通信格式。

對 HTTP 想有多的認(rèn)識可以看我之前的文章 從 1950 年開始說起，帶你看 HTTP 的演進(jìn)之路

HTTP 和 RPC 的關(guān)系

HTTP 和 RPC 其實是兩個維度的東西， HTTP 指的是通信協(xié)議。

而 RPC 則是遠(yuǎn)程調(diào)用，其對應(yīng)的是本地調(diào)用。

RPC 的通信可以用 HTTP 協(xié)議，也可以自定義協(xié)議，是不做約束的。

像之前的單體時代，我們的 service 調(diào)用就是自己實現(xiàn)的方法，是本地進(jìn)程內(nèi)的調(diào)用。

????public?User?getUserById(Long?id)?{
???????return?userDao.getUserById(id);?//?這叫本地調(diào)用
????}

現(xiàn)在都是微服務(wù)了，根據(jù)業(yè)務(wù)模塊做了不同的拆分，像用戶的服務(wù)不用我這個小組負(fù)責(zé)，我這小組只要寫訂單服務(wù)就行了。

但是我們服務(wù)需要用到用戶的信息，于是我們需要調(diào)用用戶小組的服務(wù)，于是代碼變成了以下這種

????public?User?getUserById(Long?id)?{
???????return?userConsumer.getUserById(id);?//?這是遠(yuǎn)程調(diào)用，邏輯是用戶小組的服務(wù)實現(xiàn)的。
????}

可能還有些小伙伴不太清楚，再來看個圖。

把之前的用戶實現(xiàn)拆分出來弄了一個用戶服務(wù)，訂單相關(guān)的也拆成了訂單服務(wù)，都單獨部署。

這樣訂單相關(guān)的服務(wù)要獲取用戶的信息就需要遠(yuǎn)程調(diào)用了。

可以看到 RPC 就是通過網(wǎng)絡(luò)進(jìn)行遠(yuǎn)程調(diào)用，訂單服務(wù)其實就是客戶端，而用戶服務(wù)是服務(wù)端。

這又涉及到交互了，所以也需要約定一個格式，至于要不要用 HTTP 這個格式，就是大家自己看著辦。

至此相信你對 HTTP 是啥也清楚了。

RPC 和 HTTP 的之間的關(guān)系也清楚了。

下次再也不怕被面試官問這個了。

那為什么要有 RPC？

可能你常聽到什么什么之間是 RPC 調(diào)用的，那你有沒有想過為什么要 RPC， 我們直接 WebClient HTTP 調(diào)用不行么？

其實 RPC 調(diào)用是因為服務(wù)的拆分，或者本身公司內(nèi)部的多個服務(wù)之間的通信。

服務(wù)的拆分獨立部署，那服務(wù)間的調(diào)用就必然需要網(wǎng)絡(luò)通信，用 WebClient 調(diào)用當(dāng)然可行，但是比較麻煩。

我們想即使服務(wù)被拆分了但是使用起來還是和之前本地調(diào)用一樣方便。

所以就出現(xiàn)了 RPC 框架，來屏蔽這些底層調(diào)用細(xì)節(jié)，使得我們編碼上還是和之前本地調(diào)用相差不多。

并且 HTTP 協(xié)議比較的冗余，RPC 都是內(nèi)部調(diào)用所以不需要太考慮通用性，只要公司內(nèi)部保持格式統(tǒng)一即可。

所以可以做各種定制化的協(xié)議來使得通信更高效。

比如規(guī)定 yes 代表 yes的練級攻略，你看是不是更高效了，少傳輸?shù)?5 個字。

就像特殊行動的暗號，高效簡潔！

所以公司內(nèi)部服務(wù)的調(diào)用一般都用 RPC，而 HTTP 的優(yōu)勢在于通用，大家都認(rèn)可這個協(xié)議。

所以三方平臺提供的接口都是通過 HTTP 協(xié)議調(diào)用的。

所以現(xiàn)在知道為什么我們調(diào)用第三方都是 HTTP ，公司內(nèi)部用 RPC 了吧？

對了。

上面這段話看起來仿佛 HTTP 和 RPC 是對等關(guān)系，不過相信大家看了之前的解析心里應(yīng)該都有數(shù)了。

最后

最近幾次面試下來我發(fā)現(xiàn)挺多同學(xué)基礎(chǔ)還是挺薄弱的。

地基要牢啊，八股文得背沒錯，但是這種基本概念性的東西還是有必要清晰。

看起來好像對平時的編碼沒什么用，但是這可以認(rèn)為是一個“世界觀”。

這對于一些事物的判斷和認(rèn)知有很重要的意義。

你站的高才能看的遠(yuǎn)。

對了，理解了 HTTP 的本質(zhì)相信你對 RESTful 風(fēng)格也應(yīng)該會有更深一層的理解。

HTTP 它是協(xié)議，不是運(yùn)輸通道。