身為 Java Web 開發(fā)我發(fā)現(xiàn)很多人一些 Web 基礎問題都答不上來从隆。
上周我面試了一個三年經(jīng)驗的小伙子诚撵，一開始我問他 HTTP/1、HTTP/2相關的他到是能答點東西出來键闺。
后來我問他：你怎么理解 HTTP 的寿烟，HTTP 的作用是什么？
他支支吾吾答不出來辛燥。
經(jīng)過了一番引導交談筛武，他回答是用來客戶端和服務端之間傳輸?shù)摹?/p>
我接著問那你知道什么是 HTTP 和 RPC 的關系嗎？
為什么要有 RPC挎塌？
他眼睛盯著桌上的水徘六，額了半天。
最后我跟他說回家等通知吧（當然還有很多都答不上來哈榴都，多方位我都問了）待锈。
面完試之后我回去問了同事相同的問題，我發(fā)現(xiàn)答的也不夠好嘴高，有些地方有點混淆竿音。
所以今兒我就整理一波來說說這類問題，相信看完文章之后你會有進一步的認識拴驮。
HTTP 的本質(zhì)
首先你要明確 HTTP 是一個協(xié)議谍失，是一個超文本傳輸協(xié)議。
它基于 TCP/IP 來傳輸文本莹汤、圖片快鱼、視頻、音頻等。
重點來了抹竹。
HTTP 不提供數(shù)據(jù)包的傳輸功能线罕，也就是數(shù)據(jù)包從瀏覽器到服務端再來回的傳輸和它沒關系。
這是 TCP/IP 干的窃判。
那 HTTP 有啥用钞楼？我們來分析一波。
我們上網(wǎng)要么就是獲取一些信息來看袄琳，要么就是修改一些信息询件。
比如你用瀏覽器刷微博就是獲取信息，發(fā)微博就是修改信息唆樊。
所以說瀏覽器需要告知服務器它需要什么宛琅，這次的請求是要獲取哪些信息？發(fā)怎么樣的微博逗旁。
這就涉及到瀏覽器和服務器之間的通信交互嘿辟。
而交互就需要一種格式。
像你我之間的談話就用中文片效，你要突然換成俄語我聽不懂那不就 GG 了红伦。
所以說 HTTP 它規(guī)定了一種格式，一種通信格式淀衣，大家都用這個格式來交談昙读。
這樣不論你是什么服務器、什么瀏覽器都能順利的交流膨桥，減少交互的成本蛮浑。
就像全世界如果都講中文，那我們不就不需要學英文了国撵，那不就較少交互的成本了陵吸。
不像現(xiàn)在我們還得學英文玻墅，不然就看不懂文檔等等介牙。
萬一之后俄語又起來了，咱還得對接俄文澳厢，這交互成本是不是就上來了环础。
而網(wǎng)絡世界還好，咱們現(xiàn)在的 Web 交互基本上就是 HTTP 了剩拢。
其實 HTTP 協(xié)議的格式很像我們信封线得，有個固定的格式。
左上角寫郵編徐伐，右上角貼郵票贯钩，然后地址姓名啥的依次來。
因為計算機是很死板的，不像我們?nèi)艘粯佑幸环N立體掃描感角雷，所以要規(guī)定先寫頭祸穷、再寫尾。
你要是先寫尾勺三，再寫頭計算機就認不出來了雷滚。
所以 HTTP 就規(guī)定了請求先搞請求行、再搞請求報頭吗坚、再搞請求體祈远。
響應就狀態(tài)行、響應報頭商源、響應體车份。
所以 HTTP 的本質(zhì)是什么？
就是客戶端和服務端約定好的一種通信格式炊汹。
對 HTTP 想有多的認識可以看我之前的文章 從 1950 年開始說起躬充，帶你看 HTTP 的演進之路
HTTP 和 RPC 的關系
HTTP 和 RPC 其實是兩個維度的東西， HTTP 指的是通信協(xié)議讨便。
而 RPC 則是遠程調(diào)用充甚，其對應的是本地調(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)在都是微服務了殊轴，根據(jù)業(yè)務模塊做了不同的拆分衰倦，像用戶的服務不用我這個小組負責，我這小組只要寫訂單服務就行了旁理。
但是我們服務需要用到用戶的信息樊零，于是我們需要調(diào)用用戶小組的服務，于是代碼變成了以下這種
public User getUserById(Long id) {
return userConsumer.getUserById(id); // 這是遠程調(diào)用孽文，邏輯是用戶小組的服務實現(xiàn)的驻襟。
}
可能還有些小伙伴不太清楚，再來看個圖芋哭。
把之前的用戶實現(xiàn)拆分出來弄了一個用戶服務沉衣，訂單相關的也拆成了訂單服務，都單獨部署减牺。
這樣訂單相關的服務要獲取用戶的信息就需要遠程調(diào)用了豌习。
可以看到 RPC 就是通過網(wǎng)絡進行遠程調(diào)用存谎，訂單服務其實就是客戶端，而用戶服務是服務端肥隆。
這又涉及到交互了愕贡，所以也需要約定一個格式，至于要不要用 HTTP 這個格式巷屿，就是大家自己看著辦固以。
至此相信你對 HTTP 是啥也清楚了。
RPC 和 HTTP 的之間的關系也清楚了嘱巾。
下次再也不怕被面試官問這個了憨琳。
那為什么要有 RPC？
可能你常聽到什么什么之間是 RPC 調(diào)用的旬昭，那你有沒有想過為什么要 RPC篙螟， 我們直接 WebClient HTTP 調(diào)用不行么？
其實 RPC 調(diào)用是因為服務的拆分问拘，或者本身公司內(nèi)部的多個服務之間的通信遍略。
服務的拆分獨立部署，那服務間的調(diào)用就必然需要網(wǎng)絡通信骤坐，用 WebClient 調(diào)用當然可行绪杏，但是比較麻煩。
我們想即使服務被拆分了但是使用起來還是和之前本地調(diào)用一樣方便纽绍。
所以就出現(xiàn)了 RPC 框架蕾久，來屏蔽這些底層調(diào)用細節(jié)，使得我們編碼上還是和之前本地調(diào)用相差不多拌夏。
并且 HTTP 協(xié)議比較的冗余僧著，RPC 都是內(nèi)部調(diào)用所以不需要太考慮通用性，只要公司內(nèi)部保持格式統(tǒng)一即可障簿。
所以可以做各種定制化的協(xié)議來使得通信更高效盹愚。
比如規(guī)定 yes 代表 yes的練級攻略，你看是不是更高效了站故，少傳輸?shù)?5 個字皆怕。
就像特殊行動的暗號，高效簡潔世蔗！
所以公司內(nèi)部服務的調(diào)用一般都用 RPC端逼，而 HTTP 的優(yōu)勢在于通用朗兵，大家都認可這個協(xié)議污淋。
所以三方平臺提供的接口都是通過 HTTP 協(xié)議調(diào)用的。
所以現(xiàn)在知道為什么我們調(diào)用第三方都是 HTTP 余掖，公司內(nèi)部用 RPC 了吧寸爆？
對了礁鲁。
上面這段話看起來仿佛 HTTP 和 RPC 是對等關系，不過相信大家看了之前的解析心里應該都有數(shù)了赁豆。
最后
最近幾次面試下來我發(fā)現(xiàn)挺多同學基礎還是挺薄弱的仅醇。
地基要牢啊，八股文得背沒錯魔种，但是這種基本概念性的東西還是有必要清晰的析二。
看起來好像對平時的編碼沒什么用，但是這可以認為是一個“世界觀”节预。
這對于一些事物的判斷和認知有很重要的意義叶摄。
你站的高才能看的遠。
對了安拟，理解了 HTTP 的本質(zhì)相信你對 RESTful 風格也應該會有更深一層的理解蛤吓。
HTTP 它是協(xié)議，不是運輸通道糠赦。
下一篇我會剖析下 RESTful 会傲，讓你知其然知其所以然。
平日的面試題遇到難處拙泽，或者看某個知識點翻遍全網(wǎng)的資料還是感覺很模糊淌山、不透徹，可以私聊我顾瞻，給我留言艾岂。
遇到合適的我會整理寫出一篇文章，注意這個前提我認為合適的朋其。
那種工作遇到很細節(jié)的場景的還是別了王浴，這種問你上司比較合適：）。
我是 yes梅猿，從一點點到億點點氓辣，歡迎在看、轉(zhuǎn)發(fā)袱蚓、留言钞啸，我們下篇見。
