一、面試官：請說說看HTTP1.1與HTTP1.0的主要區別是什么?

1. 連接管理：長連接與流水線處理

HTTP/1.0：默認使用短連接，每次請求需建立新TCP連接，請求完成后立即關閉。若需長連接，需顯式設置 Connection: Keep-Alive，但兼容性差（部分代理不支持）。

HTTP/1.1：默認啟用長連接（持久連接），允許在一個TCP連接上傳輸多個請求/響應，減少握手開銷。支持流水線（Pipelining）技術，客戶端可連續發送多個請求（無需等待響應），但服務器需按請求順序返回響應，避免隊頭阻塞。

2. Host頭域支持虛擬主機

HTTP/1.0：假設一個IP對應唯一服務器，請求頭中無Host字段，無法支持虛擬主機技術（如多個域名共享同一IP）。

HTTP/1.1：強制要求請求頭包含 Host 字段，用于標識目標服務器域名。若缺失，服務器返回 400 Bad Request，解決了虛擬主機場景下的資源定位問題。

3. 緩存機制增強

HTTP/1.0：依賴 Expires（絕對時間）和 Last-Modified（最后修改時間）控制緩存，存在時鐘同步問題。緩存驗證通過 If-Modified-Since 實現。

HTTP/1.1：

• 引入 Cache-Control 頭（如 max-age、no-cache），支持相對時間緩存策略。
• 新增 ETag（實體標簽）機制，通過 If-None-Match 驗證資源是否變更。
• 支持 Vary 頭，根據請求頭（如 Accept-Language）區分不同緩存版本。

4. 帶寬優化與分塊傳輸

范圍請求：HTTP/1.1 支持 Range 頭，允許請求資源部分內容（如斷點續傳），響應狀態碼為 206 Partial Content。

分塊傳輸編碼（Chunked Encoding）：動態生成內容時，通過 Transfer-Encoding: chunked 分塊傳輸，無需預知完整數據大小，提升傳輸效率。

100 Continue 狀態碼：客戶端發送大請求前，先通過 Expect: 100-continue 頭詢問服務器是否接受，避免帶寬浪費。

5. 錯誤狀態碼與內容協商

錯誤狀態碼：HTTP/1.1 新增24個狀態碼，如

• 100 Continue：（繼續請求）
• 206 Partial Content：（部分內容）
• 409 Conflict：（資源狀態沖突）
• 410 Gone：（資源永久刪除）。

內容協商：通過 Accept-* 系列頭（如 Accept-Language、Accept-Encoding）支持多語言/壓縮格式，服務器返回最適配版本，并通過 Vary 頭記錄協商依據。

6. 其他改進

請求方法擴展：HTTP/1.1 新增 OPTIONS、PUT、DELETE、TRACE 等方法，支持 RESTful API 設計。

消息傳遞優化：支持 Trailer 頭傳遞分塊傳輸后的元數據（如校驗和），提升大文件傳輸的完整性。

總結對比表：

二、面試官：不錯，能不能展開聊聊HTTP長連接怎么實現的，它的優點是什么，有什么不足？

1. HTTP持久連接（長連接）的詳細解析

(1) 原理

HTTP持久連接（Persistent Connection），也稱為長連接（Keep-Alive），允許客戶端和服務器在單個TCP連接上發送和接收多個HTTP請求/響應，而無需為每個請求重新建立新的連接。

① 工作流程

HTTP/1.0：默認短連接，每個請求需建立新TCP連接，響應后立即關閉。   如需啟用長連接，需顯式設置頭部：Connection: keep-alive。

HTTP/1.1：默認啟用長連接，除非顯式設置Connection: close。   客戶端和服務器可復用同一TCP連接處理多個請求。

② 連接管理

保活機制：通過Keep-Alive頭部字段協商參數（如超時時間、最大請求數）。   示例：Keep-Alive: timeout=5, max=100（連接空閑5秒后關閉，最多處理100個請求）。

關閉條件：

