今兒發了這篇文章很有意思，第一次這麼多評論，儘管都是批評的。
確實我寫的容易讓人產生誤解，真實的面試場景是引導的問，不可能就拋一個 HTTP 的本質就等著回答，是有互動的。
而且也不是因為這一個問題沒答出來就掛了，多方位的我都問了。
問這個問題的原因是 HTTP 的演進他說的頭頭是道，我就問了他這個問題，不是顯擺什麼，這能顯擺啥？
身為 Java Web 開發我發現很多人一些 Web 基礎問題都答不上來。
上週我面試了一個三年經驗的小夥子，一開始我問他 HTTP/1、HTTP/2相關的他到是能答點東西出來。
後來我問他：你知道 HTTP 的本質是什麼嗎？或者說它有什麼作用，是用來幹嘛的？
他支支吾吾答不出來。
我接著問那你知道什麼是 HTTP 和 RPC 的關係嗎？
為什麼要有 RPC？
他眼睛盯著桌上的水，額了半天。
最後我跟他說回家等通知吧（當然還有很多都答不上來哈，多方位我都問了）。
面完試之後我回去問了同事相同的問題，我發現答的也不夠好，有些地方有點混淆。
所以今兒我就整理一波來說說這類問題，相信看完文章之後你會有進一步的認識。
HTTP 的本質
首先你要明確 HTTP 是一個協議，是一個超文字傳輸協議。
它基於 TCP/IP 來傳輸文字、圖片、視訊、音訊等。
重點來了。
HTTP 不提供資料包的傳輸功能，也就是資料包從瀏覽器到服務端再來回的傳輸和它沒關係。
這是 TCP/IP 乾的。
那 HTTP 有啥用？我們來分析一波。
我們上網要麼就是獲取一些資訊來看，要麼就是修改一些資訊。
比如你用瀏覽器刷微博就是獲取資訊，發微博就是修改資訊。
所以說瀏覽器需要告知伺服器它需要什麼，這次的請求是要獲取哪些資訊？發怎麼樣的微博。
這就涉及到瀏覽器和伺服器之間的通訊互動。
而互動就需要一種格式。
像你我之間的談話就用中文，你要突然換成俄語我聽不懂那不就 GG 了。
所以說 HTTP 它規定了一種格式，一種通訊格式，大家都用這個格式來交談。
這樣不論你是什麼伺服器、什麼瀏覽器都能順利的交流，減少互動的成本。
就像全世界如果都講中文，那我們不就不需要學英文了，那不就較少互動的成本了。
不像現在我們還得學英文，不然就看不懂文件等等。
萬一之後俄語又起來了，我們還得對接俄文，這互動成本是不是就上來了。
而網路世界還好，我們們現在的 Web 互動基本上就是 HTTP 了。
其實 HTTP 協議的格式很像我們信封，有個固定的格式。
左上角寫郵編，右上角貼郵票，然後地址姓名啥的依次來。
因為計算機是很死板的，不像我們人一樣有一種立體掃描感，所以要規定先寫頭、再寫尾。
你要是先寫尾，再寫頭計算機就認不出來了。
所以 HTTP 就規定了請求先搞請求行、再搞請求報頭、再搞請求體。
響應就狀態行、響應報頭、響應體。
所以 HTTP 的本質是什麼？
就是客戶端和服務端約定好的一種通訊格式。
對 HTTP 想有多的認識可以看我之前的文章 從 1950 年開始說起，帶你看 HTTP 的演進之路
HTTP 和 RPC 的關係
HTTP 和 RPC 其實是兩個維度的東西， HTTP 指的是通訊協議。
而 RPC 則是遠端呼叫，其對應的是本地呼叫。
RPC 的通訊可以用 HTTP 協議，也可以自定義協議，是不做約束的。
像之前的單體時代，我們的 service 呼叫就是自己實現的方法，是本地程式內的呼叫。
public User getUserById(Long id) {
return userDao.getUserById(id); // 這叫本地呼叫
}
現在都是微服務了，根據業務模組做了不同的拆分，像使用者的服務不用我這個小組負責，我這小組只要寫訂單服務就行了。
但是我們服務需要用到使用者的資訊，於是我們需要呼叫使用者小組的服務，於是程式碼變成了以下這種
public User getUserById(Long id) {
return userConsumer.getUserById(id); // 這是遠端呼叫，邏輯是使用者小組的服務實現的。
}
可能還有些小夥伴不太清楚，再來看個圖。
把之前的使用者實現拆分出來弄了一個使用者服務，訂單相關的也拆成了訂單服務，都單獨部署。
這樣訂單相關的服務要獲取使用者的資訊就需要遠端呼叫了。
可以看到 RPC 就是通過網路進行遠端呼叫，訂單服務其實就是客戶端，而使用者服務是服務端。
這又涉及到互動了，所以也需要約定一個格式，至於要不要用 HTTP 這個格式，就是大家自己看著辦。
至此相信你對 HTTP 是啥也清楚了。
RPC 和 HTTP 的之間的關係也清楚了。
下次再也不怕被面試官問這個了。
那為什麼要有 RPC？
可能你常聽到什麼什麼之間是 RPC 呼叫的，那你有沒有想過為什麼要 RPC， 我們直接 WebClient HTTP 呼叫不行麼？
其實 RPC 呼叫是因為服務的拆分，或者本身公司內部的多個服務之間的通訊。
服務的拆分獨立部署，那服務間的呼叫就必然需要網路通訊，用 WebClient 呼叫當然可行，但是比較麻煩。
我們想即使服務被拆分了但是使用起來還是和之前本地呼叫一樣方便。
所以就出現了 RPC 框架，來遮蔽這些底層呼叫細節，使得我們編碼上還是和之前本地呼叫相差不多。
並且 HTTP 協議比較的冗餘，RPC 都是內部呼叫所以不需要太考慮通用性，只要公司內部保持格式統一即可。
所以可以做各種定製化的協議來使得通訊更高效。
比如規定 yes 代表 yes的練級攻略，你看是不是更高效了，少傳輸的 5 個字。
就像特殊行動的暗號，高效簡潔！
所以公司內部服務的呼叫一般都用 RPC，而 HTTP 的優勢在於通用，大家都認可這個協議。
所以三方平臺提供的介面都是通過 HTTP 協議呼叫的。
所以現在知道為什麼我們呼叫第三方都是 HTTP ，公司內部用 RPC 了吧？
對了。
上面這段話看起來彷彿 HTTP 和 RPC 是對等關係，不過相信大家看了之前的解析心裡應該都有數了。
最後
最近幾次面試下來我發現挺多同學基礎還是挺薄弱的。
地基要牢啊，八股文得背沒錯，但是這種基本概念性的東西還是有必要清晰的。
看起來好像對平時的編碼沒什麼用，但是這可以認為是一個“世界觀”。
這對於一些事物的判斷和認知有很重要的意義。
你站的高才能看的遠。
對了，理解了 HTTP 的本質相信你對 RESTful 風格也應該會有更深一層的理解。
HTTP 它是協議，不是運輸通道。
下一篇我會剖析下 RESTful ，讓你知其然知其所以然。
平日的面試題遇到難處，或者看某個知識點翻遍全網的資料還是感覺很模糊、不透徹，可以私聊我，給我留言。
遇到合適的我會整理寫出一篇文章，注意這個前提我認為合適的。
那種工作遇到很細節的場景的還是別了，這種問你上司比較合適：）。
我是 yes，從一點點到億點點，微信搜一搜「yes的練級攻略」第一時間閱讀，關注回覆「123」一份 20W 字的走心演算法攻略等你來領取，我們下篇見。
