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