摘要

  • MAX_DATA 与 MAX_STREAM_DATA 公布的是绝对偏移上限，不是新增字节配额或空闲内存测量值。
  • 之后更小的数值不能撤销额度；没有看到 DATA_BLOCKED 也不能证明发送方未被阻塞。
  • 容量判断必须把额度账本与流偏移、最终大小、应用消费、缓冲区占用和拥塞状态连接起来。

监控面板看到接收方把 MAX_DATA 提高到 16 MiB，便记下 16 MiB 可用空间。第一处错误是算术：这个值是累计上限，先前各流已经使用的偏移仍然计入其中。第二处错误是含义：它授权发送方扩展字节账本，并不直接测量剩余内存，也不证明应用已经读取数据。

RFC 9000 §4.1 同时规定连接级和流级两个上限。连接级控制所有 STREAM 数据的总量；流级控制防止单条流占满接收缓冲。一次写入是否有许可，取决于连接最高上限及其累计消耗，也取决于目标流最高上限及其最大已计偏移。

这些数字是绝对值，不是增量。接收方后来发送更小的 MAX_DATA 或 MAX_STREAM_DATA 不会产生效果；发送方必须忽略没有提高上限的帧。因此“最新值”不是权威指标，系统必须保留曾接受的最大值以及受其约束的消耗账。

RFC 9000 §19.9 要求所有 STREAM 数据都计入连接上限，已经终止的流也不例外。RFC 9000 §4.5 把流的最终大小定义为该流消耗的流控额度。关闭或重置一条流只是确定账目，并不会抹去历史偏移、自动补满连接窗口。

流级计算还有另一陷阱。RFC 9000 §19.10 按最大偏移计账。丢包或乱序可能使最大偏移大于当前连续可交付的字节数；新收到的 STREAM 帧也可能不再推进最大偏移。原始包字节或某一时刻的缓冲占用不能替代协议偏移账本。

RFC 9000 §4.2 把何时、增加多少额度交给实现决定。频繁的小幅更新增加控制开销；更少的更新需要更大的增量和更大的接收方资源承诺。实现可以用 RTT 和应用消费速率自动调整额度，但这些只是策略输入，不构成“额度等于空闲内存”的换算关系。

额度也不是吞吐承诺。RFC 9000 §4.3 指出，可用额度若不能持续高于连接的带宽时延积，接收吞吐会受流控限制。这说明额度可能是达到某种速率的必要条件，却不是充分条件；拥塞窗口、路径丢包、调度以及发送方工作量仍会阻止获准字节进入网络。

DATA_BLOCKED 也不是完整回执。RFC 9000 §19.12 说发送方想写但被连接流控挡住时应发送该帧，可是发送并非强制。§4.2 因此禁止接收方等到该帧才增加额度，否则发送方可能在整条连接余下时间里一直阻塞。没看到该帧，只能说明没有这项观测，不能证明仍有额度。

可辩护的运营记录应包含：连接最大上限、累计消耗、各流最大上限与偏移、最终大小、阻塞帧、应用消费边界、缓冲占用、拥塞窗口、RTT、丢包和更新时刻。MAX_DATA 只负责证明其中一个跃迁：协议允许继续扩展字节账本。