HTTP常見面試題

一.HTTP基本知識

1.HTTP 常見的狀態碼，有哪些？

「200 OK」是最常見的成功狀態碼，表示一切正常。如果是非 HEAD 請求，伺服器返回的響應頭都會有 body 資料。

「204 No Content」也是常見的成功狀態碼，與 200 OK 基本相同，但響應頭沒有 body 資料。

「206 Partial Content」是應用於 HTTP 分塊下載或斷點續傳，表示響應返回的 body 資料並不是資源的全部，而是其中的一部分，也是伺服器處理成功的狀態。

「301 Moved Permanently」表示永久重定向，說明請求的資源已經不存在了，需改用新的 URL 再次訪問。

「302 Found」表示臨時重定向，說明請求的資源還在，但暫時需要用另一個 URL 來訪問。

301 和 302 都會在響應頭裡使用欄位 Location，指明後續要跳轉的 URL，瀏覽器會自動重定向新的 URL。

「304 Not Modified」不具有跳轉的含義，表示資源未修改，重定向已存在的緩衝檔案，也稱快取重定向，用於快取控制。

「400 Bad Request」表示客戶端請求的報文有錯誤，但只是個籠統的錯誤。

「403 Forbidden」表示伺服器禁止訪問資源，並不是客戶端的請求出錯。

「404 Not Found」表示請求的資源在伺服器上不存在或未找到，所以無法提供給客戶端。

「500 Internal Server Error

「501 Not Implemented」表示客戶端請求的功能還不支援，類似“即將開業，敬請期待”的意思。

「502 Bad Gateway」通常是伺服器作為閘道器或代理時返回的錯誤碼，表示伺服器自身工作正常，訪問後端伺服器發生了錯誤。

「503 Service Unavailable」表示伺服器當前很忙，暫時無法響應伺服器，類似“網路服務正忙，請稍後重試”的意思。

2.http 常見欄位有哪些？

• Host 欄位：客戶端傳送請求時，用來指定伺服器的域名。
• Content-Length 欄位：伺服器在返回資料時，會有 Content-Length
  欄位，表明本次迴應的資料長度。
• Content-Length 欄位：伺服器在返回資料時，會有 Content-Length 欄位，表明本次迴應的資料長度。
• Content-Type 欄位：Content-Type 欄位用於伺服器迴應時，告訴客戶端，本次資料是什麼格式。
• Content-Encoding 欄位：Content-Encoding 欄位說明資料的壓縮方法。表示伺服器返回的資料使用了什麼壓縮格式，比如gzip

二.HTTP特性

1. HTTP（1.1） 的優點有哪些，缺點又有哪些？

優點：

• 1. 簡單

HTTP 基本的報文格式就是 header + body，頭部資訊也是 key-value 簡單文字的形式，易於理解，降低了學習和使用的門檻。

• 2. 靈活和易於擴充套件

HTTP協議裡的各類請求方法、URI/URL、狀態碼、頭欄位等每個組成要求都沒有被固定死，都允許開發人員自定義和擴充。

同時 HTTP 由於是工作在應用層（ OSI 第七層），則它下層可以隨意變化。

HTTPS 也就是在 HTTP 與 TCP 層之間增加了 SSL/TLS 安全傳輸層，HTTP/3 甚至把 TCP 層換成了基於 UDP 的 QUIC。

• 3. 應用廣泛和跨平臺

缺點：

• 1. 無狀態雙刃劍

無狀態的好處，因為伺服器不會去記憶 HTTP 的狀態，所以不需要額外的資源來記錄狀態資訊，這能減輕伺服器的負擔，能夠把更多的 CPU 和記憶體用來對外提供服務。

無狀態的壞處，既然伺服器沒有記憶能力，它在完成有關聯性的操作時會非常麻煩。

例如登入->新增購物車->下單->結算->支付，這系列操作都要知道使用者的身份才行。但伺服器不知道這些請求是有關聯的，每次都要問一遍身份資訊。

對於無狀態的問題，解法方案有很多種，其中比較簡單的方式用 Cookie 技術。

Cookie 通過在請求和響應報文中寫入 Cookie 資訊來控制客戶端的狀態。