• 客戶端/服務器發送`Connection: close`頭部。  
• 達到保活參數限制（如超時或最大請求數）。

(2) 優點

① 減少TCP握手開銷

• 每個TCP連接的建立需三次握手，關閉需四次揮手。  
• 復用連接避免了重復握手，降低延遲（尤其對高延遲網絡顯著）。

② 提升資源加載效率

• 網頁通常需加載多個資源（HTML、CSS、JS、圖片等）。  
• 長連接允許并行或串行復用同一連接，減少總加載時間。  

③ 減輕服務器壓力

減少頻繁創建/銷毀連接的系統調用和內存消耗。  

④ 支持管道化（Pipelining）

HTTP/1.1允許在未收到響應時發送多個請求（理論優化）。  

因實現復雜和隊頭阻塞問題，實際使用較少，但在長連接基礎上提出。

(3) 局限性

① 隊頭阻塞（Head-of-Line Blocking）

• HTTP/1.1的串行請求：同一連接中的請求必須按順序處理。若前一個請求處理慢（如大文件上傳），后續請求被阻塞。  
• HTTP/2的解決方案：引入多路復用（Multiplexing），允許并行處理請求。

② 資源占用問題

• 長連接占用服務器和客戶端的TCP端口和內存資源。  
• 高并發場景下，可能導致服務器連接數達到上限（如Linux默認ulimit -n為1024）。

③ 連接空閑浪費

• 若連接長時間無請求，仍占用資源直到超時關閉。  
• 需合理配置超時時間（如Nginx默認keepalive_timeout 75s）。

(4) 對比不同HTTP版本

2. 總結

• 核心價值：HTTP持久連接通過復用TCP連接，顯著降低延遲和服務器開銷，是Web性能優化的基石。
• 適用場景：資源密集型頁面、API高頻調用、高并發服務。
• 權衡取舍：需平衡連接復用效率與資源占用，結合HTTP/2或HTTP/3進一步優化。

三、面試官：剛剛你有提到HTTP的管道化（流水線）和隊頭阻塞，能說說看是怎么回事嗎？有什么方法可以徹底解決隊頭阻塞問題？

HTTP的流水線處理（HTTP Pipelining）是HTTP/1.1引入的一種優化技術，允許客戶端通過同一TCP連接連續發送多個請求，而無需等待前一個請求的響應返回。

1. 流水線處理的原理

(1) 與非流水線的對比

• 非流水線方式（如HTTP/1.0）：客戶端需等待前一個請求的響應完全返回后，才能發送下一個請求。例如，請求A完成后才能發送請求B，導致延遲疊加。

• 流水線方式（HTTP/1.1）：客戶端可在未收到響應時連續發送多個請求，服務器按接收順序依次處理并返回響應。例如，客戶端可一次性發送請求A、B、C，服務器依次返回A、B、C的響應。

(2) 實現條件

• 依賴長連接（Persistent Connection），即通過Connection: keep-alive保持TCP連接活躍。
• 服務器需支持按請求順序響應，且客戶端需能處理亂序到達的響應（實際中較少見，多數實現仍按順序返回）。

HTTP1.1請求報文之間沒有記錄請求順序（如請求編號、序號）的信息，因此無法保證多個響應之間的返回順序與發送的多個請求順序相對應，也就是說發送順序是請求1、請求2 和請求3，但由于服務端響應速度上是請求3、請求2和請求1，因此HTTP1.1依舊要等請求1的響應內容準備好之后才能依照 響應1、響應2和響應3的順序返回。否則亂序到達的響應就可能會交付給錯誤的請求（如將響應3交付給了請求1）。

而上述過程中，響應3和響應2就被響應1阻塞住了，這就是所謂的隊頭阻塞。HTTP的隊頭阻塞（Head-of-Line Blocking） 是指在數據傳輸過程中，某個請求或數據包的延遲或丟失導致后續請求/數據被阻塞的問題。

