瞭解HTTP/2協議

HTTP/2（2015年釋出）已經發布快10年了，雲原生社群的RPC框架中，gRPC 是直接基於 HTTP/2 實現。Dubbo 框架的預設協議，也從原先基於 TCP協議 的 dubbo協議，換成基於 HTTP/1.1、HTTP/2的 triple協議。

可能網站、框架還在使用 HTTP/1.1（1997年釋出），但隨著對系統效能的要求越來越高，HTTP/2 實在應該好好了解一番。

從 HTTP/1.0 到 HTTP/2，每個版本的升級，都存在解決各自最核心的問題，下面從各自問題入手，逐漸瞭解各版本的功能提升。

1. HTTP/1.0 - 獨立連線問題

HTTP/1.1 透過引入持久連線（Keep-Alive）機制，顯著改進了 TCP 連線的複用問題。與 HTTP/1.0 的短連線方式相比，HTTP/1.1 的持久連線減少了連線建立和關閉的開銷，最佳化了資源利用，提高了網路效能，從而顯著提升了使用者體驗和 Web 應用的效率。

1.1. HTTP/1.0 的 TCP 連線管理

1. 短連線

• 預設行為：

  • HTTP/1.0 預設使用短連線。每次請求和響應完成後，TCP 連線都會被關閉。這意味著每個資源（如 HTML 文件、圖片、CSS 檔案等）都需要建立一個新的 TCP 連線。

• 問題：

  • 頻繁的連線建立和關閉：每次請求都需要進行 TCP 三次握手和四次揮手，增加了網路延遲。
  • 資源消耗：頻繁的連線操作消耗了大量的伺服器資源，如 CPU 和記憶體。
  • 頻寬浪費：每次建立連線都需要傳輸 TCP 握手資料，浪費了頻寬。

2. Keep-Alive 擴充套件

• 非標準支援：

  • 儘管 HTTP/1.0 不正式支援持久連線，但一些實現引入了 Connection: Keep-Alive 頭部，允許在一個連線上傳送多個請求。這是一種非標準的擴充套件，不同實現之間可能存在相容性問題。

1.2. HTTP/1.1 的 TCP 連線管理

1. 持久連線（Persistent Connections）

• 預設行為：

  • HTTP/1.1 預設啟用持久連線。除非明確指定 Connection: close，否則連線會保持開啟狀態，允許在同一連線上傳送多個請求和響應。

• 優勢：

  • 減少連線建立和關閉的開銷：減少了 TCP 三次握手和四次揮手的次數，降低了網路延遲。
  • 最佳化資源利用：減少了伺服器的 CPU 和記憶體消耗，提高了資源利用率。
  • 節省頻寬：避免了頻繁的 TCP 握手資料傳輸，節省了頻寬。

2. Keep-Alive 引數

• 連線保持時間：

  • HTTP/1.1 允許客戶端和伺服器透過 Keep-Alive 頭部指定連線保持的時間。例如，伺服器可以設定 Keep-Alive: timeout=5, max=100，表示連線最多保持 5 秒，最多處理 100 個請求。

• 連線管理：

  • 客戶端和伺服器可以靈活地管理連線的生命週期，根據需要調整連線的保持時間和最大請求數。

1.3. 實際應用和影響

1. 效能提升

• 減少延遲：

  • 持久連線顯著減少了每個請求的延遲，特別是對於需要載入多個資源的網頁。例如，一個包含多個圖片和指令碼的網頁可以透過一個連線完成所有資源的載入，大大減少了總的載入時間。

• 提高吞吐量：

  • 透過減少連線建立和關閉的開銷，持久連線提高了網路的吞吐量，使得伺服器能夠處理更多的請求。

2. 資源最佳化

• 伺服器資源：

  • 持久連線減少了伺服器的 CPU 和記憶體消耗，使得伺服器能夠更高效地處理請求，支援更高效的併發連線。

• 網路資源：

  • 持久連線減少了網路頻寬的浪費，提高了頻寬利用率，特別是在高延遲和低頻寬的網路環境中效果顯著。

3. 使用者體驗

• 更快的頁面載入：

  • 持久連線顯著提升了頁面載入速度，改善了使用者體驗，特別是在載入複雜的網頁時。

• 更好的響應時間：

  • 減少的延遲和更高的吞吐量使得 Web 應用能夠更快地響應使用者請求，提供了更流暢的互動體驗。

2. HTTP/1.1 - 隊頭阻塞問題

