身為 ?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)答的也不夠好，有些地方有點混淆。

所以今兒我就整理一波來說說這類問題，相信看完文章之后你會有進一步的認(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é)議的格式很像我們信封，有個固定的格式。

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

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

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

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

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

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

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

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

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)的方法，是本地進程內(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ò)進行遠(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é)議，不是運輸通道。