摘要

  • MP_JOIN 的 SYN 携带接收端 Token，用于找到既有 MPTCP 连接；后续 HMAC、随机数和接收端本地策略才决定新 TCP 子流是否加入。
  • 地址、令牌、HMAC、TCP 建立和应用结果属于不同证据。把它们压缩成“已获信任”会制造并不存在的授权。

MPTCP 对应用承诺的表面很朴素：仍然是 TCP 式的、可靠而有序的字节流。RFC 6182 同时要求人们看到另一面：网络会看见数个普通 TCP 子流。连接级状态把它们组织起来，但并不消灭各自的 TCP 状态。多地址只是寻找多个可能路径的实用信号，并不证明路径在物理上分离，也不保证吞吐量或韧性一定增加。

这种双层表述不是术语游戏。它规定了责任不能被偷换。应用可以看见一条连续字节流；网络设备仍可能只处理一个五元组；端主机必须判断一条新流究竟能否成为旧连接的一部分。RFC 6182 还把与普通 TCP、中间盒和共享瓶颈上的其他用户共存当作设计约束。所谓多路径并不是对网络提出无限制索取的理由。

第一条子流先留下可验证的来历

RFC 8684 规定，第一条子流的 SYN、SYN/ACK 和 ACK 通过 MP_CAPABLE 协商 MPTCP。该交换表明两端愿意在这条连接上使用相应版本，并交换日后认证附加子流所需的密钥材料。若必要的 MP_CAPABLE 交换缺失，例如对端不支持或中间盒剥除了选项，最终状态应回退为普通单路径 TCP。

回退并非失败之后的装饰性条款。它承认一个路径上出现的选项不能保证另一条路径仍会保留；端主机的愿望不能代替对端或中间网络的行为。初始交换能够证明的是受限的传输协商，不能证明用户身份、应用许可、IP 地址所有权，或未来路径的质量。

版本沿革也有类似的证据尺度。RFC 6824 在 2013 年以 Experimental 身份公布，供检查、试验实现和评估，并非互联网标准。RFC 8041 在 2017 年记录了当时的实现和运营经验。2020 年的 RFC 8684 以 Standards Track 身份取代 v0，并说明 v1 的澄清与修改主要由部署经验推动。这支持“运行经验改变了协议记录”的历史判断，却不能据此声称今天的采用比例、任何厂商的默认配置或普遍性能结果。

Token 是本地索引，不是一张通行证

已有连接之后，主机可以发起新的子流。MP_JOIN 的第一个 SYN 发送接收端的 Token、发送端新生成的随机数，以及发送端的 Address ID。在 v1 的 SHA-256 选择下，Token 是接收端初始密钥经 SHA-256 后取最高 32 位。它的用途很窄：让接收端把这一个新 SYN 定位到自己保存的某一条 MPTCP 连接状态。

这是一项状态查找，不是一份可携带的准入权利。

RFC 8684 特意把两个时点分开。SYN 刚到达时，新的子流尚无任何“既有”五元组可供旧连接识别，所以需用 Token 做准入时的分用。建立完成后，子流的数据包按普通 TCP 的五元组分用。Token 不会作为永久标签附着于每个数据包，也不会取代 TCP 的序号和确认检查。

Address ID 的任务也不同。发送端用它标识源地址，即便 NAT 改变了接收端看到的 IP 头，仍可关联地址公告、连接尝试和地址撤除。它并不是可路由地址，不证明发送端拥有该 IP，也不授予离开本连接之后的任何网络或应用权限。

32 位 Token 同样不承担完整认证。它使接收端能够选择状态，并在规范限定的模型中抑制某些盲目状态耗尽尝试；它不是人的秘密、业务凭证或应用层 bearer token。设计拒绝让方便的索引膨胀成万能身份。

HMAC 证明延续，策略决定接纳

查找到状态之后，MP_JOIN 仍需证明。接收端在 SYN/ACK 中返回自己的随机数和截断 HMAC；发起端在 ACK 中返回 HMAC。两个 HMAC 使用初始 MP_CAPABLE 中交换的密钥以及两端的新随机数。新随机数使旧报文记录不能直接充当这一次加入的重放。

HMAC 成功时，RFC 8684 给出的结论很精确：双方确认自己仍是该连接开始时的同一对 MPTCP peers，并且同意这条子流加入哪一条 MPTCP 连接。这是传输层范围内的对端连续性证明。它不等于自然人的身份认证，不证明企业授权、地址归属、应用请求被接受或业务效果持久存在。

更重要的是，正确 Token 也不能强制接收端接纳。Token 未知时，接收端用 TCP RST 拒绝；Token 已知但本地策略禁止接受新子流时，同样必须拒绝；缺失或错误的 HMAC 也会关闭子流。查找在前，密码证明在后，本地主机仍保留是否增加资源和状态的决定权。

这正是该机制的治理含义：发现告诉你状态在哪里；证明告诉你提议者与先前关系有何联系；控制该状态的端点决定是否给它增加新的传输成员。任何一项都不应被挪用为另一项。

建立后的五元组也不能替应用作证

完成上述步骤后，新五元组才成为被同一 MPTCP 连接管理的一条 TCP 子流。抓包可合理说明：初始 MPTCP 协商发生过，某个 Token 定位到了状态，HMAC 被校验，特定子流建立过。这些已经是有价值的传输事实。

但它们不会自动说明应用解析了字节、账户被认证、操作获准、数据库写入，或用户得到了结果。字节流的连续性与意义的连续性不是同一件事。MPTCP 的优点恰恰在于它没有假装能裁决后者。

来源与证据边界

下列 RFC 支持本文所述架构、版本状态和规范定义的行为。它们不支持当前部署规模、真实路径是否独立、某 NAT 的实现行为、产品一致性、性能收益、人的身份或应用完成情况。