[譯] HTTP/3: 起源

時間 2019-11-06

標籤 http 起源欄目 HTTP/TCP 简体版

原文原文鏈接

原文地址：HTTP/3: From root to tip

原文做者：Lucas Pardue

譯文出自：掘金翻譯計劃

本文永久連接：github.com/xitu/gold-m…

譯者：Starrier

校對者：jerryOnlyZRJ，kasheemlew，Fengziyin1234

HTTP 是確保 Web 應用程序正常運行的應用層協議。1991 年，HTTP/0.9 正式發佈，至 1999 年，已經發展爲 IETF（國際互聯網工程任務組）的標準化協議 HTTP/1.1。在很長的一段時間裏，HTTP/1.1 表現得都很是好，但面對現在變化無窮的 Web 需求，顯然須要一個更爲合適的協議。2015 年，HTTP/2 應運而生。最近，有人披露 IETF 預計發佈一個新版本 —— HTTP/3。對有些人來講，這是驚喜，也引起了業界的激烈探討。若是你不怎麼關注 IETF，可能就會以爲 HTTP/3 的出現很是忽然。但事實是，咱們能夠透過 HTTP 的一系列實現和 Web 協議發展來追溯它的起源，尤爲是 QUIC 傳輸協議。html

若是你不熟悉 QUIC，能夠查看我同事的一些高質量博文。John 的博客從不一樣的角度討論了現現在的 HTTP 所存在的一些問題，Alessandro 的博客闡述了傳輸層的本質，Nick 的博客涉及了相關測試的處理方法。咱們對這些相關內容進行了收集整理，若是你想要查看更多內容，能夠前往 cloudflare-quic.com。若是你對此感興趣，記得去查看咱們本身用 Rust 編寫的 QUIC 開源實現項目 —— quiche。前端

HTTP/3 是 QUIC 傳輸層的 HTTP 應用程序映射。該名稱在最近（2018 年 10 月底）草案的第 17 個版本中被正式提出（draft-ietf-quic-http-17），在 11 月舉行的 IETF 103 會議中進行了討論並造成了初步的共識。HTTP/3 之前被稱爲 QUIC（之前被稱爲 HTTP/2）。在此以前，咱們已經有了 gQUIC，而在更早以前，咱們還有 SPDY。事實是，HTTP/3 只是一種適用於 IETF QUIC 的新 HTTP 語法 —— 基於 UDP 的多路複用和安全傳輸。android

在本文中，咱們將討論 HTTP/3 之前一些名稱背後的歷史故事，以及最近改名的誘因。咱們將回到 HTTP 的早期時代，探尋它一路成長中的美好回憶。若是你已經火燒眉毛了，能夠直接查看文末，或打開這個詳細的 SVG 版本。ios

HTTP/3 分層模型（蛋糕模型）git

設置背景

在咱們關注 HTTP 以前，值得回憶的是兩個共享 QUIC 的名稱。就像咱們以前解釋得那樣，gQUIC 一般是指 Google QUIC（協議起源），QUIC 一般用於表示與 gQUIC 不一樣的 IETF 標準（正在開發的版本）。github

在 90 年代初期，Web 需求就已經發生了改變。咱們已經有了新的 HTTP 版本，以傳輸層安全（TLS）的形式增強用戶安全性。在本文中，咱們會涉及 TLS。若是你想更詳細地瞭解這個領域，能夠參閱咱們其餘的高質量博文。web

爲了幫助咱們瞭解 HTTP 和 TLS 的歷史，我整理了協議規範以及日期的細節內容。這種信息通常以文本形式呈現，好比，按日期排序說明文檔標題的符號點列表。不過，由於分支標準的存在，因此重疊的時間和簡單的列表並不能正確表達複雜的關係。在 HTTP 中，並行工做致使了核心協議定義的重構，爲了更簡單的使用，咱們爲新行爲擴展了協議內容，爲了提升性能，咱們甚至還重定義了協議如何在互聯網上交換數據。當你嘗試瞭解近 30 年的互聯網歷史，跨越不一樣的分支工做流程時，你須要將其可視化。因此我作了一個 Cloudflare 安全 Web 時間線（注意：從技術上說，它是進化樹，但時間線這個術語更廣爲人知）。後端

