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