摘要

  • Incremental: ?1 是发送方对单条 HTTP 消息提出的意图：中间节点在收完整条消息前就开始向下游转发。请求与响应各是独立消息，双向都需要增量传递时，两边都必须带字段。
  • 理解字段的中间节点若明确拒绝增量转发正文，就必须返回错误，不能悄悄收全后再转发。内容检查不兼容建议用 501 与 incremental_refused；并发容量不足建议用 429 与 connection_limit_reached。
  • 这不是端到端流式承诺。不了解或不支持字段的节点仍可能缓冲；支持字段的节点也可采用有字节或时间上限的缓冲。证据必须连接消息方向、各节点识别与策略、阈值、错误语境和实测时延。

设想一段交互：客户端持续上传，服务器已经能够提前返回结果；某个代理却等待完整请求，另一个代理又等待完整响应。双方都在等对方先收到数据，应用层于是停住。最后若消息终于一次性到达，普通成功状态甚至会掩盖这次失败——数据到了，却没有在需要的时间到。

RFC 10036《HTTP 消息增量转发》正面处理这条时间属性。它于2026年8月作为 IETF 提议标准发布，作者是 Kazuho Oku、Tommy Pauly 与 Martin Thomson。2026年8月31日保存的 IETF 档案列出 Oku 参与的四份 RFC；Fastly 第一方作者页面称他为 Principal OSS Engineer，并记载 H2O、quicly 与 picoTLS 的作者身份。这些事实说明他长期参与高性能互联网软件，却不把集体标准改写为个人发明，也不证明任何具名网络已经支持它。

字段只表达一条消息的意图

Incremental 采用 Structured Fields 的 Item 类型，只有布尔值有效；若值是其他类型，接收方会忽略。?1 请求增量转发；?0 表示通常行为，中间节点可能收全消息再转发，并可因此更有把握采用缓冲。

它作用于“消息”，不是连接、域名或产品。请求带 ?1，不代表响应也带；服务器若希望响应逐步穿过代理，必须在响应上再设置一次。测试报告必须先说清方向，否则“支持 streaming”很容易用一边的成功替另一边作证。

理解 ?1 的节点不应缓存完整正文，而应先转发头部区段，再随到随转正文；完整头部和 trailer 仍可缓冲。字段因而约束正文转发，不是新传输协议。RFC 还提醒：若真正设计双向协议，Extended CONNECT 通常更符合 HTTP 架构。最小信号不会替架构选择作决定。

明确拒绝比伪装成功更有价值

RFC 最关键的边界是：节点已经理解字段，并且明确决定不增量转发正文时，必须生成错误响应，而不能把整条消息悄悄缓冲后再送出。

错误让应用可以行动：换路径、换协议、降低功能、稍后重试，或者明确告知不可用。静默缓冲则可能让连接长时间保持“正常”，却让控制台、事件流或早期响应失去价值。最终状态相同，运营后果完全不同。

这条规则并没有把所有延迟都定性为拒绝，也没有要求每个微小片段立即发出。它只把参与节点的一次明确政策决定变成可观察分支。运行代码优先的检验方式，是在真实路径发送可辨识的分段数据，记录每个受控节点收到与转发首尾字节的时间，并主动触发拒绝条件，确认错误语境能到达决策端。

两类错误对应两类约束

第一类是结构性不兼容。有些中间节点必须看完整正文，才能执行内容安全检查。完整检查与增量交付不能同时成立。此时 RFC 建议返回 501 Not Implemented，并在 Proxy-Status 中标出 incremental_refused。

单纯重试通常不会改变结果。需要改变检查方式、路由、资源位置或协议。这是安全与架构选择，不是临时扩容问题。

第二类是暂时容量不足。长时间占用的增量请求会消耗并发资源，节点可以给它设置更严格的并发池，以保护普通请求。池满时，建议返回 429 Too Many Requests，并用 connection_limit_reached 说明原因。

这时资源可能完全兼容，只是当前没有名额。退避、准入、优先级、扩容或受控降级才是对应措施。只看 501 或 429 都不够：两种状态码另有广泛用途，必须把 Proxy-Status、负责节点、资源、政策版本与时间连接起来。

不认识字段的节点仍是盲区

HTTP 可扩展性的代价是，未知字段不会自动获得执行力。不了解 Incremental 的节点不会改变行为；知道名字但不支持的节点也可能继续缓冲。因此，“没有收到拒绝错误”不能证明整条路径支持。

反而是支持字段但拒绝的节点更透明：它留下了原因。不知情节点可以增加延迟，却没有同样的痕迹。RFC 因此建议依靠经过验证的先验知识，或对具体资源做探测。

“具体资源”很重要。同一域名可能因地区、路径、正文类型、客户等级或负载走进不同政策。一场成功探测，只证明当时条件下的那条路径；它不是为供应商品牌颁发永久证书。

权限边界也应保持清楚：发送方表达意图；每个中间节点决定自己的安全、容量与转发；端点解释结果。一个端点无权替不受控软件承诺行为。

有界缓冲仍会改变结果

即使支持字段，节点也可为效率保存少量数据，避免大量小包带来的成本或滥用。它可以设置字节阈值与时间阈值；任一阈值到达就需要转发，不能无限期持有。

所以“支持”与“达到应用时延目标”不是一回事。对大响应无感的字节门槛，可能让稀疏事件流迟迟攒不够；对人类界面很短的定时器，可能让机器反馈环路失效。政策阈值必须有版本，并与首字节时间、并发占用和服务等级一起保存。

这正体现最小初始规范：共同标准只规定可互操作的意图和可读拒绝；资源适用范围、检查规则、缓冲阈值、容量预算、降级和补救属于本地决策。若把本地选择包装成全球承诺，标准反而更难部署。

建立路径—结果凭据

先记录客户端、服务器、资源、构建版本、消息标识和方向；保存字段原值、布尔解析结果、设置字段的组件与业务需要。再为每个可控或参与节点记录协议区段、识别/支持状态、内容检查规则、头部/trailer/正文策略、字节与时间阈值、并发池、占用和优先级。

随后连接结果：HTTP 状态、完整 Proxy-Status 成员、代理错误类型、负责节点、首尾字节接收与转发时间，以及应用是否按期工作。正常增量、受有界缓冲影响、结构性拒绝、临时拒绝、疑似静默缓冲与证据不足，应是不同分类。

最后保存行动：退避、换路由、换协议、扩容、安全例外、产品降级、责任人与补救期限。无需为证明时延而保存敏感正文；安全关联标识、政策版本与时间戳通常足够。

好的凭据还要记录未知。某跳不可见、Proxy-Status 被移除、只测了响应没有测请求，都应保留为缺口。能被反驳的证据，比一枚“支持流式”的绿标更可信。

来源