相當於，在客戶端第一次請求後，伺服器會下發一個裝有客戶資訊的「小貼紙」，後續客戶端請求伺服器的時候，帶上「小貼紙」，伺服器就能認得了了，

• 2. 明文傳輸雙刃劍

明文意味著在傳輸過程中的資訊，是可方便閱讀的，通過瀏覽器的 F12 控制檯或 Wireshark 抓包都可以直接肉眼檢視，為我們除錯工作帶了極大的便利性。

但是這正是這樣，HTTP 的所有資訊都暴露在了光天化日下，相當於資訊裸奔。在傳輸的漫長的過程中，資訊的內容都毫無隱私可言

• 3. 不安全

HTTP 比較嚴重的缺點就是不安全：

• 通訊使用明文（不加密），內容可能會被竊聽。比如，賬號資訊容易洩漏，那你號沒了。
• 不驗證通訊方的身份，因此有可能遭遇偽裝。比如，訪問假的淘寶、拼多多，那你錢沒了。
• 無法證明報文的完整性，所以有可能已遭篡改。比如，網頁上植入垃圾廣告，視覺汙染，眼沒了。

HTTP 的安全問題，可以用 HTTPS 的方式解決，也就是通過引入 SSL/TLS 層，使得在安全上達到了極致。

2.HTTP/1.1 的效能如何？

HTTP 協議是基於 TCP/IP，並且使用了「請求 - 應答」的通訊模式

• 1. 長連線

早期 HTTP/1.0 效能上的一個很大的問題，那就是每發起一個請求，都要新建一次 TCP 連線（三次握手），而且是序列請求，做了無謂的 TCP 連線建立和斷開，增加了通訊開銷。

為了解決上述 TCP 連線問題，HTTP/1.1 提出了長連線的通訊方式，也叫持久連線。這種方式的好處在於減少了 TCP 連線的重複建立和斷開所造成的額外開銷，減輕了伺服器端的負載。

持久連線的特點是，只要任意一端沒有明確提出斷開連線，則保持 TCP 連線狀態。

2. 管道網路傳輸

HTTP/1.1 採用了長連線的方式，這使得管道（pipeline）網路傳輸成為了可能。

即可在同一個 TCP 連線裡面，客戶端可以發起多個請求，只要第一個請求發出去了，不必等其回來，就可以發第二個請求出去，可以減少整體的響應時間。

舉例來說，客戶端需要請求兩個資源。以前的做法是，在同一個TCP連線裡面，先發送 A 請求，然後等待伺服器做出迴應，收到後再發出 B 請求。管道機制則是允許瀏覽器同時發出 A 請求和 B 請求。

但是伺服器還是按照順序，先回應 A 請求，完成後再回應 B 請求。要是前面的迴應特別慢，後面就會有許多請求排隊等著。這稱為「隊頭堵塞」。

3. 隊頭阻塞

「請求 - 應答」的模式加劇了 HTTP 的效能問題。

因為當順序傳送的請求序列中的一個請求因為某種原因被阻塞時，在後面排隊的所有請求也一同被阻塞了，會招致客戶端一直請求不到資料，這也就是「隊頭阻塞」。好比上班的路上塞車。

總之 HTTP/1.1 的效能一般般，後續的 HTTP/2 和 HTTP/3 就是在優化 HTTP 的效能。

3.HTTP快取技術

對於一些具有重複性的 HTTP 請求，比如每次請求得到的資料都一樣的，我們可以把這對「請求-響應」的資料都快取在本地，那麼下次就直接讀取本地的資料，不必在通過網路獲取伺服器的響應了，這樣的話 HTTP/1.1 的效能肯定肉眼可見的提升。

所以，避免傳送 HTTP 請求的方法就是通過快取技術，HTTP 設計者早在之前就考慮到了這點，因此 HTTP 協議的頭部有不少是針對快取的欄位。

HTTP 快取有兩種實現方式，分別是強制快取和協商快取。

什麼是強制快取？

強快取指的是隻要瀏覽器判斷快取沒有過期，則直接使用瀏覽器的本地快取，決定是否使用快取的主動性在於瀏覽器這邊。

