RFC 5238：进入队列不等于报文已经发出

Summary

上层提交握手记录，DCCP 接收了它，但拥塞控制尚未允许放行。如果计时从提交开始，超时就同时包含本地排队和网络往返。计时器声称“没有响应”，却没有证明原请求已经离开本机。

此时生成的重试进入同一队列，占用原本稀缺的发送机会，并可能继续推迟原请求。系统用等待作为复制依据，复制又制造更多等待。

RFC 5238 给出更准确的边界：在接口能够报告时，让 DTLS 等待 DCCP 将消息转交 IP，才开始计算上层响应时间。

DCCP 有连接握手，DTLS 有安全握手。通常先完成 DCCP，再进行 DTLS；为了减少往返，DTLS 记录也可以放进 DCCP-Request 或 DCCP-Response，使两者部分重叠。

但 DCCP 握手可靠，并不意味着其中的 Application Data 必然可靠。服务器可以丢弃这些数据，DCCP 的重传也可以不带首次请求中的数据。于是 DTLS 仍需自己的恢复机制。

嵌入请求的 DTLS 记录只有在 DCCP 握手结束后，才能作为普通数据重新发送。规范因此要求上层计时器等到该边界后再重启，避免多个无法发送的重试在队列里堆积。

两层都使用超时与退避，但各自保护不同对象。DCCP 超时不能证明 DTLS 记录丢失，DTLS 没有响应也不能自动定位为网络丢包。

大型 DTLS 握手可能被 DCCP 拥塞控制拖慢到触发上层重试。新增报文会让建立过程更慢。重传本身不是错误；在已有发送证据之后恢复无响应很合理，在原件仍排队时复制则是推测。

RFC 5238 明确指出，DCCP 报文序列号与其承载的 DTLS 记录序列号没有对应关系，DCCP 同步也不等于 DTLS 防重放。共同封装不创造共同语义。

尺寸边界也依赖当前状态。一个 DTLS 记录必须完整装进单个 DCCP 数据包，并不得超过当时有效的最大包尺寸；该尺寸可能随拥塞状态改变。

握手流量还可能改变随后的拥塞控制状态。CCID 2 下，大型握手可能触发乘性减小，业务流随后等待加性恢复。RFC 5238 建议在需要更平缓变化时考虑 CCID 3，但没有证明某种配置永远更优。

这里应保留两个结论：安全握手完成，以及速率状态适合应用负载。前者不能替代后者。

规范没有提供现行产品、部署、报文轨迹、时延测量、故障或市场采用证据。IANA 只证明参数登记，后续 DTLS 规范只证明标准演进。

DCCP 把数据交给 IP 也不等于物理发送、对端接收或会话可用。它只是比“队列接收”更适合启动上层计时的证据点。

对每次尝试记录提交、入队、拥塞控制决定、交给 IP、序列身份、可观察发送、对端响应、DCCP 状态、DTLS flight 和应用放行。明确每个计时器由谁负责、由什么启动、暂停和取消。

当下层仍报告原请求在队列中时，抑制上层副本。保留迟到响应、取消和被替代尝试，不要把它们统统计入网络丢失。

Lu Heng 的运行现实优先原则在这里非常具体：API 接收工作不等于工作已经执行。计时策略不仅观察时间，还会制造流量，因此必须有可归责的负责人。