上周我面了個(gè)三年Javaer，這幾個(gè)問題都沒答出來

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

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

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

他支支吾吾答不出來。

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

為什么要有 RPC？

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

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

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

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

HTTP 的本質(zhì)

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

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

重點(diǎn)來了。

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

這是 TCP/IP 干的。

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

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

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

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

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

而交互就需要一種格式。

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

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

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

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

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

萬(wàn)一之后俄語(yǔ)又起來了，咱還得對(duì)接俄文，這交互成本是不是就上來了。

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

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

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

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

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

所以 HTTP 就規(guī)定了請(qǐng)求先搞請(qǐng)求行、再搞請(qǐng)求報(bào)頭、再搞請(qǐng)求體。

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

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

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

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

HTTP 和 RPC 的關(guān)系

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

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

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

像之前的單體時(shí)代，我們的 service 調(diào)用就是自己實(shí)現(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ù)不用我這個(gè)小組負(fù)責(zé)，我這小組只要寫訂單服務(wù)就行了。

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

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

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

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

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

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

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

至此相信你對(duì) HTTP 是啥也清楚了。

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

下次再也不怕被面試官問這個(gè)了。

那為什么要有 RPC？

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

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

服務(wù)的拆分獨(dú)立部署，那服務(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的練級(jí)攻略，你看是不是更高效了，少傳輸?shù)?5 個(gè)字。

就像特殊行動(dòng)的暗號(hào)，高效簡(jiǎn)潔！

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

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

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

對(duì)了。

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

最后

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

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

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

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

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

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

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