強快取是利用下面這兩個 HTTP 響應頭部（Response Header）欄位實現的，它們都用來表示資源在客戶端快取的有效期：

• Cache-Control， 是一個相對時間；
• Expires，是一個絕對時間；

如果 HTTP 響應頭部同時有 Cache-Control 和 Expires 欄位的話，Cache-Control的優先順序高於 Expires 。

Cache-control 選項更多一些，設定更加精細，所以建議使用 Cache-Control 來實現強快取。具體的實現流程如下：

• 當瀏覽器第一次請求訪問伺服器資源時，伺服器會在返回這個資源的同時，在 Response 頭部加上 Cache-Control，Cache-Control 中設定了過期時間大小；
• 瀏覽器再次請求訪問伺服器中的該資源時，會先通過請求資源的時間與 Cache-Control 中設定的過期時間大小，來計算出該資源是否過期，如果沒有，則使用該快取，否則重新請求伺服器；
• 伺服器再次收到請求後，會再次更新 Response 頭部的 Cache-Control。

什麼是協商快取？

當我們在瀏覽器使用開發者工具的時候，你可能會看到過某些請求的響應碼是 304，這個是告訴瀏覽器可以使用本地快取的資源，通常這種通過服務端告知客戶端是否可以使用快取的方式被稱為協商快取。

協商快取可以基於兩種頭部來實現。

第一種：請求頭部中的 If-Modified-Since 欄位與響應頭部中的 Last-Modified 欄位實現，這兩個欄位的意思是：

• 響應頭部中的 Last-Modified：標示這個響應資源的最後修改時間；
• 請求頭部中的 If-Modified-Since：當資源過期了，發現響應頭中具有 Last-Modified 宣告，則再次發起請求的時候帶上 Last-Modified 的時間，伺服器收到請求後發現有 If-Modified-Since 則與被請求資源的最後修改時間進行對比（Last-Modified），如果最後修改時間較新（大），說明資源又被改過，則返回最新資源，HTTP 200 OK；如果最後修改時間較舊（小），說明資源無新修改，響應 HTTP 304 走快取。

第二種：請求頭部中的 If-None-Match 欄位與響應頭部中的 ETag 欄位，這兩個欄位的意思是：

• 響應頭部中 Etag：唯一標識響應資源；
• 請求頭部中的 If-None-Match：當資源過期時，瀏覽器發現響應頭裡有 Etag，則再次向伺服器發起請求時，會將請求頭If-None-Match 值設定為 Etag 的值。伺服器收到請求後進行比對，如果資源沒有變化返回 304，如果資源變化了返回 200。

第一種實現方式是基於時間實現的，第二種實現方式是基於一個唯一標識實現的，相對來說後者可以更加準確地判斷檔案內容是否被修改，避免由於時間篡改導致的不可靠問題。

如果 HTTP 響應頭部同時有 Etag 和 Last-Modified 欄位的時候， Etag 的優先順序更高，也就是先會判斷 Etag 是否變化了，如果 Etag 沒有變化，然後再看 Last-Modified。

注意，協商快取這兩個欄位都需要配合強制快取中 Cache-control 欄位來使用，只有在未能命中強制快取的時候，才能發起帶有協商快取欄位的請求。

使用 ETag 欄位實現的協商快取的過程如下；

• 當瀏覽器第一次請求訪問伺服器資源時，伺服器會在返回這個資源的同時，在 Response 頭部加上 ETag 唯一標識，這個唯一標識的值是根據當前請求的資源生成的；

• 當瀏覽器再次請求訪問伺服器中的該資源時，首先會先檢查強制快取是否過期，如果沒有過期，則直接使用本地快取；如果快取過期了，會在 Request 頭部加上 If-None-Match 欄位，該欄位的值就是 ETag 唯一標識；

• 伺服器再次收到請求後，

  會根據請求中的 If-None-Match 值與當前請求的資源生成的唯一標識進行比較

  ：

  • 如果值相等，則返回 304 Not Modified，不會返回資源；
  • 如果不相等，則返回 200 狀態碼和返回資源，並在 Response 頭部加上新的 ETag 唯一標識；