HTTP/1.1 的隊頭阻塞問題主要源於其序列化的請求/響應模型。在一個連線上必須等待前一個請求的響應完成後才能傳送下一個請求，這種設計限制了連線的效率，特別是在需要處理多個請求時。透過升級到 HTTP/2 或最佳化網路和伺服器效能，可以有效緩解或解決這一問題。

2.1. 序列請求/響應模型

• 單一請求處理：

  • HTTP/1.1 在一個 TCP 連線上只能同時處理一個請求和一個響應。這意味著必須等待當前請求的響應完成後，才能傳送下一個請求。
  • 這種設計導致了一個關鍵問題：如果一個請求的響應需要較長時間（可能是網路傳輸慢，可能是伺服器業務處理慢），後續的請求就會被阻塞，無法在同一個連線上並行處理。

• 典型場景：

  • 在載入網頁時，瀏覽器需要從同一個伺服器請求多個資源（如 HTML、CSS、JavaScript、影像等）。如果一個資源請求的響應較慢，其他資源的請求就會被阻塞，導致整個頁面載入變慢。

2.2. 瀏覽器的連線限制

如果基於單個 TCP 連線的 HTTP 請求，存在阻塞問題，那麼開啟多個 TCP 連線，是解決 HTTP/1.1 阻塞問題最簡單方法。不過大多數瀏覽器最多隻可以為每個域名開啟6個連線，即6個 TCP 連線，即可以有6個 HTTP 請求同時並行開啟。

突破請求數限制做的努力

為了進一步突破6個連線的現在，許多網站從子域名（例如：static.example.com）提供css、js等靜態資源，Web瀏覽器從而可以為每個新域名開啟另外的6個連線。這種技術叫 域名分片。

但瀏覽器既然限制併發的連線上限，肯定有自己的意義。多個 TCP 連線增加了伺服器和網路的負擔，因為每個連線都需要進行 TCP 握手和維護狀態，不僅增加了網路擁塞，維護連線需要消耗更多的記憶體和CPU等資源。

2.3. 資源請求的依賴性

• 資源載入順序：

  • 在複雜的網頁中，某些資源可能依賴於其他資源的載入完成。例如，JavaScript 檔案可能需要在特定的 CSS 檔案載入後執行。
  • 如果某個關鍵資源的請求被阻塞，可能會導致整個頁面的渲染延遲，從而影響使用者體驗。

2.4. 網路和伺服器因素

• 伺服器處理時間：

  • 如果伺服器處理某個請求需要較長時間，響應會被延遲，從而導致後續請求被阻塞。

• 網路延遲：

  • 網路條件不佳（如高延遲或丟包）也會加劇隊頭阻塞問題，因為它會增加請求和響應的時間。

2.5. 請求資源大

1. 文字格式體積大

HTTP/1.1 是一個簡單的文字協議，這種簡單性也帶來的一些問題，儘管訊息體可以包含二進位制資料（比如圖片等），但請求和首部都需要是文字的形式。

文字格式對於人類來說很友好，但對於機器並不友好。向HTTP首部中新增換行符，可以進行一些HTTP攻擊。最主要的是訊息體會比較大，不如二進位制體積小。

2. 請求頭冗餘

HTTP/1.1 請求頭的應用場景很多了，請求頭所佔的資料量越來越大，但內容大多重複。

就算只有主頁需要 cookie，每個發向伺服器的 HTTP 請求中都會包含 cookie。通常靜態資源，如：圖片、css、js 都不需要 cookie的。包括像 Content-Security-Policy 這種關於安全的頭部，會導致頭部非常大，從而使效率低下的問題越來越突出。通常一個 GET 請求中請求引數不大，但頭部資料可能卻佔了幾K。

頭部冗餘導致頻寬浪費，尤其在高延遲和低頻寬網路中，對效能影響顯著。完全可以利用其較高的重複性好好最佳化。

3. 合併請求做的努力

另一個常見的最佳化思路就是傳送更少的請求，包括：減少不必要的請求（比如在瀏覽器中快取靜態資源）。

對於圖片來說，有種叫做“精靈圖”的打包技術。如果網站上有很多圖示，如果每個圖示都是一張獨立的圖片，會導致很多低效的HTTP請求排隊。以為圖片比較小，所以相對於下載這些圖片所需要的時間，傳送請求的時間可能會較長。

所以，可以將它們合併到一張大的圖片裡，然後使用CSS來定點陣圖片位置，讓它們看起來像是獨立的圖片，這樣更高效。

