# 常見的錯誤批評

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

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

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

## UDP 在內核中很慢

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

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

## QUIC 使用過多的 CPU

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

隨著時間的推移這種情況會有所改善，實際上 [我們正在這個領域看到一些改進](https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency). 問題在於，這額外的 CPU 佔用部署會對部署人員帶來多大的影響。

## 只有 Google 在做

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

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

## 進步太小

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

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