迁移到HTTP2|HTTP协议篇
# 迁移到HTTP2
30 秒速记
- 迁移到
HTTPS后是否继续升级HTTP/2，需要单独评估性能收益与改造成本，不能把两次升级视为同一件事。 HTTP/2是对HTTP协议的重要升级，但题述背景下的推广力度和普及速度低于HTTPS。- 是否值得迁移应结合现有站点瓶颈判断，而不是只依据协议新旧做决定。
- 评估重点应落在升级能带来多少实际收益，以及这些收益能否覆盖部署、兼容和维护成本。
迁移到 HTTPS 后要不要继续升级 HTTP/2，应看真实性能收益能否覆盖部署、兼容和维护成本。 如果页面有大量同源小资源，瓶颈集中在请求排队、头部传输和网络往返，HTTP/2 的多路复用与 HPACK 往往更有价值。若主要耗时来自大图片、后端计算、第三方脚本或弱网丢包，只替换协议的改善可能有限。上线前应通过同内容灰度对比 LCP、排队时间、错误率和延迟，并确认 ALPN 实际协商为 h2。
前面你已经看到了新的 HTTP/2 和 HTTP/3 协议，了解了它们的特点和工作原理，如果再联系上前几天“安全篇”的 HTTPS，你可能又会发出疑问：
“刚费了好大的力气升级到 HTTPS，这又出了一个 HTTP/2，还有再次升级的必要吗？”
与各大浏览器“强推”HTTPS 的待遇不一样，HTTP/2 的公布可谓是“波澜不惊”。虽然它是 HTTP 协议的一个重大升级，但 Apple、Google 等科技巨头并没有像 HTTPS 那样给予大量资源的支持。
直到今天，HTTP/2 在互联网上还是处于“不温不火”的状态，虽然已经有了不少的网站改造升级到了 HTTP/2，但普及的速度远不及 HTTPS。
所以，你有这样的疑问也是很自然的，升级到 HTTP/2 究竟能给我们带来多少好处呢？到底“值不值”呢？
**原理拆解：**迁移判断应从真实瓶颈反推协议收益。若页面包含大量同源小资源，时间主要消耗在连接排队、请求头传输和往返等待上，HTTP/2 的多路复用与 HPACK 往往有效；若主要耗时来自大图片、后端计算、第三方脚本或弱网丢包，仅替换协议可能改善有限。上线还涉及服务器或 CDN 配置、TLS 能力、监控口径和回滚方案，因此应把协议协商成功率与用户体验指标同时纳入验收。
**最小验证：**输入两个分别启用 HTTP/1.1 和 HTTP/2 的测试页面地址，在浏览器控制台运行以下代码，验证资源协商协议以及平均响应时长。两个页面应具有相同内容，并允许通过 Timing-Allow-Origin 暴露跨域性能数据。
const pages = [
"https://h1.example.com/index.html",
"https://h2.example.com/index.html"
];
async function measure(url) {
const samples = [];
for (let i = 0; i < 5; i++) {
const target = `${url}?sample=${Date.now()}-${i}`;
performance.clearResourceTimings();
await fetch(target, { cache: "no-store" });
const entry = performance.getEntriesByName(target)[0];
samples.push({
protocol: entry.nextHopProtocol,
duration: entry.duration
});
}
return {
url,
protocol: samples.map(x => x.protocol),
averageMs: samples.reduce((n, x) => n + x.duration, 0) / samples.length
};
}
Promise.all(pages.map(measure)).then(console.table);
nextHopProtocol 的预期值通常分别为 http/1.1 和 h2，averageMs 只能作为小样本线索，不能直接代表整页收益。正式验证应使用同内容、同地域、同缓存策略的灰度流量，对比 LCP、资源排队时间、连接数、错误率及 p50/p95 延迟。
**边界与排查：**跨域响应缺少 Timing-Allow-Origin 时，部分计时字段可能不可用；缓存命中、CDN 节点差异和 TLS 会话复用也会污染对比。若协议未显示为 h2，应检查浏览器协商结果、CDN 回源链路和服务器的 ALPN 配置，而不是依据配置文件推断升级已经生效。
面试官追问
追问 1架构会上有人看到竞品已启用 HTTP/2，便断言同内容页面切换后 LCP 一定下降，你会如何反驳？
不能由竞品配置推导本站 LCP 必然改善，收益取决于真实瓶颈和请求形态。大量同源小资源、请求头和连接排队更可能受益；若耗时集中在大图片、后端计算或第三方脚本，单纯换协议的效果可能有限。
追问 2你负责给同一套页面做 HTTP/1.1 与 HTTP/2 灰度，除了平均请求耗时，还会要求团队采集什么？
应先用 nextHopProtocol 或链路指标确认实际协商为 http/1.1 与 h2，再比较 LCP、资源排队、连接数、错误率及 p50/p95 延迟。两组必须保持内容、地域和缓存策略一致，否则差异可能来自 CDN 或缓存而非协议。
追问 3测试人员用跨域 fetch 跑了五次样本，averageMs 显示 h2 更快，就要求全量发布，你会批准吗？
不会，五次跨域请求的平均值只能作为线索，不能代表整页或真实用户收益。还要确认响应提供 Timing-Allow-Origin，并控制缓存、CDN 节点和 TLS 会话复用；正式结论应来自同条件灰度的体验与尾延迟指标。
追问 4CDN 控制台显示已开启 HTTP/2，浏览器的 nextHopProtocol 却持续返回 http/1.1，你会沿链路检查什么？
应以浏览器实际协商结果为准，先检查入口的 ALPN 配置、证书终止点及 CDN 边缘是否真正提供 h2。还要核对回源与中间代理链路，避免把控制台开关当成端到端生效证明；必要时结合网络面板和服务端日志定位降级位置。
追问 5存量站点改造成本较高，但页面有上百个同源小资源和明显排队，你会怎样决定是否迁移？
该请求形态与 HTTP/2 的多路复用和 HPACK 收益较匹配，值得先做可回滚灰度验证。决策仍需计入服务器或 CDN、TLS、监控口径和运维成本；只有协议协商率与用户体验指标同时改善，才适合扩大流量。
# HTTP/2 的优点
30 秒速记
HTTP/2保留HTTP/1的语义，已有方法、状态码和应用逻辑通常可以继续使用，迁移重点落在传输实现。- 按题述协议与浏览器实践，
HTTP/2通常运行在至少TLS 1.2和具备前向安全性的ECDHE之上，并可借助False Start缩短握手；具体约束需按实现版本确认。 HPACK压缩重复的请求与响应头，题述数据给出的流量节省约为5%~10%，实际收益取决于头部规模和重复度。- 多路复用让多个请求与响应共享一个
TCP连接并发传输，减少连接资源消耗，提高带宽利用率，也缓解HTTP/1应用层的队头阻塞。 - 流优先级用于把有限带宽优先分给关键资源；服务器推送可省去客户端解析页面后再发起请求的等待。
- 这些优化仍建立在单个
TCP连接上，题述未声称消除了所有阻塞；流依赖和等待仍可能产生延迟。
HTTP/2 保留了 HTTP/1 的业务语义，主要通过头部压缩和多路复用提升传输效率。 HPACK 会压缩重复头字段，而多个请求与响应可以在一条 TCP 连接上交错传输，从而减少连接资源和应用层排队。流优先级可让关键资源先获得带宽，服务器推送也能省去解析页面后再请求的等待，但实际收益取决于链路实现。它仍受单条 TCP 有序传输约束，丢包时可能等待重传，推送也不能只凭协议支持就认定生效。
