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

  開源Linux

長按二維碼加關注~

上一篇：SSH只能用於遠程Linux主機？

1 HTTP

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

2 Post 和 Get 的區別

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

反作用指對服務器上的資源作改變，搜索是無反作用的，註冊是反作用的。

冪等指發送 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 支持更多的編碼類型且不對數據類型限制

3 常見狀態碼

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，代表服務器暫時處於超負載或正在停機維護，沒法處理請求

4 HTTP 首部

5 HTTPS

HTTPS 仍是經過了 HTTP 來傳輸信息，可是信息經過 TLS 協議進行了加密。

6 TLS

TLS 協議位於傳輸層之上，應用層之下。首次進行 TLS 協議傳輸須要兩個 RTT ，接下來能夠經過 Session Resumption 減小到一個 RTT。

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

對稱加密：

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

非對稱加密：

有公鑰私鑰之分，公鑰全部人均可以知道，能夠將數據用公鑰加密，可是將數據解密必須使用私鑰解密，私鑰只有分發公鑰的一方纔知道。

TLS 握手過程以下圖：

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

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

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

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

經過以上步驟可知，在 TLS 握手階段，兩端使用非對稱加密的方式來通      信，可是由於非對稱加密損耗的性能比對稱加密大，因此在正式傳輸數據時，兩端使用對稱加密的方式通訊。

PS：以上說明的都是 TLS 1.2 協議的握手狀況，在 1.3 協議中，首次創建鏈接只須要一個 RTT，後面恢復鏈接不須要 RTT 了。

7 HTTP 2.0

HTTP 2.0 相比於 HTTP 1.X，能夠說是大幅度提升了 web 的性能。

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

在 HTTP 1.X 中，由於隊頭阻塞的緣由，你會發現請求是這樣的

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

8 二進制傳輸

HTTP 2.0 中全部增強性能的核心點在於此。在以前的 HTTP 版本中，咱們是經過文本的方式傳輸數據。在 HTTP 2.0 中引入了新的編碼機制，全部傳輸的數據都會被分割，並採用二進制格式編碼。

9 多路複用

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

幀表明着最小的數據單位，每一個幀會標識出該幀屬於哪一個流，流也就是多個幀組成的數據流。

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

10 Header 壓縮

在 HTTP 1.X 中，咱們使用文本的形式傳輸 header，在 header 攜帶 cookie 的狀況下，可能每次都須要重複傳輸幾百到幾千的字節。

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

11 服務端 Push

在 HTTP 2.0 中，服務端能夠在客戶端某個請求後，主動推送其餘資源。

能夠想象如下狀況，某些資源客戶端是必定會請求的，這時就能夠採起服務端 push 的技術，提早給客戶端推送必要的資源，這樣就能夠相對減小一點延遲時間。固然在瀏覽器兼容的狀況下你也可使用 prefetch 。

12 QUIC

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

• 該協議支持多路複用，雖然 HTTP 2.0 也支持多路複用，可是下層還是 TCP，由於 TCP 的重傳機制，只要一個包丟失就得判斷丟失包而且重傳，致使發生隊頭阻塞的問題，可是 UDP 沒有這個機制

• 實現了本身的加密協議，經過相似 TCP 的 TFO 機制能夠實現 0-RTT，固然 TLS 1.3 已經實現了 0-RTT 了

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

• 糾錯機制：經過異或的方式，算出發出去的數據的異或值並單獨發出一個包，服務端在發現有一個包丟失的狀況下，經過其餘數據包和異或值包算出丟失包

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

13 DNS

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 作的查詢。

14 從輸入 URL 到頁面加載完成的過程

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

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 繪製，合成圖層，將內容顯示在屏幕上了

來源：公衆號運維軍團

   
 
 
    
 
      
    
 

   

   
   
   
    
    
             
    

   
 
 
    - End - 

   
關注「開源Linux」加星標，提高IT技能

   
   
   
    
    
             
    

   
 
 
    
 
     
 
      
 
       
 
       
好文章，分享、點贊、在看三連哦❤️↓↓↓
 
      
 
     
 
    
 

   

本文分享自微信公衆號 - 開源Linux（qinlulu_123）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。