身為 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 的演進之路](https://mp.weixin.qq.com/s/No2cusaCeKvcEHUafyAG7A) ## 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 字的走心演算法攻略等你來領取，我們下篇見。**