在建立它時，通過深思熟慮後，我選擇關注 IETF 中的成功分支。本文未涉及的內容，包括 W3C HTTP-NG 工做組的努力成果，還有些熱衷於解釋如何發音的做者的奇特想法：HMURR（發音爲 'hammer'）和 WAKA（發音爲「wah-kah」）。緩存

爲了讓大家更好地把握本文的脈絡，下面的一些部分，我會沿着這條時間線來解釋 HTTP 歷史的重點內容。瞭解標準化以及 IETF 是如何對待標準化的。所以，在回到時間線以前，咱們首先會對這個主題進行一個簡短的概述。若是你已經很是熟悉 IETF 了，能夠跳過該內容。安全

Internet 標準的類型

通常而言，標準定義了共同的職責範圍、權限、適用性以及其餘相關內容。標準有多種形狀和大小，能夠是非正式的（即事實上的），也能夠是正式的（由 IETF、ISO 或 MPEG 等標準定義組織協商/發佈的）。標準應用於衆多領域，甚至還有一種爲製茶而定義的正式標準的 —— BS 6008。

早期 Web 使用在 IETF 以外發布的 HTTP 和 SSL 協議定義，它們在安全的 Web 時間線上被標記爲紅線。客戶端和服務的對這些協議的妥協使它們得以成爲事實上的標準。

迫於當時的形式，這些協議最終被肯定爲標準化（一些激進的緣由會在以後進行描述）。互聯網標準一般在 IETF 中定義，以「多數共識和運行的代碼」非正式原則做爲指導。這是基於在互聯網上開發和部署項目的經驗。這與試圖在真空中開發完美協議的 "clean room" 方法造成了鮮明對比。

IETF 互聯網標準一般被稱爲 RFCs。這是一個解釋起來很複雜的領域，所以我建議閱讀 QUIC 工做組主席 Mark Nottingham 的博文 "如何閱讀 RFC"。工做組或 WG，或多或少的只是一個郵件列表。

IETF 每一年舉行三次會議，爲全部工做組提供時間和設施，若是他們願意的話，能夠親自前來。這幾周的行程擠在了一塊兒，須要在有限的時間裏深刻討論高級技術領域。爲了解決這個問題，一些工做組甚至選擇在 IETF 的通常性會議期間舉行臨時會議。這有助於保持規範開發的信心。自 2017 年以來，QUIC 工做組舉行了幾回臨時會議，能夠在其會議網站頁面查看完整清單。

這些 IETF 會議也爲 IETF 的相關羣體提供了機會，好比互聯網架構委員會或者互聯網研究任務組。最近幾年，在 IETF 會議前的幾周還舉行了 IETF Hackathon。這爲社區提供了一個開發運行代碼的機會，更重要的是，能夠和其餘人進行交互操做性測試。這有助於發現規範中的問題，並在接下來的會議中進行討論。

這個博客最重要的目的是讓你們理解 RFCs 並非憑空出世的。很顯然，它經歷了以 IETF 因特網草案（I-D）格式開始的過程，該格式是爲了考慮採用而提交的。在已發佈規範的狀況下，I-D 的準備可能只是一個簡單的重格式化嘗試。I-Ds 自發布起，有 6 個月的有效期。爲了保證它的活躍，須要發佈新的版本。實踐中，讓 I-D 消逝並不產生嚴重的後果，並且這一狀況時有發生。對於想要了解它們的人，能夠在 IETF 文檔網站閱覽。

I-Ds 在安全 Web 時間線上顯示爲紫色。每條線都有格式爲 draft-{author name}-{working group}-{topic}-{version} 的惟一名稱。工做組字段是可選的，它能夠預測 IETF 工做組是否在此工做，這是可變的參數，若是選用了 I-D，或者若是 I-D 是直接在 IETF 內啓動的，名稱爲 draft-ietf-{working group}-{topic}-{version}。I-Ds 就可能會產生分支，合併或者死亡。從 00 版本開始，每次發佈新草案就 +1。好比，I-D 的第四稿有 03 版本號。不管什麼時候，只要 I-D 變動名稱，它的版本號就會重置爲 00。

