最近 IETF （互聯網工程任務組），負責開發互聯網的協議和架構， 廣為人知 那個新聞 完成了 HTTP/3.0 協議的 RFC 的形成 並在標識符 RFC 9114 和 RFC 9204 下發布了相關規範。
HTTP/3.0 規範 收到“建議標準”的狀態， 之後工作將開始為 RFC 提供標準草案（Draft Standard）的狀態，這實際上意味著協議的完全穩定並考慮到所有的評論。
協議書 HTTP/3 定義了 QUIC 協議的使用 （快速 UDP 互聯網連接） 作為 HTTP/2 的傳輸。 QUIC 是 UDP 協議的插件，支持多連接的多路復用，並提供等同於 TLS/SSL 的加密方法。
該協議由 Google 於 2013 年創建 作為 Web 的 TCP + TLS 的替代方案，解決了 TCP 中連接建立和協商時間過長的問題，並消除了數據傳輸過程中由於丟包而導致的延遲。
目前， QUIC 和 HTTP/3.0 支持已經在所有瀏覽器中實現 熱門網站。 在服務器端，HTTP/3 的實現可用於 nginx（在單獨的分支中並作為單獨的模塊）、Caddy、IIS 和 LiteSpeed。 Cloudflare 的內容交付網絡也支持 HTTP/3。
QUIC的主要特點：
- 高安全性，類似於 TLS（實際上 QUIC 提供了使用 TLS over UDP 的能力）
- 傳輸完整性控制，防止丟包
- 能夠立即建立連接並確保發送請求和接收響應之間的延遲最小（RTT，往返時間）
- 重傳數據包時使用不同的序列號，讓您在確定收到的數據包時避免歧義並擺脫超時
- 丟失數據包只會影響與其關聯的流的傳遞，並且不會停止通過當前連接並行傳輸的流中數據的傳遞
- 糾錯工具，可最大限度地減少由於丟失數據包的重新傳輸而導致的延遲。 使用特殊的數據包級糾錯碼來減少需要重新傳輸丟失的數據包數據的情況。
- 加密塊邊界與QUIC包邊界對齊，減少丟包對後續包內容解碼的影響
- 阻止TCP隊列沒有問題
- 連接識別支持以減少移動客戶端的重新連接時間
- 連接用於連接過載控制的高級機制的可能性
- 在每個方向上使用帶寬預測技術來確保最佳的數據包轉發率，避免數據包丟失的擁塞情況。
- 顯著的性能和性能優於 TCP。 對於 YouTube 等視頻服務，QUIC 已被證明可以將視頻緩衝操作減少 30%。
除此之外，同時還發布了 HTTP/1.1 (RFC 9112) 和 HTTP/2.0 (RFC 9113) 協議規範的更新版本，以及定義 HTTP 請求語義的文檔 (RFC 9110). 和 HTTP 緩存控制標頭 (RFC 9111)。
的變化 規範 HTTP/1.1，你可以注意到禁令 從單獨使用回車符 (CR) 正文以外的內容，即在協議元素中，CR 字符只能與換行符（CRLF）一起使用。
El 改進了分塊請求佈局算法 以簡化帶有標題的附加字段和部分的分離。 添加了處理模糊內容的指南，以阻止“HTTP 請求走私”類攻擊，這些攻擊可能會侵入前端和後端之間流中其他用戶請求的內容。
規範的更新 HTTP/2.0 明確定義了對 TLS 1.3 的支持， 不推薦使用的優先級方案和相關的頭字段和更新機制 已棄用 HTTP/1.1 連接已棄用。
最後，如果您有興趣能夠了解更多，可以在 以下鏈接。