如果是 CSS、JS檔案，前端框架通常也會將多個檔案合併成一個檔案，這樣需要的請求數就少了，總的程式碼量並不會變。在合併檔案的時候，通常還會去掉程式碼中不必要的空格、註釋等。

這種思路不錯，但也會帶來一定的複雜性。如果需要修改某個圖示，還需要重新維護整個精靈圖。

3. HTTP/2 - 解決隊頭阻塞

HTTP/2 透過一系列技術革新，去解決 HTTP/1.1 的隊頭阻塞問題。HTTP/1.1 的隊頭阻塞主要是因為其在一個 TCP 連線上只能同時處理一個請求和響應，這種序列化的處理方式導致了效能瓶頸。HTTP/2 的設計目標之一就是消除這種限制。以下是 HTTP/2 如何解決隊頭阻塞問題的詳細介紹：

3.1. 多路複用

• 概念：

  • HTTP/2 允許在一個單一的 TCP 連線上同時傳送和接收多個請求和響應，而不必按照請求的順序來等待響應。這是透過引入“流”（streams）的概念實現的。

• 工作機制：

  • 在 HTTP/2 中，資料被分成更小的幀，這些幀可以在同一個連線中並行傳輸。每個流都有一個唯一的識別符號，資料幀可以亂序到達和處理。
  • 這種機制避免了 HTTP/1.1 中必須等待前一個請求完成後才能傳送下一個請求的限制。

• 優勢：

  • 透過多路複用，HTTP/2 消除了單個請求阻塞其他請求的情況，提高了資料傳輸效率和網路利用率。

3.2. 二進位制分幀

• 高效傳輸：

  • HTTP/2 使用二進位制格式傳輸資料，取代了 HTTP/1.1 的文字格式。這種格式更緊湊，解析更快，減少了由於格式解析而導致的延遲。

• 幀的獨立性：

  • 資料被分割成二進位制幀，幀是獨立的，這樣即使某個流中的幀被延遲或丟失，也不會影響其他流的資料傳輸。

3.3. 流優先順序和依賴

• 優先順序設定：

  • HTTP/2 允許客戶端為每個流設定優先順序，伺服器可以根據這些優先順序來決定資源分配策略。

• 依賴關係：

  • 流可以相互依賴，形成一個依賴樹結構，伺服器可以根據優先順序和依賴關係最佳化資源處理。

• 效果：

  • 透過優先順序和依賴關係，關鍵請求可以被優先處理，進一步減少可能的阻塞和延遲。

3.4. 頭部壓縮

HTTP/2 的頭部壓縮機制使用了 HPACK 演算法來減少 HTTP 頭部資訊的冗餘傳輸，從而提高傳輸效率。這一機制透過靜態表和動態表來壓縮頭部欄位及其值，並使用哈夫曼編碼進行進一步壓縮。以下是對 HPACK 頭部壓縮的詳細介紹，並附帶一個簡單示例。

3.4.1. HPACK 壓縮機制

1. 靜態表

• 靜態表是一個預定義的頭部欄位及其常用值的集合。在 HPACK 中，這個表是固定的，包含了常用的 HTTP 頭部欄位，如 :method, :path, :authority 等。
• 使用靜態表時，可以透過索引直接引用這些常用的頭部欄位，減少傳輸資料量。

2. 動態表

• 動態表是在連線期間動態維護的表，用於儲存最近使用的頭部欄位和值。每當一個新的頭部欄位被傳輸時，它可以被新增到動態表中。
• 動態表是可變大小的，伺服器和客戶端可以根據需要調整其大小。

3. 哈夫曼編碼

• 哈夫曼編碼是一種可變長度的編碼方法，用於對頭部欄位的名稱和值進行進一步壓縮。它透過對頻繁出現的字元使用更短的編碼來減少資料量。

3.4.2. 示例

假設我們有一個 HTTP 請求，其頭部如下：

:method: GET
:scheme: https
:authority: www.example.com
:path: /index.html
user-agent: Mozilla/5.0

1. HPACK 壓縮過程

1. 使用靜態表：

   • :method: GET 和 :scheme: https 可以在靜態表中找到對應的索引，因此可以直接使用索引來引用。

2. 使用動態表：

   • :authority: www.example.com 和 user-agent: Mozilla/5.0 可能是首次傳輸，因此會被新增到動態表中以供後續請求使用。

3. 哈夫曼編碼：

   • :path: /index.html 和其他未在靜態表中的值可以使用哈夫曼編碼進行壓縮。

