總結從HTTP到HTTP/3的發展簡史

這篇文章主要講解了“總結從HTTP到HTTP/3的發展簡史”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“總結從HTTP到HTTP/3的發展簡史”吧！

雖然 HTTP/3 規范仍處于起草階段，但最新版本的 Chrome 瀏覽器已經默認支持它了。Chrome 擁有約 70％的瀏覽器市場份額，所以，可以說 HTTP/3 已經進入主流世界。

這一基礎協議的最新修訂版旨在讓 Web 更加高效、安全并縮短內容交付延遲。從某些角度來說，它是 HTTP2 的完善：通過使用新的專用協議 QUIC 替換基礎 TCP 協議來解決和之前類似的目標。

想要弄明白 QUIC 的優點，最好的辦法是講清楚 TCP 作為 HTTP 請求的傳輸方式有哪些不足之處。

為此，我們將從頭開始細細道來。

1. HTTP：起源

1991 年，當蒂姆·伯納斯·李爵士設計出一個簡單的單行超文本交換協議時，TCP 已經是一個古老而可靠的協議了。前者的原始定義文檔（也就是后人熟知的 HTTP 0.9）特別提到 TCP 是首選的（盡管并非唯一的）傳輸協議：

注意：HTTP 當前運行在 TCP 上，但也可以運行在任何面向連接的服務上。

當然，HTTP 的這個概念驗證版本與我們現在所知道和喜歡的 HTTP 幾乎沒有相似之處。沒有標頭，也沒有狀態碼。典型的請求只有GET/path而已。響應僅包含 HTML，且 TCP 連接關閉就會結束。

由于瀏覽器尚未流行，因此用戶需要直接閱讀 HTML。可以用它鏈接到其他資源，但是在這個 HTML 早期版本中存在的所有標簽都不會異步請求其他資源。一個 HTTP 請求就傳遞了一個完整的、自給自足的頁面。

2. HTTP/1.0 出現

在隨后幾年中，互聯網迎來爆炸式的發展，盡管傳輸 HTML 仍然是 HTTP 的主要特色，但它逐漸發展成一種可擴展且靈活的通用協議。HTTP 的三大重要更新奠定了這一演變的基礎：

•  方法的引入使客戶能確定其想要執行操作的類型。例如，引入 POST 是為了允許客戶端將數據發送到服務器以處理和存儲；

•  狀態碼為客戶端提供了一種確認服務器已成功處理請求的方法——如果處理失敗，則可以用它了解發生了哪種錯誤；

•  標頭增加了將結構化文本元數據附加到可以修改客戶端或服務器行為的請求和響應上的功能。例如，編碼和內容類型頭使 HTTP 不僅可以傳輸 HTML，還可以傳輸任何類型的負載。“壓縮”標頭允許客戶端和服務器協商支持的壓縮格式，從而減少了通過連接傳輸的數據量。

同時，HTML 也不斷進化，支持了圖像、樣式和其他鏈接資源。

現在，瀏覽器需要執行多個請求來顯示一個網頁，而原始的“按請求連接”架構是做不到的。建立和終止 TCP 連接涉及大量的數據包來回交換，因此在延遲開銷方面相對昂貴。網頁不見得一定由單個文本文件組成，但是隨著每頁請求數量的增加，延遲也隨之增加。

下圖說明了每建立一個新的 TCP 連接涉及多少請求開銷。

TCP 連接需要三個請求才能建立連接，四個請求可以完全關閉。

人們創建了一個“連接”標頭來解決這個問題。客戶端發送帶有“connection:keep-alive”標頭的請求，以表明意圖為后續請求保持 TCP 連接的打開狀態。如果服務器理解此標頭并同意遵守該標頭，則其響應還將包含“connection:keep-alive”標頭。

這樣，雙方都保持 TCP 通道打開并使用它進行后續通信，直到任何一方決定關閉它為止。隨著 SSL/TLS 加密技術的發展，這一點變得更加重要，因為協商加密算法和交換加密密鑰需要在每個連接上增加一個請求 / 響應周期。

單個 TCP 連接可以通過“connection:keep-alive”標頭。

重用于多個請求當時，許多 HTTP 改進都是自發出現的。當流行的瀏覽器或服務器應用程序需要新的 HTTP 功能時，它們會自己實現該功能，并希望其他各方也能效仿。具有諷刺意味的是，去中心化的 Web 需要一個中心化的管理機構來避免碎片化造成的不兼容問題。

