连接状态
本章节定义初版 NRCP over QUIC 的连接状态机。该版本连接状态只描述 QUIC 连接、NRCP 会话可用性、心跳异常、恢复流程与关闭流程
NRCP 连接状态是每个 Endpoint 的本地观察结果,不是双方强一致共享状态。Client 与 Server 可能在短时间内处于不同状态,接收端必须以自己的本地状态决定是否处理收到的消息
状态定义
| 状态 | 适用端 | 含义 | 允许行为 |
|---|---|---|---|
DISCONNECTED | 双方 | 未建立 QUIC 连接 | 无业务消息 |
CONNECTING | Client | QUIC 连接建立中,包含内部 TLS 1.3 握手 | 无 NRCP 业务消息 |
CONNECTED | 双方 | QUIC 握手完成,NRCP 会话可用 | Operation、Flow、Heartbeat |
DEGRADED | 双方 | QUIC 仍连接,但 NRCP 心跳或业务活性异常 | 停止高危控制类消息,可继续关闭或恢复流程 |
RECOVERING | Client | Client 正在同一 QUIC 连接上恢复 NRCP 层会话状态 | 停止高危控制类消息,重新建立 NRCP 状态 |
CLOSING | 双方 | 连接关闭中 | 拒绝新 Operation 与新 Flow,释放已有资源 |
状态迁移
Client 侧典型状态迁移如下:
DISCONNECTED
-> CONNECTING
-> CONNECTED
-> DEGRADED
-> RECOVERING
-> CONNECTED
CONNECTED
-> CLOSING
-> DISCONNECTED
DEGRADED
-> CLOSING
-> DISCONNECTED
Server 侧典型状态迁移如下:
DISCONNECTED
-> CONNECTED
-> DEGRADED
-> CONNECTED
CONNECTED
-> CLOSING
-> DISCONNECTED
DEGRADED
-> CLOSING
-> DISCONNECTED
Server 不主动建立 QUIC 连接,因此没有 CONNECTING。Server 不主动恢复 Client,因此没有 RECOVERING
典型触发条件:
- Client 发起 QUIC 连接时进入
CONNECTING; - QUIC 握手完成后进入
CONNECTED; - QUIC 仍连接,但心跳超时、连续丢包或路径质量明显恶化时进入
DEGRADED; - Client 决定在同一 QUIC 连接上恢复 NRCP 层会话状态时进入
RECOVERING; - 任一端主动关闭、收到关闭通知或发生不可恢复错误时进入
CLOSING; - QUIC 连接断开时直接进入
DISCONNECTED,旧 NRCP Session 立即失效;
NRCP 不直接管理 TLS 状态。TLS 1.3 握手由 QUIC 连接建立过程完成,应用层只要求 QUIC 握手完成后才能发送 NRCP 业务消息
本地状态原则
由于心跳双向独立发送,网络异常可能是非对称的,因此双方状态不要求同时迁移。以下组合都是允许出现的短暂状态:
| Client 状态 | Server 状态 | 含义 |
|---|---|---|
CONNECTED | DEGRADED | Server 认为 Client 活性异常,但 Client 尚未发现异常 |
DEGRADED | CONNECTED | Client 认为 Server 活性异常,但 Server 尚未发现异常 |
RECOVERING | DEGRADED | Client 正在发起恢复,Server 仍认为当前 Session 异常 |
协议处理遵循以下原则:
- 发送端只能根据自己的本地状态决定是否发送消息;
- 接收端必须根据自己的本地状态决定是否处理消息;
- 接收端本地状态拥有最终处置权;
- 发送端不能以自身处于
CONNECTED作为消息应被执行的依据; - 双方通过 Heartbeat、Error、恢复请求和 Flow 重建逐步收敛状态;
状态行为
CONNECTED
CONNECTED 是正常工作状态,双方允许执行以下行为:
- 周期性发送 Heartbeat Ping;
- 响应 Heartbeat Pong;
- 发起 Operation;
- 创建、更新和关闭 Flow;
- 接收状态数据和控制数据;
进入 CONNECTED 后,Heartbeat 与时钟同步必须持续维护。Flow 只能在本地状态为 CONNECTED 时建立和运行
DEGRADED
DEGRADED 表示底层 QUIC 连接仍存在,但 NRCP 会话不再可信地满足实时通信要求
进入 DEGRADED 后:
- 双方应停止发送新的高危控制类消息;
- Server 应使机器人进入安全降级状态;
- Client 应停止依赖当前 NRCP 会话,并准备恢复 NRCP 层状态;
- 已建立的 Flow 可按业务策略暂停、关闭或等待恢复;
进入 DEGRADED 后,Endpoint 不得建立新 Flow,也不得将收到的 FLOW_DATA 交给业务处理逻辑
当 Endpoint 本地处于 DEGRADED 时,它不得执行来自该 Session 的高危控制类消息。若传输条件允许,应返回明确错误;若无法可靠返回错误,允许直接丢弃
典型错误码包括:
SESSION_DEGRADED;HEARTBEAT_TIMEOUT;CONTROL_SUSPENDED;
若 QUIC 连接已经断开,则不再进入或停留在 DEGRADED,而是直接进入 DISCONNECTED
RECOVERING
RECOVERING 只存在于 Client 本地状态机,用于表示 Client 正在同一 QUIC 连接上恢复 NRCP 层会话状态。Server 不主动恢复 Client,也不需要进入 RECOVERING
Client 进入 RECOVERING 后:
- 停止发送高危控制类消息;
- 重新执行 NRCP 层恢复流程;
- 重新建立必要 Flow;
- 等待当前 QUIC 连接上的 NRCP 会话重新进入
CONNECTED;
心跳恢复不应直接使状态从 DEGRADED 自动回到 CONNECTED。心跳连续恢复只表示链路具备恢复条件,Client 应进入 RECOVERING 并主动发起 NRCP 层恢复流程。只有恢复流程完成后,Client 才能回到 CONNECTED
恢复流程必须覆盖以下步骤:
- 确认当前 QUIC 连接仍然存在;
- 确认旧 NRCP Session 未超过恢复窗口;
- 重新同步或重建必要 Flow;
- 重新确认 QoS Grant 是否仍有效;
- 重置本地 Sequence、去重窗口和缓存状态;
- 重新建立有效的时钟偏移估计;
Server 收到恢复请求后,只根据当前 Session、Flow、QoS 和资源状态响应恢复结果,不需要进入 RECOVERING
恢复结果取值如下:
RECOVERED:旧 NRCP Session 可继续使用;REBUILD_REQUIRED:旧 NRCP Session 可用,但 Flow 需要重建;SESSION_EXPIRED:旧 NRCP Session 已失效;
初版不提供跨 QUIC 连接的 Session 恢复机制。若 QUIC 已经断开,Client 必须新建 QUIC 连接,新连接视为全新的 NRCP Session
消息处置规则
Endpoint 收到消息时,应先根据本地状态判断是否允许处理:
| 本地状态 | 收到普通 Operation | 收到 Flow 数据 | 收到高危控制类消息 | 收到 Heartbeat | 收到恢复请求 |
|---|---|---|---|---|---|
CONNECTED | 允许 | 允许 | 按业务规则校验 | 允许 | 按本地策略处理 |
DEGRADED | 可拒绝或降级处理 | 可暂停或丢弃 | 必须拒绝或丢弃 | 允许 | Server 可处理 |
RECOVERING | Client 本地暂停 | Client 本地暂停 | Client 本地暂停 | 允许 | Client 等待响应 |
CLOSING | 拒绝 | 丢弃 | 丢弃 | 可忽略 | 拒绝 |
若 Server 已进入 DEGRADED,而 Client 仍处于 CONNECTED 并继续发送控制指令,Server 必须以自己的 DEGRADED 状态为准拒绝或丢弃该控制指令。Client 可通过 Error 或后续心跳超时发现异常并进入 DEGRADED 或 RECOVERING
CLOSING
进入 CLOSING 后,Endpoint 应拒绝新的 Operation 和新的 Flow,并开始释放资源
需要释放的资源包括:
- 未完成 Operation;
- 未完成 Flow 协商;
- 已建立 Flow 上下文;
- QoS Grant;
- 心跳和时钟同步状态;
- 重传、去重和 Rate Limiter 状态;
与心跳的关系
心跳用于驱动 CONNECTED 到 DEGRADED 的状态迁移。具体超时公式和 NRCP 层恢复窗口见心跳与时钟同步
连接状态机只规定状态迁移与资源处理,心跳章节负责定义 Heartbeat Ping/Pong、超时判断、NRCP 层恢复窗口和时钟同步采样