摘要

  • RFC 9846 中的 close_notify 有序关闭连接的一个 TLS 发送方向，为接收方提供密文记录流的截断边界；它不是应用解析、持久化、副作用或结算的确认。
  • 可审计的关闭记录必须把通道末端与另一份应用事务记录关联起来：前者记最后接收的 TLS 记录和关闭告警，后者记事务标识、权威结果与重试规则，二者不能因时间相邻而互相替代。

设想一个支付客户端写入指令、冲刷缓冲区，然后收到服务器发来的 close_notify。TLS 库报告数据结束，没有协议错误。此时客户端若直接把状态改成“已支付”，证据从哪里来？关闭告警并没有提供它。服务器可能读到了字节但拒绝指令，也可能解析成功却在提交前失败；还可能已经提交，只是响应未能返回。甚至服务器可以关闭自己的发送方向，却继续读取另一方向。通道所见事实无法区分这些结局。

RFC 9846 是 2026 年 7 月发布的 TLS 1.3 建议标准，它取代 RFC 8446，同时保留 TLS 1.3 的协议版本，并纳入兼容性澄清与更新。该标准给 close_notify 的职责非常窄：它是连接一个方向的有序关闭告警，发送者借此声明，此连接上不会再发送 TLS 消息。接收方收到告警后，后续数据必须忽略，TLS 实现应向上层应用报告数据结束。

“一个方向”是治理上的关键。任一方都可以发送 close_notify 来关闭自己的写入侧，这不会关闭它的读取侧。客户端可以结束发送而继续收取服务器响应；服务器也可以结束发送但继续接收客户端余下的数据。TLS 1.3 没有把一个方向的告警变成双向同时拆除，更没有把两个方向的关闭拼成分布式提交。

除非已经发送错误告警，每一方在关闭自己的写入侧前都必须发送 close_notify。然而，一方在关闭读取侧之前不必等待对端的 close_notify；不等待会带来可能的截断。因此，两条独立受控的方向产生两项关闭事实。一个事实证明本方如何结束发送，另一个事实证明对端如何结束发送，它们不是应用的两阶段确认票。

这个告警保护的是通道尾部。如果底层传输先于 close_notify 关闭，接收方无法知道发送者发出的数据是否全部到达。经过当前连接状态保护的关闭告警，可以把有序终点与字节流尾部不明消失区分开来。这项保证十分重要，但它只覆盖记录是否在认证通道内完整抵达边界，并不说明接收应用怎样处理边界之前交付的内容。

IANA TLS 参数登记表 为 close_notify 登记了告警描述码。RFC 9846 还恢复了以旧式 warning 等级发送它的要求。“警告”不是“可有可无”，更不是业务上的成功或失败等级。严重度、是否必须发送、应用结果分别回答不同问题。错误告警意味着中止式关闭并阻止后续数据，与有序关闭的状态路径不能混用。

TLS 1.3 也修正了旧版本中可能造成损害的联动：过去接收 close_notify 后立即丢弃待发数据、回送告警并关闭，可能截断接收方仍在使用的发送方向。新规则保持读写方向独立，使应用配置能够完成必要输出，而不是把对端结束发送误解为放弃本地输出的命令。

应用可以在收到关闭告警后冲刷发送缓冲区并立即回应自己的 close_notify。但 RFC 9846 明确提醒，攻击者可以通过延迟告警或延迟应用数据包的传送来影响对端最终收到什么。于是，真正决定事务状态的规则必须位于应用层：例如发送关闭后不再接受新请求，或者在确认操作状态前必须取得完整、可关联的应用响应。

这里要区分交付顺序与结果权威。TLS 保护记录并给记录序列提供经过认证的终点。可靠有序传输支持这样一个假设：关闭写入侧时，待发数据会先于传输销毁而可靠交付。然而 TLS 和传输都不定义应用解析器，不校验事务标识，不分配幂等键，不提交存储，也不签发业务回执。

RFC 9293 描述许多 TLS 连接下方的 TCP 模型，包括单独关闭发送侧。RFC 9110 与 RFC 9112 分别规定 HTTP 语义和 HTTP/1.1 消息成帧。各层可以组合，却不会因此共享同一项完成条件。HTTP 请求需要与之对应的最终响应、完整的消息体和适用的状态语义；队列可能需要持久写入后的代理确认；付款则需要具有稳定操作标识的领域回执。

反方向的误判同样危险。缺少 close_notify 并不证明应用操作失败。应用可能已经提交并发送了回执，随后传输才意外消失。此时缺失的是这个方向的 TLS 截断保证，而非必然缺失业务效果。把每一次无告警断线都自动重放，可能重复执行非幂等操作。

user_canceled 也不能承担事务语义。RFC 9846 用它表达与协议失败无关的握手取消，并要求随后发送 close_notify；接收方在关闭到来前应继续读取。握手完成后通常应使用普通关闭。这些信号描述 TLS 状态，不代表退款、撤单、撤回同意或任何应用层取消已经生效。

标准还把连接生命周期的权力留给具体使用配置。如果某协议允许 TLS 结束后仍在同一底层传输上传输非 TLS 数据，TLS 实现必须先收到 close_notify，才能向应用报告 TLS 数据结束。更一般地说，RFC 9846 不规定使用 TLS 的配置如何管理底层传输，也不规定何时打开或关闭连接。

这条边界防止把流式 TLS 的控制套用到所有加密传输。RFC 9001 使用 TLS 保护 QUIC 握手，却以 QUIC 自己的记录保护和连接关闭机制取代 TLS 的相应机制。RFC 9147 则给 DTLS 1.3 规定数据报环境下的行为。为有序 TLS 流设计的关闭判断，不能仅因底层也使用密码学就直接移植。

身份也仍是另一条控制线。RFC 9525 说明应用协议怎样把服务身份验证纳入 TLS 使用规则。身份判断发生在连接建立及应用规定的上下文中。一次有序关闭不会重新认证任何一方，不会延长授权，不会确认最终操作者，也不会批准最后一项副作用。

事故时间线里，最后一次应用写入、最后一条接收的 TLS 记录和关闭告警经常靠得很近。时间邻近能帮助调查，但不能替代因果回执。服务器可以在工作排队后、执行提交前关闭发送方向，也可以在决定拒绝操作之后关闭。只有拥有业务状态机的应用知道哪一个状态具有权威。

RFC 5116 给认证加密接口提供了更底层的共同语言：认证数据与密文完整性有明确边界。它没有把密码学验证提升为业务意图。TLS 告警受到当前连接状态保护，说明消息来自该通道中的对端；这与说明对端某个业务子系统完成了持久动作，仍隔着一条必须显式跨越的证据边界。

阅读现行规范时，还应保留版本与勘误的可追踪性。RFC 9846 发布记录 给出正式状态和元数据，RFC 9846 勘误页 提供之后核对勘误的入口，RFC 8446 则记录被取代的旧文本。它们让审计者能说明采用了哪个规则版本，却不能提供任何具体部署率、厂商行为或现场事故的推断。

来源