新的 QUIC 和 HTTP/3 協議即將到來，這是可謂是網絡發展的精華所在。 結合過去30年來網絡實踐中的經驗和教訓，新一代的協議棧針對性能、隱私、安全和靈活性方面，均有大幅的提升、改進。

當前，關于 QUIC 發展潛力的討論，大都是基于此前 Google 進行的早期版本 QUIC的實驗結果 。然而，其潛在的缺陷卻很少有人討論；此外，對于即將發布的標準版的功能特性，我們依然知之甚少。盡管大家對 QUIC 極其樂觀和期待，但是，本文將一反常態，以“唱反調”的觀點，探討 QUIC 和 HTTP/3 在實踐中可能失敗的種種因素。為了盡可能客觀、公正的陳述觀點，在我的每一條觀點后面，我將列舉出若干的反對意見。希望讀者能在兩方的辯駁中，思考判斷，得出自己的一些觀點來。

注意：如果你尚不清楚 QUIC 和 HTTP/3 的具體情況，建議花點時間，快速了解下。以下這些資源，對你快速了解，或將有些幫助：

Mattias Geniar 的博客文章
Cloudflare 的文章
Robert Graham 評論
Daniel Stenberg(@bagder) 的 HTTP/3 詳解
Patrick McManus 的郵件列表和博客文章
以及今年我本人在 DeltaVConf的探討

1. 端到端 UDP 加密？

QUIC 的賣點之一，便是其端到端加密。在現有的 TCP 協議中，大部分的傳輸信息都是公開的，只有數據部分是加密的；而 QUIC 幾乎對所有內容進行加密處理，并且應用數據完整性保護（圖 1 ）。這將極大地提高隱私保護和數據安全性，避免數據被網絡中間設備篡改。上述的改進，是 QUIC 采用 UDP 的主要原因之一：改進 TCP 太過困難了，牽一發而動全身。

圖 1：TCP 和 QUIC 中（加密）字段的簡化概念表示

• 網絡運營商和 spin bit
  現今，網絡運營商極少去優化和管理網絡。他們無法確認某個數據包是 ACK 包還是重傳包；對于擁塞控制/發送速率控制，除了丟包，他們別無它法。所以，對于某個給定的連接，要估算其 RTT（若該時間增大，意味著擁塞或 bufferbloat（緩沖區膨脹）） ，更是困難。

關于將這些標記添加回可見的 QUIC 頭部已經有很多討論，但最終結果是，只有 1 bit 用于 RTT 測算—— spin bit。這個“輪轉位”的概念的是這樣的：在每次往返時改變一次值，從而使得網絡中間設備可以觀察到變化并以這種方式估算 RTT，參見 圖 2。雖然有點幫助，但是仍然大大地限制了運營商，特別是初始標識是 Chrome 和 Firefox 不支持的“輪轉位”。QUIC 唯一支持的其他選項是“顯式擁塞提醒”，它采用 IP 級別的標識來表示擁塞。

圖 2：“輪轉位”工作原理簡述

• UDP 攔截、alt-svc
  不知道你會怎樣做？但如果我是一個網絡運營商，如果我正在進行 TCP 網絡優化或者在應用特殊的安全措施，我會非常想要徹底地封鎖 QUIC。對于網頁瀏覽來說，攔截 443 端口上的 UDP 流量，并不會有什么問題。在開發 QUIC 時，Google 也認識到了該問題。為了搞清楚當前網絡對 UDP/QUIC 的封鎖情況，他們研究得出 3-5% 的網絡不允許 QUIC 流量通過。結果看起來還不錯，不過該數據并未包含不計其數的企業網絡；此外，更重要的問題是，這種狀況還會一直延續下去嗎？如果 QUIC 應用的更加廣泛后，這些網絡會停止對 QUIC 的主動攔截嗎（至少是在他們更新他們的防火墻和網絡管理工具后）？
  在使用 quick-tracker conformance 工具測試我們自己的 QUIC 實現時，發生一個“有趣”的小故事：當測試一臺在加拿大的服務器時，大部分測試突然失效。更進一步測試發現，一些 IP 段主動阻塞 QUIC 流量，導致了測試的失敗。

