HTTP/3 把 QUIC 跑在 UDP:443 上，值得在意的理由是丢一个包的代价。TCP 连接上所有流共用一个字节流，丢一个段就会挡住它后面所有数据的交付，直到重传到达。QUIC 让每条流各自拥有丢失恢复，同一个丢包只挡住数据真的在那个包里的流。 别扭的地方在于这不是一个开关。客户端必须先知道服务器会说 HTTP/3 才可能去试，而它得知这件事所走的那条路径，恰恰是你想优化的那条。 两种传输，一个端口号 UDP:443 和 TCP:443 属于彼此独立的命名空间，所以一个监听可以同时占住两者。这就是为什么 nginx 的 server 块可以把 listen 443 quic reuseport; 和 listen 443 ssl; http2 on; 并排放着，用同一个端口号同时服务 QUIC 和 HTTP/2。reuseport 比看起来更重要：没有它，第二次绑定 UDP:443 会拿到 EADDRINUSE，而这正是两个 server 块都声称要占用 QUIC 监听时看到的报错。 ...
下一代 HTTP 从 TCP 转向 QUIC——一种在 UDP 之上、自带可靠性机制的传输。收益是:一条流上的丢包,不再像 TCP 上的 HTTP/2 那样卡住整条连接。 为什么 TCP 是上限 HTTP/2 在一条 TCP 连接上多路复用许多流,但 TCP 本身只认得一条字节流。一旦丢包,TCP 必须重传,并按字节序补好,这条连接上的所有流都要等它恢复完毕才能继续。这正是 HTTP/2 从它的传输层继承下来的那块队头阻塞。要让某个流不拖累邻居,办法不是修 TCP,而是换一种传输:给每条流各自的可靠交付,对方的序号不再和整条连接绑在一起。HTTP/3 要拆的,正是这层天花板。 QUIC 换了传输,没换语义 HTTP/3 继承了 HTTP/2 的大多数设计——多路复用、头压缩、流优先级——但把它们跑在 QUIC 上,而 QUIC 是坐在 UDP 之上、自带安全设计的传输。它实现了逐流的流控与丢包恢复、自带加密,还能在网络路径变化时迁移连接——这些都是 TCP 做不到的。对应用来说语义几乎不变:同样是方法、URL、状态码。真正移动的是字节被保护的方式、连接是哪一层维护的,而这正是让「一条流丢包不再拖垮整页」的机制所在。 何时它最要紧 逐流恢复的回报在丢包严重的路径上最明显:移动网络信号不稳、高延迟的末段链路、以及链路质量差的跨区网络——正是当年一条停滞的流就能把整页拖住的地方。这又是一种协商式升级,客户端与服务器都同意才启用;不支持 QUIC 的地方自动回落 HTTP/2,网站方不需要任何操作。所以往前滚是渐进而兼容的:部署风险低,收益又恰好集中用户最敏感的那一路——不稳定的连接上。 ...