HTTP/3 与 Web 性能

浏览器里的页面迟迟没有完成，服务器却报告每次请求只花了几毫秒：这并不矛盾。请求需要经过进程、连接、网络路径和缓存，页面还要等待资源下载与执行。本课用可观察的时间线解释 HTTP/3 的作用，建立从协议选择到用户体验的判断方法。

1 HTTP/3 与 Web 性能要回答什么

设想你在值班时收到反馈：办公网络访问正常，通勤途中打开页面偶尔要等很久。网关的平均响应时间没有明显变化，应用进程的 CPU 使用率也很低。此时应该先问：慢发生在建立连接、等待响应、接收内容，还是浏览器处理内容？如果把这些等待全称为“服务器慢”，后面的优化很容易偏离问题。

HTTP 描述请求与响应的语义，例如方法、状态码和缓存规则。HTTP/2 与 HTTP/3 保留了这些核心语义，但传送数据的方式不同。常见的 HTTP/2 部署使用 TLS 加密并运行在 TCP 上；HTTP/3 使用 QUIC，QUIC 通过 UDP 承载并结合 TLS 1.3 完成安全握手。版本变化首先改变连接如何建立、数据如何恢复以及多个请求如何相互影响，并不自动改变应用进程执行查询的速度。

把页面访问想成若干有依赖关系的工作：先获得文档，解析后发现样式、脚本和图片，部分脚本又会发起请求。即使所有资源都能并行传送，发现得太晚的资源仍然要等。页面完成时间取决于关键依赖路径，不能简单把所有请求耗时相加，也不能只看最快完成的请求。传输协议能缩短某些等待，却无法消除应用自己制造的串行依赖。

先约定几个观测量。RTT 是数据往返的时间尺度；吞吐量表示单位时间实际传送的数据量；TTFB 是从选定起点到收到首个响应字节的时间。不同工具对 TTFB 起点的定义可能不同，引用结果时必须写清。完整下载时间还包括首字节之后的接收过程。页面可交互、关键内容出现等体验指标又包含浏览器工作，不能拿下载结束直接代替。

尾延迟关注慢的那部分访问。例如 p95 表示按耗时排序后，约 95% 的样本不超过该值。平均值下降时，p95 仍可能上升；单个用户需要等待多个关键资源时，遇到某个慢请求的机会也会增加。对于真实网络运营，协议选择应回答“哪些用户、哪些路径、哪个指标改善”，而不是只回答“启用了哪个版本”。

本课把观察范围分成客户端、网络路径、网关和应用进程。客户端记录协商协议与资源依赖；网络侧检查连通性和重传迹象；网关记录接入协议与上游等待；应用记录实际处理耗时。每处证据都要带时间与条件，才能把同一次访问拼起来。仅凭服务器日志没有报错，无法证明途中没有等待。

2 QUIC、多路复用与队头阻塞

HTTP/2 允许在 1 条连接上交错传送多个流。可以把流理解为独立编号的请求与响应通道：大文件尚未发完时，小文件的数据也能穿插发送。这减少了必须为每个资源单独建立连接的需要。不过，HTTP/2 的这些流共享下方的 TCP 字节流。TCP 提供有序交付；如果中间某段数据没有收到，后面已经到达的数据也不能作为连续字节交给上层继续解析。

举例说，连接正在传送样式文件和状态接口。某个 TCP 报文段丢失，后续报文段中即使已经包含完整的接口响应，接收端也要先等待缺口恢复。阻塞发生在传输层有序交付这一处，而不是因为接口进程没有运行。这个现象通常称为 TCP 队头阻塞。HTTP/2 解决了应用层串行排队的一部分问题，却仍然受共享 TCP 字节顺序约束。

QUIC 为不同流分别维护有序交付。HTTP/3 中某个流的数据出现缺口时，其他流已经完整收到的数据通常可以继续交付。因此，大资源上的丢失不必直接卡住所有无关响应。这是理解 HTTP/3 多路复用价值的关键。它不是放弃可靠性：缺失数据仍需要恢复，只是可靠交付的顺序约束不再统一施加到所有流上。

也不要反过来理解为“每个流有完全独立的网络”。多个流依然共享连接的发送能力、拥塞控制约束和路径带宽。丢包可能使连接减少发送，链路拥塞仍会让多个流一起变慢。如果同个 QUIC 数据包装有多个流的数据，丢失也会同时影响其中相关的流。准确的说法是减少跨流的交付阻塞，而不是消除所有跨流影响。

