常見的錯誤批評

UDP 在許多公司和組織中無法作用

許多企業，運營商和組織都在端口 53（ 用於DNS ）之外阻止或限制UDP流量，因為此種流量常常被濫用於攻擊。 尤其是一些現有的 UDP 協定和實作容易受放大攻擊（ amplification attack ）的威脅，攻擊者可以控制無辜的主機向受害者投放發送大量的流量。

QUIC 內置了對放大攻擊的緩解處理。它要求初始封包不能小於 1200 字節，並且協定中限制，伺服器端在未收到客戶端回覆的情況下，不能發送超過請求大小三倍的響應內容。

UDP 在內核中很慢

這似乎是個事實，至少在最初的時候是。 我們當然不能說這將如何發展，以及其中有多少僅僅是由於 UDP 傳輸性能多年來未引起開發人員關注的結果。

對於大多數客戶端來說，這個程度的 "緩慢" 從未被覺察到。

QUIC 使用過多的 CPU

與上述 "UDP慢" 類似，部分原因是世界上 TCP 和 TLS 的使用已經有較長的時間來成熟，改進和獲得硬體的幫助，造成 UDP 看上去比較慢。

隨著時間的推移這種情況會有所改善，實際上 我們正在這個領域看到一些改進. 問題在於，這額外的 CPU 佔用部署會對部署人員帶來多大的影響。

只有 Google 在做

事實並非如此。Google 通過大規模的部署證明，通過 UDP 部署這種協定可以正常運行且表現良好，這是 IETF 帶來了初始的規範。

在那之後，很多公司和組織的人員都在這個利益方中立的 IETF 組織下推進標準化。在這個階段，雖然 Google 的員工也有參與，但 Mozilla、Fastly、Cloudflare、Akamai、Microsoft、Facebook、Apple 等等很多公司的員工也參與進來，共同推進網際網路的傳輸層協定。

進步太小

這是一個觀點而非批評。也許進步很小，這可能與相距 HTTP/2 的發布時間點很近有密切關係，時間距離太短了。

HTTP/3 在容易遺失封包的網路中可能表現更好，它提供了更快的交握，所以能改善可感知和實際的延遲。這些進步足夠推動人們在伺服器端和服務上部署 HTTP/3 的支援嗎? 時間以及未來的性能測試將會給我們答案！