摘要

  • Sent 的含义是消息衍生的数据已向下进入或穿过底层协议栈，不再由 Transport Services API 负责。
  • RFC 9622 明说此时数据究竟已真正传输、位于网卡缓冲区、内核缓冲区，还是别的状态，要由实现决定；因此它不能成为统一的送达凭据。

许多系统把“已发送”当成一种对外结论：日志据此关闭任务，告警据此停止重试，界面据此告诉用户操作完成。问题不在于本地日志没有价值，而在于一个本地动词悄悄借用了远端事实的权威。究竟是应用放手、内核排队、接口发包、对端接收，还是业务系统处理，分别需要不同的观察点。

RFC 9622 的写法给出了一条干净的界线。这份 2025 年 Standards Track 文档由 Colin Perkins 等人共同署名，定义的是应用与本地 Transport Services System 之间的抽象 API。Send 之后出现 Sent，表示从消息得出的数据已经向下或穿过底层协议栈，API 不再承担它们。但文档紧接着保留了真实的不确定性：数据可能已经传输，也可能仍在网络接口或内核的缓冲区，具体由实现决定。

这不是需要用乐观话术填平的空白。RFC 9621 将属性分为选择、连接和消息三类；应用可以提出要求、禁令或偏好，候选路径和协议栈却还受系统策略与启发式规则影响。优先级同样是有限表达：它可以只影响发送端的本地调度，RFC 9622 不保证系统会怎样实现这一表达。

失败信号也应留在它们实际证明的层次。Expired 表示消息没有在 Lifetime 到期前被发送；SendError 是消息过大、底层栈失败或属性不相容等本地错误。Lifetime 本身只是给系统的提示，并不保证过期后绝不会发送。这些记录适合诊断本机的责任流转，却不能代替远端读取、校验或执行的证据。

因此，审计链应从本地 API 调用继续向外延伸：栈的接手、设备或接口状态、线上观察、对端传输、远端应用处理以及真正关心的业务效果。Sent 精确回答其中一问；把它说得更大，反而会失去它的可靠性。

Sources