• 如果瀏覽器收到 304 的請求響應狀態碼，則會從本地快取中載入資源，否則更新資源。

三.HTTP與HTTPS

1.HTTP 與 HTTPS 有哪些區別？

1. HTTP 是超文字傳輸協議，資訊是明文傳輸，存在安全風險的問題。HTTPS 則解決 HTTP 不安全的缺陷，在 TCP 和 HTTP 網路層之間加入了 SSL/TLS 安全協議，使得報文能夠加密傳輸。
2. HTTP 連線建立相對簡單， TCP 三次握手之後便可進行 HTTP 的報文傳輸。而 HTTPS 在 TCP 三次握手之後，還需進行 SSL/TLS 的握手過程，才可進入加密報文傳輸。
3. HTTP 的埠號是 80，HTTPS 的埠號是 443。
4. HTTPS 協議需要向 CA（證書權威機構）申請數字證書，來保證伺服器的身份是可信的。

2.HTTPS 解決了 HTTP 的哪些問題？

HTTP 由於是明文傳輸，所以安全上存在以下三個風險：

• 竊聽風險，比如通訊鏈路上可以獲取通訊內容，使用者號容易沒。
• 篡改風險，比如強制植入垃圾廣告，視覺汙染，使用者眼容易瞎。
• 冒充風險，比如冒充淘寶網站，使用者錢容易沒。

HTTPS 在 HTTP 與 TCP 層之間加入了 SSL/TLS 協議，可以很好的解決了上述的風險：

• 資訊加密：互動資訊無法被竊取，但你的號會因為「自身忘記」賬號而沒。
• 校驗機制：無法篡改通訊內容，篡改了就不能正常顯示，但百度「競價排名」依然可以搜尋垃圾廣告。
• 身份證書：證明淘寶是真的淘寶網，但你的錢還是會因為「剁手」而沒。

可見，只要自身不做「惡」，SSL/TLS 協議是能保證通訊是安全的。

3.HTTPS 是如何解決上面的三個安全風險的？

1.混合加密

HTTPS 採用的是對稱加密和非對稱加密結合的「混合加密」方式：

• 在通訊建立前採用非對稱加密的方式交換「會話祕鑰」，後續就不再使用非對稱加密。
• 在通訊過程中全部使用對稱加密的「會話祕鑰」的方式加密明文資料。

採用「混合加密」的方式的原因：

• 對稱加密只使用一個金鑰，運算速度快，金鑰必須保密，無法做到安全的金鑰交換。
• 非對稱加密使用兩個金鑰：公鑰和私鑰，公鑰可以任意分發而私鑰保密，解決了金鑰交換問題但速度慢。

2.摘要演算法

摘要演算法用來實現完整性，能夠為資料生成獨一無二的「指紋」，用於校驗資料的完整性，解決了篡改的風險。

客戶端在傳送明文之前會通過摘要演算法算出明文的「指紋」，傳送的時候把「指紋 + 明文」一同加密成密文後，傳送給伺服器，伺服器解密後，用相同的摘要演算法算出傳送過來的明文，通過比較客戶端攜帶的「指紋」和當前算出的「指紋」做比較，若「指紋」相同，說明資料是完整的。

3.數字證書

客戶端先向伺服器端索要公鑰，然後用公鑰加密資訊，伺服器收到密文後，用自己的私鑰解密。

這就存在些問題，如何保證公鑰不被篡改和信任度？

所以這裡就需要藉助第三方權威機構 CA （數字證書認證機構），將伺服器公鑰放在數字證書（由數字證書認證機構頒發）中，只要證書是可信的，公鑰就是可信的。

4.HTTPS 是如何建立連線的？其間互動了什麼？

SSL/TLS 協議基本流程：

• 客戶端向伺服器索要並驗證伺服器的公鑰。
• 雙方協商生產「會話祕鑰」。
• 雙方採用「會話祕鑰」進行加密通訊。

另外一種說法

• 通過CA體系交換public key

• 通過非對稱加密演算法，交換用於對稱加密的金鑰

• 通過對稱加密演算法，加密正常的網路通訊

SSL/TLS 的「握手階段」涉及四次通訊

