微軟已經開放了 HTTP/3 中使用的 QUIC 協定的實現

微軟公司 宣布了 關於打開庫程式碼 姆斯奎克 隨著網路協定的實現 QUIC。該程式碼是用 C 編寫的， 分發者 根據麻省理工學院的許可。該庫是跨平台的，不僅可以在 Windows 上使用，還可以在 Linux 上使用 SCHANNEL 或用於 TLS 1.3 的 OpenSSL。未來計劃支援其他平台。

該程式庫基於 Windows 10 核心（Insider Preview）中提供的 msquic.sys 驅動程式程式碼，以啟用 HTTP 和 SMB 在 QUIC 之上。該程式碼也用於在內部 Windows 堆疊和 .NET Core 中實作 HTTP/3。 MsQuic 函式庫的開發將完全在 GitHub 上進行，使用公共同儕審查、拉取請求和 GitHub 問題。已經準備好基礎設施，用於在 4000 多個測試中檢查每個提交和拉取請求。開發環境穩定後，計畫接受第三方開發者的變更。

MsQuic 已可用於建立伺服器和用戶端，但目前並非 IETF 規格中定義的所有功能都可用。例如，不支援 0-RTT、客戶端遷移、路徑 MTU 發現或伺服器首選位址控制。在實現的功能中，值得注意的是優化以實現最大吞吐量和最小延遲、支援非同步輸入/輸出、RSS（接收端縮放）以及組合輸入和輸出 UDP 流的能力。 MsQuic 實作已經過與 Chrome 和 Edge 瀏覽器實驗版本的兼容性測試。

回想一下，HTTP/3 標準化了 QUIC 協定作為 HTTP/2 傳輸的使用。 協定 QUIC （快速UDP 網路連線）由Google 自2013 年起開發，作為Web 的TCP+TLS 組合的替代方案，解決了TCP 連線建立和協商時間長的問題，並消除了資料傳輸過程中資料包遺失時的延遲。 QUIC是UDP協定的擴展，支援多個連線的複用，並提供相當於TLS/SSL的加密方法。

主要的 產品特點 快速：

• 類似於 TLS 的高安全性（本質上 QUIC 提供了透過 UDP 使用 TLS 1.3 的能力）；
• 流量完整性控制，防止丟包；
• 能夠立即建立連線（0-RTT，在大約 75% 的情況下，可以在發送連線建立資料包後立即傳輸資料）並在發送請求和接收回應之間提供最小的延遲（RTT，往返時間）；
  

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

來源： opennet.ru