摘要

  • RFC 3758 用 FORWARD TSN 提供通用的序列推进机制，同时把每条消息的放弃条件留给上层服务定义。
  • “定时可靠性”允许实现选择方便的检查时机；时限到达本身并不会强制栈在那一刻执行检查。

时钟归零了，SCTP 栈却仍可能晚些时候才查看那条消息。这不是 RFC 3758 的漏洞，而是它划定的实现边界。

部分可靠传输并非简单地把 SCTP 改成“不可靠”。RFC 3758 允许上层按消息定义传输层还应坚持发送或重传多久。只有在双方于关联建立时协商支持 FORWARD TSN 后，发送端才可放弃某条消息，并通知接收端推进累计传输序列号（TSN）边界。对于有序数据，信号还携带流内序列信息，帮助接收端释放卡在缺口之后的消息。

策略和线上信号承担不同职责。接收端不必知道发送端因时限、重传上限还是其他服务规则而放弃；它只需要知道哪些序列号不再等待，以及哪些有序消息因此可以继续交付。FORWARD TSN 传递的是推进要求，不是发送端作出决定的完整理由。

这一区分从旧 SCTP 的消息寿命规则开始。RFC 2960 里的 lifetime 可以阻止一个尚未首次发送、已经过期的消息发出；但只要它在过期前已首次发送，就仍按普通可靠消息处理。RFC 3758 的 timed-reliability 服务撤销了这个限制：首次发送后，过期消息也可以被放弃。

然而，撤销限制并没有把 lifetime 变成实时闹钟。发送端需要在分配 TSN 前检查消息是否过期；如果 TSN 已分配，也要在发送或重传前检查。RFC 3758 同时明确，不必为每条消息都维护独立计时器。实现可以在已有处理节点检查，例如分配 TSN、准备发送或重传定时器到期时；也可以在其他方便的时机检查。规范没有要求检查必须与消息寿命到期发生在同一瞬间。

所以，接口接受一个 lifetime 值，并不自动构成严格实时期限承诺。该值说明消息在被检查后是否仍适合发送；它不一定规定协议栈何时发现期限已经过去。对时延敏感的应用而言，检查时机应是服务契约的一部分，而不是被埋在传输层实现中的假设。

消息所处阶段也会改变后果。若在分配 TSN 之前过期，发送端可以直接放弃，不留下需要接收端跨越的序列缺口。若 TSN 已经分配，发送端要把数据标为 abandoned，并可能需要发送 FORWARD TSN。分片消息的一个片段被放弃时，RFC 3758 要求其余片段一并放弃。TSN 属于整个关联的序列空间，而有序消息序号属于各自的数据流；同一个控制块要同时协调这两种推进。

FORWARD TSN 不是投递回执。它表示发送端不再追逐某些 TSN，并要求接收端越过这些位置；它不能证明被放弃的载荷曾到达，也不能证明后续消息已被应用接受，更不证明端到端时限已经满足。拥塞控制仍然有效：被放弃的数据不能为拥塞窗口增加确认字节；若该事件原本会触发重传，拥塞调整也不能因此被抹掉。停止追发过期内容可以节省带宽，却不会把传输进展变成业务成功。

关联级能力协商是另一项前提。若对端不支持 FORWARD TSN，该关联就不能使用部分可靠服务。依赖它的应用必须知道协商结果，再决定终止、切换策略或继续使用普通可靠传输。本地栈支持这项功能，不代表对端也接受它。

RFC 7496 后来又定义了限制重传次数和按优先级放弃消息的策略。规则在变化，接收端推进序列空间所需的通用信号则可以保持不变。服务决定什么时候放弃；传输协议决定怎样在放弃后继续往前走。

来源