1. ClientHello

首先，由客戶端向伺服器發起加密通訊請求，也就是 ClientHello 請求。

在這一步，客戶端主要向伺服器傳送以下資訊：

（1）客戶端支援的 SSL/TLS 協議版本，如 TLS 1.2 版本。

（2）客戶端生產的隨機數（Client Random），後面用於生產「會話祕鑰」。

（3）客戶端支援的密碼套件列表，如 RSA 加密演算法。

2. SeverHello

伺服器收到客戶端請求後，向客戶端發出響應，也就是 SeverHello。伺服器迴應的內容有如下內容：

（1）確認 SSL/ TLS 協議版本，如果瀏覽器不支援，則關閉加密通訊。

（2）伺服器生產的隨機數（Server Random），後面用於生產「會話祕鑰」。

（3）確認的密碼套件列表，如 RSA 加密演算法。

（4）伺服器的數字證書。

3.客戶端迴應

客戶端收到伺服器的迴應之後，首先通過瀏覽器或者作業系統中的 CA 公鑰，確認伺服器的數字證書的真實性。

如果證書沒有問題，客戶端會從數字證書中取出伺服器的公鑰，然後使用它加密報文，向伺服器傳送如下資訊：

（1）一個隨機數（pre-master key）。該隨機數會被伺服器公鑰加密。

（2）加密通訊演算法改變通知，表示隨後的資訊都將用「會話祕鑰」加密通訊。

（3）客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時把之前所有內容的發生的資料做個摘要，用來供服務端校驗。

上面第一項的隨機數是整個握手階段的第三個隨機數，這樣伺服器和客戶端就同時有三個隨機數，接著就用雙方協商的加密演算法，各自生成本次通訊的「會話祕鑰」。

4. 伺服器的最後迴應

伺服器收到客戶端的第三個隨機數（pre-master key）之後，通過協商的加密演算法，計算出本次通訊的「會話祕鑰」。然後，向客戶端發生最後的資訊：

（1）加密通訊演算法改變通知，表示隨後的資訊都將用「會話祕鑰」加密通訊。

（2）伺服器握手結束通知，表示伺服器的握手階段已經結束。這一項同時把之前所有內容的發生的資料做個摘要，用來供客戶端校驗。

至此，整個 SSL/TLS 的握手階段全部結束。接下來，客戶端與伺服器進入加密通訊，就完全是使用普通的 HTTP 協議，只不過用「會話祕鑰」加密內容。

四. HTTP/1.0，HTTP/1.1，HTTP/2，HTTP/3

1.HTTP/1.1 相比 HTTP/1.0 提高了什麼效能？

HTTP/1.1 相比 HTTP/1.0 效能上的改進：

• 使用 TCP 長連線的方式改善了 HTTP/1.0 短連線造成的效能開銷。
• 支援管道（pipeline）網路傳輸，只要第一個請求發出去了，不必等其回來，就可以發第二個請求出去，可以減少整體的響應時間。

但 HTTP/1.1 還是有效能瓶頸：

• 請求 / 響應頭部（Header）未經壓縮就傳送，首部資訊越多延遲越大。只能壓縮 Body 的部分；
• 傳送冗長的首部。每次互相傳送相同的首部造成的浪費較多；
• 伺服器是按請求的順序響應的，如果伺服器響應慢，會招致客戶端一直請求不到資料，也就是隊頭阻塞；
• 沒有請求優先順序控制；
• 請求只能從客戶端開始，伺服器只能被動響應。

2.針對 HTTP/1.1 的效能瓶頸，HTTP/2 做了什麼優化？

HTTP/2 相比 HTTP/1.1 效能上的改進：

1. 頭部壓縮

HTTP/2 會壓縮頭（Header）如果你同時發出多個請求，他們的頭是一樣的或是相似的，那麼，協議會幫你消除重複的部分。

這就是所謂的 HPACK 演算法：在客戶端和伺服器同時維護一張頭資訊表，所有欄位都會存入這個表，生成一個索引號，以後就不傳送同樣欄位了，只發送索引號，這樣就提高速度了。

2. 二進位制格式

