Rustls项目中半关闭连接状态处理的改进探讨

在Rustls项目的0.23.4版本中，开发者在使用无缓冲(unbuffered)接口时发现了一个关于TLS连接半关闭状态处理的问题。这个问题揭示了当前API在处理连接关闭流程时存在的一些局限性，特别是当通信双方需要分阶段关闭连接时。

问题背景

在TLS协议中，连接关闭是一个需要双方协商的过程。通常情况下，一方发送关闭通知(close_notify)后，另一方可能还需要发送一些数据，然后再发送自己的关闭通知。这种分阶段关闭的方式被称为"半关闭"。

在Rustls的无缓冲接口中，当前的状态转换机制将半关闭视为完全关闭，这导致了一个实际应用场景无法被正确处理：当客户端发送一个字节后关闭连接，服务器尝试发送一个字节再关闭时，服务器无法获得必要的WriteTraffic状态来发送其数据。

技术细节分析

当前的ConnectionState状态机在处理关闭流程时过于简化。当接收到Closed状态后，连接就被视为完全终止，无法再进行任何数据写入操作。这与TLS协议的实际需求不符，因为在真实场景中：

1. 一方可能先接收完所有数据并读到对方的关闭通知
2. 然后还需要发送自己的剩余数据
3. 最后发送自己的关闭通知

解决方案探讨

Rustls维护团队提出了一个改进方案，通过扩展ConnectionState枚举来更精确地描述连接关闭的各个阶段：

1. ReadTraffic：读取对方的关闭通知
2. PeerClosed：通知应用层对方已关闭，不会有更多数据到来
3. WriteTraffic：允许应用层发送剩余数据
4. EncodeTlsData：编码TLS数据
5. TransmitTlsData：确认数据已发送
6. Closed：最终完全关闭状态

这种设计保持了Closed作为终态的性质，同时增加了必要的中间状态，使得应用能够正确处理半关闭场景。

对开发者的影响

对于使用Rustls无缓冲接口的开发者来说，这一改进将带来更灵活的连接管理能力。特别是在需要精确控制连接关闭流程的应用中，如某些需要确保所有数据都已传输完毕的场景。

值得注意的是，由于ConnectionState枚举被标记为non_exhaustive，添加新状态不会造成语义版本兼容性问题。这使得改进可以相对平滑地进行，而不会破坏现有代码。

最佳实践建议

在使用Rustls无缓冲接口时，开发者应当：

1. 完整处理所有可能的连接状态
2. 为EncodeTlsData准备足够大的缓冲区(建议至少18KB以符合协议最大需求)
3. 实现适当的状态转换逻辑，特别是在处理连接关闭时
4. 考虑在应用中维护自己的连接状态机，与Rustls的状态协同工作

这一改进将使Rustls的无缓冲接口能够覆盖更多实际应用场景，为需要高性能和精确控制TLS连接行为的应用提供更好的支持。