流内部仍有先后关系。某个脚本文件缺少前面的字节，浏览器不能把缺失位置当成不存在；页面必须等脚本执行后才发现接口时，接口也不会因为 HTTP/3 自动提前出现。此外，响应头解码等协议状态依赖在某些情况下也会带来等待。本课只保留这条边界，不展开压缩表或恢复算法内部结构。

在操作系统视角，UDP 只提供数据报传递接口，不替应用保证可靠、有序或加密。QUIC 库在进程侧承担这些协议能力。因此，“UDP 会丢包，所以 HTTP/3 不可靠”是把承载方式与上层协议混为一谈；“UDP 没有连接，所以不需要握手”也不成立。QUIC 仍要建立安全通信状态，确认对端与路径条件。

下面的动画固定资源大小与网络条件，只移动丢失位置。观察响应已经到达与响应可以交付之间的区别，再比较不同流的等待范围。这个模型帮助定位机制，不代表所有实际网络都会获得相同收益。低丢包、低 RTT 的路径上，跨流阻塞可能根本不是主要成本。

3 TLS 握手、0-RTT 与连接迁移

请求传送之前通常要先解析域名、找到网络路径并建立安全连接。这里的握手是在双方之间交换必要信息、建立后续通信状态的过程。传统的 HTTP/2 接入通常先建立 TCP，再进行 TLS 握手；QUIC 把传输与 TLS 1.3 的握手配合起来，可以减少新连接开始发送请求前的往返等待。实际节省多少，还取决于是否已有连接、是否恢复会话、是否发生重试以及客户端如何找到 HTTP/3 入口。

第一次访问某站点，浏览器可能先通过其他协议取得 Alt-Svc 响应头，知道该站点还提供 HTTP/3 服务；有些环境也能通过 DNS 的 HTTPS 记录获得相关信息。因此，第 1 次访问没有使用 HTTP/3，并不能单独证明服务配置失败。反过来，看见 Alt-Svc 也只说明服务通告了入口，不说明本次请求已经通过该入口完成。最终应检查实际连接或请求记录。

0-RTT 指在满足恢复条件时，客户端可以更早发送应用数据，不必等待本次完整握手结束。它需要以前建立的会话信息和服务端支持，不是首次访问就有的功能，也不等于网络耗时为 0。服务端还可能拒绝早期数据，客户端随后继续正常流程。评估时应把恢复成功、恢复失败和全新连接分开，否则平均结果容易掩盖条件差异。

早期数据有重放风险：攻击者可能让某段早期请求被服务再次看到。因而不能把所有请求都交给 0-RTT。读取静态文件通常比执行状态变更容易制定安全策略，但仅凭 GET 方法也不能保证没有副作用。系统应明确允许的路径与处理规则；会修改配置、触发任务或扣减配额的操作，需要根据业务语义处理，不能靠协议名称替代判断。详细防护设计留到后续安全课程。

连接迁移解决另一类等待。设备从无线局域网切到移动网络时，地址或端口可能变化。QUIC 使用连接标识帮助关联已有连接状态，在实现与部署支持、并完成必要路径验证的情况下，可以继续使用连接。这样就有机会减少重新建立连接带来的停顿。它不是任意更换目标服务器，也不保证切换时完全无感：验证、丢包和新的 RTT 都可能造成短暂停顿。

网关部署需要配合这种行为。如果负载均衡只按源地址与端口把数据送往不同后端，迁移后可能落到不认识该连接的进程。连接标识、转发规则与进程生命周期之间要有一致安排。本课不展开具体路由算法，但要知道客户端支持迁移并不足够。中间设备过滤 UDP、路径变化后无法到达相同服务，都可能让连接迁移无法完成。

排查握手问题时，应先区分“根本没有收到 UDP 回包”“安全握手失败”和“握手成功后应用报错”。它们分别指向连通性、证书或协议配置、应用处理等不同范围。浏览器报出的笼统连接错误只是起点。把失败阶段写清，才能避免用修改应用超时去掩盖网络入口配置问题。

4 动手：对比一次 HTTP/2 与 HTTP/3 时间线

选择自己可控制的测试站点，在相同主机名下提供固定文件，例如 /probe.bin，使 HTTP/2 与 HTTP/3 都指向相同内容。使用测试环境，记录文件大小、缓存头和内容摘要，避免把内容变化当成协议差异。先在 shell 运行 curl -V，确认当前构建是否列出 HTTP2、HTTP3 等能力。系统自带的 curl 不一定支持 HTTP/3，选项不存在与服务器拒绝连接是不同故障。

