基于Protocol Buffers的消息完整性校验方案咨询

针对无SSL场景下Protobuf消息的完整性校验需求，这里提供几个可靠且高效的解决思路：

1. 利用Protobuf官方规范化序列化能力 #

Protobuf默认序列化是非规范化的，但从3.15版本开始，官方提供了规范化序列化（Canonical Serialization） API，能保证相同内容的消息在任何语言环境下，序列化后的字节序列完全一致。

• 具体操作：比如C++中用Message::SerializeToCanonicalString()，Java中用Message.toByteString(ByteString.CANONICAL)，Python中可通过google.protobuf.util.json_format.MessageToJson开启canonicalize选项（或直接调用对应序列化参数）。
• 校验流程：发送端将原消息通过规范化序列化得到字节数组，计算CRC32/SHA-256等值作为校验和，和原消息一起封装发送；接收端对收到的原消息执行相同规范化序列化，重新计算校验和并对比即可。
• 优势：彻底规避非规范化序列化的差异，性能优于JSON转换，仅增加校验和的字节开销（如CRC32仅占4字节）。

2. 自定义固定序列化规则（适配旧版本Protobuf） #

如果你的Protobuf版本低于3.15，无法使用官方规范序列化，可以手动约束序列化行为：

• 强制字段按编号顺序序列化（多数Protobuf实现默认按字段号排序，需确认关闭“按声明顺序序列化”选项）；
• 禁止序列化默认值字段；
• 忽略未知字段（避免不同版本客户端/服务端的未知字段干扰）；
• 统一浮点数序列化格式（比如指定固定精度，或转成字符串后再序列化）。
• 注意：这种方式要求所有通信端严格遵循相同规则，维护成本较高，可靠性不如官方方案。

3. 封装带校验和的通用消息结构 #

定义一个专门的校验消息载体，将原消息的规范序列化字节和校验和一起发送：

message SecuredMessage {
  // 原消息的规范化序列化字节
  bytes payload = 1;
  // 校验和，比如CRC32的字节数组，或SHA-256的十六进制字符串
  bytes checksum = 2;
}

• 发送流程：序列化原消息为规范字节 → 计算校验和 → 填充到SecuredMessage中发送；
• 接收流程：解析SecuredMessage → 对payload计算校验和并与checksum对比 → 校验通过后解析payload为原消息。

不推荐方案说明 #

• 转JSON计算校验和：存在浮点数格式、字段顺序、默认值处理等跨语言差异，极易导致校验失败，仅适合精度要求极低的场景；
• 附加完整消息副本：直接让消息体积翻倍，带宽和存储开销大，完全没必要，不如规范序列化+校验和的方案高效。

内容的提问来源于stack exchange，提问作者Kevin