雖然理論上HTTP1.1的流水線支持一個連接并發傳輸多個請求和響應，但由于隊頭阻塞問題無法解決，因此HTTP1.1在實際應用中不會開啟流水線，依舊是一個連接只能串行傳輸請求和響應，要等上一個請求的響應返回了才發送下一個請求，如果要并發發送請求只能通過建立多個連接實現較為有限的并發。

隊頭阻塞問題在不同協議層（如HTTP/1.1、TCP）中表現不同，以下是詳細說明。

2. HTTP/1.1中的隊頭阻塞

HTTP/1.1即使啟用了流水線（Pipelining），客戶端可以并發的發送請求，但服務器仍需按請求順序串行的返回響應。若第一個請求的響應因服務器處理緩慢被阻塞，后續請求即使已處理完成，也需等待前一個響應返回后才能被客戶端接收。

示例：請求A、B、C依次發送，若A的響應延遲1秒，B和C的響應即使已生成，也必須在A的響應返回后才能被客戶端處理。

影響  ：

• 頁面加載延遲：資源（如圖片、CSS）需排隊等待，拖慢整體加載速度。
• 資源利用率低：TCP連接無法被其他請求充分利用，浪費帶寬。

采用HTTP2的多路復用機制可以解決應用層的隊頭阻塞問題。

要介紹HTTP2如何解決應用層的隊頭阻塞，就需要介紹流（Stream）、消息（Message）和幀（Frame）的概念和他們之間的關系。

在HTTP/2中，一個流代表一個獨立的請求-響應交互，可以包含多個消息，每個消息由多個幀組成。流具有唯一的標識符，可以在同一個連接上并行傳輸多個流的幀，從而實現多路復用。

從上圖中看到：

• 1 個 TCP 連接包含一個或者多個 Stream；
• Stream 里可以包含 1 個或多個 Message，Message 對應請求或響應，由 HTTP 頭部和包體構成；
• Message 里包含一條或者多個 Frame，Frame 是 HTTP/2 的最小傳輸單位，以二進制壓縮格式存放請求Message；

一個Message消息是由 Headers 幀和DATA 幀組成的。

在 HTTP/2 連接上，不同 Stream 的幀是可以亂序發送的（因此可以并發不同的 Stream ），因為每個幀的頭部會攜帶 Stream ID 信息，所以接收端可以通過 Stream ID 有序組裝成 HTTP 消息，而同一 Stream 內部的幀和消息必須是嚴格有序的。

比如下圖，服務端并行交錯地發送了兩個響應： Stream 1 的響應Message 和 Stream 3 的響應Message，這兩個 Stream 都是跑在一個 TCP 連接上，客戶端收到后，會根據相同的 Stream ID 有序組裝成 HTTP 消息。

這樣一來，假設stream1的請求Message比stream3的請求Message先到達服務端，而stream3的響應Message先準備好，不需要等待stream1的響應Message準備好就可以發送。客戶端可以通過消息上唯一的流標識符準確的拼裝好 Stream1 和 Stream3 的響應Message并通過唯一的流標識符交付給對應的請求從而解決隊頭阻塞問題，提高并發。

四、面試官：能不能說說看HTTP/2相比HTTP/1.1還有哪些地方做了提升？

HTTP/2 在 HTTP/1.1 的基礎上通過多項技術改進顯著提升了性能，主要優化點如下：

1. 多路復用

HTTP/2 的多路復用（Multiplexing） 是其核心特性之一，通過在一個 TCP 連接上并行傳輸多個請求和響應，徹底解決了 HTTP/1.1 的隊頭阻塞問題。以下是其原理及性能提升的詳細分析：

(1) 流（Stream）與幀（Frame）

• 流：HTTP/2 連接中的邏輯通道，每個流獨立傳輸雙向的幀序列（請求或響應）。
• 幀：數據傳輸的最小單位，包含流標識符（Stream ID）和類型（如 HEADERS、DATA）。
• 實現方式：多個流的幀可交錯傳輸，客戶端和服務器按流 ID 重組數據，無需按順序等待。