以下命令中的域名需要替换成测试站点。-o /dev/null 丢弃下载内容，-sS 保留错误输出，--max-time 避免等待无限延长。这里使用 shell 变量组织相同输出格式，时间单位为秒。失败时同时查看错误信息与退出码，不能把空值或未完成连接的数值当作成功样本。

probe_url='https://test.example.net/probe.bin'
probe_fmt='version=%{http_version} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total} bytes=%{size_download}\n'
curl -sS --max-time 20 --http2 -o /dev/null -w "$probe_fmt" "$probe_url"
curl -sS --max-time 20 --http3-only -o /dev/null -w "$probe_fmt" "$probe_url"

--http2 请求使用 HTTP/2，但结果仍应检查 version；协商条件可能使实际版本不同。支持该选项的 curl 中，--http3-only 可以用来观察仅尝试 HTTP/3 的结果；它失败时有助于暴露 HTTP/3 路径问题。正常用户访问还需要另外测试允许回退的行为，因为严格测试的失败不等于浏览器最终无法打开页面。不要用关闭证书验证来消除握手错误。

这些时间大多从操作开始累计，不能直接当成彼此独立的阶段长度。对于常见 TCP 加 TLS 的测量，差值有助于理解连接与握手区间；在 QUIC 中两者互相关联，curl 版本对时间点的报告也有差异，不应机械套用相同减法。TTFB 的 first 包括此前连接等待与首字节前等待，无法单独推出应用处理耗时。total 与 first 的差更接近首字节后的接收区间。

单个文件只能初步观察握手与下载，无法直接证明多路复用的收益。接着在浏览器打开含多个独立资源的测试页，在开发者工具网络面板显示协议列与瀑布图，确认请求是否共享连接，标出文档、样式和接口的起止时间。使用新浏览器配置或明确的缓存控制区分冷、热条件；禁用内容缓存并不必然清除连接、DNS 或会话恢复状态。

重复访问时交替安排协议组，保留时间、路径、实际协议、成功与失败记录；不要只挑最快的结果。真实页面还要注意后台标签、扩展与 Service Worker 的影响。若需要复现丢包或限速，使用隔离实验环境中的网络仿真工具，并记录作用范围。浏览器开发者工具的网络限制不一定等价于真实链路丢包，更不能据此宣称已验证 TCP 与 QUIC 的恢复差异。

5 缓存、压缩与关键优先级的取舍

传输层减少等待的前提，是这些数据确实需要传送。对可长期复用的静态资源，命中本地缓存往往比更换传输协议带来的收益更大。内容带版本标识、缓存策略正确且尚未过期时，浏览器可以直接复用；需要重新验证时，仍可能发出条件请求，即使最终收到 304，也付出了网络往返。讨论缓存收益时，要把本地命中、重新验证与完整下载分别记录。

配置文件系统里的资源时，应让发布流程和缓存策略配合。带内容版本的脚本可以有较长新鲜期；引用它的文档则需要合适的更新策略。若路径不变却长期缓存，用户可能持续运行旧脚本；若所有内容都禁止缓存，每次访问又要重复消耗网络。HTTP/3 不会自动纠正缓存头，网关或浏览器缓存中的错误副本也不会因为协议更新而变正确。

压缩减少传输字节，但需要编码与解码工作。文本样式、脚本和结构化响应常有压缩空间；已经压缩的图片或归档再次压缩，收益可能很小。可以为静态文件预先生成压缩版本，减少运行时 CPU 消耗。动态响应则要观察进程负载与排队：如果压缩让工作进程忙于计算，首字节反而可能更晚。不同内容编码的缓存变体也要正确区分，避免发送客户端不能处理的内容。

优先级处理的是“有限发送机会先给谁”。页面顶部样式、关键字体或决定首屏内容的接口，可能比屏幕之外的大图更急。浏览器的资源发现顺序、优先提示、网关排队与服务器实现会共同影响结果。优先提示不是强制完成顺序的保证。即便 HTTP/3 允许多个流独立前进，若关键资源很晚才被发现，或发送队列充满不急用的数据，用户仍然会等待。

可以从可控的 3 件事入手：让关键资源更早被发现，减少关键路径上的字节量，避免后台大资源抢占紧张链路。不要把所有资源都标成最高优先级；当所有请求都声称紧急时，标记便失去区分作用。也不要为了减少请求数，把互不相关的内容全部塞进巨大文件，因为任何小变更都可能导致整包重新下载，并延后真正需要部分的使用时机。

