2022年HTTP協(xié)議發(fā)展?fàn)顩r盤點(diǎn)

HTTP已經(jīng)有30多年的歷史了，但它仍然是Web的基礎(chǔ)，也是互聯(lián)網(wǎng)上最流行的協(xié)議之一。它不僅用于瀏覽、看視頻和聽音樂，還用于應(yīng)用程序和機(jī)器對機(jī)器通信，甚至還作為構(gòu)建其他協(xié)議的基礎(chǔ)，形成了經(jīng)典互聯(lián)網(wǎng)沙漏圖中的“第二腰”。

為什么HTTP如此成功？一個(gè)答案是，對于大多數(shù)需要應(yīng)用程序協(xié)議的應(yīng)用程序來說，它擊中了一個(gè)“甜蜜點(diǎn)”?！笆褂肏TTP構(gòu)建協(xié)議”（由HTTP工作組于2022年作為一項(xiàng)最佳當(dāng)前實(shí)踐RFC發(fā)布）一文認(rèn)為，HTTP的成功源于以下因素：

-實(shí)施者、規(guī)范編制者、管理員、開發(fā)人員和用戶的熟悉程度；

-各種客戶端、服務(wù)器和代理實(shí)施的可用性；

-易用性；

-Web瀏覽器的可用性；

-重用現(xiàn)有機(jī)制，例如身份認(rèn)證和加密；

-目標(biāo)部署中存在HTTP服務(wù)器和客戶端；以及

-穿越防火墻的能力。

另一個(gè)重要因素是使用、實(shí)施和標(biāo)準(zhǔn)化HTTP的社區(qū)。我們共同努力，積極維護(hù)和開發(fā)協(xié)議，以確保其可互操作，并滿足當(dāng)今的需求。如果HTTP停滯不前，另一種協(xié)議將（理所當(dāng)然地）取代它，那么我們將失去社區(qū)的所有投資、共享理解和互操作性。

為此，Cloudflare和其他很多公司及組織派工程師參與IETF，這是大多數(shù)討論和標(biāo)準(zhǔn)化大部分互聯(lián)網(wǎng)協(xié)議的方式。我們還參加和贊助社區(qū)活動(dòng)，例如HTTP Workshop，討論人們有什么問題，他們需要什么，并了解哪些更改可能有助于他們。

那么，在2022年進(jìn)行所有這些工作組會議、規(guī)范文件和附帶活動(dòng)中發(fā)生了什么事情呢？Web協(xié)議的實(shí)施者和部署者在做什么？接下來會發(fā)生什么呢？

新規(guī)范：HTTP/3

在規(guī)范方面，2022年最重大的事件就是HTTP/3的發(fā)布，因?yàn)樗ㄟ^更有效地使用網(wǎng)絡(luò)來釋放Web性能，在滿足現(xiàn)代應(yīng)用程序和網(wǎng)站的要求方面邁出了巨大的一步。

在20世紀(jì)90年代，HTTP/0.9和HTTP/1.0對每個(gè)請求都使用一個(gè)新的TCP連接，這是對網(wǎng)絡(luò)極其低效的利用。HTTP/1.1引入了持久連接（通過`Connection:Keep-Alive`標(biāo)頭被向后移植到HTTP/1.0）。這個(gè)改進(jìn)幫助服務(wù)器和網(wǎng)絡(luò)應(yīng)對了爆炸式的Web流行，但即使是在那個(gè)時(shí)候，社區(qū)也知道它有重大局限性，特別是隊(duì)頭阻塞（某個(gè)連接上的一個(gè)未完成請求會阻止其他請求完成）。

這在90年代和21世紀(jì)初還不太重要，但今天的Web頁面和應(yīng)用對網(wǎng)絡(luò)的要求使得這些限制對性能至關(guān)重要。頁面通常有數(shù)百個(gè)資源爭奪網(wǎng)絡(luò)資源，而HTTP/1.1無法勝任。經(jīng)過最初的一些錯(cuò)誤，社區(qū)終于在2015年通過HTTP/2解決了這些問題。