該協議的最初創建者蒂姆·伯納斯·李（TimBerners-Lee）意識到了這種危險，并于 1994 年成立了萬維網聯盟（W3C），該聯盟與互聯網工程任務組（IETF）一起致力于規范互聯網的技術棧。作為為已有環境帶來更多規范的第一步，他們記錄了當時 HTTP 中最常用的一些功能，并將其命名為 HTTP/1.0 協議。

但是，由于這種“規范”描述的是多種多樣的，通常在“實踐”中用法不一致的技術，因此它從未獲得過標準地位。相比之下，關于 HTTP 協議新版本的工作已經開始了。

3. HTTP/1.1 的標準化

HTTP/1.1 修復了 HTTP/1.0 的不一致之處，并調整了協議，使其在新的 Web 生態系統中具備更好的性能表現。新版引入的兩個最關鍵的更改是默認使用持久 TCP 連接（保持活動狀態）和 HTTP 管線化。

HTTP 管線化的意思就是客戶端無需在發送后續 HTTP 請求之前等待服務器響應請求。此功能可以更有效地利用帶寬并減少延遲，但它的改進空間甚至更大。HTTP 管線化仍要求服務器按照接收到的請求順序進行響應，因此，如果管線化中的單個請求執行得很慢，則對客戶端的所有后續響應都將相應地延遲下去。這個問題被稱為線頭阻塞。

由于首先請求了 large-picture.jpg，因此阻止了 style.css 的發布

在這個時候，Web 正在獲得越來越多的交互功能。Web 2.0 指日可待，一些網頁包含數十個甚至數百個外部資源。為解決線頭阻塞，并降低頁面加載速度，客戶端會在每個主機上建立多個 TCP 連接。當然，連接開銷并沒有消失不見。實際上情況變得更糟了，因為越來越多的應用程序開始使用 SSL/TLS 加密 HTTP 通信。因此，大多數瀏覽器都設置了最大可能同時連接數的限制，以尋求微妙的平衡。

許多較大的 Web 服務已經意識到，現有的限制對于其交互極為繁重的 Web 應用程序來說太過嚴格，因此它們會通過多個域名分發其應用程序來“玩弄系統”。這種辦法好歹起效了，但是解決方案根本談不上優雅。

盡管存在一些缺點，但是 HTTP/1.0 和 HTTP/1.1 的簡單性使它們獲得了廣泛的成功，并且十多年來，沒有人認真地嘗試過改變它們。

4. SPDY 和 HTTP/2

谷歌在 2008 年發布了 Chrome 瀏覽器，這種瀏覽器因其快速和創新而迅速流行。它使谷歌在互聯網技術問題上獲得了強大的話語權。在 2010 年代初期，谷歌在 Chrome 中增加了對其 Web 協議 SPDY 的支持。

HTTP/2 標準基于 SPDY，并進行了一些改進。HTTP/2 通過在單個打開的 TCP 連接上多路復用 HTTP 請求，解決了線頭阻塞問題。這允許服務器以任何順序響應請求，然后客戶端可以在接收到響應時重新組合響應，從而在單個連接中加快整個交換的速度。

由于 HTTP/2 可以多路傳輸，因此在 large-picture.jpg 之前返回了 style.css

實際上，使用 HTTP/2 服務器甚至可以在請求之前就將資源提供給客戶端！舉個例子，如果服務器知道客戶端很可能需要樣式表來顯示 HTML 頁面，它可以將 CSS“推”到客戶端，而無需等待相應的請求。雖然這從理論上講是有益的，但此功能在實踐中很少見，因為它需要服務器了解其服務的 HTML 結構，但這種情況很少發生。

除了請求正文以外，HTTP/2 還允許壓縮請求標頭，這進一步減少了通過網絡傳輸的數據量。

HTTP/2 解決了 Web 上的許多問題，但不是全部。在 TCP 協議級別上仍然存在類似類型的線頭問題，而 TCP 仍然是 Web 的基礎構建塊。當 TCP 數據包在傳輸過程中丟失時，在服務器重新發送丟失的數據包之前，接收方無法確認傳入的數據包。由于 TCP 在設計上不遵循 HTTP 之類的高級協議，因此單個丟失的數據包將阻塞所有進行中的 HTTP 請求的流，直到重新發送丟失的數據為止。這個問題在不可靠的連接上尤為突出，這在無處不在的移動設備時代并不罕見。