下面的滑块把网络速率与压缩耗时显式摆出来。文件原始大小固定，压缩比固定时，网络越慢，减少字节越有价值；网络越快，额外编码成本越显眼。它只计算单个资源的简化耗时，不模拟并发排队、浏览器渲染或真实拥塞控制。因此可以用它练习提出假设，不能把图中的交点当成线上配置的通用阈值。

实际决策要回到同批用户的完整时间线：缓存是否命中，内容大小是否真的减少，进程是否新增排队，关键内容是否更早出现。缓存、压缩、优先级和传输协议作用在不同位置，可以相互补充，也可能相互掩盖。只有把变化位置标清，才能知道某次“升级变快”究竟来自哪里。

6 常见坑：只看 TTFB 忽视尾延迟

假设新配置让多数请求首字节提前了，但偶尔出现大文件下载停顿。面板只展示平均 TTFB，就可能报告显著提升；用户却仍在等待页面所需的最后资源。TTFB 对握手与服务响应有价值，但不覆盖响应后半段的丢失恢复、传输停顿和资源执行。指标不是越多越好，而是要覆盖用户任务真正依赖的几个阶段。

另一个常见错误是只统计成功请求。UDP 被某段网络过滤时，部分客户端可能等待 HTTP/3 尝试超时后才回退。最终的 HTTP/2 请求很快，如果日志只记录这条成功连接，就会漏掉用户此前的等待。统计必须说明起点，并保留连接失败率、回退比例与回退前等待。服务端完全没有收到的请求，需要客户端观测来补足。

尾分位数需要足够样本。拿 10 次访问就写 p99，无法稳定刻画罕见停顿；拿不同时间段的 p95 直接平均，也不能得到全体请求的 p95。应保存可合并的分布或原始耗时，并说明样本量与窗口。比较协议时还要防止样本偏差：成功使用 HTTP/3 的用户可能本来就有不同网络条件，不能把所有 HTTP/2 用户都当作随机对照组。

日志关联也容易出错。网关记录的请求耗时通常从它接收请求的某个时刻开始，不包含客户端此前的全部等待；应用日志又可能只覆盖处理函数。跨主机时间戳如果没有合理同步，会让阶段顺序看似矛盾。优先使用每个观测点自己的耗时，再通过请求标识和明确阶段关联，避免拿不同机器的时间戳随意相减。

在 Linux 测试机上，ss -tn 可以查看 TCP 连接，ss -un 可以查看 UDP 套接字相关信息，但 UDP 行数不等于 QUIC 连接数。用 ss -lun 检查 UDP 监听时，进程信息还受权限影响，不能因看不到进程名就断言服务未运行。抓包可确认地址、端口与数据报往返；加密流量本身通常不能直接显示请求路径和完整应用耗时。

排障时按顺序收敛：先检查实际协议，再确认失败发生的阶段，然后对照资源依赖、网关和应用记录。HTTP/3 路径不通时查 UDP 入口、回程和映射；连接正常但多资源同时停顿时检查共享带宽与发送限制；只有某类接口慢时再看上游处理和资源竞争。不要看到 UDP 就调整 TCP 参数，也不要看到网关返回 200 就停止调查。

这里的“尾”也包含运营边界。少量网络长期无法完成连接，比多数访问节省几毫秒更值得关注。发布评估应同时设定体验目标与失败上限，观察改动是否把成本转移给某类用户。只有成功率、完整耗时与关键内容体验共同改善，才能认为优化对目标场景有效。

7 案例：队头阻塞拖垮接口尾延迟

某内部设备监控页会同时下载趋势图资源，并轮询状态接口。办公室访问稳定，远程值班人员偶尔发现状态区域迟迟不刷新。应用处理记录显示，状态接口通常在 8 毫秒内生成响应；调整应用进程数量后，问题没有明显变化。团队决定先保留应用配置，关联浏览器瀑布图、网关请求记录和测试网络条件。

初步证据显示，较慢的状态请求经常与趋势资源下载重叠，并使用同条 HTTP/2 连接。应用侧处理已经结束，浏览器却晚得多才获得可用响应。这支持“等待可能在应用之后”的方向，但还不能直接证明 TCP 队头阻塞，因为共享带宽、代理缓冲与客户端处理同样可能造成类似现象。团队需要可重复、能区分假设的实验。

