Chrome 增加了對 HTTP/3 協定的實驗性支持

實驗性構建 鍍鉻加那利 添加 支援 HTTP/3 協議，該協議實現了一個附加元件，使 HTTP 能夠透過 QUIC 協定運作。 QUIC 協議本身是五年前添加到瀏覽器中的，此後一直用於優化與 Google 服務的工作。 同時，Chrome中使用的Google QUIC版本在一些細節上與來自的版本有所不同 規格 IETF，但現在實作是同步的。

HTTP/3 標準化了 QUIC 作為 HTTP/2 傳輸的使用。 啟用 HTTP/3 和 QUIC 選項 23 稿 IETF 規格要求 Chrome 啟動時使用選項“-enable-quic -quic-version=h3-23”，然後在開啟測試站點時 快速搖滾：4433 在開發者工具的網路檢查模式下，HTTP/3 活性將顯示為「http/2+quic/99」。

回想一下協議 QUIC （快速UDP 網路連線）由Google 自2013 年起開發，作為Web 的TCP+TLS 組合的替代方案，解決了TCP 連線建立和協商時間長的問題，並消除了資料傳輸過程中資料包遺失時的延遲。 QUIC是UDP協定的擴展，支援多個連線的複用，並提供相當於TLS/SSL的加密方法。 該協定已經整合到 Google 伺服器基礎架構中，並且是 Chrome 的一部分。 計劃 包含在 Firefox 中，並積極用於處理 Google 伺服器上的用戶端請求。

主要的 產品特點 快速：

• 類似於 TLS 的高安全性（本質上 QUIC 提供了透過 UDP 使用 TLS 的能力）；
• 流量完整性控制，防止丟包；
• 能夠立即建立連線（0-RTT，在大約 75% 的情況下，可以在發送連線建立資料包後立即傳輸資料）並在發送請求和接收回應之間提供最小的延遲（RTT，往返時間）；
• 重傳資料包時不使用相同的序號，這可以避免識別接收到的資料包時出現歧義並消除逾時；
• 資料包遺失僅影響與其關聯的流的傳送，並且不會停止透過目前連接傳輸的平行流中的資料傳送；
• 糾錯功能可最大限度地減少因重傳遺失資料包而導致的延遲。 在資料包層級使用特殊的糾錯碼可以減少需要重傳遺失的資料包資料的情況。
• 密碼塊邊界與QUIC資料包邊界對齊，減少丟包對後續資料包內容解碼的影響；
• 不存在TCP隊列阻塞的問題；
• 支援連線標識符，減少行動客戶端重新建立連線的時間；
• 連接高階連接擁塞控制機制的可能性；
• 採用單向吞吐量預測技術，確保資料包以最佳速率發送，防止資料包擁塞而導致丟包；
• 可感知的 生長 與 TCP 相比的效能和吞吐量。 對於 YouTube 等影片服務，QUIC 已被證明可以將觀看影片時的重新緩衝操作減少 30%。

來源： opennet.ru