(2) 與 HTTP/1.1 的對比

• HTTP/1.1請求/響應需嚴格串行化，一個請求延遲會導致后續請求阻塞（隊頭阻塞）。
• HTTP/2同一 TCP 連接上可并行處理多個請求，流之間相互獨立，互不干擾。

HTTP2的多路復用帶來了如下提升。

① 消除隊頭阻塞

• 問題場景：在 HTTP/1.1 中，若請求 A 的響應延遲，后續請求 B、C 需排隊等待。
• 解決方案：HTTP/2 的多路復用允許請求 B、C 的幀與請求 A 的幀交錯傳輸，即使 A 延遲，B 和 C 的響應仍可被優先處理。

② 減少 TCP 連接數

• HTTP/1.1：瀏覽器通常為每個域名建立 6-8 個 TCP 連接以并行請求資源。
• HTTP/2：僅需一個連接即可并行傳輸所有請求，降低連接建立和維護的開銷（如三次握手、TLS 握手）。

③ 提升傳輸效率

• 資源利用率：TCP 連接的帶寬被多個流共享，避免單個請求占用TCP連接內的全部資源。
• 延遲優化：在弱網環境下，多路復用可減少 30%-50% 的頁面加載時間。例如，請求一個大 JS 文件和一個小 CSS 文件時，HTTP/2 可并行傳輸，而 HTTP/1.1 需串行等待。

④ 節省服務器資源

減少并發連接數可降低服務器內存和 CPU 的消耗，提升高負載場景下的穩定性。

2. 頭部壓縮

HTTP/2 的頭部壓縮是通過 HPACK 算法實現的核心優化技術，旨在減少 HTTP 頭部的冗余數據，提升傳輸效率。以下是其原理及優點的詳細說明：

(1) HPACK 算法

核心思想：通過靜態表、動態表和哈夫曼編碼，消除重復的頭部字段，減少傳輸體積。

實現方式：

• 靜態表（Static Table）：預定義 61 個常用頭部字段（如 `:method`、`:path`、`content-type`），直接用索引號代替完整字段名。例如，`:method: GET` 可編碼為索引 `2`，僅需傳輸 1 字節。  

• 動態表（Dynamic Table）：在會話過程中動態存儲客戶端與服務器交換的自定義頭部字段，后續請求直接引用索引。

例如，首次發送 `user-agent: Mozilla/5.0` 后，后續請求只需發送其動態表索引。  

• 哈夫曼編碼（Huffman Coding）：對頭部字段的鍵和值進行字符級壓縮，高頻字符用短編碼，低頻字符用長編碼。例如，字母 `e` 出現頻率高，編碼為 `010`，而 `z` 編碼為 `111111`。

頭部壓縮的總和效果如下圖所示：

(2) 頭部壓縮的優點

① 顯著減少帶寬消耗

• 通過消除冗余頭部字段（如重復的 Cookie、User-Agent），降低傳輸數據量，尤其適用于移動端或低帶寬環境。
• 例如，一個包含 20 個請求的頁面，HTTP/1.1 的頭部總大小可能達 10KB，而 HTTP/2 壓縮后可降至 1KB 以下。

② 降低延遲，提升并發性能

• 減少 TCP 連接數：頭部壓縮允許單個連接承載更多請求。
• 加速首屏加載：關鍵資源（如 HTML、CSS）的頭部壓縮后，傳輸時間縮短，頁面渲染更快。

3. 服務器推送

HTTP/2 的服務器推送（Server Push） 是一種允許服務器主動向客戶端發送資源的技術，無需等待客戶端顯式請求。以下是其特性與優點的詳細說明：

(1) 主動推送機制

服務器在客戶端請求一個資源（如 HTML 頁面）時，可主動推送與之關聯的其他資源（如 CSS、JS、圖片）。  

示例：客戶端請求 index.html，服務器同時推送 style.css 和 script.js，減少后續請求的往返時間（RTT）。

