协议演进与兼容

协议部署后，客户端、服务端、代理、缓存、历史数据和离线任务不会同时升级。兼容性设计就是让这些不同版本在明确边界内共存，而不是只在头部加一个版本号，或者要求解析器“尽量接受”。

先写清谁生成数据、谁读取数据

以数据生产者/消费者为参照，新 reader 能读旧 writer 的数据通常称向后兼容；旧 reader 能处理新 writer 的数据通常称向前兼容。不同社区的术语参照可能不同，设计文档最好同时写出明确的版本方向。

“新客户端配旧服务端”包含两条路径：新客户端写请求给旧服务端读，同时旧服务端写响应给新客户端读。两条路径需要不同的能力，不能用一张 client/server 年龄表替代数据方向矩阵。

一个字段改单位，怎样把 wire 兼容变成业务错误

假设原字段 timeout_seconds = 1 是 uint32，新需求希望支持毫秒。将字段 1 改名为 timeout_ms，字节解析可能仍成功，但原值 5 从五秒变成五毫秒，是语义破坏。换成 uint64 也不会修复单位含义。

更可控的演进是保留旧字段，引入新的、有存在性的 timeout_ms = 2，定义两者同时出现时的优先级，并在旧 reader 退出前保持可用的写入方式。若 0 表示“不设超时”，就必须区分“没有提供”与“明确提供 0”，不能只用真值判断。

# 教学模型：字段名代表已解析字段，显式 presence 由 key 是否存在表达。
def read_timeout_ms(message):
    if 'timeout_ms' in message:
        value = message['timeout_ms']
    elif 'timeout_seconds' in message:
        value = message['timeout_seconds'] * 1000
    else:
        value = 30_000
    if type(value) is not int or not 0 <= value <= 3_600_000:
        raise ValueError('invalid timeout')
    return value

assert read_timeout_ms({'timeout_seconds': 5}) == 5000
assert read_timeout_ms({'timeout_ms': 0}) == 0
assert read_timeout_ms({}) == 30000
assert read_timeout_ms({'timeout_seconds': 5, 'timeout_ms': 1200}) == 1200
# 如果旧 reader 只支持整秒，1.2 s 无法无损回写成旧字段。
assert 1200 % 1000 != 0
print('单位、缺省、显式 0 与双字段优先级通过')

不能声称新字段任何值都能“自动降级”。1.2 秒在旧格式中只能拒绝、限制新功能或采用明确的有损转换策略，选择应属于业务契约。在 Protobuf 中可用相应 presence 机制表达缺失与显式默认值；语言生成代码和字段版本也要一起检查。Protobuf Field Presence

Protobuf 删除字段后应 reserve 相应标识，避免旧字节在未来被解释为另一个含义。字段号相同并且 wire type 能读，不等于类型、数值和业务兼容。Proto3 更新消息

未知数据：跳过、保留、拒绝是不同策略

HTTP/2 定义未知帧类型的忽略规则，并规定未知 SETTINGS 参数处理，但仍要遵守连接前言、CONTINUATION 序列等约束。QUIC v1 对未知传输 frame type 则要求 FRAME_ENCODING_ERROR；它不是每帧都有统一 length 的 TLV，因此不能把 HTTP/2 的规则搬过去。HTTP/2、QUIC §12.4

HTTP/3 又有自己的 frame 和 stream 扩展规则，必须区分“未知”与“已知但出现在禁止位置”。扩展容忍性应由每个层次的语法和语义共同决定。HTTP/3 扩展

旧中间层即使成功解析再写出，也可能丢信息：将 Protobuf 转为 JSON、逐字段复制到 DTO、存进只含旧列的数据库，都会改变未知字段路径。应测试新消息经过实际中间层后的往返结果，不只是直接用两个最新版库互测。

旧中间层说解析成功，新字段怎么还是丢了？

先发送ms=1200，经保留路径仍为1.2秒，经重建路径变为旧字段的5秒。再将ms设为0，保留路径明确表示不限时；取消字段存在性才是回退到5秒。不能用if(value)判断这项优先级。

协商、发现与 fallback 不要混成一步

HTTP Upgrade 的典型现代使用可以参考 WebSocket；HTTP/2 的旧 h2c Upgrade 机制已在 RFC 9113 中弃用，不宜继续作为当前通用 HTTP/2 建连教程。ALPN 在 TLS 1.2 中的服务端选择位于 ServerHello，在 TLS 1.3 中位于 EncryptedExtensions；不能只画一种 ServerHello 回答所有 TLS 版本。HTTP Upgrade、ALPN、TLS 1.3 扩展位置