靜態表 VS 動態表

• 靜態表：內容固定，不會隨連線變化。它包含常用的、標準化的頭部欄位及其常見值。
• 動態表：內容可變，隨著連線的進展動態更新，儲存在連線過程中實際傳輸的頭部欄位和值。

可以看到靜態表內容是固定的。動態表更靈活，但需要動態管理，增加了實現的複雜性，涉及記憶體和效能的開銷，所以效能上不如靜態表。

因此，如果內容在靜態表中存在，協議優先使用靜態表，否則再考慮使用動態表。

壓縮後的傳輸

透過上述步驟，頭部資訊會被轉換為一系列的二進位制資料，這些資料比原始的頭部資訊要小得多。在接收端，這些二進位制資料會被解碼成原始的頭部資訊。

3.5. 伺服器推送

HTTP/2 的伺服器推送（Server Push）是一項強大的功能，它允許伺服器在客戶端請求某個資源之前，主動將相關資源推送到客戶端。這種機制可以顯著減少網頁載入時間，尤其是在高延遲網路環境中。以下是關於 HTTP/2 伺服器推送的詳細介紹。

1. 工作原理

1. 客戶端請求：

   • 客戶端發起一個 HTTP 請求，比如請求一個 HTML 頁面。

2. 伺服器識別依賴：

   • 伺服器在處理請求時，可以識別出該頁面所需的其他資源，比如 CSS、JavaScript 或圖片檔案。

3. 傳送推送承諾（Push Promise）：

   • 伺服器向客戶端傳送一個 PUSH_PROMISE 幀。這一幀告知客戶端將要推送的資源，幷包含這些資源的請求頭資訊。
   • PUSH_PROMISE 幀的傳送順序是在客戶端請求的響應之前，這樣客戶端可以知道即將接收到哪些資源。

4. 主動推送資源：

   • 伺服器隨後將這些資源作為響應推送給客戶端，類似於正常的 HTTP 響應。

5. 客戶端處理：

   • 客戶端接收這些推送的資源後，可以將其快取，以便後續使用，而無需再發起請求。

2. 優勢

• 減少延遲：透過提前傳送資源，減少了客戶端請求這些資源的延遲。
• 最佳化載入順序：伺服器可以根據頁面依賴關係最佳化資源的推送順序，提高頁面載入效率。
• 減少請求次數：避免了客戶端在解析 HTML 後再發起的額外請求，減少了請求次數和伺服器負載。

3. 示例

假設一個網頁需要載入多個資源：

1. 客戶端請求 /index.html。
2. 伺服器識別出 /index.html 依賴於 /style.css 和 /script.js。
3. 伺服器傳送 PUSH_PROMISE 幀給客戶端，表示將推送 /style.css 和 /script.js。
4. 伺服器隨後主動推送 /style.css 和 /script.js 的內容。
5. 客戶端接收這些資源並快取，以便在解析 HTML 時直接使用。

4. HTTP、TCP隊頭阻塞

前面講解 HTTP/1.1 的隊頭阻塞問題，其實我們也常接觸到 TCP 隊頭阻塞問題，這兩者不是同一個概念。

雖然 HTTP/1.1 也是基於 TCP協議建立連線到，HTTP/1.1 隊頭阻塞問題，也會因為 TCP 隊頭阻塞問題受到影響，但二者不能劃等號。

HTTP/1.1 的隊頭阻塞問題主要是由於其序列請求/響應模型導致的，而 TCP 的隊頭阻塞問題則源於其可靠傳輸的順序保證機制。HTTP/1.1 的問題可以透過升級到 HTTP/2 來解決，而 TCP 的問題可以透過使用 QUIC 協議或網路最佳化來緩解。透過針對不同層次的問題採取適當的解決方案，可以顯著提高網路傳輸效率和使用者體驗。

4.1. HTTP/1.1 隊頭阻塞

1. 產生原因

1. 序列請求/響應模型：

   • 在 HTTP/1.1 中，一個 TCP 連線上通常只能同時處理一個請求和一個響應。這意味著在一個連線中，必須等待當前請求的響應完成後，才能開始處理下一個請求。
   • 這種序列化的處理方式導致了隊頭阻塞問題：如果一個請求的響應時間較長，後續的請求就會被阻塞，無法及時處理。

