临时禁用 HTTP/2 的运维代价

临时禁用 HTTP/2 看起来只是加一个参数的事，实际代价往往在流水线跑起来之后才浮现。它属于典型的“止血有效、长期昂贵”的处置手段：能立刻让受影响的客户端脱离漏洞触发路径，但代价是把整个上传链路的传输模型从多路复用退回单连接串行。

代价首先体现在连接层。HTTP/2 允许在同一 TCP 连接上并行多个流，禁用后每个并发上传都需要独立握手，TLS 协商次数随并发数线性增长。对于大批量小文件上传的场景，握手开销和首字节延迟的占比会明显上升，单位时间内可完成的产物推送数量随之下降。这不是理论推测，而是协议降级的直接结果。

其次是超时与重试语义的变化。HTTP/2 的流级错误可以在连接内被隔离处理，而 HTTP/1.1 下连接一旦异常，往往影响该连接上正在进行的整个请求。CI 任务中常见的并行上传、分片推送，在降级后更容易出现整体重试，进而放大对制品库的瞬时压力。

第三层代价在运维可观测性上。团队为了规避漏洞，通常会在脚本、自研客户端初始化代码和构建节点配置中分别注入降级设置，这些散落的开关很难统一管理。一旦后续升级完成，忘记回收这些配置，就会让流水线长期停留在低效模式，而没人意识到性能基线已经偏移。

因此，临时禁用 HTTP/2 的定位应当是明确的过渡措施，而不是解决方案。合理的做法是：先确认漏洞版本与上传场景的真实可达性，再决定哪些链路需要降级、哪些链路可以维持原状；同时把降级配置集中管理并标注失效条件，配合版本升级和回归验证，在确认补丁生效后尽快移除。否则，安全上的短期收益会被长期累积的交付效率损耗抵消。