攔截 QUIC 流量并不會對瀏覽網頁的終端用戶帶來任何影響–網站照常訪問。因為，無論如何瀏覽器（和服務器）必須要解決 UDP 阻塞問題。為此，他們總是把 TCP 留為備用措施，而不是干等著 QUIC 連接 timeout。
服務器將采用 alt—svc 機制提供對 QUIC 的支持，但瀏覽器只能在一定程度上信任它；因為快速變化的網絡環境意味著 QUIC 隨時有可能被攔截。在 QUIC 流量被攔截的企業網絡里，網絡管理員無需處理用戶的各種問題同時還可以維持對網絡的有力控制，他們何樂而不為呢？他們還無需為此額外地維護一個獨立的 QUIC/HTTP3 協議棧。

最后，有人可能會問了：為什么這些巨頭比如 Google 即使是極其不容易的情況下，還要開發部署 QUIC 協議呢？在我看來，像 Google 這樣的巨頭公司對他們從服務器到各個邊緣網絡的鏈路，有著絕對的掌控，同時，還與其他網絡運營商有聯系。他們或多或少是知道網絡上的問題的，并通過調整負載均衡，路由和服務器來緩解這些問題。為了解決這些問題，在開發 QUIC 時，他們可能會做點手腳，比如在 QUIC 的非加密部分編碼一些信息 – 連接 ID。該 18 字節長的域可以編碼負載均衡信息在里頭。他們還可以設想為其數據包添加額外的包頭，一旦流量離開企業網絡就將其剝離。所以，這樣看來，在這個游戲中，這些巨頭可能會失去一些，但是那些服務器提供商或是小公司會失去更多。

反對觀點

• 由于其優秀的性能，終端用戶迫切希望用上 QUIC ；
• 基于其自身的擁塞控制及快速啟動配置，QUIC 并不需要性能增強的中間設備；
• 大部分網絡并沒有阻擋 QUIC 流量，大的變革同時也意味著大的機會；
• 運行 QUIC + HTTP/3 只需在現有的 TCP + HTTP/2 的服務器配置文件添加若干行配置即可。

2.CPU 問題

到目前為止， QUIC 協議完全是在用戶層實現的（而 TCP 協議是典型的運行在操作系統內核空間的）。在用戶層實現，可以方便地更新、迭代，而無需升級內核，但同時也帶來嚴重的性能開銷（主要是用戶層到內核空間的通信）和潛在的安全問題。

在他們發表的研究論文中，Google 表示，相較于同等條件下的 TCP+TLS 協議棧，他們在服務器端的 QUIC 協議棧，需要 2 倍于前者的 CPU 開銷。這已經是在經過優化的內核上的較好的結果。換句話來說，為了提供同等質量的網絡，至少需要 2 倍性能的硬件。他們也提到 QUIC 協議在移動設備上性能降低的問題，不過并未提供相關數據。還好，我們找到了另外一份關于移動設備上的測試報告。該報告研究顯示， Google 的 QUIC 比 TCP 快，只是在不同機型上這一優勢并不明顯，見圖 3。這主要是因為 QUIC 的擁塞控制是基于限制應用程序時間 58%（vs 桌面設備的 7%），這意味著 CPU 不能處理數目過大的接入數據包。

圖 3：性能 QUIC vs TCP 。紅色 = QUIC 表現較好, 藍色 = TCP 表現較好。

看來 QUIC 將為 TCP 網絡不好的##高端##設備帶來改善的機會。不幸的是，不良的網絡往往是由于落后的硬件設備。那么，采用 QUIC 協議為網絡帶來的改進，將被緩慢的硬件抵消。結合現在的網頁也越來越消耗 CPU 資源的事實（導致網頁的整體性能越來越依賴于 JavaScript 的性能而非網絡性能），這確實是個難題。

IoT 和 TypeScript

QUIC 另一個常被吹噓的應用場景是物聯網（IoT）設備，因為這些設備經常需要間歇性的（蜂窩）網絡接入，而 QUIC 的低延遲啟動、0-RTT和良好的傳輸可靠性,看起來很適合物聯網設備。但是，這些設備的 CPU 通常相當的慢。盡管，據我所知目前尚未有在該類設備上測試的 QUIC 協議棧，但 QUIC 的設計者提到，在物聯網應用場景下仍存在很多的問題，任何一個決定都有可能影響到 QUIC 性能表現。類似的，不少人提到了硬件實現 QUIC 的想法，不過，據我的經驗來看，這只是某些人一廂情愿的想法罷了。