須要注意的是，任何人均可以向 IETF 提交一個 I-D；你不該該將這些視爲標準。但若是 IETF 的 I-D 標準化過程獲得了一致的確定，並且經過了最終的文件審查，咱們就會獲得一個 RFC。在此階段，名稱會再次變動。每一個 RFC 都有一個惟一的數字。好比，RFC 7230。他們在安全 Web 時間線上顯示爲藍色。

RFC 是不可變文檔。這意味着 RFC 的更改會產生一個全新的數字。爲了合併修復的錯誤（發現和報告的編輯或技術錯誤）或是簡單地重構規範來改進佈局，能夠進行更改。RFC 可能會棄用舊版本，或只是更新它們（實質性改變）。

全部的 IETF 文檔都是開源在 tools.ietf.org 上的。由於它提供了從 I-D 到 RFC 的文檔進度可視化，因此我的認爲 IETF Datatracker 對用戶很友好。

如下是顯示 RFC 1945 —— HTTP/1.0 開發的示例，它爲安全 Web 時間線提供了一個明確靈感來源。

IETF RFC 1945 Datatracker 視圖

有意思的是，在個人工做過程當中，我發現上述可視化是不正確的。因爲某種緣由，它丟失了 draft-ietf-http-v10-spec-05。因爲 I-D 生命週期只有 6 個月，因此在成爲 RFC 以前會存在分歧，而實際上草案 05 直到 1996 年 8 月，仍處於活躍狀態。

探索安全的 Web 時間線

稍微瞭解因特網標準文檔是如何實現後，咱們就能夠着手安全網絡時間線了。在本節中，有許多摘選圖顯示了時間軸的重要部分。每一個點對應着文檔或功能的可用日期。對於 IETF 文檔，爲了清晰可見，省略了草案編號。但若是你想查看全部細節，能夠查看完整的時間線。

HTTP 在 1991 年以 HTTP/0.9 協議開始，在 1994 年 I-D draft-fielding-http-spec-00 發佈。它很快就被 IETF 採用，致使 draft-ietf-http-v10-spec-00 的名稱被修改。在 RFC 1945 —— HTTP/1.0 於 1996 年發佈以前，I-D 已經已經了 6 個草案版本的修改。

甚至在 HTTP/1.0 尚未完成以前，HTTP/1.1 就已經開始了一個獨立的分支。I-D draft-ietf-http-v11-spec-00 於 1995 年 11 月發佈，1997 年正式以 RFC 2068 形式出版。敏銳的洞察力會讓你發現安全 Web 時間線並不能捕捉到事件順序，這是用於生成可視化工具的一個不幸的反作用。我會盡量的減小這樣的問題。

HTTP/1.1 修訂工做在 1997 年年中以 draft-ietf-http-v11-spec-rev-00 形式開始。1999 年出版的 RFC 2616 標誌着這一計劃的完成。直到 2007 年，IETF HTTP 世界纔得到平靜。咱們很快會再說起此事。

SSL 和 TLS 的歷史

如今咱們開始研究 SSL。咱們能夠看到 SSL 2.0 規範是在 1995 年先後發佈的，SSL 3.0 是在 1996 年 11 月發佈的。有趣的是，在 2011 年 8 月發佈的 SSL 3.0 RFC 6101 是里程碑版本，一般是爲了「記錄被考慮和丟棄的想法，或者是在決定記錄他們時已經具備歷史意義的協議」。參照 IETF。在這種狀況下，擁有描述 SSL 3.0 的 IETF 文檔是有利的，由於它能夠做爲其餘地方的規範引用。

咱們更感興趣的是 SSL 如何促進 TLS 發展的，TLS 的生命在 1996 年 11 月開始於 draft-ietf-tls-protocol-00。它經過了 6 個草案版本，發佈時爲 RFC 2246 —— TLS 1.0 起始於 1999。

在 1995 年和 1999 年，SSL 和 TLS 協議被用於保護因特網上的 HTTP 通訊。做爲一個事實上的標準，它並無太大的問題。直到 1998 年 1 月，HTTPS 的正式標準化進程才隨着 I-D draft-ietf-tls-https-00 的出版而開始。這項工做結束於 2000 年 5 月，發佈的 RFC 2616 —— HTTP over TLS。