他们在隔离测试网络提供固定的大资源与小接口，确保接口不访问外部服务，并让 2 类请求共享连接。先测稳定路径，再引入受控丢包，固定 RTT 与带宽。比较时保持响应内容、压缩、缓存状态和应用进程配置一致。通过客户端与传输观测确认：部分停顿中，缺口后的数据已经到达，而接口数据交付仍在等待 TCP 恢复。

下面是一组教学示例，数值用于说明结果应如何组织，不是对真实协议收益的承诺。每组包含 2000 次接口请求，结果以客户端完整接收接口响应的耗时计算。真实实验还应报告测试环境、失败数量和分布随时间的变化，不能只摘出这张表作为结论。

HTTP/3 组的尾部等待缩短，符合减少跨流有序交付阻塞的机制预期；p50 变化很小，也说明收益集中于部分事件。HTTP/3 的 p99 仍明显高于稳定路径，是因为丢包恢复、共享发送能力和路径波动还存在。不能从这组数值推导出“接口永远不受大文件影响”，也不能把所有改善都归因于某个算法参数。

团队还做了 2 类对照：暂停大资源传输，观察接口尾部是否收敛；保留大资源但去掉受控丢包，观察停顿是否显著减少。它们与协议对比共同加强了因果判断。如果这些对照都没有变化，就应退回证据链，继续检查代理缓冲、接口自身排队或浏览器主线程工作，而不是坚持最初解释。

最终方案同时减少非关键趋势资源体积，并对支持的客户端开放 HTTP/3。上线后按网络类型观察实际协议、回退等待、接口完整耗时和页面状态更新时间。对于无法使用 HTTP/3 的路径，仍保留正常服务能力。这个案例的可迁移经验是：先找出等待发生的位置，再用匹配条件的对照验证机制，最后选择能改善用户任务的组合改动。

8 把传输层假设写进前端与网关方案

方案里写“支持 HTTP/3”只描述了能力，没有描述目标。更可执行的表达是：在多资源并发、较高 RTT 或存在丢包的目标网络中，减少关键接口的尾部等待，同时保持连接成功率和回退体验。接着列出必须成立的假设，例如客户端确实支持协议、UDP 入口可达、证书有效、接入网关启用了相同资源服务。这些假设都应有对应的验证方法。

前端需要给出资源依赖与缓存策略，标记真正影响用户操作的资源。若状态接口必须等大脚本执行才发出，应先解释这段依赖；如果图片下载与接口争用网络，可以延后屏幕外资源。传输层优化无法代替减少不必要请求，但也不应因为应用还能优化就忽略明确的传输等待。把各改动对应的耗时区间写清，有助于分别验收。

网关侧要列出 TCP 与 UDP 接入范围、证书、HTTP/3 通告方式、空闲超时和回退策略。常用的 HTTPS 端口号相同，并不表示 TCP 443 放通就同时允许 UDP 443。健康检查也应覆盖实际协议路径；只用 TCP 探活，可能在 UDP 服务失效时仍显示健康。发布时应验证真实请求能够完成，而不只是确认进程启动和套接字监听。

还要明确协议在哪终止。浏览器到网关使用 HTTP/3，网关到应用可能仍使用 HTTP/2 或其他协议。外部连接改善不能证明内部链路没有排队；内部应用报错也不能简单归为 QUIC 故障。观测记录中应分别标识客户端接入协议与上游协议，并通过请求标识把它们关联，避免把分段行为拼成不存在的端到端协议。

容量评估同时看带宽、CPU、内存和连接状态。QUIC 实现常在用户态进程中工作，加密和恢复处理也会消耗资源；某些部署里，更高连接量可能改变网关 CPU 与内存压力。没有必要预先认定它更贵或更便宜，应该在代表性负载下测量。进程重启、滚动更新和配置热加载时，已有连接如何结束，也会影响用户看到的停顿。

发布可以逐步扩大流量，但要记录分组方式，避免只对网络条件较好的客户端试验后宣布全体受益。验收指标应包含实际协商比例、连接失败率、回退耗时、完整响应尾分位数和关键内容体验。停止条件也应写成可观察行为，例如目标网络失败率明显超出原有水平，或网关资源持续饱和，而不是凭某张平均值曲线判断。

如果需要退回原配置，应检查通告缓存与已建立连接的影响。停止新通告不一定让所有客户端立刻忘记旧入口；回滚方案需要考虑客户端仍尝试旧地址的时间窗口。保持可解释的兼容路径，核对回滚后的实际协议与成功率，才能让“可回滚”从文档承诺变成可以操作的步骤。

9 从 Web 性能走向数据中心网络硬件（H35）