我是 Quicer（NodeJS QUIC 的 TypeScript 實現）的合著者。對于那些用 C/C++，Rust 或 Go 實現的協議棧來說，這顯得相當離奇。我們選擇用 TypeScript 主要是為了評估 QUIC 腳本語言實現的開銷和可行性。由于我們的進行試驗的時間處于 QUIC 的早期，所以測試結果并不是太好，見圖 4。
圖 4：CPU、內存使用率 Quicker (TypeScript) vs ngtcp2 (C/C++)

反對觀點

• QUIC 將在內核/硬件層實現。
• 相較于其他開銷，TCP+TLS 連接的開銷低得不值一提；即使 QUIC 連接的開銷是 TCP+TLS 的 2 倍。
• 現在的測試數據是 Google 版的 QUIC,IETF 版的 QUIC 將與此不同。
• （客戶端）硬件將會越來越快。
• QUIC 的開銷并沒有高到不可控制。
• 即使要花費巨大的投入，Google 仍決定大規模部署 QUIC 。這表明其帶來收益大于成本，或許更佳的 web 性能將為其營收帶來大幅提升。
• TCP 在物聯網領域也占有一席之地。
• “我看過你的 TypeScript 代碼，簡直就是一團糟。合格的開發者能讓 QUIC 運行地更快”

3. 0-RTT 的實際應用

QUIC 的另一主要賣點（實際上是源于 TLS 1.3）是 0-RTT 連接配置：你初始（HTTP）請求可以綁定到第一個握手包上，在第一個回應包就可以得到請求的數據，簡直不能再快了！

然而，這有個前提條件：服務器必須是之前通過正常的 1-RTT 連接過的。二次連接的 0-RTT 數據是用首次連接得到的“預共享密鑰(pre-shared secret)”加密的。服務器也需要知道該密鑰，所以 0-RTT 只能連接同一臺服務器，而不是同一個服務器集群。這意味著，負載均衡器要足夠智能地將請求路由到正確的服務器。在最初的 QUIC 開發中，Google 測試的正確率是 87%（桌面端）- 67%（移動端）。這一結果相當令人印象深刻，因為他們要求用戶保持他們的 IP 地址不變。

此外，還有其他的缺陷：0-RTT 數據包容易受到“重放攻擊”，攻擊者重復多次發送最初的數據包。由于完整性保護，數據包的內容不會被更改，但是依據數據包內請求的內容不同，重復多次的請求可能會導致一些不希望的行為（e.g., POSTbank.com?addToAccount=1000）。因此，只有叫做“冪等”的數據可以通過 0-RTT 發送。根據應用場景，這將會嚴重限制 0-RTT 發揮作用（例如，IoT 傳感器使用 0-RTT POST 數據，這可不是個好主意）。

最后還存在的問題是 IP 地址欺騙和 UDP 放大攻擊。在該場景下，攻擊者偽裝成受害者的 IP a.b.c.d 然后發送一個 UDP 包給服務器。如果服務器響應返回一個相當大的 UDP 包給 a.b.c.d ，這樣，攻擊者就以一個相當小的帶寬產生了大流量的攻擊，見 圖 5。為了防止該類攻擊，QUIC 加入了兩條緩解措施：客戶端的第一個數據包必須至少為 1200 字節（實踐中最大為 1460）；同時，在未收到客戶端響應時，服務器響應包不得超過 3 倍的請求包大小。所以只有 3600 - 4380 字節，包括 TLS 握手和 QUIC 開銷，只有少量空間留給 HTTP 響應（如果有）。你會發送HTML 嗎？header， push 一些東西？這有關系嗎？這個確切的問題是我期待深入研究的事情之一。

圖 5：UDP 放大攻擊

對 QUIC 最后致命一擊的是 TCP+TLS 1.3 的“Fast Open”選項（不過也存在上述的缺陷）也可以使用 0-RTT 功能。所以 0-RTT 這個功能并不足以讓人采用 QUIC 。

反對觀點