伴隨着 TLS 1.1 和 1.2 的標準化，TLS 在 2000 至 2007 年得以繼續發展。距下一個 TLS 版本的開發時間還有 7 年時間，它在 2014 年 4 月的 draft-ietf-tls-tls13-00 中被經過，在歷經 28 份草案以後，RFC 8446 —— TLS 1.3 於 2018 年 8 月完成。

因特網標準化過程

在看了下時間線以後，我但願你能對 IETF 的工做方式有大概的瞭解。互聯網標準造成方式的概況是，研究人員或工程師和他們具體用例的實驗協議。他們在不一樣規模的公共或私有協議中進行試驗。這些數據有助於發現能夠優化的地方或問題。這項工做多是爲了解釋試驗，收集更普遍的投入，或幫組尋找其餘實驗者。其餘對早期工做的參與者可能會使其成爲事實上的標準；可能最後會有足夠的緣由使其成爲正式標準化的一種選擇。

對於正在考慮實施、部署或以某種範式使用協議的組織來講，協議的狀態多是一個重要的因素。一個正式的標準化過程能夠促使事實上的標準更具吸引力，由於標準化傾向於提供穩定性。管理和指導由 IETF 這類組織提供，它反映了更普遍的經驗。然而，須要強調的是，並不是全部的正式標準都是成功的。

建立最終標準的過程與標準自己同等重要。從具備更普遍知識、經驗和用例的人那裏獲取初步的想法和貢獻，能夠幫助產生對更普遍人羣有用的產物。但標準化的過程並不容易。存在陷阱和障礙，有時，須要花費很長的時間過程，才能排除不相關的內容。

每一個標準定義組織都存在本身的標準化過程，主要圍繞其對應領域和參與者。解釋 IETF 如何運轉的全部工做細節，遠遠超過了這個博客的涵蓋範圍。IETF 的「咱們的運行原理」是很好的起點，涵蓋了不少內容。是的，理解的最好途徑就是本身參與其中。就像加入電子郵件列表或添加相關 GitHub 倉庫的討論同樣容易。

Cloudflare 的運行代碼

Cloudflare 爲成爲新的、不斷髮展的協議的早期採用者而感到自豪。咱們很早就採用了新標準，好比 HTTP/2。咱們還測試了一些實驗性或還沒有最終肯定的特性，好比 TLS 1.3 和 SPDY。

在 IETF 標準化過程當中，將運行中的代碼部署到多個不一樣網站的真實網絡上，能夠幫助咱們理解協議在實踐中的工做效果。咱們將現有的專業知識與實現信息進行結合，來改進運行中的代碼，並在有意義的地方，對工做組的反饋問題或改進進行修正，來促使協議標準化。

測試新特性並非惟一的優先級。做爲改革者，須要知道何時推動進度，拋棄舊的創新。有時，這會涉及到面向安全的協議，好比 Cloudflare 由於 POODLE 的漏洞而默認禁用 SSLv3。在某些狀況下，協議會被更先進的所取代；Cloudflare 廢棄 SPDY，轉而支持 HTTP/2。

相關協議的介紹和廢棄在安全 Web 時間線上顯示爲橙色。垂直虛線有助於將 Cloudflare 事件與 IETF 相關文檔關聯。好比，Cloudflare 在 2016 年 9 月開始支持的 TLS 1.3，最後的文檔 RFC 8446，在近兩年後的 2018 年 8 月發佈。

重構 HTTPbis

HTTP/1.1 是很是成功的協議，時間線顯示 1999 年之後 IETF 並不活躍。然而，事實是，多年的積極使用，爲 RFC 2616 研究潛在問題提供了實戰經驗，但這也致使了一些交互操做的問題。此外，RFC（像 2817 和 2818）還對該協議進行了擴展。2007 年決定啓動一項改進 HTTP 協議規範的新活動 —— HTTPbis（"bis" 源自拉丁語，意爲「二」、「兩次」或「重複」），它還採用了新的工做組形式。最初的章程詳細描述了嘗試解決的問題。

簡而言之，HTTPbis 決定重構 RFC 2616。它將歸入勘誤修訂，合併在此期間發佈的其餘規範的一些內容。文件將被分爲幾個部分，這致使 2017 年 12 月發佈了 6 個 I-D：

