這樣理解 HTTP，面試再也不用慌了

HTTP 協議是個無狀態協議，不會儲存狀態。

先引入副作用和冪等的概念。

副作用指對伺服器上的資源做改變，搜尋是無副作用的，註冊是副作用的。

冪等指傳送 M 和 N 次請求（兩者不相同且都大於 1），伺服器上資源的狀態一致，比如註冊 10 個和 11 個帳號是不冪等的，對文章進行更改 10 次和 11 次是冪等的。

在規範的應用場景上說，Get 多用於無副作用，冪等的場景，例如搜尋關鍵字。Post 多用於副作用，不冪等的場景，例如註冊。

在技術上說：

• Get 請求能快取，Post 不能

• Post 相對 Get 安全一點點，因為Get 請求都包含在 URL 裡，且會被瀏覽器儲存歷史紀錄，Post 不會，但是在抓包的情況下都是一樣的。

• Post 可以透過 request body來傳輸比 Get 更多的資料，Get 沒有這個技術

• URL有長度限制，會影響 Get 請求，但是這個長度限制是瀏覽器規定的，不是 RFC 規定的

• Post 支援更多的編碼型別且不對資料型別限制

2XX 成功

• 200 OK，表示從客戶端發來的請求在伺服器端被正確處理

• 204 No content，表示請求成功，但響應報文不含實體的主體部分

• 205 Reset Content，表示請求成功，但響應報文不含實體的主體部分，但是與 204 響應不同在於要求請求方重置內容

• 206 Partial Content，進行範圍請求

3XX 重定向

• 301 moved permanently，永久性重定向，表示資源已被分配了新的 URL

• 302 found，臨時性重定向，表示資源臨時被分配了新的 URL

• 303 see other，表示資源存在著另一個 URL，應使用 GET 方法獲取資源

• 304 not modified，表示伺服器允許訪問資源，但因發生請求未滿足條件的情況

• 307 temporary redirect，臨時重定向，和302含義類似，但是期望客戶端保持請求方法不變向新的地址發出請求

4XX 客戶端錯誤

• 400 bad request，請求報文存在語法錯誤

• 401 unauthorized，表示傳送的請求需要有透過 HTTP 認證的認證資訊

• 403 forbidden，表示對請求資源的訪問被伺服器拒絕

• 404 not found，表示在伺服器上沒有找到請求的資源

5XX 伺服器錯誤

• 500 internal sever error，表示伺服器端在執行請求時發生了錯誤

• 501 Not Implemented，表示伺服器不支援當前請求所需要的某個功能

• 503 service unavailable，表明伺服器暫時處於超負載或正在停機維護，無法處理請求

HTTPS 還是通過了 HTTP 來傳輸資訊，但是資訊透過 TLS 協議進行了加密。

TLS 協議位於傳輸層之上，應用層之下。首次進行 TLS 協議傳輸需要兩個 RTT ，接下來可以透過 Session Resumption 減少到一個 RTT。

在 TLS 中使用了兩種加密技術，分別為：對稱加密和非對稱加密。

對稱加密：

對稱加密就是兩邊擁有相同的秘鑰，兩邊都知道如何將密文加密解密。

非對稱加密：

有公鑰私鑰之分，公鑰所有人都可以知道，可以將資料用公鑰加密，但是將資料解密必須使用私鑰解密，私鑰只有分發公鑰的一方才知道。

TLS 握手過程如下圖：

1. 客戶端傳送一個隨機值，需要的協議和加密方式

2. 服務端收到客戶端的隨機值，自己也產生一個隨機值，並根據客戶端需求的協議和加密方式來使用對應的方式，傳送自己的證書（如果需要驗證客戶端證書需要說明）

3. 客戶端收到服務端的證書並驗證是否有效，驗證透過會再生成一個隨機值，透過服務端證書的公鑰去加密這個隨機值併發送給服務端，如果服務端需要驗證客戶端證書的話會附帶證書

