來自 RFC7540：
雖然 HTTP/1.x 使用訊息起始行（參見 [RFC7230]，第 3.1 節）來傳達目標 URI、請求的方法和回應的狀態代碼，但 HTTP/2 使用特殊的偽標頭欄位為此，以 ':' 字符（ASCII 0x3a）開頭。
那么為什么 HTTP/2 使用偽頭欄位呢？HTTP/1.x 中的訊息起始行有什么問題嗎？
uj5u.com熱心網友回復：
借用
在這張圖片中，您可以看到在第一個請求中的前兩個標題行通常是這樣的：
GET /resoure HTTP/1.1
Host: https://example.com
...
現在被分成這樣的標題幀
:method: GET
:scheme: https
:host: example.com
:path: /resource
...
而其余的標題或多或少相同，除了都是小寫字符。
HTTP/2 嘗試盡可能地最小化負載大小。它還將壓縮與前一個請求中發送的標頭相同的標頭和條標頭，如鏈接影像的右側部分所示。
在 HTTP/1.1 中，連續請求看起來像第一個初始請求，只是針對不同的資源：
GET /otherResource HTTP/1.1
Host: https://example.org
...
而在 HTTP/2 中，對同一服務器的連續請求只需要
:path: /otherResource
因為所有其他標頭都已經可用，并且可以從以前快取和索引的標頭中恢復。
因此，這是進一步減少連續請求的有效負載的優化。
uj5u.com熱心網友回復：
HTTP/2 是新協議，采用二進制編碼。
HTTP/2 中沒有狀態行，就像單個標頭沒有“行”一樣。必須發明一種全新的方法來對 HTTP 請求的每個部分進行編碼。
標題實際上是一個鍵-> 值結構。與其為出現在 HTTP/1.1 請求第一行的內容發明不同的編碼，不如將相同的編碼方法用于這些內容，從而使協議更簡單。
畢竟，像“路徑”和“http 方法”這樣的東西已經在標頭中了，為什么不采用相同的方法將它們編碼為常規標頭。該:前確保沒有沖突與現有的HTTP / 1.1頭，因為頭的名稱不能含有:。
所以 tl;dr 是：通過將來自 HTTP 請求和回應的第一行的資訊編碼為特殊的 HTTP 標頭，協議可以更簡單。
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/330783.html