HTTP 已誕生三十餘年，現在仍是 Web 的作業基礎，也是最熱門的一種網際網路通訊協定 — 不僅可用於瀏覽網站、觀賞視訊和聆聽音樂，還可用於應用程式、機器對機器通訊，甚至用作構建其他通訊協定的基礎，從而被一些人稱為傳統網際網路沙漏圖中的「第二腰」。
是什麼讓 HTTP 如此成功？答案之一便是：對於大多數需要應用程式通訊協定的應用程式而言，它是「最佳選擇」。而「使用 HTTP 構建通訊協定」（由 HTTP 工作群組於 2022 年作為「目前最佳做法 RFC」發佈）認為，可將 HTTP 的成功歸因於以下幾種因素：
- 為實作者、指定者、管理員、開發人員及使用者所熟悉；
- 可以實作各種用戶端、伺服器和 Proxy；
- 使用方便；
- 可以使用 Web 瀏覽器；
- 重複使用現有機制，如驗證和加密；
- 目標部署中存在 HTTP 伺服器和用戶端；以及
- 能夠周遊防火牆。
另一個非常重要的因素是使用、實作和標準化 HTTP 的人們形成了一個社群。我們共同努力，積極地維護和發展該通訊協定，從而確保它既可互通，又符合現今的需求。如果 HTTP 停滯不前，另一種通訊協定則會（有充分的理由）取而代之，我們將失去所有的社群投資、達成的共識以及互通性。
Cloudflare 以及其他很多公司的具體做法是，派遣工程師去參加 IETF（大多數網際網路通訊協定在這裡進行討論和實現標準化）。我們也會參加並贊助社群活動（如 HTTP 研討會），針對人們的問題、人們的需求進行交談，從而瞭解哪些變化會對他們有所助益。
在 2022 年舉行的這些工作群組會議和邊會活動以及發佈的規範文件中發生了什麼？Web 通訊協定的實作者和部署者正在做什麼？接下來又會發生什麼呢？
新規範：HTTP/3
在規範方面，2022 年發生的最大的一件事就是 HTTP/3 的發佈，因為這意味著能夠更高效地使用網路來提升 Web 效能，從而向滿足現代應用程式和網站要求邁出了一大步。
上世紀 90 年代，HTTP/0.9 和 HTTP/1.0針對每個要求使用一個新的 TCP 連線 — 網路使用如此低效，真是令人震驚。HTTP/1.1 推出了永久連線（可使用 `Connection: Keep-Alive` 標頭向後移植到 HTTP/1.0）。這是為協助伺服器和網路應對 Web 的迅速普及而做出的一種改進，但社群知道，即使在那時，它也有很大的局限性 — 特別是線路前端封鎖（連線上的一個未執行的要求會阻止其他要求完成）。
這些局限性在上世紀 90 年代以及 21 世紀初並不那麼重要，但現今的網頁和應用程式對網路提出了要求，讓它們成為至關重要的效能因素。網頁通常有數百個資產同時爭搶網路資源，而 HTTP/1.1 無法勝任這項工作。在經歷數次初始失敗之後，社群最終於 2015 年使用 HTTP/2 解決了這些問題。
然而，在 HTTP 中移除線路前端封鎖卻在更低的一層（即 TCP）中暴露出同樣的問題。因為 TCP 是一種依順序的可靠的傳遞通訊協定，在流程中遺失一個封包會封鎖對其後封包的存取，即使位於作業系統的緩衝區亦是如此。這對於 HTTP/2 部署來說，是一個真正的問題，特別是在不理想的網路上。
解決方案當然是取代 TCP — 這一備受推崇的傳輸通訊協定是大部分網際網路的構建基礎。在 QUIC 工作群組進行大量討論和多次起草之後，QUIC 第 1 版作為取代方案於 2021 年發佈。
HTTP/3 是使用 QUIC 的 HTTP 版本。雖然工作群組實際上在 2021 年就與 QUIC 一起完成了該版本，但其發佈卻拖到了 2022 年，以便與其他文件（請參閱下文）同步發佈。2022 年也是 HTTP/3 部署的里程碑之年；Cloudflare 發現，人們對新通訊協定的採用率和信心均與日俱增。
雖然 HTTP/2 和 HTTP/3 僅相差短短數年，但社群中對很快開發 HTTP/4 並沒有太大的興趣。QUIC 和 HTTP/3 都是新事物，全世界仍在學習如何最好地實作通訊協定、運作它們，以及使用它們來構建網站和應用程式。雖然我們無法排除未來強行推出新版本的局限性，但 IETF 基於現代網路的廣泛產業經驗構建這些通訊協定，並提供大量的擴充性來減少任何必要的變更。
新規範：HTTP「核心」
2022 年 HTTP 規範的另一起頭條事件就是發佈了「核心」文件 — HTTP 規範的中心。該核心包括：HTTP 語義 — 方法、標頭、狀態代碼和訊息格式等；HTTP 快取 — HTTP 快取的運作方式；HTTP/1.1 — 使用人人皆知且喜愛的格式，將語義對應至網路。
此外，還重新發佈了 HTTP/2，以與語義文件正確整合，並修正一些尚未解決的問題。
在這些文件的一長串修訂版中，這是最新的版本 — 過去，我們有 RFC 723x 系列、（可能是最為知名的）RFC 2616、RFC 2068 及其所有這些版本的父父代，RFC 1945。每個修訂版都旨在提高可讀性、修正錯誤、更好地說明概念，以及釐清通訊協定作業。取代了指定（或實作）較差的功能；新增了改進通訊協定作業的新功能。如需詳細資料，請參閱每個文件中的「以下修訂版之後的變更」附錄。而且，務必始終參閱上面連結的最新修訂版；舊版 RFC 現已過時。
部署 Early Hints
HTTP/2 包括伺服器推送，該功能旨在讓伺服器知曉在用戶端需要什麼內容時，將要求/回應對「推送」至用戶端，因此可避免發出要求和等待回應的延遲處罰。
在 HTTP/2 於 2015 年完成後，Cloudflare 和其他很多 HTTP 實作公司很快推出了伺服器推送，以期大幅提升效能。遺憾的是，這可比看起來難多了；實際上，伺服器推送需要伺服器能夠預測未來 — 不僅要預測用戶端將傳送的要求，還要預測網路狀況。而且，當伺服器出錯（「過度推送」）時，被推送的要求會直接與瀏覽器發出的真實要求競爭，這意味著巨大的機會成本，這很可能會損害效能而不是提升效能。如果瀏覽器在快取中已有一個複本，則會產生更糟糕的影響，因此它根本不需要推送。
因此，Chrome 在 2022 年移除了 HTTP/2 伺服器推送。其他瀏覽器和伺服器可能仍然支援該功能，但社群似乎一致認為它目前僅適用於特定用途，比如，瀏覽器通知特定的 Web 推送通訊協定。
然而，這並不意味著我們要放棄。103 (Early Hints) 狀態代碼由 HTTP 工作群組於 2017 年作為實驗性 RFC 發佈。它可讓伺服器在非最終回應中先將提示傳送給瀏覽器，然後再傳送「真正的」最終回應。如果您知道內容將包括瀏覽器所擷取資源的一些連結，但需要更多時間將回應傳送至用戶端（因為產生回應需要更多的時間，或者因為伺服器需要從其他位置擷取回應，CDN 就是這樣），這是非常有用的。
在伺服器推送適用的很多情況下，都可以使用 Early Hints，例如，當您擁有網頁需要載入的 CSS 和 JavaScript 時。理論上，它們並不像伺服器推送那樣具有最佳效能，因為僅在有未執行的要求時才會傳送提示，還因為將提示傳送至用戶端並採取動作會增加一定的等待時間。
而實際上，Cloudflare 以及我們的合作夥伴（比如 Shopify 和 Google）在 2022 年對 Early Hints 進行了實驗，發現它們不僅使用起來更安全，還具有顯著的效能優點，包括大大降低了關鍵 Web 效能標準。
我們對 Early Hints 所展示的潛力激動不已；我們非常高興已經將其整合至 Cloudflare Pages 中。我們還在評估通訊協定中使用這一新功能來提升效能的新方式。
注重隱私權的中間資源
對許多人而言，2022 年最令人激動的 HTTP 通訊協定延伸主要體現在中間資源上 — 能將 Proxy、閘道和類似元件插入通訊協定中以實現特定的目標，通常是為了改進隱私權。
例如，MASQUE 工作群組致力於將新的通道功能新增至 HTTP，以便中間資源可以將通道流量傳遞給另一台伺服器。
雖然 CONNECT 已經啟用 TCP 通道很長時間了，但 MASQUE 啟用了 UDP 通道，從而更高效地傳輸更多通訊協定（包括 QUIC 和 HTTP/3）。
Cloudflare 非常願意與 Apple 合作，使用 MASQUE 來實作 iCloud Private Relay 並增強客戶的隱私權，而不僅僅依賴於一間公司。我們對該工作群組的未來工作也很感興趣，包括支援 MASQUE 型 VPN 的 IP 通道設定。
另一個注重中間資源的規範是 Oblivious HTTP（即 OHTTP）。OHTTP 使用幾組中繼來防止伺服器使用連線或 IP 位址來追蹤用戶端，為收集遙測或其他敏感性資料等工作提供更大的隱私權保障。本規範剛剛完成標準流程，我們將使用它來構建一款非常重要的新產品 — Privacy Gateway，從而為客戶的客戶的隱私權提供保護。
我們以及網際網路社群中的其他許多公司認為，這僅僅是個開始，因為中間資源可以分割通訊，這是一個寶貴的隱私權改進工具。
通訊協定安全性
最後，2022 年在 HTTP 的網路安全相關層面做了大量工作。摘要欄位規範是現在很古老的 `Digest` 標頭欄位的更新，可將完整性摘要新增至訊息。HTTP 訊息簽章規範可對要求和回應啟用密碼編譯簽章 — 該簽章已廣泛地臨機部署，但目前還缺少一個標準。這兩個規範都處於標準化的最終階段。
2022 年，Cookie 規範修訂也取得了很大的進展，應該很快就會定稿。因為此規範不能很快完全移除，所以我們做了大量工作來限制其作業方式以改進隱私權和安全性，包括新的 `SameSite` 屬性。
Cloudflare 投資多年的另一組網路安全相關規範是隱私權通行證，也稱為「隱私權存取權杖」。這是一些密碼編譯權杖，可確保用戶端是真實的人而不是機器人，但無需使用干擾性 CAPTCHA，也無需追蹤使用者的線上活動。在 HTTP 中，它們採用了全新的驗證配置形式。
雖然隱私權通行證還未完全通過標準流程，但 2022 年，Apple 對其進行了廣泛的部署，這是一個巨大的進步。而且由於 Cloudflare 在 Turnstile（我們的 CAPTCHA 替代方案）中使用它，現在，您的使用者會獲得更舒適的使用體驗。
2023 年呢？
那麼，接下來會發生什麼呢？除了上述還未完全完成的規範以外，HTTP 工作群組還在進行其他幾項工作，包括 QUERY 方法（想想 GET，但有一個主體）、可繼續的上傳（基於 tus）、變體（一個用於快取的改進的 Vary 標頭）、改進結構化欄位（包括一個全新的日期類型），以及將現有標頭改造為結構化欄位的方式。2023 年，我們會隨著這些工作的推進，撰寫更多相關內容。
在 2022 年 HTTP 研討會上，社群還討論了我們可以開展哪些新工作來改進該通訊協定。經過討論的觀點包括改進我們的共用通訊協定測試基礎結構（我們目前有一些資源，但可以更好）、改進（或取代）替代服務以允許更智慧和更正確的連線管理，以及更徹底的變更，如替代性二進位標頭序列化。
社群中還在繼續討論 HTTP 是否應該採用 pub/sub，或者是否應將其標準化以在 WebSockets（很快就會成為 WebTransport）上工作。儘管現在還很難說，但剛剛啟動的透過 QUIC 的媒體的相鄰工作可能會提供一個機會來推進這方面的工作。
當然，這不是全部內容，而且 2023 年（及以後）HTTP 會發生什麼還有待觀察。雖然 HTTP 與目前所能想像的規模最大的分散式超文字系統（即全球資訊網）保持相容，發展的腳步卻從未停止。