HTTP/3

HTTP/3 运行在 QUIC 与 UDP 之上，常用端口是 443，但协议不要求只能使用这个端口。HTTP/2 各流共用 TCP 的有序字节流，缺失片段可能阻塞无关请求的数据交付。QUIC 按流提供有序交付，某条流丢失数据不必阻塞另一条流；连接级拥塞控制与 HTTP 层依赖仍可能影响多个流，不能说每条流都有完全独立的拥塞控制或丢包恢复状态。 仅启用服务器模块还不够。客户端需要 HTTP/3 支持、可代表该源的端点、可验证的 TLS 身份，以及实际可用的 UDP 路径。发现机制和回退策略决定何时尝试它；不能把此前必须成功访问一次 TCP 服务当成所有客户端都要满足的协议前提。 两种传输，一个端口号 UDP:443 与 TCP:443 使用不同套接字，只是端口数字相同；并不是一个套接字同时监听两种传输。nginx 的 server 块可以并列配置 listen 443 quic reuseport; 与 listen 443 ssl; http2 on;。受支持系统上的 reuseport 用于每个 worker 的监听套接字，不是修复重复 server 声明或其他进程占用端口的万能选项。应先核对完整配置、实际错误与套接字归属，再判断是否需要修改。 ...

HTTP/3 把 HTTP 放在 QUIC 上传输，不再依赖 TCP。QUIC 提供逐流有序交付：一条流缺少某段内容时，另一条流已经完整收到的数据不一定必须跟着等待。它解除的是特定的传输顺序依赖，并没有给每个请求配备独立的拥塞控制器、丢包检测器或确定的完成期限。先区分交付顺序和恢复机制，才能准确理解收益。 QUIC 解除一种跨流交付顺序依赖：A 缺字节时，完整的 B 仍可交付。但恢复、带宽、流控与应用依赖并未全部隔离；此排序模型不提供耗时结论。 交付顺序不等于丢包检测 HTTP/2 的帧共享 TCP 的一个有序字节流。中间缺少一段时，后续字节即使属于另一个响应，也要等缺口补齐才能交给 HTTP。已经交付的内容不会被收回，应用也不会因为出现一次丢包就全部停止。究竟影响哪些请求，要看它们的字节相对缺口处于什么位置，不能笼统说整条连接上的所有工作都同时冻结。 QUIC 在每条流内维护偏移量。当 A 流仍缺少前面的字节时，B 流完整收到的数据可以交付。不过，一个 QUIC 包可以携带多条流的帧，因此丢掉一个包也可能同时影响多条流。需要恢复的信息会装进新包再次发送；包编号与流偏移量承担不同职责，并不是每个流各自重新传送一份独立的旧包。 ...