然而，消除HTTP中的隊(duì)頭阻塞暴露了更低一層（即TCP）中的相同問題。因?yàn)門CP是一種有序的、可靠的交付協(xié)議，數(shù)據(jù)流中一個(gè)數(shù)據(jù)包的丟失會阻止對后續(xù)數(shù)據(jù)包的訪問，即使它們位于操作系統(tǒng)的緩沖區(qū)中。對于HTTP/2部署而言，這是一個(gè)真正的問題，尤其是在非最優(yōu)網(wǎng)絡(luò)上。

當(dāng)然，答案就是取代TCP——互聯(lián)網(wǎng)的大部分都是基于這個(gè)古老的傳輸協(xié)議。經(jīng)過QUIC工作組的大量討論和多個(gè)草案，QUIC第一版于2021年發(fā)布，作為上述替代。

HTTP/3是使用QUIC的HTTP版本。雖然工作組實(shí)際上早在2021年就與QUIC一起完成了這個(gè)版本，但其發(fā)布被推遲到2022年，以便與其他文件的發(fā)布同步（見下文）。2022年也是HTTP/3部署具有里程碑意義的一年；Cloudflare看到對新協(xié)議采用和信心不斷增加。

雖然HTTP/2和HTTP/3之間只有短短幾年的間隔，但社區(qū)對開發(fā)HTTP/4的興趣并不大。QUIC和HTTP/3都是新事物，人們?nèi)匀辉趯W(xué)習(xí)如何最好地實(shí)施協(xié)議、運(yùn)行協(xié)議，并使用它們構(gòu)建網(wǎng)站和應(yīng)用。雖然我們不能排除迫使將來推出新版本的限制，但I(xiàn)ETF基于有關(guān)現(xiàn)代網(wǎng)絡(luò)的廣泛行業(yè)經(jīng)驗(yàn)構(gòu)建了這些協(xié)議，并具有顯著的可擴(kuò)展性，可輕松實(shí)現(xiàn)任何必要的更改。

新規(guī)范：HTTP“核心”

2022年HTTP規(guī)范的另一個(gè)重大事件是其“核心”文檔的發(fā)布——這些文檔是HTTP規(guī)范的核心。核心文檔包括：HTTP語義——方法、標(biāo)頭、狀態(tài)碼和消息格式；HTTP緩存——HTTP緩存如何工作；HTTP/1.1——將語義映射到網(wǎng)絡(luò)上，使用人人都知道和喜愛的格式。

此外，HTTP/2重新發(fā)布，以正確地集成以上語義文檔，并修復(fù)一些突出的問題。

這是這些文檔一長串修訂中的最新一輪——過去有RFC 723x系列，（可能最眾所周知的）RFC 2616，RFC 2068，以及最早的RFC 1945。每個(gè)修訂的目標(biāo)都是提高可讀性、修復(fù)錯(cuò)誤、更好地解釋概念并闡明協(xié)議運(yùn)行。規(guī)范（或?qū)嵤┣芳训奶匦员粭売?；改善協(xié)議運(yùn)行的新特性被加入。查看每個(gè)文檔的“修訂記錄”附件以了解詳情。此外，重要的是，始終參考上面鏈接的最新修訂；老的RFC現(xiàn)已過時(shí)。

部署Early Hints

HTTP/2包含服務(wù)器推送（server push）特性，當(dāng)服務(wù)器知道客戶端將需要什么東西時(shí)，它可以“推送”一個(gè)請求/響應(yīng)對給客戶端，這樣就可以避免發(fā)起請求并等待響應(yīng)的延遲。

