java 11释放了TLSv1.3支持，默认使用。
在HTTPS和SSL插座的背景下，它可以正常工作，但是当使用SSLEngine时，由于TLSv1.3行为的变化而存在其他障碍。
因此，使用NIO可以通过CC_4实现强大的通信，而当启用TLSv1.3时，它不再起作用。没有明显的错误，以例外或SSL错误的形式，两个节点只会来回发送包装/解开邮件，最终将超时发送。
我对使用TLSV1.2和SSLENGINE使用TLSV1.3的SSLENGINE之间的行为更改感兴趣，如果可能的话，这些行为更改之间的行为更改感兴趣。不幸的是，Java 11的Sslengine Javadocs没有此信息 - Java 11中没有新方法，也没有提及TLSV1.3。
的确，没有明确的引用TLS 1.3对SSLEngine在JDK 11中的Javadoc中的影响，并且其方法没有变化。
但是，在JDK 11中的Javadoc开始时，SSLEngine阶段列表中的第五项（关闭）在一般说明中进行了更新：
关闭 - 当不再需要连接时，客户端和 服务器应用程序应分别关闭其各自的两侧 连接。对于
SSLEngine对象，应用程序应致电closeOutbound()并将剩余的任何消息发送给对等。同样地， 应用程序应从对等方面接收剩余的消息 在调用closeInbound()之前。基础运输机制可以 然后在关闭SSLEngine的两侧后关闭。如果 连接未以有序的方式关闭（例如closeInbound()在对等写闭合通知之前被调用 已收到），将提出例外，以表明 错误发生了。一旦关闭引擎，它就无法重复使用： 必须创建新的SSLEngine。
在JDK 11：
的Oracle发行说明中也讨论了更改TLS 1.3半关节策略
一个新的系统属性，jdk.tls.acknowledgeCloseNotify已添加。默认值的默认值 系统属性是错误的。如果系统属性设置为true，则 接收到相应的close_notify alert接收到close_notify警报，连接将关闭。tls 1.2和先前的版本使用双链交易策略，而TLS 1.3 使用半关节政策。入站和出站关闭_notify TLS 1.3的警报是独立的。升级到TLS 1.3时， 如果您的应用程序关闭，可能会发生意外行为 （d）仅使用
SSLEngine.closeInbound()或SSLEngine.closeOutbound()API，但在 联系。如果您的申请表现出意外的悬挂或超时 当基础（D）TLS运输未关闭双链体时，您 可能需要将此属性设置为true。请注意，当不再需要TLS/DTLS连接时 服务器应用程序应关闭其两侧 各自的连接。
因此，将jdk.tls.acknowledgeCloseNotify设置为 true 可能会解决您对与TLS 1.3一起使用SSlEngine时的特定关注：
如果您的应用程序显示出意外的挂起或超时当基础（d）TLS运输未关闭时，您可以 需要将此属性设置为true。
发行说明文档还链接到封闭的JDK Bug JDK-8208526：TLS 1.3半相关和同步问题，该问题讨论了更改的更改。
相关（和关闭的）错误JDK-8207009：TLS 1.3半关节和同步问题也可能引起人们的关注。
其他参考：
- 请参阅RFC 8446的" 附录D.向后兼容"：" 传输层安全性（TLS）协议版本1.3 "（pp。138-141）。<<<<<<<</li>
- 在此Oracle视频" 星期一技术会议：Moscone West 2004 "中，TLS 1.3与更早版本之间的兼容性进行了简要讨论。li>
最后，我们需要在握手完成后读取来自缓冲区的剩余数据，拆开并更新握手状态。看起来像是我们以前没有处理过的边缘外壳。
相关提交：IGNITE-11298修复以支持通信中的TLSV1.3