(2) 資源預判與優先級

• 服務器可根據業務邏輯預判客戶端需要的資源（如通過 Link 頭部聲明推送列表）。
• 支持設置推送資源的優先級，確保關鍵資源（如首屏 CSS）優先傳輸。

(3) 服務器推送的優點與局限性

① 顯著減少延遲（優點）

• 減少往返次數：通過提前推送資源，客戶端無需額外發起請求，降低頁面加載時間。
• 加速首屏渲染：關鍵資源（如 CSS、JS）的提前到達可更快完成頁面渲染。

② 僅支持靜態資源（局限）

服務器推送無法傳輸動態生成的內容（如實時數據），需結合 WebSocket 或 SSE 實現實時通信。

4. 安全機制提升

• 協議要求：HTTP/2 規范（RFC 7540）建議與 TLS 1.2 或更高版本 結合使用，且必須支持 前向安全（Forward Secrecy） 和 服務器名稱指示（SNI）。
• TLS 1.3 支持：HTTP/2 結合 TLS 1.3 時，握手僅需 1 個往返時間（RTT），且通過臨時密鑰（Ephemeral Key）實現前向安全，即使長期密鑰泄露，歷史通信也無法被解密。
• 會話復用：支持基于會話 ID 或票據（Session Ticket）的快速握手，減少重復連接的加密開銷。
• 二進制分幀：HTTP/2 使用二進制格式而非明文傳輸，降低中間設備（如代理、防火墻）因解析文本協議導致的注入攻擊或篡改風險。
• 頭部壓縮安全：HPACK 算法通過動態表和哈夫曼編碼壓縮頭部，避免明文頭部字段被竊取或篡改。

五、面試官：HTTP/2有什么局限性？HTTP/3基于UPD的QUIC協議如何提升連接效率？？

1. HTTP/2 的缺陷

(1) TCP層面的隊頭阻塞

HTTP/2 通過 Stream 的并發能力，解決了 HTTP/1 隊頭阻塞的問題，看似很完美了，但是 HTTP/2 還是存在“隊頭阻塞”的問題，只不過問題不是在 HTTP 這一層面，而是在 TCP 這一層。

HTTP/2 是基于 TCP 協議來傳輸數據的，TCP 是字節流協議，TCP 層必須保證收到的字節數據是完整且連續的，這樣內核才會將緩沖區里的數據返回給 HTTP 應用，那么當「前 1 個字節數據」沒有到達時，后收到的字節數據只能存放在內核緩沖區里，只有等到這 1 個字節數據到達時，HTTP/2 應用層才能從內核中拿到數據，這就是 HTTP/2 隊頭阻塞問題。

圖片

因為 TCP 是字節流協議，TCP 層必須保證收到的字節數據是完整且有序的，如果序列號較低的 TCP 段在網絡傳輸中丟失了，即使序列號較高的 TCP 段已經被接收了，應用層也無法從內核中讀取到這部分數據。從 HTTP 視角看，就是請求被阻塞了。

舉個例子，如下圖：

圖中發送方發送了很多個 Packet，每個 Packet 都有自己的序號，你可以認為是 TCP 的序列號，其中 Packet 3 在網絡中丟失了，即使 Packet 4~6 被接收方收到后，由于內核中的 TCP 數據不是連續的，于是接收方的應用層就無法從內核中讀取到，只有等到 Packet 3 重傳后，接收方的應用層才可以從內核中讀取到數據，這就是 HTTP/2 的隊頭阻塞問題，是在 TCP 層面發生的。

所以，一旦發生了丟包現象，就會觸發 TCP 的重傳機制，這樣在一個 TCP 連接中的所有的 HTTP 請求都必須等待這個丟了的包被重傳回來。

(2) TCP 與 TLS 的握手時延遲

發起 HTTP 請求時，需要經過 TCP 三次握手和 TLS 四次握手（TLS 1.2）的過程，因此共需要 3 個 RTT 的時延才能發出請求數據。