2. 有限的併發連線：

   • 瀏覽器為了減輕單連線的限制，通常會對每個域名開啟多個併發連線（通常是 6 個左右）。然而，連線數的增加會導致伺服器負載增加和網路資源浪費。
   • 即便如此，多個連線之間的請求仍然是序列化的，無法完全消除隊頭阻塞的問題。

2. 影響

• 頁面載入速度慢：當一個請求被阻塞時，後續請求的資源無法及時獲取，導致頁面載入變慢。
• 使用者體驗下降：由於資源載入緩慢，使用者可能會感到網頁響應遲緩，影響使用者體驗。

4.2. TCP 隊頭阻塞

1. 產生原因

1. 可靠傳輸的順序保證：

   • TCP 協議旨在提供可靠的、有序的資料傳輸。它透過序列號來確保資料包按序到達。接收方必須按照序列號的順序來處理資料包。
   • 如果某個資料包丟失或延遲到達，接收方必須等待該資料包被重傳或到達，才能繼續處理後續的資料包。

2. 網路抖動和丟包：

   • 在實際網路環境中，資料包可能會因為各種原因（如網路擁塞、硬體故障等）而丟失、延遲或亂序。
   • TCP 的順序保證機制要求在處理後續資料之前，必須解決這些丟失或延遲的問題，這會導致整個連線的阻塞。

2. 影響

• 傳輸延遲增加：因為需要等待丟失的資料包被重傳，整個資料流的傳輸延遲會增加。
• 吞吐量降低：由於某個資料包的丟失或延遲，整個連線的吞吐量會降低，因為後續的資料包無法被及時處理。

4.3. 兩者之間的關係

1. 層次不同：

   • TCP 隊頭阻塞發生在 傳輸層，而 HTTP 隊頭阻塞發生在 應用層。這意味著它們發生在網路協議棧的不同層次。

2. 間接影響：

   • 雖然 TCP 的隊頭阻塞不會直接導致 HTTP 的隊頭阻塞，但它會間接影響 HTTP 請求的效率。
   • 在 HTTP/1.1 中，如果 TCP 連線上的某個資料包丟失，整個連線上的所有 HTTP 請求都會受到影響，因為 TCP 必須等待丟失的資料包重傳。

3. HTTP/2 的改進：

   • HTTP/2 透過多路複用技術在應用層解決了 HTTP/1.1 的隊頭阻塞問題。即使在同一個 TCP 連線上，多個請求和響應也可以同時進行。
   • 然而，HTTP/2 仍然依賴於 TCP，因此仍然可能受到 TCP 隊頭阻塞的影響。如果 TCP 層發生隊頭阻塞，HTTP/2 的所有流都會受到影響。

4.4. 解決方案概述

4.4.1. HTTP/2 不能真正解決問題

按照前文的方式，從 HTTP/1.1 升級到 HTTP/2，可以“解決”隊頭阻塞的問題。HTTP/2 引入了多路複用技術，允許在一個 TCP 連線上同時處理多個請求和響應，避免了序列化處理的瓶頸。

雖然 HTTP/2 在應用層有效地緩解了 HTTP 層面的隊頭阻塞，但由於其依賴於 TCP 作為底層傳輸協議，仍然會受到 TCP 隊頭阻塞問題的影響。只有也解決了傳輸層的隊頭阻塞問題，才能說HTTP應用層真正解決了。

4.4.2.TCP 隊頭阻塞的解決

HTTP/2 無法徹底解決隊頭阻塞問題，解決傳輸層隊頭阻塞問題的答案在 HTTP/3，HTTP/3 使用的傳輸層協議是 QUIC協議。QUIC 執行在 UDP 之上，而不是 TCP。

QUIC（Quick UDP Internet Connections）是由 Google 開發的一種傳輸層網路協議，旨在提高網路應用的效能和安全性。QUIC 的設計初衷是解決 TCP 的一些固有缺陷，特別是在高延遲和高丟包率的網路環境中。它已經被廣泛應用於 HTTP/3 中。

QUIC 協議透過多個創新機制解決了傳統 TCP 中的隊頭阻塞問題，以下是詳細說明：

1. 多路複用的獨立流

• 流的獨立性：

  • QUIC 協議允許在單個連線中同時進行多個獨立的流傳輸。每個流都有自己的流 ID，並且在傳輸過程中是彼此獨立的。
  • 在 TCP 中，如果一個資料包丟失，接收端必須等待該資料包被重傳後才能處理後續的資料包，這就導致了隊頭阻塞。
  • QUIC 透過允許不同流獨立傳輸，使得即便一個流中的資料包丟失，也不會影響其他流的傳輸和處理。

