概述
max_udp_payload_size、idle_timeout等这类属性属于 QUIC 语义，不属于 NRCP QoS
NRCP QoS 描述的是某个业务 Flow 在应用层的传输约束。它不替代 QUIC 的拥塞控制、连接保活、Stream 顺序可靠传输或 Datagram 能力，而是在 channel_id、flow_epoch 和服务端授权的 Flow 上下文之上，约束消息应该如何发送、接收、丢弃和判定失活
QoS 以 Flow 为粒度生效。接收端不能信任单个消息自报的 QoS 参数，而应通过 channel_id + message_type + flow_epoch 查询本地保存的上下文，再执行对应策略
范围
NRCP 狭义 QoS 包含以下属性：
- 可靠性：描述消息是否允许丢失、是否需要可靠到达；
- 时效性：描述单条消息的有效期；
- 活性：描述请求响应超时，或持续数据流在多久没有新消息后被判定为失活；
- 频率限制：描述该 Flow 允许的最大消息频率、突发数量和字节速率；
顺序、去重、心跳、ACK、优先级属于协议层语义或调度语义，不归纳进狭义 QoS 属性。它们只作为 QoS 实现和诊断的辅助机制，不属于 QoS 授权内容本身
可靠性
可靠性描述消息是否必须可靠到达
| 模式 | 语义 | 承载 |
|---|---|---|
reliable | 消息需要可靠送达，不应被传输层主动丢弃 | QUIC Stream |
best_effort | 消息允许丢失，接收端以最新可用数据为准 | QUIC Datagram |
典型使用：
- RPC 请求、响应、订阅确认、错误消息应使用
reliable； - 高频状态、传感器快照、可被下一帧覆盖的数据可使用
best_effort； - 安全相关控制消息即使使用低延迟通道，也必须结合时效性、Sequence 和连接状态校验；
reliable 只表示传输可靠，不表示业务一定成功。业务成功与否仍由响应消息或错误消息表达
时效性
时效性描述消息从产生到被接收处理之间允许存在的最长时间。超过有效期的消息应被接收端丢弃或标记为 stale，不应继续驱动业务状态
时效性判断依赖帧头中的 source_mono_timestamp 和 Flow QoS 中授权的 TTL。由于 APP 与本体的系统时间默认不同步，接收端不能直接用两端系统时钟相减判断过期，而应基于单调时钟同步或等价的时钟转换机制估算消息年龄
接收端使用服务端授权的 Flow TTL 判断是否过期
TTL 不放在通用帧头中，因为 TTL 属于服务端授权的 Flow QoS，发送端不得逐包自报 TTL
活性
活性描述一个请求或持续 Flow 在多久没有进展后被判定为失活
对于 Request/Response 型消息，活性表现为请求超时：
- 请求发出后，若在授权或默认超时时间内没有收到响应，则请求方应判定请求失败；
- 响应晚到时，应通过
message_id、related_id和请求状态判断是否仍可接受；
对于持续数据流，活性表现为消息间隔超时：
- 若订阅 Flow 在授权时间内没有收到新消息，接收端可将该 Flow 标记为 inactive；
- inactive 不一定表示 QUIC 连接断开，只表示该业务 Flow 没有按预期产生数据；
- 应用层按本地策略据此触发告警、重订阅、降级显示或安全停机；
活性检测允许借助心跳或统计信息实现，但心跳本身属于协议层会话健康机制，不属于狭义 QoS 属性
频率限制
频率限制描述该 Flow 在单位时间内允许发送或接收的消息数量与字节量
频率限制至少应覆盖：
- 最大消息频率；
- 最大突发数量；
- 最大字节速率；
- 超限后的处理策略；
接收端应在 Flow 上下文中维护 Rate Limiter。超限消息处置方式必须由该 Flow 的业务类型和授权结果决定，取值包括丢弃、延迟处理、触发降级或关闭 Flow
频率限制主要用于：
- 防止高频状态或日志数据挤占控制消息；
- 限制异常客户端或异常模块产生过量数据；
- 约束动态订阅的资源消耗；
- 为调试、告警和限流统计提供依据；
与帧头字段的关系
QoS 的执行依赖通用帧头中的若干字段，但这些字段本身不是 QoS 属性：
| 字段 | 与 QoS 的关系 |
|---|---|
channel_id | 查询 Flow 上下文 |
message_type | 校验消息类型是否符合该 Flow 授权 |
flow_epoch | 校验 Flow QoS 版本，隔离旧授权下的迟到消息 |
source_mono_timestamp | 用于消息时效性判断 |
sequence | 辅助乱序、旧包、重复包识别和丢包统计 |
message_id / related_id | 辅助请求超时、ACK、错误和日志追踪 |
其中 flow_epoch 是动态 Flow 的 QoS 版本标识。当服务端更新 QoS、重建订阅或复用 channel_id 时，应递增 flow_epoch。旧 Epoch 的消息晚到时，接收端应丢弃或按兼容窗口处理