• HTTP 服務器應該能免疫重放攻擊了。
• 阻止重放攻擊很容易，只需添加一些內容如時間戳或序列號，因為攻擊者無法修改數據包內容。
• 1-RTT 仍比 TCP+TLS 1.2 的 3-4 RTT 好不少。
• 服務端為了性能考慮可以忽略 RFC 中規定的 3600 字節的限制。
• 有證據顯示更大的初始擁塞窗口（initial congestion window）并未給 TCP 的 HTTP/2 整體連接帶來大提升，所以 QUIC 終端限制或許不會對 HTTP/3 實際應用帶來影響
• TCP 的“Fast Open”尚不可用，Mozilla 甚至不打算在 Firefox 支持它。（反對觀點：久而久之，對 TCP Fast Open 的支持也會增多）

4.QUIC v3.5.66.6.8.55-Facebook

與 TCP 相對的是，QUIC 集成有完整的版本協商配置，主要是為了在不破壞現有部署的前提下進行版本演進。客戶端使用其最支持的版本發送第一握手包。如果服務端不支持該版本，則返還一個協議版本協商包，列出服務端支持的版本。客戶端選擇其一版本，嘗試重新連接。該過程是必要的，因為各版本的編碼實現必然會有些差異的。

每一個 RTT 都是多余的
承上所述，每一次版本協商需要額外的 1 RTT 。在有限數量的版本的情況下，這并不存在什么問題。只是，實際情況可能是每年有不止一個正式版本，而是一大批不同的版本。一種可能的情況是，甚至因為某個單一的功能而發布一個新版本（比如前面提到的 輪轉位（spin bit））。另外一種情況是，為了讓用戶體驗不同的，非標準化的功能特性。這些都將導致“狂野西部（wild-wild-west）” ，不同部分的人運行略微有點區別的 QUIC ，最終使得版本協商（意味著 1 RTT 開銷）的可能性增加。考慮地更全面深入一點，可能一部分人覺得他們自己的 QUIC 版本更好而不愿意更新到新的標準版本.最終，導致了 drop-and-forget 的情況，例如，物聯網應用場景里，軟件更新頻率極低并且嚴重滯后。

我們可以從參數傳輸的過程中找到部分的解決思路。這些參數被用來作為握手認證的一部分，同時用來啟用/關閉某些功能。例如，QUIC 中有 1 個參數用于表示切換連接遷移支持。然而，目前尚不清楚 QUIC 實際實現是傾向于版本標記還是參數控制。

對于一個以 0-RTT 標榜的傳輸協議來說，竟然還需要為了 1 個 RTT 的版本協商而大費腦筋，實在是有點自相矛盾。

反對觀點

• 瀏覽器只支持主流的版本，只要服務端也支持，那么就沒什么問題。
• 運行他們自己版本的人需要確保客戶端和服務端都支持其功能，或者是通過版本協商確定。
• 客戶端將會把服務端支持的版本列表緩存下來用于接下來的連接。
• 用于支持獨立功能特性的版本可以放在單獨的數據庫中。如果不支持某個版本，服務端將會智能的不進行版本協商；如果主線功能一致，那么服務端將安全地忽略其他不一致的功能。
• 即使沒有版本協商，服務端也總是會將他們支持的版本列表完整的回傳。這樣，在二次連接時，客戶端可以選擇其最支持的版本來建立連接。

5.擁塞控制的公平性

QUIC 的端到端加密，版本協商和用戶空間實現，為用戶提供了前所未見的靈活性。到目前為止，擁塞控制算法(congestion control algorithms (CCAs))都是在內核實現的。你可以選擇選擇不同的算法，但是，該算法將應用到整個服務器。由此，大多數擁塞控制算法都是通用算法，因為它們需要處理的是各種接入鏈路。在 QUIC 中，你可以根據某個連接的具體情況選擇合適的算法或者至少可以很容易地試用不同的（新的）算法。比如，我想用 NetInfo API 來確定接入鏈路的類型，并以此來調整擁塞控制算法的參數。

Calimero

上一例子也明確地表明了潛在的危險：如果任何人都可以決定和修改擁塞控制算法（無需重新編譯內核），這將會為濫用行為大開方便之門。畢竟，擁塞控制的很重要一部分是使每個連接得到或多或少盡量公平的帶寬，這一原則稱為“公平性”。如果一些 QUIC 服務器使用更極端的擁塞控制算法，使其連接獲得超過公平原則下的帶寬，這將會拉低其他非 QUIC 連接和使用不同擁塞控制算法的 QUIC 連接的帶寬。