Alt-Svc 不把现有 TCP 连接原地改成 QUIC，也不强迫客户端一定迁移；客户端仍需验证替代服务对原 origin 的权威性。广告有效期、失败缓存和已有连接都会影响实际选择。Alt-Svc

版本号和 capability 也不是一回事：版本 2 的部分实现可能没有某个可选压缩功能。一个功能的存在可能有方向性、参数范围及依赖，位图只能表达适用的简单能力集合，TLS cipher suites 列表本身就不是 capability 位图。

先求可用交集，再执行本地策略

def choose(local_preference, peer_offered, forbidden=()):
    offered = set(peer_offered)
    for name in local_preference:
        if name in offered and name not in forbidden:
            return name
    raise ValueError('no acceptable common mode')

assert choose(['v2', 'v1'], ['v1']) == 'v1'
assert choose(['v2', 'v1'], ['v1', 'v2']) == 'v2'
try:
    choose(['v2', 'v1'], ['v1'], forbidden={'v1'})
except ValueError:
    pass
else:
    raise AssertionError('local minimum policy bypassed')
print('交集、偏好与本地最低要求分别生效')

这是教学选择函数，不代表所有协议都按同一方偏好排序。实际还必须验证对端选择来自合法报价，并将需要保护的协商内容绑定到认证握手，避免中间设备删掉强能力后迫使降级。

fallback 是尝试失败后的策略，不是协商本身。暂时网络故障、版本不支持、证书验证失败和授权不足不应全部触发同一种回退；回退不能悄悄取消身份验证或改变业务权限。存在最低要求时，没有可接受交集就是失败。

GREASE：持续使用“应该能忽略”的扩展位置

协议规范写着忽略未知值，但生态长期只发送几个固定值，错误实现就可能把这些值写死。GREASE 通过在允许的位置持续发送保留值，使这种错误尽早暴露，维持扩展点的可用性。

TLS GREASE 使用规范保留的值，不是任意随机字节注入任意字段。服务端应按未知候选处理并选择其他合法能力；如果服务端把 GREASE 值当成真实协商结果返回，客户端反而必须拒绝。它检验的是正确未知值行为，不是要求所有位置都宽松接收。RFC 8701

HTTP/3 为一些设置等空间保留 0x1f * N + 0x21 形式的值来锻炼相应忽略规则；不同注册表各有规定，不应把这一公式作为 TLS 或所有 QUIC 层次的统一规则。GREASE 也不保证每个实现都发送全部变体。HTTP/3 保留设置

如果实现只对白名单中的 GREASE 值特判放行，对真正未知值仍报错，就没有达到目的。测试应覆盖不同值、位置、长度和混合已知字段，同时严格拒绝规范禁止的输入。

QUIC 的可演进性有明确边界

QUIC 加密并保护大量传输细节，减少中间设备对它们作错误推断的机会；但并非“所有 flags 全加密，中间盒只能看到 CID”。长头仍有版本和连接 ID 等可见字段，部分首字节位也有公开含义；header protection 也不同于把整个头部内容全部隐藏。QUIC 不变量

QUIC Initial 的初始保护密钥可由公开信息派生，不能作为对被动观察者隐藏所有握手内容的通用保证。连接迁移依赖 CID、路径验证和状态，不是把 IP/端口彻底从网络路径中移除。可演进的内部格式与稳定的外部不变量需要共同设计。

基础 Version Negotiation 包本身没有普通握手的认证保证，不能盲信其中列表即可实现安全降级。RFC 9368 定义兼容版本协商及相关验证，升级窗口和服务集群能力也影响防降级边界。QUIC 兼容版本协商

发布顺序要包含存储与回滚

假设服务先升级为双读但旧写，旧消费者仍正常；随后确认所有必需路径能读新字段，再灰度启用新写入。若要支持回滚到原始旧二进制，就不能先写出它无法读取或正确解释的数据。更常见的可回滚目标是“已支持双读但关闭新写功能”的版本。

还要计入长连接、离线客户端、重试队列、备份和批处理的最长存活期。“生产流量已经没有旧版本”不意味着旧格式数据已完全消失。删除旧路径前应有使用证据与明确保留窗口。

宽容解析如果没有统一规则，会让实现对同一输入产生不同结果，反而制造互操作和安全问题。将可接受输入、扩展位置与失败行为写清，再通过混合版本和实际数据路径持续验证，才能让协议稳定演进。Maintaining Robust Protocols