问题描述
Java 11发布时支持TLSv1.3 ，默认使用。
它在HTTPS和SSL套接字的上下文中工作正常，但似乎在使用SSLEngine ，由于TLSv1.3行为的变化而存在其他障碍。
因此，使用SSLEngine通过NIO进行通信的强大实现在启用TLSv1.3时不再有效。
没有明显的错误，以异常或SSL错误的形式，两个节点将只来回发送包装/解包消息并最终超时。
我对使用TLSv1.2的SSLEngine和使用TLSv1.3的SSLEngine之间的行为更改的确切列表感兴趣，并且如果可能的话，我们感兴趣的是这些之间的迁移清单。 不幸的是，Java 11的SSLEngine javadocs没有这个信息 - 在Java 11中没有新方法，也没有对TLSv1.3的引用。
1楼
确实没有明确提及TLS 1.3在JDK 11中的Javadoc中对SSLEngine的影响，并且其方法没有变化。
但是在JDK 11中Javadoc开头的一般描述中进行了更新：
闭包 - 当不再需要连接时，客户端和服务器应用程序应各自关闭其各自连接的两端。 对于
SSLEngine对象，应用程序应调用closeOutbound()并将任何剩余消息发送给对等方。 同样，应用程序应在调用closeInbound()之前从对等方接收任何剩余消息。 然后可以在关闭SSLEngine两侧之后关闭基础传输机制。 如果连接未按顺序关闭（例如，在收到对等方的写入关闭通知之前调用closeInbound()），则会引发异常以指示发生了错误。 一旦引擎关闭，它就不可重复使用：必须创建一个新的SSLEngine。
也讨论了这一变化：
TLS 1.3半封闭政策
添加了一个新的系统属性jdk.tls.acknowledgeCloseNotify。 系统属性的默认值为false。 如果系统属性设置为true，相应的close_notify alert将接收时被发送close_notify警报，连接将被关闭复式。TLS 1.2和先前版本使用双工关闭策略，而TLS 1.3使用半关闭策略。 TLS 1.3的入站和出站close_notify警报是独立的。 升级到TLS 1.3时，如果应用程序仅使用
SSLEngine.closeInbound()或SSLEngine.closeOutbound()API中的一个关闭（D）TLS连接，则会发生意外行为，但不能同时关闭连接的每一侧。 如果您的应用程序在基础（D）TLS传输未双工关闭时出现意外挂起或超时，则可能需要将此属性设置为true。请注意，当不再需要TLS / DTLS连接时，客户端和服务器应用程序应各自关闭其各自连接的两端。
所以设置jdk.tls.acknowledgeCloseNotify为真可能会解决您的有关使用超时时特别关注SSlEngine使用TLS 1.3：
如果您的应用程序 在基础（D）TLS传输未双工关闭时 出现意外挂起或超时 ，则可能需要将此属性设置为true。
发行说明文档还链接到已关闭的JDK错误 ，更详细地讨论了更改。
相关（和已关闭）的错误也可能是有意义的。
其他参考文献：
- 请参阅 “ 附录D.向后兼容性 ”：“ 传输层安全性（TLS）协议版本1.3 ”（第138-141页）。
- 在2:53:37和2:56:35之间的Oracle视频“ ”中，简要讨论了TLS 1.3与早期版本之间的兼容性。
2楼
最后，我们需要在握手完成后从缓冲区中读取剩余数据，解包并更新握手状态。 看起来像我们之前没有处理过的边缘情况。
相关提交：