HTTP/2 不再像 HTTP/1.1 裡的純文字形式的報文，而是全面採用了二進位制格式，頭資訊和資料體都是二進位制，並且統稱為幀（frame）：頭資訊幀和資料幀。

這樣雖然對人不友好，但是對計算機非常友好，因為計算機只懂二進位制，那麼收到報文後，無需再將明文的報文轉成二進位制，而是直接解析二進位制報文，這增加了資料傳輸的效率。

3. 資料流

HTTP/2 的資料包不是按順序傳送的，同一個連線裡面連續的資料包，可能屬於不同的迴應。因此，必須要對資料包做標記，指出它屬於哪個迴應。

每個請求或迴應的所有資料包，稱為一個數據流（Stream）。每個資料流都標記著一個獨一無二的編號，其中規定客戶端發出的資料流編號為奇數， 伺服器發出的資料流編號為偶數

客戶端還可以指定資料流的優先順序。優先順序高的請求，伺服器就先響應該請求。

4. 多路複用

HTTP/2 是可以在一個連線中併發多個請求或迴應，而不用按照順序一一對應。

移除了 HTTP/1.1 中的序列請求，不需要排隊等待，也就不會再出現「隊頭阻塞」問題，降低了延遲，大幅度提高了連線的利用率。

舉例來說，在一個 TCP 連線裡，伺服器收到了客戶端 A 和 B 的兩個請求，如果發現 A 處理過程非常耗時，於是就迴應 A 請求已經處理好的部分，接著迴應 B 請求，完成後，再回應 A 請求剩下的部分。

5. 伺服器推送

HTTP/2 還在一定程度上改善了傳統的「請求 - 應答」工作模式，服務不再是被動地響應，也可以主動向客戶端傳送訊息。

舉例來說，在瀏覽器剛請求 HTML 的時候，就提前把可能會用到的 JS、CSS 檔案等靜態資源主動發給客戶端，減少延時的等待，也就是伺服器推送（Server Push，也叫 Cache Push）。

3.HTTP/2 有哪些缺陷？HTTP/3 做了哪些優化？

HTTP/2 主要的問題在於，多個 HTTP 請求在複用一個 TCP 連線，下層的 TCP 協議是不知道有多少個 HTTP 請求的。所以一旦發生了丟包現象，就會觸發 TCP 的重傳機制，這樣在一個 TCP 連線中的所有的 HTTP 請求都必須等待這個丟了的包被重傳回來。

• HTTP/1.1 中的管道（ pipeline）傳輸中如果有一個請求阻塞了，那麼佇列後請求也統統被阻塞住了
• HTTP/2 多個請求複用一個TCP連線，一旦發生丟包，就會阻塞住所有的 HTTP 請求。

這都是基於 TCP 傳輸層的問題，所以 HTTP/3 把 HTTP 下層的 TCP 協議改成了 UDP！

UDP 發生是不管順序，也不管丟包的，所以不會出現 HTTP/1.1 的隊頭阻塞 和 HTTP/2 的一個丟包全部重傳問題。

大家都知道 UDP 是不可靠傳輸的，但基於 UDP 的 QUIC 協議 可以實現類似 TCP 的可靠性傳輸。

• QUIC 有自己的一套機制可以保證傳輸的可靠性的。當某個流發生丟包時，只會阻塞這個流，其他流不會受到影響。
• TLS3 升級成了最新的 1.3 版本，頭部壓縮演算法也升級成了 QPack。
• HTTPS 要建立一個連線，要花費 6 次互動，先是建立三次握手，然後是 TLS/1.3 的三次握手。QUIC 直接把以往的 TCP 和 TLS/1.3 的 6 次互動合併成了 3 次，減少了互動次數。

TCP HTTPS（TLS/1.3） 和 QUIC HTTPS

所以， QUIC 是一個在 UDP 之上的偽 TCP + TLS + HTTP/2 的多路複用的協議。

QUIC 是新協議，對於很多網路裝置，根本不知道什麼是 QUIC，只會當做 UDP，這樣會出現新的問題。所以 HTTP/3 現在普及的進度非常的緩慢，不知道未來 UDP 是否能夠逆襲 TCP。