4. 服務端收到加密過的隨機值並使用私鑰解密獲得第三個隨機值，這時候兩端都擁有了三個隨機值，可以透過這三個隨機值按照之前約定的加密方式生成金鑰，接下來的通訊就可以透過該金鑰來加密解密

透過以上步驟可知，在 TLS 握手階段，兩端使用非對稱加密的方式來通 信，但是因為非對稱加密損耗的效能比對稱加密大，所以在正式傳輸資料時，兩端使用對稱加密的方式通訊。

PS：以上說明的都是 TLS 1.2 協議的握手情況，在 1.3 協議中，首次建立連線只需要一個 RTT，後面恢復連線不需要 RTT 了。

HTTP 2.0 相比於 HTTP 1.X，可以說是大幅度提高了 web 的效能。

在 HTTP 1.X 中，為了效能考慮，我們會引入雪碧圖、將小圖內聯、使用多個域名等等的方式。這一切都是因為瀏覽器限制了同一個域名下的請求數量，當頁面中需要請求很多資源的時候，隊頭阻塞（Head of line blocking）會導致在達到最大請求數量時，剩餘的資源需要等待其他資源請求完成後才能發起請求。

在 HTTP 1.X 中，因為隊頭阻塞的原因，你會發現請求是這樣的

在 HTTP 2.0 中，因為引入了多路複用，你會發現請求是這樣的

HTTP 2.0 中所有加強效能的核心點在於此。在之前的 HTTP 版本中，我們是透過文字的方式傳輸資料。在 HTTP 2.0 中引入了新的編碼機制，所有傳輸的資料都會被分割，並採用二進位制格式編碼。

在 HTTP 2.0 中，有兩個非常重要的概念，分別是幀（frame）和流（stream）。

幀代表著最小的資料單位，每個幀會標識出該幀屬於哪個流，流也就是多個幀組成的資料流。

多路複用，就是在一個 TCP 連線中可以存在多條流。換句話說，也就是可以傳送多個請求，對端可以透過幀中的標識知道屬於哪個請求。透過這個技術，可以避免 HTTP 舊版本中的隊頭阻塞問題，極大的提高傳輸效能。

在 HTTP 1.X 中，我們使用文字的形式傳輸 header，在 header 攜帶 cookie 的情況下，可能每次都需要重複傳輸幾百到幾千的位元組。

在 HTTP 2.0 中，使用了 HPACK 壓縮格式對傳輸的 header 進行編碼，減少了 header 的大小。並在兩端維護了索引表，用於記錄出現過的 header ，後面在傳輸過程中就可以傳輸已經記錄過的 header 的鍵名，對端收到資料後就可以透過鍵名找到對應的值。

在 HTTP 2.0 中，服務端可以在客戶端某個請求後，主動推送其他資源。

可以想象以下情況，某些資源客戶端是一定會請求的，這時就可以採取服務端 push 的技術，提前給客戶端推送必要的資源，這樣就可以相對減少一點延遲時間。當然在瀏覽器相容的情況下你也可以使用 prefetch 。

這是一個谷歌出品的基於 UDP 實現的同為傳輸層的協議，目標很遠大，希望替代 TCP 協議。

• 該協議支援多路複用，雖然 HTTP 2.0 也支援多路複用，但是下層仍是 TCP，因為 TCP 的重傳機制，只要一個包丟失就得判斷丟失包並且重傳，導致發生隊頭阻塞的問題，但是 UDP 沒有這個機制

• 實現了自己的加密協議，透過類似 TCP 的 TFO 機制可以實現 0-RTT，當然 TLS 1.3 已經實現了 0-RTT 了

• 支援重傳和糾錯機制（向前恢復），在只丟失一個包的情況下不需要重傳，使用糾錯機制恢復丟失的包

• 糾錯機制：透過異或的方式，算出發出去的資料的異或值並單獨發出一個包，服務端在發現有一個包丟失的情況下，透過其他資料包和異或值包算出丟失包