到这里，我们主要从浏览器、网关与进程观察传输等待。但字节最终仍要经过主机网卡、链路和交换设备。HTTP/3 改变数据组织和恢复方式，没有创造额外物理带宽。当同条出口已接近容量，或大量响应在某个端口前排队时，多个流仍会共同等待；这正是继续理解数据中心网络硬件的入口。

可以把端到端问题拆成 3 个尺度。应用尺度关注请求依赖与处理；连接尺度关注握手、流和恢复；路径尺度关注链路容量、设备队列与转发。它们互相影响，但证据并不等价。页面尾延迟变高不能直接证明交换设备故障，网卡字节计数增加也不能直接证明应用得到更高有效吞吐。必须先说明每个指标覆盖的范围。

例如多台服务器同时向同个接收点返回数据，平均流量未必持续很高，却可能在短时间集中到达。若某处可发送的速率跟不上到达速率，就会形成排队，进一步带来延迟或丢失。这个直觉足以解释为什么只看长时间平均带宽可能漏掉问题。具体队列结构、硬件转发细节和突发处理方法，留给 H35 展开。

本课可以先练习朴素观察：在 Linux 上用 ip -s link 查看接口统计，通过多次采样理解计数变化。某个接口的丢弃计数上升，只能说明该观测点出现了相应事件，不能自动定位到整条路径中的某台设备。统计口径、接口选择和采样窗口都需要注明。容器、虚拟接口与物理网卡可能展示不同范围，不能把它们的字节数直接相加作为业务流量。

同样，浏览器里观察到 HTTP/3 偶发停顿，应先检查是否为连接恢复、回退或资源依赖，再决定是否需要沿路径继续调查。客户端、网关与网络设备的证据可以逐层补充，不能相互替代。如果暂停大文件后接口恢复平稳，说明存在资源竞争线索；竞争发生在客户端接入、服务器出口还是中间链路，仍要进一步定位。

进入 H35 时，请带着明确的问题：数据从进程交给网络后，会在哪些地方等待？每处等待有哪些可见计数？当协议层已经减少跨流阻塞，剩余尾延迟是否来自共享路径容量？这样学习网卡、交换机和链路时，就能把硬件能力连接到页面体验，而不是只记住接口速率和设备名称。

放进方案里

把“启用 HTTP/3”改写成可以验收的变更说明：目标是改善远程监控页在多资源并发与不稳定网络下的状态更新时间，重点比较接口完整耗时的 p95、p99，同时约束连接失败率与回退等待。基线记录包括样本窗口、客户端类型、网络条件、实际协议和缓存状态，避免用协议标签代替实验条件。

前端负责人提供关键资源依赖图，确认状态请求何时被发现，列出可以缓存、压缩或延后加载的内容。网关负责人确认 UDP 入口、证书、通告、超时与上游协议，说明进程重启对已有连接的影响。应用负责人保留处理耗时与请求标识，使客户端等待能够与服务器执行区间对应。每项假设都写出证据来源和失败时的处理办法。

验证先在受控环境对比相同资源与负载，分别观察稳定路径、较高 RTT 和受控丢包；再用代表性流量检查实际协商、失败、回退以及网关资源占用。结果同时呈现成功请求分布和失败数量，保留冷连接与复用连接的区别。若只改善首字节，却没有改善关键内容出现时间，应重新检查下载后半段和浏览器依赖。

发布按可解释的分组逐步扩大范围，并约定负责人、观察窗口与停止条件。回退时保留可用入口，考虑已缓存的协议通告与现有连接，验证客户端最终成功访问所需的完整等待。上线后把剩余问题归到资源依赖、应用处理、连接机制或共享路径，再决定后续投入。这样的方案既能说明预期收益，也能让值班人员在失败时找到下一条可执行的检查动作。

10 小结：下一步数据中心网络硬件（H35）

HTTP/3 使用 QUIC，在保持 HTTP 语义的同时，减少不同流之间由传输层有序交付引起的阻塞，并提供新的握手与迁移能力。它的收益有条件：共享带宽、应用依赖、缓存错误和处理排队仍然存在。

自测时试着回答：接口进程已经完成，为何浏览器仍可能等待？为什么首次访问不能假定具有 0-RTT？为什么 HTTP/3 组的平均 TTFB 改善，还不足以支持全面发布？如果能把每个答案对应到实际协议、时间线和失败记录，就具备了继续排查的基础。

下一课 H35 将沿着字节经过的路径，认识网卡、交换设备与链路容量，继续解释协议之外的排队与竞争。