5. HTTP/3 革命

由于 HTTP/2 的問題不能僅靠應用程序層來解決，因此協議的新迭代必須更新傳輸層。但是，創建新的傳輸層協議并非易事。傳輸協議需要硬件供應商的支持，并且需要大多數網絡運營商的部署才能普及。由于此事涉及的成本和工作量，運營商們不愿進行更新。以 IPv6 為例：它是 24 年前推出的，但如今距離獲得普遍支持還有很遠的距離。

幸運的是還有另一種選擇。UDP 協議與 TCP 一樣得到廣泛支持，但前者足夠簡單，可以作為在其之上運行的自定義協議的基礎。UDP 數據包是一勞永逸的：沒有握手、持久連接或錯誤校正。HTTP3 背后的主要思想是放棄 TCP，轉而使用基于 UDP 的 QUIC 協議。QUIC 以對 Web 環境有意義的方式添加了許多必要的功能（包括以前由 TCP 提供的功能，以及更多功能）。

與 HTTP2 在技術上允許未加密的通信不同，QUIC 嚴格要求加密后才能建立連接。此外，加密不僅適用于 HTTP 負載，還適用于流經連接的所有數據，從而避免了一大堆安全問題。建立持久連接、協商加密協議，甚至發送第一批數據都被合并到 QUIC 中的單個請求 / 響應周期中，從而大大減少了連接等待時間。如果客戶端具有本地緩存的密碼參數，則可以通過簡化的握手（0-RTT）重新建立與已知主機的連接。

為了解決傳輸級別的線頭阻塞問題，通過 QUIC 連接傳輸的數據被分為一些流。流是持久性 QUIC 連接中短暫、獨立的“子連接”。每個流都處理自己的錯誤糾正和傳遞保證，但使用連接全局壓縮和加密屬性。每個客戶端發起的 HTTP 請求都在單獨的流上運行，因此丟失數據包不會影響其他流/請求的數據傳輸。

HTTP/3 將連接分為單獨的流UDP 是一種無狀態協議（持久連接只是其之上的抽象），使 QUIC 能夠支持一些很大程度上忽略了數據包傳遞復雜性的功能。例如，從理論上講，客戶端更改其 IP 地址中間連接（例如智能手機從移動網絡跳轉到家庭 wifi）時不應中斷連接，因為該協議允許在不同 IP 地址之間遷移而無需重新連接。

QUIC 協議的所有現有實現當前都在用戶空間，而不是 OS 內核中運行。由于客戶端（例如瀏覽器）和服務器的更新通常比操作系統內核更新的頻率更高，因此人們希望可以藉此更快地采用新功能。

6. HTTP/3 存在的問題

我認為 HTTP/3 標準雖然是向更快、更安全的互聯網邁出的一大步，但它并不完美。它的某些問題是由其新穎性引起的，而其他一些問題似乎是該協議固有的。

TCP 協議已經存在了很長時間，對于路由器來說很容易理解。它具有清晰的未加密標記（用于建立和關閉連接），可用于跟蹤和控制現有會話。在網絡硬件學會了解新協議之前，它將把 QUIC 流量簡單地看作獨立的 UDP 數據包流，這將使網絡配置更加棘手。

從客戶端緩存“恢復”連接的能力使該協議很容易遭受重播攻擊：在某些情況下，惡意攻擊者可以重新發送以前捕獲的數據包，這些數據包將被服務器解釋為有效的，來自受害者的。像那些提供靜態內容的 Web 服務器一樣，許多 Web 服務器不會受到此類攻擊的傷害。對于身處易受攻擊環境的應用程序來說，必須要記住禁用 0-RTT 功能。

這就是 HTTP 到今天為止的故事。我認為 HTTP/3 是向前邁出的一大步，并且當然希望 HTTP/3 在不久的將來會被廣泛采用。

感謝各位的閱讀，以上就是“總結從HTTP到HTTP/3的發展簡史”的內容了，經過本文的學習后，相信大家對總結從HTTP到HTTP/3的發展簡史這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！