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