這是極其不合情理的！Google 的 QUIC 支持兩種擁塞控制算法：基于 TCP 的 CUBIC 和 BBR。盡管有一些矛盾的信息，但是至少一些信息表明，他們的擁塞算法對普通的“TCP”連接很不公平。一篇研究指出， QUIC+CUBIC 占用 2 倍于 4 條 TCP+CUBIC 連接的帶寬。另一篇博客文章顯示 TCP+BBR 占用 2/3 的可用帶寬，見圖 6。這并不是說 Google 惡意降低其他（競爭）連接，卻很好地展示了隨意修改擁塞控制算法的風險。最糟糕的情況是，這可能導致相互間的“軍備競賽”：大家爭相部署實施更加極端的擁塞控制算法或是眼看著自己的網絡鏈路“沉溺”在 QUIC 包的海洋里。

圖 6：公平性 BBR vs CUBIC (均為 TCP 網絡)

另外一個原因是擁塞算法實現上的（小）錯誤將會使你的算法表現不理想，拉低你的網絡性能。因為所有的東西都得從頭開始，我保證類似的問題一定會出現。因為擁塞控制算法調試極其困難，可能要好一段時間才能發現其中的問題。舉例來說，Google 在 QUIC 最初的開發中發現了 TCP CUBIC 中一個古老的 bug，修復該 bug 后，TCP 和 QUIC 的性能都得到了大幅提升。

反對觀點

• 網絡有緩解措施和速率限制等來避免該類濫用。
• 自 TCP 伊始，擁塞控制就存在，這在實際應用中，并沒有什么問題。
• 并沒有證據表明巨頭公司（如 Youtube，Netflix）用該策略來使他們的網絡獲得優先。

6.“為時過早”也“為時過晚”

QUIC 存在了相當長一段時間了：2012 年起始于 Google 的實驗（gQUIC），經過相當正式的部署試驗后，于 2015 年通過 IETF 標準（iQUIC），證明它確實是有發展潛力的。盡管經過長達 6 年的設計和開發，QUIC 仍遠未達到完備。IETF v1 的最后期限推遲到 2018年11月，現在又推遲到 2019年7月。雖然大多數主要的功能特性已經定下來了，但是實現上的更新迭代卻仍在進行。目前，有超過 15 個獨立的實現版本，不過傳輸層的功能特性總共也就那些。由于 gQUIC 與 iQUIC 在底層實現上存在較大差異，目前尚不清楚前者的測試結果是否適用于后者。這也意味著理論上的設計已趨于完結，但是工程實現上仍有未證實的（盡管 Facebook 宣傳，他們已在內部網絡測試 QUIC+HTTP/3）。這也并不僅僅是一個基于瀏覽器的實現，雖然 Apple，Microsoft，Google 和 Mozilla 都在進行 IETF QUIC 的實現工作；我們也有一個基于 Chromium 的 POC 項目。

為時過早

這會成為問題，是因為人們對于 QUIC 的興趣在不斷增強，尤其是最近熱門的 HTTP-over-QUIC 更名為 HTTP/3 后。人們會希望盡快嘗試，有可能使用尚不完善的版本，從而導致低于標準的性能，不完善的安全特性和意料之外的情況等等。他們可能會嘗試去調試這些問題，卻發現幾乎沒有什么工具或框架用來調試。大多數現有的工具都是為 TCP 設計的或是壓根就未涉及傳輸層。此外，QUIC 跨越層級的特性使得調試必須跨層（例如，0-RTT 與 HTTP/3 服務器推送結合）和一些復雜的問題（例如，多路傳輸，前向糾錯，新的擁塞控制等等）。在我看來，這是一個廣泛的問題，以至于我專門寫了一篇文章，請見：文章鏈接。文章里面，我主張采用一個通用日志格式，以允許創建一組可重用的調試和可視化工具，見圖 7。
![07 一個針對 QUIC stream 的可視化工具，用于幫助查看跨資源的帶寬分配和流量控制]

圖 7：一個針對 QUIC stream 的可視化工具，用于幫助查看跨資源的帶寬分配和流量控制

因此，當人們想開始使用它時，存在 QUIC 尚不完善的風險，使得“幻滅的低谷”提前到來，導致大范圍的部署將延遲數年。在我看來，這也可以從 CDN 廠商如何處理 QUIC 中看出：例如，Akamai 決定不再等待 iQUIC，而是在一段時間內測試和部署 gQUIC。LiteSpeed 則對 gQUIC 和 iQUIC 都支持。另一方面，Fastly 和 Cloudflare 只關注 iQUIC。