• 在丟失兩個包或以上的情況就使用重傳機制，因為算不出來了

DNS 的作用就是透過域名查詢到具體的 IP。

因為 IP 存在數字和英文的組合（IPv6），很不利於人類記憶，所以就出現了域名。你可以把域名看成是某個 IP 的別名，DNS 就是去查詢這個別名的真正名稱是什麼。

在 TCP 握手之前就已經進行了 DNS 查詢，這個查詢是作業系統自己做的。當你在瀏覽器中想訪問 www.google.com 時，會進行一下操作：

1. 作業系統會首先在本地快取中查詢

2. 沒有的話會去系統配置的 DNS 伺服器中查詢

3. 如果這時候還沒得話，會直接去 DNS 根伺服器查詢，這一步查詢會找出負責 com 這個一級域名的伺服器

4. 然後去該伺服器查詢 google 這個二級域名

5. 接下來三級域名的查詢其實是我們配置的，你可以給 www 這個域名配置一個 IP，然後還可以給別的三級域名配置一個 IP

以上介紹的是 DNS 迭代查詢，還有種是遞迴查詢，區別就是前者是由客戶端去做請求，後者是由系統配置的 DNS 伺服器做請求，得到結果後將資料返回給客戶端。

PS：DNS 是基於 UDP 做的查詢。

這是一個很經典的面試題，在這題中可以將本文講得內容都串聯起來。

1. 首先做 DNS 查詢，如果這一步做了智慧 DNS 解析的話，會提供訪問速度最快的 IP 地址回來

2. 接下來是 TCP 握手，應用層會下發資料給傳輸層，這裡 TCP 協議會指明兩端的埠號，然後下發給網路層。網路層中的 IP 協議會確定 IP 地址，並且指示了資料傳輸中如何跳轉路由器。然後包會再被封裝到資料鏈路層的資料幀結構中，最後就是物理層面的傳輸了

3. TCP 握手結束後會進行 TLS 握手，然後就開始正式的傳輸資料

4. 資料在進入服務端之前，可能還會先經過負責負載均衡的伺服器，它的作用就是將請求合理的分發到多臺伺服器上，這時假設服務端會響應一個 HTML 檔案

5. 首先瀏覽器會判斷狀態碼是什麼，如果是 200 那就繼續解析，如果 400 或 500 的話就會報錯，如果 300 的話會進行重定向，這裡會有個重定向計數器，避免過多次的重定向，超過次數也會報錯

6. 瀏覽器開始解析檔案，如果是 gzip 格式的話會先解壓一下，然後透過檔案的編碼格式知道該如何去解碼檔案

7. 檔案解碼成功後會正式開始渲染流程，先會根據 HTML 構建 DOM 樹，有 CSS 的話會去構建 CSSOM 樹。如果遇到 script 標籤的話，會判斷是否存在 async或者defer，前者會並行進行下載並執行 JS，後者會先下載檔案，然後等待 HTML 解析完成後順序執行，如果以上都沒有，就會阻塞住渲染流程直到 JS 執行完畢。遇到檔案下載的會去下載檔案，這裡如果使用 HTTP 2.0 協議的話會極大的提高多圖的下載效率。

8. 初始的 HTML 被完全載入和解析後會觸發 DOMContentLoaded 事件

9. CSSOM 樹和 DOM 樹構建完成後會開始生成 Render 樹，這一步就是確定頁面元素的佈局、樣式等等諸多方面的東西

10. 在生成 Render 樹的過程中，瀏覽器就開始呼叫 GPU 繪製，合成圖層，將內容顯示在螢幕上了

來源：公眾號運維軍團

來一份閃亮亮的日程（持續更新） ⬇️

【來源：高效運維】

宣告：轉載此文是出於傳遞更多資訊之目的。若有來源標註錯誤或侵犯了您的合法權益，請作者持權屬證明與本網聯絡，我們將及時更正、刪除，謝謝。 郵箱地址：[email protected]