协议设计原理：从状态机到向后兼容

0. 元信息

• 主题路径：docs/topics/network/subtopics/protocol-design/
• 父主题：network
• 主分类：计算机基础
• 辅助分类：工程技术
• 适合对象：写过 TCP/UDP 客户端、读过 Wireshark 抓包，想自己设计或演进二进制/文本协议的开发者
• 建议周期：3～4 周（每周 6～8 小时，含 RFC 阅读、proto 编写、对比实现）
• 前置知识：tcp-ip-stack；熟悉 TCP 三次握手、IP 报文头、字节（byte）/位（bit）的概念
• 最终目标：能画协议状态机、用 TLV/Protobuf 描述消息、为新字段加版本号和特性开关、解释 rolling upgrade 怎么做、给已有协议设计一次向后兼容的扩展

1. 学习路线

协议分层与角色
  → 报文边界与字节序
  → 定长字段、TLV、变长编码
  → 有限状态机 (FSM)
  → 文本协议 vs 二进制协议
  → 协议描述语言 (Protobuf / FlatBuffers / Cap'n Proto)
  → 版本号、特性开关、协商
  → 向后兼容与 rolling upgrade
  → 失败模式：粘包、半包、重放、降级
  → 设计评审：一份 RFC 的最小骨架

每一步先看一份真实协议（DNS、HTTP/1.1、Protocol Buffers、TLS ClientHello），再回到自己的设计。

2. 阶段周数分配

3. 九阶段表

4. 第一周任务

Day 7 拆解

步骤 A —— 最小可用（60 分钟）

1. 选一个场景：「消息推送通道」或「设备影子同步」；
2. 列出 3~5 种消息，每种用一行 TLV 描述；
3. 画初始状态机（CLIENT_HELLO → SERVER_HELLO → OPEN → CLOSE）；
4. 用 Protobuf 写出 .proto；
5. 写一个 Go 或 Python 客户端，编解码一条消息成功收发。

步骤 B —— 补齐四类边界（45 分钟）

• 加一个版本号字段，演示两个版本协商；
• 加一个 feature flag，演示旧客户端忽略新字段；
• 列出三类失败模式（粘包、长度异常、版本不匹配）；
• 把 RFC 骨架写到 notes/day7-rfc-skeleton.md。

5. 阶段通用验收

1. 不看资料画出 TCP 与 TLS 1.2 握手状态机；
2. 用 varint 手算 5 个数；
3. 用 protoc --decode_raw 解释一段二进制 Protobuf；
4. 给一个已有协议加一个新字段，并解释它如何向后兼容；
5. 准备至少 3 个版本演进场景（旧→新、新→旧、滚动升级）并说明哪一端会失败；
6. 记录 wire format 字节布局（含字节序与对齐）；
7. 能修改已有协议设计（加字段、删字段、改编码），而不是只能照抄。

6. 最终验收

• 独立画出 TCP、TLS 1.2、TLS 1.3 三份状态机；
• 独立实现一个 varint 编码器；
• 完成至少 6 个实验：DNS 报文解析、字节序对比、varint 编解码、Protobuf decode、TLS 1.3 ClientHello 字段布局、向自己协议加新字段；
• 完成 1 个综合项目：定义一份带版本号、feature flag 和向后兼容策略的小协议，并跑通两个版本的客户端互通；
• 用 15 分钟讲清「加字段 vs 改字段 vs 删字段」分别会破坏哪类兼容性。

7. 综合项目

首选：可演进的迷你 RPC 协议。用 Protobuf 定义 5~8 条消息（含 Request/Response/Heartbeat/VersionNegotiation/FeatureProbe）。实现一个服务端、一个老版本客户端、一个新版本客户端。演示三种场景：旧→新、新→旧、滚动升级期间混合。

备选：MQTT 子集实现 / HTTP/1.1 风格的文本协议 + TLV 扩展头 / 二进制长连接协议。

项目必做要求：

1. 协议规范：一份 RFC 风格的 .md，含消息定义、字段编码、状态机、版本策略；
2. IDL：.proto 或等价描述；
3. 参考实现：服务端 + 两个版本客户端；
4. 兼容性测试：新字段被旧客户端忽略、新客户端拒绝过老的版本号；
5. 失败模式清单：粘包、长度字段被攻击、版本降级、重复消息；
6. 抓包证据：用 Wireshark 或 tcpdump 抓一次握手与一次正常消息；
7. README：运行步骤、目录结构、复盘；
8. 复盘：哪些设计在第 2 天就被自己推翻。

交付物放到项目仓库的 notes/：design.md、test.md、retrospective.md。

本主题贡献

本主题沉淀协议设计的工程骨架：状态机 FSM、TLV 与 varint 编码、字节序、Protobuf 字段编号与 rolling upgrade，所有设计都有 RFC 风格 .md + 参考实现。

职责（3 项）

1. 画 TCP 三次握手状态机、TLS 1.2 握手状态机、TLS 1.3 1-RTT 握手状态机，能从 FSM 角度解释 FIN_WAIT_2、CLOSE_WAIT、TIME_WAIT 的合法性边界与攻击面；
2. 区分定长字段、TLV（type/length/value）、varint（Protobuf 7-bit 编码 + zigzag）、length-prefixed，能解释 wire type 选择对演进的影响，能手算 varint(300)、varint(16384)；
3. 用 .proto + field number + reserved 字段约束演进，能解释为什么「加字段 + 默认值 = 向后兼容」「删除用 reserved 保留编号」「feature flag 比主版本号更适合长生命周期协议」。

交付物（4 项）

1. 一份迷你协议的 RFC 风格 .md（消息定义 + 状态机 + 版本策略 + 失败模式清单 + 不变量）；
2. Protobuf .proto 定义（5~8 条消息，含 Request/Response/Heartbeat/VersionNegotiation/FeatureProbe）+ protoc --decode_raw 输出对照；
3. TLS 1.3 ClientHello 字节布局图（legacy_version/random/session_id/cipher_suites/extensions）+ openssl s_client -msg 抓包标注；
4. 两个版本客户端互通（演示三种场景：旧→新、新→旧、滚动升级期间混合），含 wire format 抓包证据。

指标（3 项）

1. varint 编码效率：小整数（< 128）占用 1 字节，相对定长 4 字节节省 75%；
2. 字段编号冲突率 = 0（CI 检查 reserved 字段 + 已删除字段不可重用）；
3. 滚动升级窗口期破坏性变更 = 0（feature flag 默认关闭，逐租户灰度打开）。

8. 推荐开源资料

复制 .proto 或协议片段前看对应 LICENSE：Protobuf 走 BSD-3-Clause，gRPC 走 Apache-2.0，RFC 文本属公共领域但不可冒充 IETF 文档发布。

9. 学习资料汇聚（v0.3 自包含）

本节由本计划生成。资料按用途筛选。协议行为以 RFC 和实现文档为准。

9.1 背景与动机

互联网是「在不可靠网络上构造可靠协议」的工程结果。早期的 NCP 没有分层；TCP/IP 把网络分成链路、网际、传输、应用四层，让每一层只关心自己的语义。这套分层思想直接来自协议设计本身——每一层都要给下一层一组「能做什么、不能做什么」的承诺。

协议设计的本质是约束：字节序定死、字段长度定死、状态转移定死。新字段怎么加、旧字段怎么删、版本怎么谈，都是在「已有实现已经部署」的前提下做手术。我们学它，是因为写 RPC、写 SDK、写配置文件、写数据库协议、写游戏通信，都会撞到同一组问题：粘包、半包、字段被攻击者构造、版本错配。

一句话总结：协议设计是「让两个互不信任的程序，在不可靠链路上达成一致语义」的工程。

9.2 概念地图

flowchart LR
  分层[协议分层] --> 头[报文头]
  分层 --> 负载[负载 / payload]
  字节序[字节序] --> 头
  编码[字段编码] --> 定长[定长字段]
  编码 --> TLV
  编码 --> 变长[varint / length-prefixed]
  TLV --> 类型[类型字段]
  TLV --> 长度[长度字段]
  TLV --> 值[值字段]
  编码 --> IDL[IDL: Protobuf / FlatBuffers]
  FSM[有限状态机] --> 状态[状态]
  FSM --> 事件[事件]
  FSM --> 动作[动作]
  FSM --> 转移[转移]
  版本[版本与协商] --> 主版本[主版本]
  版本 --> 特性[特性开关 / feature flag]
  版本 --> 协商[版本协商]
  兼容[向后兼容] --> 加字段[加字段]
  兼容 --> 保留[reserved]
  兼容 --> 默认值[默认值]
  兼容 --> 丢弃[未知字段丢弃]
  失败[失败模式] --> 粘包[粘包 / 半包]
  失败 --> 长度攻击[长度字段攻击]
  失败 --> 重放[重放]
  失败 --> 降级[降级]

关系说明：

• 分层决定报文头与负载的边界；字节序影响所有多字节字段。
• 字段编码是「如何把语义塞进字节」：定长最快，TLV 最常见，变长编码最省空间。
• FSM 给协议「活」的部分：每个事件对应一个或多个状态转移，状态决定下一条消息的合法性。
• 版本与协商、向后兼容是协议演进的能力，决定新老实现能否共处。
• 失败模式提醒我们：长度字段是攻击面，重放需要 nonce 或 sequence，降级需要版本最低保障。

9.3 基础知识讲解

经典论文 / RFC

经典书籍

优秀博客

核心人物

开发方法

9.4 经典问题与经典案例

9.5 学习难点

概念难点

思维难点

工程难点

9.6 技术标准与接口

9.6.1 Entity

9.6.2 Scope

• TCP / IP / DNS / TLS / QUIC：传输与网络层协议，本计划把它们当作「真实世界里的设计范例」来读，不是要重新实现。
• IDL（Protobuf / Cap’n Proto / Avro / FlatBuffers）：跨语言序列化与协议描述工具。它们解决「同一份数据在不同语言、不同版本下的兼容」。
• 向后兼容策略：包括字段编号保留、未知字段丢弃、默认值、feature flag。这些不是协议，但任何长期协议都要做。
• 不适用：纯本地内存数据结构（用语言原生 struct 即可）、单进程配置（用 YAML/TOML 即可）、一次性导出格式（CSV/Parquet 已够）。

9.6.3 Structure

协议设计者必须掌握的字段布局与编码概念：

// Protobuf 风格的 .proto：演示 IDL + wire type
syntax = "proto3";

message Header {
  uint32 magic       = 1;   // 定长，4 字节 big-endian
  uint32 version     = 2;   // 版本号，永远保留位置
  repeated string features = 3;  // feature flag 列表
  reserved 10 to 19;        // 旧字段保留编号
  reserved "old_name";      // 旧字段名保留
}

message Envelope {
  Header header            = 1;
  bytes   payload          = 2;  // 长度前缀 + 字节
  uint32  crc32            = 3;  // 校验
}

// TLS 1.3 ClientHello 字节布局（简化版）
uint16  legacy_version = 0x0303   // TLS 1.2 兼容位
bytes[32] random                     // 32 字节 client random
opaque session_id<0..32>             // 长度前缀 + 字节
opaque cipher_suites<2..2^16-2>      // 长度前缀 + 2 字节套件
opaque compression_methods<1..255>   // 长度前缀 + 1 字节方法
// extensions 整段走 TLV：type(2) + length(2) + value
opaque extensions<8..2^16-1>

必须掌握的字段、概念与 API：

• 字节序：htonl/ntohl（C）、encoding/binary（Go）、struct.pack('!I', x)（Python）；
• varint：Protobuf 的 7-bit 编码与 zigzag；
• TLV：type / length / value，常见于 DNS、ASN.1、TLV 风格的二进制协议；
• FSM：state、event、transition、action、guard；
• Protobuf：protoc、--decode_raw、--encode_raw、field number、reserved；
• TLS：supported_versions、key_share、signature_algorithms；
• HTTP：Upgrade、ALPN、SETTINGS（HTTP/2 帧 0x4）。

9.6.4 Ecosystem

• 序列化与 IDL：Protobuf（跨语言主流）、Cap’n Proto（零拷贝）、FlatBuffers（嵌入式/游戏）、Avro（数据管道）、Thrift（RPC 历史选项）；
• 网络库：gRPC、Twirp、Finagle、Netty、Envoy、Tokio（Rust）；
• 协议设计工具：Wireshark、tshark、protoc、capnp compile、flatc；
• 服务网格：Envoy、Linkerd、Istio。它们把协议策略（重试、超时、负载均衡）抽到 sidecar，让应用层协议更聚焦语义；
• 事实标准 vs 标准本身：Upgrade: h2c 是 HTTP/1.1 字段，但 HTTP/2 客户端必须支持——这是事实标准；Protobuf 字段编号语义稳定，但 proto3 与 Editions 在默认值上不同——演进要选对版本。

9.6.5 Depth Tiers

本计划要求达到：L3。需要维护长生命周期 RPC 或跨语言 SDK 时再进入 L4。

9.6.6 Source

• TCP：RFC 793（https://www.rfc-editor.org/rfc/rfc793）；更新见 RFC 9293。
• TLS 1.3：RFC 8446，https://www.rfc-editor.org/rfc/rfc8446。
• QUIC 帧：RFC 9000 §17，https://www.rfc-editor.org/rfc/rfc9000#section-17。
• DNS 头：RFC 1035 §4.1.1，https://www.rfc-editor.org/rfc/rfc1035#section-4.1.1。
• Protobuf Encoding：https://protobuf.dev/programming-guides/encoding/
• Protobuf Style：https://protobuf.dev/programming-guides/style/
• gRPC Versioning：https://github.com/grpc/grpc/blob/master/doc/versioning.md
• 引用版本快照日期：2026-07-30。

10. 常见误区

• 把「能用就行」当成协议设计。半年后会出现版本错配；
• 只画消息格式不画状态机。合法消息仍可能造成非法语义；
• 在 Protobuf 里改字段名当兼容。序列化是按编号，名字是注释；
• 复用字段编号删字段。会让老消息被错解；
• 不校验长度字段。攻击者发一个 length=0xFFFFFFFF 直接 OOM；
• 用文本协议只因为「好调试」。生产抓包要的是 wire format；
• 把 feature flag 做成主版本号。每次大改都升级主版本会逼所有人同步；
• 忽略字节序。把内存里的 struct 直接 write() 出去，跨架构全乱；
• 状态机不写不变量。代码 review 时没人知道哪些转移合法；
• rolling upgrade 期间上线破坏性变更。先发 feature flag，再开默认；
• 协议里有「必须按顺序读」的隐式约束。文档不写，新人不会知道；
• 把加密和身份认证混淆。协议层不解决机密性，靠 TLS 或应用层加密；
• 把版本号当字符串比较。「1.10」小于「1.9」会让升级失败。

11. 所有知识点分类（统一规则）

1. 编程语言
2. 数据结构与算法
3. 计算机基础：协议分层、字节序、状态机、版本演进
4. 工程技术：IDL、序列化库、跨语言兼容、滚动升级
5. Web 与后端：HTTP、gRPC、QUIC、负载均衡
6. 前端与客户端
7. 数据与人工智能
8. 项目与职业能力：协议评审、RFC 写作、抓包验证
9. 安全与可靠性：长度校验、版本降级、重放保护

本计划归属：计算机基础 主 + 工程技术 辅。