2. 基於 UDP 的實現

• 去除 TCP 順序依賴：

  • QUIC 使用 UDP 作為底層協議，而不是 TCP。這意味著 QUIC 不受 TCP 的順序交付限制，可以自由實現自己的流控制和擁塞控制。
  • 因為 QUIC 在使用者態實現，可以直接管理資料包的傳輸順序和重傳策略，而無需依賴核心態的 TCP 棧。

3. 高效的重傳機制

• 快速重傳：

  • QUIC 協議支援快速重傳機制。當檢測到資料包丟失時，QUIC 可以立即重傳丟失的資料包，而不需要等待傳統的 TCP 超時。
  • QUIC 的設計允許接收方傳送關於丟失資料包的精確反饋，傳送方可以根據這些反饋迅速進行重傳。

4. 靈活的擁塞控制

• 自定義擁塞控制演算法：

  • QUIC 允許實現自定義的擁塞控制演算法，這使得它可以在不同網路條件下最佳化資料傳輸。
  • 由於其在使用者態實現，開發者可以根據具體需求調整擁塞控制策略，以減少丟包對傳輸效率的影響。

5. 前向糾錯

• 糾錯機制：

  • QUIC 可以在傳輸資料時新增冗餘資訊，使得接收方能夠在一定程度上自行糾正丟失的資料包，而無需重傳。這進一步減少了因丟包帶來的延遲。

6. 0-RTT 連線建立

• 快速連線建立：

  • QUIC 支援 0-RTT（零往返時間）連線建立，這意味著在某些情況下，資料可以在連線建立的同時傳送。這減少了初始連線建立的延遲。

5. HTTP各版本

HTTP 的每個版本都在解決其前任版本的不足，並適應不斷變化的網路需求和技術進步。HTTP/1.1 增強了持久連線和快取控制，HTTP/2 提升了傳輸效率和併發能力，而 HTTP/3 則透過 QUIC 協議提供了更快和更可靠的網路傳輸體驗。

1. HTTP/0.9

• 釋出年份：1991

• 特點：

  • 最初的 HTTP 版本，設計極為簡單。
  • 僅支援 GET 方法，沒有版本號標識。
  • 響應僅包含純文字資料，沒有 HTTP 頭部。
  • 主要用於傳輸簡單的 HTML 頁面。

2. HTTP/1.0

• 釋出年份：1996 (RFC 1945)

• 特點：

  • 引入了 HTTP 頭部，允許傳輸更多型別的資料。
  • 支援多種方法：GET、POST、HEAD。
  • 引入了狀態碼和響應頭，提供更多的響應資訊。
  • 每個請求/響應對使用一個單獨的 TCP 連線。

3. HTTP/1.1

• 釋出年份：1997 (RFC 2068)，後續更新為 RFC 2616，並最終在 2014 年被 RFC 7230-7235 替代。

• 特點：

  • 預設使用持久連線（Persistent Connection），減少了連線建立的開銷。
  • 支援請求管道化（Pipelining），允許在同一個連線上傳送多個請求而無需等待響應。
  • 增強了快取控制機制。
  • 支援分塊傳輸編碼（Chunked Transfer Encoding），允許動態生成內容。
  • 增加了更多的 HTTP 方法和頭欄位。

4. HTTP/2

• 釋出年份：2015 (RFC 7540)

• 特點：

  • 引入二進位制分幀層，提升了傳輸效率。
  • 支援多路複用，允許在一個連線上同時處理多個請求和響應。
  • 使用 HPACK 壓縮演算法對頭部進行壓縮，減少傳輸資料量。
  • 支援伺服器推送（Server Push），允許伺服器主動向客戶端傳送資源。

5. HTTP/3

• 釋出年份：2022 (RFC 9114)

• 特點：

  • 基於 QUIC 協議，執行在 UDP 之上，提供更快的連線建立和恢復能力。
  • 解決了 TCP 層的隊頭阻塞問題，透過獨立流提供更好的效能。
  • 繼續支援多路複用和伺服器推送。
  • 提供更好的安全性和加密效能。

前期的版本都是小版本迭代，有良好的相容性，如：HTTP/1.0 -> HTTP/1.1。

但 HTTP/1.1 -> HTTP/2，HTTP/2 直接到 HTTP/3，都是大版本迭代，因為變更很大，向前相容很難。另外市場上各家瀏覽器、社群生態對新版本的相容也需要時間，所以主流的使用版本還是 HTTP/1.1。