為時過晚

QUIC v1 來的過早，而 QUIC v2 來的過晚。眾多高級功能（一些為 gQUIC 里的），比如前向糾錯，多路傳輸和部分重傳等因降低整體復雜度的需要而不納入該版本。類似的，HTTP/3 的主要更新并沒有把 cookie 部分考慮進來。我認為，HTTP/3 只是謹慎地將 HTTP/2 映射到 QUIC 上而已，只有少量的改進。

將 QUIC 和 HTTP/3 這兩個概念分開來，是因為 QUIC 是一個通用傳輸協議，可以承載其他應用層數據。但是，我總是很難為此提出具體的例子… WebRTC 經常被提及，還有一個是 DNS-over-QUIC提案 ，但還有其他項目在進行嗎？我想，如果 v1 如果有更多的高級功能，或許會有更多的應用。DNS 提案被推遲到 v2 似乎印證了這一點。

我認為，如果沒有這些新型的功能，很難將 QUIC 推銷給外行。0-RTT 看起來不錯，但可能影響不大，并且也可以用 TCP 實現。低“隊頭阻塞”只有當你的網絡存在大量丟包的情況下才有用。增加安全性和隱私聽起來對用戶很好，但除了主要原則之外，幾乎沒有任何附加價值。Google 搜索速度提高了 3-8%：這足以證明額外的服務器和投入的成本得到了回報嗎？

反對觀點

• 只有當 QUIC 足夠穩定，用戶使用無明顯 bug 時，瀏覽器才會對它進行支持。
• QUIC 調試工作將由那些自己有工具的專業人士進行。
• HTTP/2 存在不少大問題和漏洞，但是依然廣泛應用。
• 即使 QUIC 在頭兩年未得到大范圍應用，但是其價值還在，未來的 30 年我們都將使用 QUIC。
• QUIC v2 很快就會到來，很多工作組在對其各方面特性進行開發。
• QUIC 的靈活性保證了我們可以在應用和傳輸層快速迭代新功能。
• 外行人會隨巨頭公司而動。
• A wizard is never late。

結論

如果你看完前面的內容，到這個結論部分，那么恭喜你！坐下，喝一杯！

我想在此刻，讀者肯定會有有很多不同的感受（除了疲憊和脫水）以及一些 QUIC 合作者可能會感到憤怒。但是，請記住我在開頭所說的內容：這是我以“唱反調”的角度，試圖消除當前關于 QUIC 爭論中的邏輯錯誤。大多數（全部？）這些問題都是標準化 QUIC 的人所熟知的，所有的決定都是在（非常）詳細的討論和論證之后做出的。本文中可能有一些錯誤和不恰當的內容，因為我不是所有子主題的專家（如果你發現了問題，請一定要告訴我）。這也是為什么，QUIC 工作組是由來自不同背景和公司的一群人建立起來的：盡可能多的考慮到各個方面。

話雖如此，我仍然認為 QUIC 可能會失敗。但是，幾率不會很高，不過確實存在。相反的是，我不認為它一開始就可能取得成功，并立即在大公司之外獲得廣泛的受眾。我認為在一開始未能得到大范圍普及的可能性更高，相反，它需要在幾年內緩慢地獲得廣泛的部署份額。這可能會比我們在 HTTP/2 上看到的要慢，但（希望）比 IPv6 的部署更快。

我個人仍然堅信 QUIC（我以我的博士學位打賭）。這是最有可能實際應用的針對傳輸層的首個建設性的改進方案。我非常感激有機會近距離見證 QUIC 標準化和部署。隨著它的發展，我認為它有可能在緩慢的開拓中存活下來，并在接下來的數十年一直保持相當的發展勢頭。那些大公司將部署、調試、改進、開源 QUIC，并在未來的 5年內，QUIC 的占有率將會逐漸超過 TCP。

轉載自:https://bbs.pediy.com/thread-249300.htm
譯文作者：看雪翻譯小組 StrokMitream
原文鏈接：https://calendar.perfplanet.com/2018/quic-and-http-3-too-big-to-fail/

總結

以上是生活随笔為你收集整理的[翻译]QUIC 与 HTTP/3:太过庞大而致失败？-- 论导致 QUIC 失败的因素的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。