HTTP/1.1 与 HTTP/2

Scrapeless Web Unlocker 通过一个 API 获取目标网页内容，从而形成一个提供方边界，客户端应当将其与到目标的连接区分开来。

摘要

HTTP/1.1 和 HTTP/2 共享 HTTP 语义。 它们的主要差异在于消息表示方式和连接使用方式。
HTTP/2 在一条连接上复用多个流。 独立的 HTTP 消息可以在该连接上不受 HTTP/1.1 响应顺序的限制而推进。
HTTP/2 仍然运行在 TCP 之上。 丢包会延迟共享同一传输通道的各个流的数据投递。
协议协商针对每一段连接分别进行。 客户端到提供方使用 HTTP/2 的连接，并不能证明提供方与目标之间也使用了 HTTP/2。

HTTP/1.1 与 HTTP/2 是对 HTTP 消息如何传输的比较，而不是对一次成功资源请求含义的改变。方法、状态码和表示元数据仍然属于同一个 HTTP 模型。连接和分帧机制决定这些消息如何共享传输带宽。

对于一个 Web 客户端，性能取决于远多于协商出的版本这一因素。资源数量、连接复用、服务器行为、网络状况以及应用自身的工作量都会产生影响。在把页面或 API 响应变慢归因于某个协议选择之前，先弄清你在测量的是哪一条连接。

文本消息和二进制帧表示的是同样的工作

HTTP/1.1 使用文本消息结构，包括请求行或状态行、字段以及消息体分帧。该 HTTP/1.1 消息规范定义了接收方如何解析这些消息并确定它们的边界。持久连接允许在一条连接上传输多个请求。

HTTP/2 使用二进制帧和流来表示通信。该 HTTP/2 分帧与流规范定义了消息如何映射到这一结构。二进制表示并不会让应用层的值更加正确，它改变的是协议对这些值的传输方式。

保持表示层边界与应用负载相互独立。同一个 JSON 响应可以通过任一版本传输。该 JSON 的解析错误不能仅仅用线上存在 HTTP/2 帧来解释。将传输分帧、表示解码和业务模式校验视为三个独立阶段，并分别观察各自的结果。

维度	HTTP/1.1	HTTP/2
消息表示	文本起始行和字段	二进制帧与流
单连接上的并发消息	响应顺序限制了流水线化	流被多路复用
首部表示	文本字段	HPACK 压缩的首部块
传输排序	TCP 有序投递	仍然适用 TCP 有序投递
应用含义	共享的 HTTP 语义	共享的 HTTP 语义

多路复用降低了 HTTP 层面的响应顺序约束

HTTP/2 多路复用允许不同流的帧共享一条连接。一个耗时较长的响应不必在另一个流前进之前占满整个应用层响应顺序。在 HTTP/1.1 中，一条连接上的流水线化响应必须遵循请求顺序，客户端通常会使用多条连接来并发处理工作。

这一差异可以帮助从同一源请求多个资源的工作负载。但这并不意味着无限度的并行工作是免费的。服务器会公布限制，多个流共享传输带宽，而应用本身也可能存在瓶颈。遵循客户端和服务器的流控与并发行为。

对于一个采集器，要将 HTTP 并发与业务任务并发区分开来。即便多个流很快完成，它们仍可能输送到一个跟不上的抽取或数据库阶段。在增加并发之前，先测量完整的排队路径。向一个阻塞的处理阶段更快地投递数据，可能会增加内存压力，却无法提升有效记录的处理速率。

HPACK 压缩的是首部而不是响应主体

HTTP/2 使用 HPACK 高效编码首部字段。该 HPACK 首部压缩格式定义了静态表、动态表以及编码规则。重复的首部信息可以比一次次发送相同的文本字段更紧凑地表示。

头部压缩与压缩响应主体是分开的。无论头部表示与载荷编码之间有何区别，服务器都可以通过内容编码来压缩 HTML 或 JSON。在衡量传输字节数时，应分别比较这些层。

不要假设每个响应都同样受益。一条带有大量通用标题的小型重复请求，与一条标题可复用内容很少的大型响应正文，具有不同的特征。如果中间节点更改了连接，那么压缩上下文属于该连接，而不是自动沿整条路径继承。跟踪被测量的链路，避免将所有字节节省都归因于单一特性。

TCP 仍然在 HTTP/2 流之间耦合传输

HTTP/2 复用应用流，但并未消除 TCP 的有序传输行为。如果缺失的传输数据导致后续字节的交付被延迟，那么同一 TCP 连接上的多个流都可能受到影响。这就是为什么应用层复用与传输层队头阻塞行为需要分别加以说明。

效果取决于网络状况和工作负载。承载许多小资源的稳定连接，可能会因为共享容量而获益匪浅。经历丢包的连接则可能表现出不同的权衡。两种观察都不足以证明某个协议在所有路径上总是优于另一个。