另外，TCP 由于具有「擁塞控制」的特性，所以剛建立連接的 TCP 會有個「慢啟動」的過程，它會對 TCP 連接產生“減速”效果。

(3) 網絡遷移需要重新連接

一個 TCP 連接是由四元組（源 IP 地址，源端口，目標 IP 地址，目標端口）確定的，這意味著如果 IP 地址或者端口變動了，就會導致需要 TCP 與 TLS 重新握手，這不利于移動設備切換網絡的場景，比如 4G 網絡環境切換成 WiFi。

這些問題都是 TCP 協議固有的問題，無論應用層的 HTTP/2 在怎么設計都無法避免。

HTTP3把傳輸層協議替換成 UDP，從傳輸層徹底進行優化。

2. HTTP/3 的優化

(1) 無隊頭阻塞

QUIC 協議也有類似 HTTP/2 Stream 與多路復用的概念，也是可以在同一條連接上并發傳輸多個 Stream，Stream 可以認為就是一條 HTTP 請求。

由于 QUIC 使用的傳輸協議是 UDP，UDP 不關心數據包的順序，如果數據包丟失，UDP 也不關心。

不過 QUIC 協議會保證數據包的可靠性，每個數據包都有一個序號唯一標識。當某個流中的一個數據包丟失了，即使該流的其他數據包到達了，數據也無法被 HTTP/3 讀取，直到 QUIC 重傳丟失的報文，數據才會交給 HTTP/3。

而其他流的數據報文只要被完整接收，HTTP/3 就可以讀取到數據。可以認為HTTP/3 把 HTTP/2 在應用層上的多個流的概念轉移到了傳輸層上，解決了傳輸層的隊頭阻塞問題。

(2) 更快的連接建立

對于 HTTP/1 和 HTTP/2 協議，TCP 和 TLS 是分層的，分別屬于內核實現的傳輸層、OpenSSL 庫實現的表示層，因此它們難以合并在一起，需要分批次來握手，先 TCP 握手，再 TLS 握手。

HTTP/3 在傳輸數據前雖然需要 QUIC 協議握手，這個握手過程只需要 1 RTT，握手的目的是為確認雙方的「連接 ID」，連接遷移就是基于連接 ID 實現的。

但是 HTTP/3 的 QUIC 協議并不是與 TLS 分層，而是 QUIC 內部包含了 TLS，它在自己的幀會攜帶 TLS 里的“記錄”，再加上 QUIC 使用的是 TLS/1.3，因此僅需 1 個 RTT 就可以「同時」完成建立連接與密鑰協商，如下圖：

甚至，在第二次連接的時候，應用數據包可以和 QUIC 握手信息（連接信息 + TLS 信息）一起發送，達到 0-RTT 的效果。

如下圖右邊部分，HTTP/3 當會話恢復時，有效負載數據與第一個數據包一起發送，可以做到 0-RTT（下圖的右下角）：

(3) 連接遷移

基于 TCP 傳輸協議的 HTTP 協議，由于是通過四元組（源 IP、源端口、目的 IP、目的端口）確定一條 TCP 連接。

那么當移動設備的網絡從 4G 切換到 WIFI 時，意味著 IP 地址變化了，那么就必須要斷開連接，然后重新建立連接。而建立連接的過程包含 TCP 三次握手和 TLS 四次握手的時延，以及 TCP 慢啟動的減速過程，給用戶的感覺就是網絡突然卡頓了一下，因此連接的遷移成本是很高的。

而 QUIC 協議沒有用四元組的方式來“綁定”連接，而是通過連接 ID 來標記通信的兩個端點，客戶端和服務器可以各自選擇一組 ID 來標記自己，因此即使移動設備的網絡變化后，導致 IP 地址變化了，只要仍保有上下文信息（比如連接 ID、TLS 密鑰等），就可以“無縫”地復用原連接，消除重連的成本，沒有絲毫卡頓感，達到了連接遷移的功能。