HTTP/1.1 与 HTTP/2：帧、复用和性能

介绍

HTTP/1.1 和 HTTP/2 通过不同的线缆格式传递相同的应用语义。GET 仍然是 GET，状态码保持其含义，URI 标识相同的资源。主要变化是消息如何共享连接。

HTTP/1.1 在每个连接上序列化文本消息。HTTP/2 将消息拆分为分配给流的二进制帧，允许在一个连接上进行许多交换。这消除了几个 HTTP 层的调度限制，但两个版本仍然依赖于 TCP，因此共享一些传输行为。

文本消息与二进制帧

HTTP/1.1 定义了开始行、文本字段、空行和可选内容。消息长度通过如 Content-Length、传输编码、连接关闭或方法和状态语义等规则确定。如果实现对边界的理解不一致，解析错误可能会导致连接不同步。

RFC 9112 定义 HTTP/1.1 消息传递。HTTP/2 用类型化的二进制帧替换了文本线缆语法。HEADERS 和 DATA 帧通过编号流传递消息，而控制帧管理设置、流和连接状态。

并发和复用

HTTP/1.1 连接通常保持响应顺序，因此客户端打开多个连接以获得并行性或使用经过仔细控制的流水线。每个额外连接都有设置和资源成本，浏览器限制它们的使用频率。

HTTP/2 在一个 TCP 连接上复用流。缓慢的响应不必阻塞 HTTP 层的后续响应，因为它们的帧可以交错。 HTTP/2 规范 还定义了每个流和连接的流控制，以便接收方可以限制在飞行中的数据量。

使用 HPACK 进行头压缩

Web 请求重复字段名称和值，例如 cookies、用户代理、内容类型和缓存指令。HTTP/1.1 在每个请求中发送它们的文本形式，仅在不同层面上受到其它压缩的限制。

HTTP/2 使用 HPACK 对带有静态和动态表的头列表进行编码。重复的值可以变为紧凑的引用，而敏感字段可能被标记以避免索引。压缩状态属于连接，因此中介不能简单地拼接任意流而不参与协议。

TCP 首行行为

HTTP/2 解决了 HTTP 消息之间的顺序压力，但每个流仍然共享一个可靠的 TCP 字节流。如果 TCP 段丢失，则直到修复间隙后，后续字节才能送达 HTTP/2 层，因此不相关的流可以一起暂停。

这种区别解释了为什么复用是有价值的，而不是魔法。在干净、低延迟的路径上，一个活跃的连接是高效的。在丢失的情况下，一个活跃流组可能共享一个停滞。HTTP/3 将传输映射更改为 QUIC，因此丢失恢复可以按流隔离。

兼容性和协商

HTTPS 客户端通常在 TLS 握手期间通过 ALPN 协商 HTTP/2。如果双方都选择它，则应用程序使用 HTTP/2；否则，它可以继续使用 HTTP/1.1。这使得部署主要成为边缘、服务器和客户端配置任务，而不是 API 重新设计。

旧版中介和专用客户端可能仅支持 HTTP/1.1。保持回退健康，保留正确的 Host 和授权路由，并确认可观察性工具能够解码协商的版本。 MDN 的 HTTP 演变指南 将版本放在它们的部署上下文中。

HTTP/2 最有帮助的地方

HTTP/2 倾向于帮助对同一来源发出许多请求、重复大头集合或遭受连接设置开销的页面和 API。它还为服务器提供了更清晰的流模型，以进行流控制和取消。

单个大下载可能几乎看不到好处。较差的优先级、缓慢的应用处理程序、缺失的缓存、超大内容或负载过重的来源可能主导协议收益。在将性能变化归因于仅 HTTP/2 之前，测量协商协议、首次字节时间、传输时间、连接重用、丢失和服务器饱和。

HTTP/1.1与HTTP/2验证计划

HTTP语义保持稳定。应用程序通常不会为HTTP/2重写路由或方法。在整个生产路径中验证该声明。从一个小的代表性交换开始，记录客户端和边缘协商的行为，确认应用程序通过与实际流量相同的网关、代理、证书终止点和网络策略接收它期望的字段、帧或事件。

将第一个设计假设转化为失败演练：在TLS边缘启用HTTP/2。然后检查关于第二个假设的资源压力：保持HTTP/1.1回退测试。正确的实现应该在记录的限制内失败，释放连接和缓冲状态，并留下一个解释结果的痕迹，而不暴露凭证或私有负载。

资产重型页面和API网关测试设计的不同部分，因此兼容性测试应包括相关的两种流量形状。添加当前浏览器、非浏览器客户端、较慢的网络路径和支持的最旧中介。记录版本选择、连接生命周期、消息或响应年龄、队列深度和首选路径及其回退的关闭原因。

在测试期间将语义和传输视为独立层。成功的连接并不证明应用程序正确处理了排序、授权、取消、缓存、重放或状态恢复。同样，应用程序错误并不证明协商的协议失败。用资源、用户范围、逻辑操作和连接标识符标记观察，然后比较每个端点认为发生了什么。这种分离使容量工作更加有用：团队可以看到延迟是否来自连接建立、网络传输、排队、应用程序处理、序列化或慢接收者。在常规遥测中避免私有内容，同时保留足够的时序和结果数据以重现决策。

HTTP/1.1与HTTP/2在实践中的出现

HTTP/1.1与HTTP/2生产检查表

• 在TLS边缘启用HTTP/2。 将这一点转化为书面的接受测试，以便审阅者区分预期行为与意外实现细节。
• 保持HTTP/1.1回退测试。 命名拥有设置的组件和当其观察行为变化时作出响应的人员或团队。
• 确认诊断中的ALPN协商。 在日志或追踪中捕获相关信号，然后验证该信号在真实路径中的每个代理、网关和服务边界中存活。
• 删除仅为旧连接限制而添加的域分片。 用正常案例、慢速对等体、关闭连接、超大输入以及版本或能力不匹配来测试决策。
• 测量每个来源的请求并发性。 记录安全默认值和允许例外的确切条件；隐藏的例外在后续变更中会成为互操作性问题。
• 观察流和连接流控窗口。 从代表性浏览器或客户端检查此行为，而不是仅依赖本地单元测试或服务器端配置屏幕。
• 保持头部大小在记录的限制内。 设置有限的资源限制，使得结果拒绝对操作员和调用的应用程序可见。
• 验证使用二进制框架的中介。 保留足够的标识符以关联客户端、边缘、应用程序以及任何异步工作者之间的一个逻辑交换。
• 将数据包丢失与多流停滞相关联。 在流量形状变化后审查选择，因为连接计数、有效负载大小和消息频率可能会改变正确的设计。
• 比较推广前后的实际工作负载。 保持回退路径可观察和经过测试，以便兼容性不依赖于已经静默停用的旧路径。

结论

HTTP 语义保持稳定。应用程序通常不会为 HTTP/2 重写路由或方法。HTTP/2 不是一个普遍的速度保证。负载形状、延迟、丢包、服务器调优和缓存决定结果。将这两个事实与明确的限制、可观察状态及经过代表性客户端测试的回退相结合。

参考文献

• Scrapeless Scraping Browser 文档
• Scrapeless Scraping Browser 产品概述
• Scrapeless WebSocket 帧捕获指南