避免仅根据单个慢请求就诊断传输层问题。尽可能收集协商得到的协议版本、连接复用情况、各阶段耗时以及相关的服务器观测信息。应用查询耗时过长、DNS 查询延迟和传输丢包都可能增加总耗时，但各自需要不同的解决方案。将结论限定在你的测量实际捕获到的证据范围内。

HTTP 语义与 TLS 是相互独立的层

HTTP 方法和状态含义适用于所有版本。与版本无关的 HTTP 语义提供共享模型。切换到 HTTP/2 并不能解决无效凭据问题、将被禁止的资源变为允许的资源，或确保响应正文包含预期的数据。

TLS 是另一层。HTTPS 部署通常通过 TLS 机制协商使用 HTTP/2，但该协议的二进制分帧本身并不是加密。应根据相关的 TLS 和应用配置来描述机密性和认证，而不是将版本号视为一个完整的安全属性。

应在实际客户端和部署路径中检查兼容性。服务器可能支持 HTTP/2，而特定的库构建或中间层使用 HTTP/1.1。请在环境详情中保留所观察到的协议。源站上的某个功能复选框并不能证明某个特定请求是由哪种协议承载的。

映射代理或提供者工作流的每一个环节

一个中介会创建多个协议关系，而不是一个端到端的版本标签。你的客户端可以与代理或 API 提供者协商一个版本，而该服务在与目标通信时使用另一个连接。一个 CONNECT 隧道在代理传输与隧道内部流量之间又引入了另一层区分。

为无痕网页解锁器，将对 API 的请求与服务提供商的目标检索区分开来。不要根据您在客户端连接上观察到的版本来推断未记录的目标协议行为。网页数据收集中的传输层讨论为分离请求路径的各个部分提供了相关背景。

使用当前无采集定价在规划服务商使用并独立衡量你的客户端连接时要注意。API 接受状态和目标检索结果描述了不同的边界；协商好的协议是与它们并列的另一种观测，而不是对其中任一者的替代。

使用受控工作负载评估该版本

有用的比较应保持请求的内容和验收标准不变。当测量界面公开这些信息时，记录客户端版本和配置、目标、协商协议、连接复用、已耗阶段以及字节数。将连接建立与在已建立连接上重复发起的请求区分开来。

包括真正重要的工作负载：单个 API 响应、包含许多同源资源的页面，或一系列集合请求。针对某一种形式得到的结果不应被泛化到另一种形式。在比较延迟之前，先检查输出是否完整，以防止不完整的响应因为工作量更少而“获胜”。

从客户端支持的默认设置开始，仅在识别出具体约束后再进行调优。检查服务器限制和应用处理情况，同时关注传输指标。启用或优先使用 HTTP/2 的决策应在不削弱兼容性或可观测性的前提下，提升已测得的工作负载表现。保留足够的环境信息，以便在客户端或服务器更新后能够复现对比结果。

结论

当与特定连接和工作负载关联时，HTTP/1.1 与 HTTP/2 的比较才最有用。先理解分帧、多路复用以及头部压缩，再对已部署的客户端路径进行测量。将 TCP 行为、TLS、服务提供方边界以及应用程序正确性区分开来。协议版本是关于传输层的证据，而一个有效的响应仍然是关于任务本身的证据。

准备好定义清晰的检索边界了吗？

通过其已记录的 API 使用 Web Unlocker，并将客户端传输与目标内容和数据验证分别进行评估。

今天注册即可获得 5 美元的免费额度 — 无需信用卡.

领取您的 $5 额度 →

常见问题

HTTP/2 是否消除了队头阻塞？

HTTP/2 通过多路复用的流减少了 HTTP 层面的响应顺序约束，但当传输数据丢失时，TCP 的有序交付仍可能延迟多个流。在描述这一限制时，应将应用层流的行为与传输层的交付区分开来。

HTTP/2 总是比 HTTP/1.1 更快吗？

HTTP/2 并不总是对每一种工作负载和网络路径都更快。资源模式、连接复用、服务器限制以及应用程序自身的工作都会影响结果。请在对你的服务真正重要的环境中，对等地比较完整响应。

HPACK 会压缩 JSON 正文吗？

HPACK 压缩的是 HTTP/2 头字段，而不是 JSON 响应正文。正文压缩使用单独的 content-encoding 机制。在解释传输字节数变化时，应分别衡量头部和负载的行为。

对一个 API 使用 HTTP/2 能证明对目标也使用了 HTTP/2 吗？

与一个 API 建立 HTTP/2 连接并不能证明服务提供方对目标网站也使用了 HTTP/2。提供方边界会形成独立的连接链路。除非服务对外文档化或暴露了目标使用的协议，否则应将目标的协议行为视为未知。