此文驳斥了那些认为 QUIC 更快的迷思，逐条分析批判了那些常见的“认为 QUIC 更快”的观点

Laisky's Notes

昨天那篇文章介绍了 QUIC 并不一定更快。这篇文章则更犀利地指出，QUIC 不仅不快，简直慢得要命😂。原生 QUIC 的吞吐只有 TCP 的 27.7%，只有 TCP+TLS 的 42.5%。 https://laisky.notion.site/QUIC-vs-TCP-Which-is-Better-ad3bcd403c2340038a6d761fe70b1984 而从优化的思路可以看出导致 QUIC 慢的主要原因：逐包 ACK、逐包加密、用户态处理导致的额外切换开销。而优化方式也是对症下药，延迟…

此文驳斥了那些认为 QUIC 更快的迷思，逐条分析批判了那些常见的“认为 QUIC 更快”的观点。QUIC 的根本目的是为未来做好一个易于部署和迭代的基座，其当前版本的性能没有任何优势甚至更慢。

https://laisky.notion.site/HTTP-3-Performance-Improvements-Part-2-Smashing-Magazine-bc610b26c95e4d2cb258bfca78f8240d?pvs=4

1. 拥塞阻塞？QUIC 也有
2. 0-RTT？QUIC 最多只能比 TCP 少一个 RTT，而且还极不安全。
3. connection migration？需要大改负载均衡器，而且没太大收益。
4. HoLB？取决于 multiplexer 算法，大部分情况下都比不上串行。
5. 和 TCP + TLS 比？QUIC 的性能远逊于 TLS。

prev: https://t.me/laiskynotes/62

Laisky on Notion

HTTP/3: Performance Improvements (Part 2) — Smashing Magazine | Notion

TL;DR;