draft-ietf-httpbis-p1-messaging
draft-ietf-httpbis-p2-semantics
draft-ietf-httpbis-p4-conditional
draft-ietf-httpbis-p5-range
draft-ietf-httpbis-p6-cache
draft-ietf-httpbis-p7-auth

圖表顯示了這項工做是如何在長達 7 年的草案過程當中取得進展的，在最終被標準化以前，已經發布了 27 份草案。2014 年 6 月，發佈了 RFC 723x 系列（x 範圍在 0-5）。HTTPbis 工做組的主席以 "RFC2616 is Dead" 來慶祝這一成果。若是它不夠清楚，這些新文檔就會棄用舊的 RFC 2616。

這和 HTTP/3 有什麼聯繫？

儘管 IETF 的 RFC 723x 系列的工做繁忙，可是技術的進步並未中止。人們繼續增強、擴展和測試因特網上的 HTTP。而 Google 已率先開始嘗試名爲 SPDY（發音同 Speedy）的技術。該協議宣稱能夠提升 Web 瀏覽性能，一個使用 HTTP 原則的用例。2009 年末，SPDY v1 發佈，2010 年 SPDY v2 緊隨其後。

我想避免深刻 SPDY 的技術細節。由於這又是另外一個話題。重要的是理解 SPDY 採用的是 HTTP 核心範例，經過對交換格式的修改來改進技術。咱們能夠看到 HTTP 清楚地劃分了語義和語法。語義描述了請求和響應的概念，包括：方法，狀態碼，頭字段（元數據）和主體部分（有效載荷）。語法描述如何將語義映射到 wire 字節上。

HTTP/0.九、1.0 和 1.1 有不少相同的語義。它們還以經過 TCP 鏈接發送字符串的形式共享語法。SPDY 採用 HTTP/1.1 語義，語法修改是，將字符串改成二進制。這是一個很是有趣的話題，但今天並不會深刻涉及這些問題。

Google 對 SPDY 實驗代表，改變 HTTP 語法是有但願的，維持現有 HTTP 語義是有意義的。好比，保留 URL 的使用格式 —— https://，能夠避免許多可能影響採用的問題。

看到一些積極的結果後，IETF 決定考慮 HTTP/2.0。2012 年 3 月 IETF 83 期間舉行的 HTTPbis 會議的 slides顯示了請求、目標和成功標準。它還明確指出 "HTTP/2.0 與 HTTP/1.x 連線格式不兼容"。

社區在此次會議期間被邀請分享提案。提交審議的 I-D 包括 draft-mbelshe-httpbis-spdy-00、draft-montenegro-httpbis-speed-mobility-00 和 draft-tarreau-httpbis-network-friendly-00。最終，SPDY 草案被經過，在 2012 年 11 月開始於 draft-ietf-httpbis-http2-00。在超過 2 年的時間裏完成了 18 次草案，RFC 7540 —— HTTP/2 於 2015 年發佈。在此規範期間，HTTP/2 的精確語法的差別致使 HTTP/2 和 SPDY 不兼容。

這幾年，IETF 的 HTTP 相關工做繁重，HTTP/1.1 的重構與 HTTP/2 的標準化齊頭並進。與 21 世紀初的平靜造成了鮮明對比。你能夠查看完整的時間表來查看這些繁重的工做。

儘管 HTTP/2 正處於標準化階段，但使用和實驗 SPDY 的好處不言而喻。Cloudflare 在 2012 年 8 月引入了對 SPDY 的支持，在 2018 年 2 月將其棄用，咱們的統計數據顯示只有不到 4% 的 Web 客戶仍然會考慮繼續使用 SPDY。與此同時，咱們在 2015 年 12 月引入對 HTTP/2的支持，在 RFC 發佈不久後，咱們的分析代表有意義的 Web 客戶端能夠對其加以利用。

使用 SPDY 和 HTTP/2 協議的 Web 客戶端支持首選使用 TLS 的安全選項。2014 年 9 月引入 Universal SSL 有助於確保全部註冊 Cloudflare 的網站都可以利用這些新協議。

gQUIC

