[譯] HTTP/3: 起源

原文地址：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 傳輸協議。

如果你不熟悉 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 的多路複用和安全傳輸。

在本文中，我們將討論 HTTP/3 以前一些名稱背後的歷史故事，以及最近更名的誘因。我們將回到 HTTP 的早期時代，探尋它一路成長中的美好回憶。如果你已經迫不及待了，可以直接檢視文末，或開啟這個詳細的 SVG 版本。

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

設定背景

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

在 90 年代初期，Web 需求就已經發生了改變。我們已經有了新的 HTTP 版本，以傳輸層安全（TLS）的形式加強使用者安全性。在本文中，我們會涉及 TLS。如果你想更詳細地瞭解這個領域，可以參閱我們其他的高質量博文。

為了幫助我們瞭解 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.9、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 的努力付出，讓本文的質量水平進行了提升。

如果發現譯文存在錯誤或其他需要改進的地方，歡迎到掘金翻譯計劃對譯文進行修改並 PR，也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。

掘金翻譯計劃是一個翻譯優質網際網路技術文章的社群，文章來源為掘金上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注掘金翻譯計劃、官方微博、知乎專欄。