在HTTP/2于2015年敲定后，Cloudflare和其他很多HTTP實(shí)施推出了服務(wù)器推送，期待在性能上突飛猛進(jìn)。不幸的是，事實(shí)證明這比看起來要難；服務(wù)器推送實(shí)際上要求服務(wù)器預(yù)測未來，不僅要預(yù)測客戶端將發(fā)送什么請求，還要預(yù)測網(wǎng)絡(luò)狀況。而且，當(dāng)服務(wù)器出錯(cuò)時(shí)（“過度推送”），所推送的請求將與瀏覽器發(fā)出的真正請求相競爭，這意味著巨大的機(jī)會成本，有可能會損害性能，而不是促進(jìn)性能。當(dāng)瀏覽器緩存中已經(jīng)有副本時(shí)，影響更大，因此根本不需要推送。

因此，Chrome在2022年移除了HTTP/2服務(wù)器推送。其他瀏覽器和服務(wù)器可能仍然支持它，但社區(qū)似乎一致認(rèn)為，它目前只適用于特定的用途，如瀏覽器通知特定的Web推送協(xié)議。

然而，這并不意味著我們要放棄。103（Early Hints）狀態(tài)碼是由HTTP工作組在2017年作為實(shí)驗(yàn)性RFC發(fā)布的。它允許服務(wù)器在“真正的”最終響應(yīng)之前，以非最終響應(yīng)的形式向?yàn)g覽器發(fā)送提示。如果您知道內(nèi)容中將包含一些資源的鏈接，瀏覽器將獲取這些資源，但需要更多時(shí)間向客戶端發(fā)送響應(yīng)（因?yàn)樗鼘⒒ㄙM(fèi)更多時(shí)間生成，或者因?yàn)榉?wù)器需要從其他地方獲取它，如CDN），那么這是有用的。

Early Hints可用于許多服務(wù)端推送被設(shè)計(jì)使用的情況——例如，當(dāng)有頁面將需要加載的CSS和JavaScript時(shí)。理論上，它們并不像服務(wù)端推送那樣理想，因?yàn)樗鼈冎辉试S在有未完成請求時(shí)發(fā)送提示，而且將提示發(fā)送給客戶端并進(jìn)行操作會增加一些延遲。

然而，在實(shí)踐中，Cloudflare及其合作伙伴（如Shopify和Google）在2022年試驗(yàn)了Early Hints，發(fā)現(xiàn)它們使用起來更安全，有望帶來性能提升,包括關(guān)鍵Web性能指標(biāo)的顯著降低。

我們對Early Hints顯示的潛力感到興奮，因而將其集成到Cloudflare Pages中。我們也在評估使用協(xié)議中的這一新功能來提高性能的新方法。

注重隱私的中介

對于許多人來說，2022年最令人興奮的HTTP協(xié)議擴(kuò)展是中介（intermediation）——在協(xié)議中插入代理、網(wǎng)關(guān)和類似組件，以實(shí)現(xiàn)特定目標(biāo)，通常側(cè)重于改善隱私。

例如，MASQUE工作組正在努力向HTTP添加新的隧道功能，以便中介可將隧道中的流量傳遞給另一個(gè)服務(wù)器。

雖然CONNECT實(shí)現(xiàn)TCP隧道已有很長時(shí)間，MASQUE實(shí)現(xiàn)了UDP隧道，允許更多協(xié)議更有效地傳輸，包括QUIC和HTTP/3。

Cloudflare滿懷熱情地與Apple合作使用MASQUE實(shí)施iCloud Private Relay，并增強(qiáng)其客戶的隱私，無需完全依賴于一家公司。我們也對該工作組未來的工作感興趣，包括IP隧道，其將實(shí)現(xiàn)基于MASQUE的VPN。

另一個(gè)專注于中介的規(guī)范是Oblivious HTTP（縮寫為OHTTP）。OHTTP使用一組中介來防止服務(wù)器使用連接或IP地址跟蹤客戶端，從而為收集遙測或其他敏感數(shù)據(jù)等工作提供更大的隱私保障。這個(gè)規(guī)范正在完成標(biāo)準(zhǔn)流程，我們使用它構(gòu)建一個(gè)重要的新產(chǎn)品：Privacy Gateway，以保護(hù)我們客戶的隱私。