2012 - 2015 之間，Google 繼續進行試驗，他們發佈了 SPDY v3 和 v3.1。他們還開始研究 gQUIC(當時的發音相似於 quick），在 2012 年年初，發佈了初始的公共規範。

gQUIC 的早期版本使用 SPDY v3 形式的 HTTP 語法。這個選擇是有意義的，由於 HTTP/2 還沒有完成。SPDY 二進制語法被打包到能夠用 UDP 數據報發送數據的 QUIC 包中。這與 HTTP 傳統上依賴的 TCP 傳輸不一樣。當全部的東西堆疊在一塊兒時，就會像這樣：

SPDY 式 gQUIC 分層模型（蛋糕模型）

gQUIC 使用巧妙的設計來實現性能優化。其中一個是破壞應用程序與傳輸層之間清晰的分層。這也意味着 gQUIC 只支持 HTTP。所以，gQUIC 最後被稱爲 "QUIC"。它是 HTTP 下一個候選版本的同義詞。QUIC 從過去的幾年到如今，一直在持續更新，但咱們並不會涉及過多的討論，QUIC 也被人們理解爲是初始 HTTP 的變體。不幸的是，這正是咱們在討論協議時，常常出現混亂的緣由。

gQUIC 繼續在實驗中摸索，最後選擇了更接近 HTTP/2 的語法。也正由於如此，它才被稱爲 "HTTP/2 over QUIC"。但由於技術上的限制，全部存在一些很是微妙的差異。一個示例是，HTTP 頭是如何序列化並交換的。這是一個細微的差異，但實際上，這意味着 HTTP/2 式 gQUIC 與 IETF's HTTP/2 並不兼容。

最後，一樣重要的是，咱們老是須要考慮互聯網協議的安全方面。gQUIC 選擇不使用 TLS 來提供安全性。轉而使用 Google 開發的另外一種稱爲 QUIC Crypto 的方法。其中一個有趣的方面是有一種加速安全握手的新方法。之前與服務器創建了安全會話的客戶端能夠重用信息來進行「零延遲往返握手」或 0-RTT 握手。0-RTT 後來被歸入 TLS 1.3。

如今能夠告訴你什麼是 HTTP/3 了麼？

固然。

到目前爲止，你應該已經瞭解了標準化的工做原理，gQUIC 並不是不同凡響。或許你也對 Google 用 I-D 格式編寫的規範感興趣。在2015 年 6 月的 draft-tsvwg-quic-protocol-00 中，寫有 "QUIC：基於 UDP 的安全可靠的 HTTP/2 傳輸" 已經提交。請記住我以前提過的，幾乎都是 HTTP/2 的語法。

Google 宣佈將在布拉格舉行一次 Bar BoF IETF 93 會議。若有疑問，請參閱 RFC 6771。提示：BoF 是物以類聚（Birds of a Feather）的縮寫。

總之，與 IETF 的合做結果是 QUIC 在傳輸層提供了許多優點，並且它應該與 HTTP 分離。應該從新引入層與層之間清楚的隔離。此外，還有返回基於 TLS 握手的優先級（它自 TLS 1.3 起就在運行，因此並非太槽糕，並且它結合了 0-RTT 握手）。

大約是一年後，在 2016 年，一組新的 I-D 集合被提交：

這裏是關於 HTTP 和 QUIC 的另外一個困惑的來源。draft-shade-quic-http2-mapping-00 題爲 "HTTP/2 使用 QUIC 傳輸協議的語義"，對於本身的描述是 "HTTP/2 式 QUIC 的另外一種語義映射"。但這個解釋並不正確。HTTP/2 在維護語義的同時，改變了語法。並且，我很早以前就說過了，"HTTP/2 式 gQUIC" 從未對語法進行確切的描述，記住這個概念。

這個 QUIC 的 IETF 版本即將成爲新的傳輸層協議。由於任務艱鉅，因此 IETF 會在首次確認以前，評估測評人員對其的實際興趣程度。所以，2016 年在柏林舉行 IETF 96 會議期間，舉行了一次正式的 Birds of a Feather 會議。我很榮幸地參加了此次會議，幻燈片並未給出公正的評價。就像 Adam Roach 的圖片所示，有數百人蔘加了此次會議。會議結束時，達成了一致的共識：QUIC 將被 IETF 採用並標準化。

將 HTTP 映射到 QUIC 的第一個 IETF QUIC I-D —— draft-ietf-quic-http-00，採用了 Ronseal 方法來簡化命名 —— "HTTP over QUIC"。不幸的是，它並無達到預期效果，整個內容中都殘留有 HTTP/2 術語的實例。Mike Bishop —— I-D 的新編輯，發現並修復了 HTTP/2 的錯誤名稱。在 01 草案中，將描述修改成 "a mapping of HTTP semantics over QUIC"。

隨着時間和版本的推動，"HTTP/2" 的使用逐漸減小，實例部分僅僅是對 RFC 7540 部分的引用。從 2018 年 10 月開始向前回退兩年的時間開始計算，I-D 現在已是第 16 版本。雖然 HTTP over QUIC 與 HTTP/2 有類似內容，但始終是獨立的（非向後兼容的 HTTP 語法）。然而，對那些不密切關注 IETF 發展的人來講（人數衆多），他們並不能從名稱中發現一些細微的差別。標準化的重點之一是幫助通訊和互操做性。但像命名這樣的簡單事件，纔是致使社區相對混亂的主要緣由。

回顧 2012 年的內容，"HTTP/2.0 意味着 wire 格式與 HTTP/1.x 格式不兼容"。IETF 遵循現有線索。IETF 103 是通過深思熟慮才最終達成一致的，即："HTTP over QUIC" 命名爲 HTTP/3。互聯網正在促使世界變得更加美好，咱們能夠繼續進行更加劇要的的探討。

但 RFC 7230 和 7231 並不一樣意你對語義和語法的定義！

文檔的標題有時候會給人形成困擾。現在描述 HTTP 文檔語法和語義的是：

RFC 7230 —— 超文本傳輸協議（HTTP/1.1)：消息語法和路由
RFC 7231 —— 超文本傳輸協議（HTTP/1.1）：語法和上下文

