引言
HTTP/3是QUIC傳輸層的HTTP應用映射。這個名稱于2018年10月底在draft-ietf-quic-http-17中正式提出，并在同年11月，在曼谷舉行的IETF 103會議中達成了一定的共識。HTTP/3之前被叫做HTTP over QUIC，而其之前又被稱為QoS/2，而不是QUIC。在此之前，我們有基于gQUIC的HTTP/2，更早之前，我們有基于gQUIC的SPDY。 然而，其實HTTP/3只是一種適用于IETF QUIC的新的HTTP語法，基于UDP的多路復用和安全傳輸。
在這篇文章中，我們將探討一些HTTP/3之前名稱背后的歷史，并介紹最近更改名稱的動機。我們將從HTTP早期階段開始講，會提及一些重要的工作。
HTTP/3 分層示意圖
入門知識
在我們討論HTTP之前，值得注意的是，有兩個協議都叫做QUIC。正如我們之前解釋的那樣，gQUIC通常是指Google QUIC（原始協議），而QUIC通常用于表示與gQUIC不同的IETF版本。
從90年代初期開始，網絡的需求就發生了變化。我們有了新版本的HTTP，并以安全傳輸層協議（TLS）的形式增加了用戶安全性。為了更好地闡述HTTP和TLS的歷史，我開始整理協議規范和日期的細節。此信息通常以文本形式呈現，例如按日期排序的說明文檔標題列表。但是，存在分支標準，每個標準都在時間上重疊，簡單的列表無法表達真實的復雜的關系。在HTTP中，已經進行了一些并行工作，如重構核心協議定義以便于使用，擴展了協議以用于新的用途，重新定義協議如何通過Internet交換數據以提高性能等。當你試圖在近30年的互聯網歷史中跨越不同分支接觸這些工作時，你需要一個可視化的列表。所以我制作了一個Cloudflare Secure Web 時間線. （注意：它其實是一個“進化樹”，但“時間線”更通俗易懂）。
我在創建時間線時選擇了一些IETF中成功的分支。一些未顯示的內容包括W3 Consortium HTTP-NG工作組的工作，以及他們的作者解釋如何發音的一些奇特的想法：如HMURR（發音為'hammer'）、WAKA（發音為“wah-kah”）等。
在接下來的幾節中，我將按照這個時間表來解釋HTTP發展歷史中的關鍵節點。理解為什么標準化是有益的，以及IETF是如何做的，可以幫你更好地讀懂這篇文章的內容。因此，在談時間線之前，我們將簡要介紹一下該內容。如果您已熟悉IETF，請跳過下一部分。
互聯網標準的類型
通常，標準定義了共同的參考術語，范圍，約束，適用性和一些其他考慮因素。標準存在許多形式，可以是非正式（事實上）的或是正式的，正式標準由標準定義組織（例如IETF，ISO或MPEG）同意/發布。標準用于許多領域，甚至有正式的英國制茶標準——BS 6008。
早期的Web使用在IETF外部發布的HTTP和SSL協議定義，這些定義在Secure Web時間線上標記為紅線。客戶端和服務器對這些協議的采用使它們成為“事實上”的標準。
而在某一時刻，大家決定將這些協議正式化（一些激勵原因將在后面的部分中描述）。互聯網標準通常在IETF中定義，它遵循“相信共識和運行的代碼”的非正式原則。這是基于在Internet上開發和部署內容的經驗。這與嘗試在真空中開發完美方案的“潔凈室”方法形成對比。
IETF Internet標準通常稱為RFC，這比較難以解釋，因此我建議您閱讀由QUIC工作組聯合主席Mark Nottingham撰寫的博客“如何閱讀RFC”（"How to Read an RFC", https://www.ietf.org/blog/how-read-rfc/）。一個工作組（Wrok Group, WG），只是一個郵件列表。
每年IETF舉行三次會議，為所有工作組提供時間和設施，如果他們愿意，可以親自見面。這幾周的議程可能變得非常擁擠，只有有限的時間可以深入討論高度技術性的領域。為了解決這個問題，一些工作組選擇在IETF一般會議之間的幾個月內舉行臨時會議。這有助于保持規范開發的勢頭。自2017年以來，QUIC WG已舉行了幾次臨時會議，會議頁面上提供了完整的清單。
這些IETF會議還為其他與IETF相關的人員會議提供了機會，例如互聯網架構委員會或互聯網研究工作組。近年來，IETF Hackathon在IETF會議之前的周末舉行。這為社區提供了開發運行代碼的機會，更重要的是，在與他人共用的同一個房間內進行互操作性測試。這有助于查找可在接下來的幾天中討論的規范中的問題。
在本文中，需要理解的是RFC不會忽然出現。相反，它們會經歷一個過程，通常從提交供考慮采用的IETF Internet草稿（I-D）格式開始。在已經發布規范的情況下，I-D的準備可能只是一個簡單的重新規范化練習。 I-D從發布之日起有6個月的有效期。要使它們保持活動狀態，需要發布新版本。在實踐中，讓I-D過期并沒有太多后果，而且經常發生。這些文件繼續在IETF文檔的網站上托管，供任何想要閱讀它們的人使用。
I-D在Secure Web時間線上表示為紫色線條。每個都有一個唯一的名稱，其形式為draft- {作者}-{工作組}-{議題}-{版本}。工作組字段是可選的，它可能會預測IETF WG將在該文件上工作，有時這會發生變化。如果IETF采用I-D，或者I-D直接在IETF內啟動，則名稱為draft-ietf- {工作組}-{議題}-{版本}。I-D可以在分叉，合并或死亡。版本從00開始，每次發布新草稿時增加1。例如，I-D的第4稿將具有版本03。任何時候I-D更改名稱，其版本將重置為00。
值得注意的是，任何人都可以向IETF提交I-D。你不應該把它們當作標準。但是，如果I-D的IETF標準化過程確實達成共識，并且最終文檔通過審核，我們最終會得到一個RFC。在此階段，名稱再次發生變化。每個RFC都會獲得一個唯一的編號（例如RFC 7230）。這些在Secure Web時間線上以藍線表示。
RFC是不可變的文檔。這意味著對RFC的更改需要一個全新的數字。可能會進行更改以便合并勘誤表（已發現和報告的編輯或技術錯誤）或僅重構規范以改進布局。 RFC可能會淘汰舊版本（完全替換），或者只是更新它們（實質性更改）。
所有IETF文檔均可在http://tools.ietf.org上公開獲取。我個人認為IETF Datatracker（https://datatracker.ietf.org/）更加用戶友好，因為它提供了從I-D到RFC的文檔進度的可視化。下圖是一個顯示RFC 1945-HTTP/1.0開發的示例，這是Secure Web時間線的靈感來源。
IETF Datatracker中RFC 1945的發布過程
有趣的是，在我的工作過程中，我發現上面的可視化是不正確的。 由于某種原因，缺少draft-ietf-http-v10-spec-05。由于I-D壽命為6個月，因此與RFC之間存在區別，而實際上草案05在1996年8月之前仍然有效。
探索Secure Web時間線
通過對互聯網標準文檔如何實現的認識，我們可以開始走向Secure Web時間線。 在本節中，有一些摘錄圖表顯示了時間線的重要部分。 每個點代表文檔或功能可用的日期。 對于IETF文檔，為清楚起見，這里省略了草稿編號。
HTTP在1991年開始作為所謂的HTTP / 0.9協議開始，并且在1994年發布了I-D draft-fielding-http-spec-00。它很快被IETF采用，導致名稱更改為draft-ietf-http-v10-spec-00。I-D在1996年作為RFC 1945-HTTP/1.0發布之前經歷了6個草案版本。
但是，即使在HTTP /1.0工作完成之前，也會在HTTP/1.1上啟動單獨的活動。 ID draft-ietf-http-v11-spec-00于1995年11月發布，并于1997年正式發布為RFC 2068。敏銳的讀者會發現Secure Web時間線并未捕獲該事件序列，這是由于用于生成可視化的工具存在一些問題。我們試圖盡可能減少這些問題。
1997年中期以draft-ietf-http-v11-spec-rev-00的形式開始了HTTP/1.1修訂工作，并這1999年隨著RFC 2616的發布完成。在IETF HTTP時間線中，直到2007年之前并沒有更多值得關注的大事發生。我們很快就會回到這里。
SSL和TLS的歷史
將視線移到SSL。我們看到SSL 2.0規范是在1995年左右發布的，SSL 3.0于1996年11月發布。有趣的是，SSL 3.0由RFC 6101描述，它于2011年8月發布。它位于歷史類別中，IETF對該類別的解釋是“通常用于記錄被考慮和丟棄的想法，或者在決定記錄它們時已經具有歷史意義的協議”。在這種情況下，擁有一個描述SSL 3.0的IETF文檔是有利的，因為它可以在其他地方用作規范參考。
我們更感興趣的是SSL如何激發了TLS的發展。TLS從1996年11月的draft-ietf-tls-protocol-00開，經歷了6個草案版本并在1999年作為RFC 2246-TLS 1.0發布。
在1995年和1999年之間，SSL和TLS協議用于保護Internet上的HTTP通信。這作為非正式的標準工作得很好。直到1998年1月，HTTPS的正式標準化過程才開始發布I-D draft-ietf-tls-https-00。該工作于2000年5月RFC 2616-HTTP over TLS的發布結束。
TLS在2000年至2007年間繼續發展，標準化為TLS 1.1和1.2，距TLS的下一版本開始工作之前有7年的時間。下一個版本在2014年4月被采納為draft-ietf-tls-tls13-00，并且在28次草案之后，在2018年8月完成了RFC 8446-TLS 1.3。
互聯網標準化進程
在仔細觀察時間表后，我希望您能夠了解IETF是如何運行的。互聯網標準形成方式的一個概括是研究人員或工程師設計適合其特定用例的實驗協議。他們在不同規模的水平上試驗公共或私人協議。數據有助于識別改進或問題。可以發布這項工作來解釋實驗，收集更廣泛的意見或幫助找到其他實施者。其他人接受這項早期工作可能會成為“事實上”的標準;最終可能有足夠的動力使標準正式化。
對于可能正在考慮實施，部署或以某種方式使用協議的組織而言，協議的狀態可能是一個重要的考慮因素。正式的標準化過程可以使“事實上”的標準更具吸引力，因為它傾向于提供穩定性。管理和指導由IETF等組織提供，反映了更廣泛的經驗。但是，值得強調的是，并非所有正式化標準都能成功。
創建最終標準的過程幾乎與標準本身一樣重要。最初的想法和邀請具有更廣泛知識，經驗和用例的人的貢獻可以幫助產生對更廣泛的人群更有用的東西。但是，標準化過程并不總是那么容易。存在陷阱和障礙。有時，該過程太長以至于產出的標準已經無關緊要了。
每個標準定義組織都傾向于擁有自己的流程，圍繞其領域和參與者。解釋有關IETF如何工作的所有細節遠遠超出了本文的范圍。IETF的“我們如何工作”頁面（https://www.ietf.org/how/）是一個很好的起點，涵蓋了許多方面。像往常一樣，形成理解的最佳方法是親自參與。這可以像加入電子郵件列表或參加相關GitHub repository上的討論一樣簡單。
Cloudflare的運行代碼
Cloudflare很自豪能夠成為新的和不斷發展的協議的早期采用者。我們有早期采用新標準的長期記錄，例如HTTP/2。我們還測試了一些實驗性的功能，如TLS 1.3和SPDY。
關于IETF標準化過程，在各種網站上的真實網絡上部署此運行代碼有助于我們了解協議在實踐中的運作情況。我們將現有的專業知識與實驗信息相結合，以幫助改進運行代碼，并在有意義的情況下，反饋問題或改進標準化協議的工作組。
測試新事物不是唯一的優先事項。作為一個創新者的一部分是知道什么時候該向前邁進，并放棄部分舊的創新。有時這與面向安全的協議有關，例如，由于POODLE漏洞，Cloudflare默認禁用SSLv3。在另一些情況下，舊的協議會被技術更先進的新協議取代，例如Cloudflare已經取消使用SPDY，因為支持的HTTP/2中包含了SPDY的思想。
相關協議的引入和棄用在Secure 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。它將包含勘誤修復，并引入在此期間發布的其他規范的一些方面。最后決定將文檔分成幾部分，最終在2007年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）。如果不是特別聲明，這些新文件將廢棄舊的RFC 2616。
這些與HTTP/3有什么關系？
雖然IETF正忙著研究RFC 723x系列，但世界并未停止。人們繼續在互聯網上增強，擴展和試驗HTTP。其中包括谷歌，谷歌已經開始嘗試一種名為SPDY（發音為speedy）的東西。該協議被吹捧為提高Web瀏覽的性能，這是HTTP的一個主要用例。在2009年底，SPDY v1被宣布，2010年SPDY v2很快被推出。
我們想避免進入SPDY的技術細節，這是另一個話題。重要的是，要了解SPDY采用HTTP的核心范例并稍微修改交換格式以獲得改進。事后看來，我們可以看到HTTP明確劃分了語義和語法。語義描述了請求和響應交換的概念，包括：方法，狀態代碼，頭字段（元數據）和主體（有效負載）。語法描述了如何將語義映射到線路上的字節。
HTTP/0.9, 1.0和1.1共享許多語義。它們還以通過TCP連接發送的字符串形式共享語法。 SPDY采用HTTP/1.1語義并將語法從字符串更改為二進制。這是一個非常有趣的話題，但今天我們將不再深入了解那個兔子洞。
Google對SPDY的實驗表明，在改變HTTP語法方面存在前景，并且保留現有HTTP語義的價值。例如，保持使用https://的URL格式可以避免許多可能影響采用的問題。
在看到一些積極的結果后，IETF決定是時候考慮HTTP/2.0的樣子了。2012年3月IETF 83期間舉行的HTTPbis會議的幻燈片顯示了其要求、目標和衡量標準被提出。它還明確指出“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。在短短兩年多的時間內完成了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發布后不久。
SPDY和HTTP/2協議的Web客戶端支持首選使用TLS的安全選項。 2014年9月引入通用SSL有助于確保所有注冊到Cloudflare的網站都能夠在我們引入這些新協議時利用這些新協議。
gQUIC
谷歌在2012年至2015年期間繼續進行實驗，他們發布了SPDY v3和v3.1。 他們也開始研究gQUIC（當時發音同quick），最初的公開規范于2012年初推出。
gQUIC的早期版本使用了SPDY v3形式的HTTP語法。這樣選擇是因為當時HTTP/2還沒有完成標準化。SPDY二進制語法被打包成可以在UDP數據報中發送的QUIC數據包。 這與HTTP傳統上依賴的TCP傳輸有所不同。這看起來像：
基于SPDY的gQUIC分層示意圖
gQUIC使用巧妙的技巧來實現性能提升。其中之一是打破應用程序和傳輸之間的明確分層。這在實踐中意味著gQUIC只支持HTTP。因此，當時被稱為“QUIC”的gQUIC與作為HTTP的下一個候選版本同義。盡管QUIC在過去幾年中不斷發生變化，直到今天，人們還是將QUIC這個術語理解為最初的僅限HTTP的變體。不幸的是，這在討論協議時經常引起混淆。
gQUIC繼續進行實驗并最終切換到更接近HTTP/2的語法，所以，大多數人簡稱為“HTTP/2 over QUIC”。但是，由于技術限制，存在一些非常微妙的差異。例如如何序列化和交換HTTP頭。這是一個微小的差異，但實際上意味著gQUIC上的HTTP/2與IETF的HTTP/2不兼容。
最后，我們始終需要考慮Internet協議的安全性方面。 gQUIC選擇不使用TLS來提供安全性。相反，Google開發了一種名為QUIC Crypto的不同方法。其中一個有趣的方面是加速安全握手的新方法。先前與服務器建立安全會話的客戶端可以重用信息來執行“零往返時間”（0-RTT握手）。0-RTT后來被納入TLS 1.3。
所以現在可以告訴我到底什么是HTTP/3了么？
差不多了。
到目前為止，您應該熟悉標準化的工作原理和 gQUIC。人們又足夠的興趣將Google的規范寫成I-D。2015年6月，提交了題為“QUIC: A UDP-based Secure and Reliable Transport for HTTP/2”的draft-tsvwg-quic-protocol-00。如剛才提到的，其語法幾乎與HTTP/2一致。隨后谷歌宣布在布拉格的IETF 93舉行Bar BoF（Birds of a Feather）。
簡而言之，與IETF合作的結果是，QUIC似乎在傳輸層提供了許多優勢，并且它應該與HTTP分離。應重新引入層之間的明確分離。此外，有人傾向于返回基于TLS的握手（由于TLS 1.3在此階段正在進行，并且正在整合0-RTT握手，因此并沒有那么糟糕）。大約一年后，在2016年，提交了一套新的I-D：
draft-hamilton-quic-transport-protocol-00
draft-thomson-quic-tls-00
draft-iyengar-quic-loss-recovery-00
draft-shade-quic-http2-mapping-00
這里是關于HTTP和QUIC的另一個混亂源頭開始的地方。draft-shade-quic-http2-mapping-00的標題是“使用QUIC傳輸協議的HTTP/2語義”，它將自己描述為“QUIC上HTTP/2語義的映射”。然而，這里用詞不當。HTTP/2是在改變語法的同時保持語義。此外，如我之前提到，“HTTP/2 ” 也從來不是對語法的準確描述。請保持這個想法。
這個IETF版本的QUIC將是一個全新的傳輸協議。這是一項艱巨的任務，在投入這類任務之前，IETF喜歡從其成員那里評估實際的利益。為此，在2016年柏林舉行的IETF 96會議上，舉行了一次正式的BoF會議。我很幸運能親自參加會議。數百人參加了會議，在會議結束時達成了共識， QUIC將在IETF中采用并標準化。
用于將HTTP映射到QUIC的第一個IETF QUIC I-D，draft-ietf-quic-http-00，采用Ronseal方法并將其名稱簡化為“HTTP over QUIC”。不幸的是，它沒有完全完成工作，并且其中存在許多HTTP/2術語的實例。I-D新編輯Mike Bishop發現了這一點并開始修復HTTP/2的誤稱。在01草案中，描述改為“基于QUIC的HTTP語義映射”。
隨著時間和版本的推移，術語“http/2”的使用逐漸減少，這些實例變成了對RFC7540部分的引用。向前推進兩年到2018年10月，I-D現在的版本是16。而HTTP在QUIC上與HTTP/2相似，它最終是一個獨立的，非向后兼容的HTTP語法。然而，對于那些不密切跟蹤IETF發展的人（大部分人），文檔名稱并沒有捕捉到這種差異。標準化的一個要點是幫助溝通和互操作。然而，命名等簡單的事情是導致社區混亂的主要原因。
回想一下2012年所說的“HTTP/2.0與HTTP/1.x的格式不兼容”。IETF遵循現有的提示，在IETF 103之前和期間經過深思熟慮后，達成了共識，將“HTTP over QUIC”重命名為HTTP/3。現在，我們可以繼續進行更重要的辯論。
但RFC 7230和7231對語義和語法的定義與您的理解不同！
有時文檔標題可能會令人困惑。 描述語法和語義的當前HTTP文檔是：
RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
我們可能會對這些名稱進行過多的解讀，并認為基本的HTTP語義是特定于HTTP版本的，即HTTP/1.1。但是，這是HTTP系列樹的意外誤解。好消息是HTTPbis工作組正試圖解決這個問題。一些成員正在進行另一輪文件修訂。這項工作現在正在進行中，并被稱為HTTP核心活動。這將把六個草案縮減為三個：
HTTP Semantics (draft-ietf-httpbis-semantics)
HTTP Caching (draft-ietf-httpbis-caching)
HTTP/1.1 Message Syntax and Routing (draft-ietf-httpbis-messaging)
在這種新結構下，HTTP/2和HTTP/3顯然是通用HTTP語義的語法定義。但這并不意味著它們除了語法之外沒有自己的特性，但這應該有助于今后的討論。
總結
本文對過去三十年來IETF中HTTP的標準化過程進行了簡單的介紹。在不涉及很多技術細節的情況下，我試圖解釋我們今天是如何使用HTTP/3的。如果您跳過中間的部分，并在這里尋找一句話總結，那么它就是：HTTP/3只是一種新的HTTP語法，它用于IETF QUIC，其是一種基于UDP的多路復用和安全傳輸協議。
本文中，我們探討了HTTP和TLS開發中的重要節點，但這些節點是獨立的。 我們通過將它們全部整合到下面提供的完整Secure Web時間線中來結束本文。您可以使用它來自行調查詳細的歷史記錄。
微信掃一掃