我們和互聯(lián)網(wǎng)社區(qū)的很多其他人相信這只是一個(gè)開端，因?yàn)橹薪槟芊指敉ㄐ牛且粋€(gè)改善隱私的寶貴工具。

協(xié)議安全性

最后，2022年期間，HTTP協(xié)議的安全相關(guān)方面進(jìn)行了大量工作。Digest字段規(guī)范是現(xiàn)已非常古老的`Digest`標(biāo)頭字段的更新，允許將完整性摘要添加到消息中。HTTP消息簽名允許對請求和響應(yīng)進(jìn)行加密簽名——這已經(jīng)被廣泛地臨時(shí)部署，但直到現(xiàn)在依然缺乏標(biāo)準(zhǔn)。這兩個(gè)規(guī)范都處于標(biāo)準(zhǔn)化的最后階段。

Cookie規(guī)范的一個(gè)修訂在2022年也取得了重大進(jìn)展，且應(yīng)該即將完成。由于不可能在短時(shí)間內(nèi)完全擺脫它們，人們已經(jīng)做了很多工作來限制它們運(yùn)作的方式以改善隱私和安全，包括一個(gè)新的`SameSite`屬性。

Cloudflare已投入多年努力的另一個(gè)安全相關(guān)規(guī)范是Privacy Pass（隱私通行證），又名“Private Access Token（私有訪問令牌）”。這些加密令牌可以確保客戶端是真實(shí)的人，而不是機(jī)器人，無需使用侵入性驗(yàn)證碼，也不會跟蹤用戶的在線活動(dòng)。在HTTP中，它們采用一種新的身份驗(yàn)證模式。

雖然Privacy Pass仍未完全通過標(biāo)準(zhǔn)程序，但在2022年，Apple已經(jīng)進(jìn)行了廣泛部署，這是一個(gè)重要的進(jìn)展。由于Cloudflare在我們的替代產(chǎn)品——Turnstile使用了這一規(guī)范，您的用戶今天就可以擁有更好的體驗(yàn)。

2023年展望

那么，下一步將如何發(fā)展呢？此外，上述規(guī)范還沒有完成，HTTP工作組還有一些其他進(jìn)行中的工作，包括QUERY方法（想象GET但有body），可恢復(fù)上傳（基于tus），Variants（用于緩存的Vary標(biāo)頭改進(jìn)版），對結(jié)構(gòu)化字段的改進(jìn)（包括一個(gè)新的Date類型），以及一種將現(xiàn)有標(biāo)頭改造為結(jié)構(gòu)化字段的方式。隨著這些工作在2023年的進(jìn)展，我們將進(jìn)一步撰文介紹。

在2022年HTTP研討會上，社區(qū)還討論了我們可以開展哪些新工作來改進(jìn)該協(xié)議。討論的一些想法包括改進(jìn)我們的共享協(xié)議測試基礎(chǔ)設(shè)施（目前我們有一些資源，但有很大改進(jìn)余地），改進(jìn)（或替代）Alternative Services以允許更智能和正確的連接管理，以及更徹底的更改，例如替代性的、標(biāo)頭二進(jìn)制序列化。

社區(qū)中也在持續(xù)討論HTTP是否應(yīng)該支持pub/sub，或者是否應(yīng)該將其標(biāo)準(zhǔn)化，以便在WebSockets（以及即將到來的WebTransport）上工作。雖然現(xiàn)在還很難說，剛剛開始的Media over QUIC相關(guān)工作可能提供一個(gè)推進(jìn)這方面工作的機(jī)會。

當(dāng)然，以上并不是全部，HTTP在2023年（及以后）會發(fā)生什么還有待觀察。HTTP仍在發(fā)展，盡管其繼續(xù)兼容有史以來最大規(guī)模的分布式超文本系統(tǒng)——萬維網(wǎng)（World Wide Web）。