對這些名稱的過分解讀可能會讓你認爲 HTTP 版本的核心語義是特定的。好比，HTTP/1.1。但這是 HTTP 家族樹的反作用。好消息是 HTTPbis 工做組正在嘗試解決這個問題。一些勇敢的成員正在進行文檔的另外一輪修訂，就像 Roy Fielding 說的 "one more time!"。這項工做目前正做爲 HTTP 核心任務進行（你可能也聽過 moniker HTTPtre 或 HTTPter；命名工做很艱難）。這將把六個草案壓縮成三個：

HTTP 語義（draft-ietf-httpbis-semantics）
HTTP 緩存（draft-ietf-httpbis-caching）
HTTP/1.1 消息語法和路由（draft-ietf-httpbis-messaging）

在這種新結構之下，對於常見的 HTTP 定義來講，HTTP/2 和 HTTP/3 的語法定義會更清晰。這並不意味着它擁有超出語法之外的特性，但這在將來是否有變數仍可商榷。

總結

本文對過去三十年 IETF 如何標準化 HTTP 作了大概的簡介。在不涉及技術細節的狀況下，我儘可能解釋 HTTP/3 的歷史發展進程。若是你跳過了中間的 good bits 部分卻又想歸納地瞭解它，概況來講就是：HTTP/3 只是一種適用於 IETF QUIC 的新 HTTP 語法 —— 一種基於 UDP 多路複用的安全傳輸層。仍有許多有趣的領域須要深刻探索，但須要等下次有機會再作介紹。

本文的敘述過程當中，咱們探究了 HTTP 和 TLS 開發中的重要章節，但它們都是單獨闡述的。在文章即將結束時，咱們會將它們所有總結到下面介紹的完整安全 Web 時間線。你能夠用它來調查詳細的歷史記錄。對於 super sleuths，請務必查看包括草案編號的完整版本。

本文部份內容語句的順序對部分讀者可能會引發不適，或者因爲部分譯文致使的邏輯不符，能夠查看這個連接進行翻譯過程查看，如若還不行，可閱讀原版英文，或是經過下述方法進行反饋，也可在本文下方進行評論和反饋，感謝你的關注和支持，謝謝。同時，還要感謝本文的第三個校對者：Fengziyin1234 的努力付出，讓本文的質量水平進行了提高。