如何避免SSLSocket优雅关闭时发送"user canceled"告警？

问题背景 #

基于Java 17的Quarkus应用编译为原生可执行文件（ubi-quarkus-native-image:22.2-java17），运行在Kubernetes环境中。通过SSLSocket连接旧集成服务器发送HTTP请求，请求执行完成后调用SSLSocket#close()时，对方服务器收到的是**user canceled告警（代码90）**而非预期的close notify告警。对方将该警告视为错误，会丢弃已完成的响应。

临时方案是在close前调用shutdownOutput()，但该方案在部分服务器上会导致连接关闭失败（这些服务器需要正常的双向close notify完成干净关闭），因此需要合规的通用解决方案。

原因分析 #

直接调用SSLSocket#close()触发user canceled告警，核心原因是SSL关闭流程不符合规范：

1. 标准SSL干净关闭要求双向交换close notify告警：我方发送close notify后，需等待对方返回close notify，再关闭底层套接字。
2. GraalVM原生镜像下的SSL实现（如OpenSSL绑定），若在未完成双向通知流程时强行关闭套接字，会触发user canceled告警；而标准JVM环境下的SSL实现对流程兼容性更强。
3. 若未完全读取SSL输入流中的所有数据（即使业务层认为已读完响应），close时SSL层会判定为异常中断，发送非标准告警。

合规解决方案 #

遵循SSL规范（RFC 5246）的双向关闭流程，确保双方正常交换close notify告警，具体步骤如下：

客户端代码改造 #

替换原try-with-resources的自动关闭逻辑，手动处理SSL关闭流程：

SSLSocket socket = null;
try {
    socket = connect(url, httpChannel);
    // 执行请求并读取所有响应数据（必须确保业务层完全读取HTTP响应的头和体）
    
    // 1. 确保所有输出数据已发送到SSL层
    socket.getOutputStream().flush();
    
    // 2. 关闭输出流，触发发送close notify告警
    socket.shutdownOutput();
    
    // 3. 读取输入流直到EOF，接收对方的close notify告警
    byte[] buffer = new byte[1024];
    int readBytes;
    while ((readBytes = socket.getInputStream().read(buffer)) != -1) {
        // 无需处理数据，仅消耗SSL层残留的输入流
    }
} finally {
    if (socket != null) {
        // 4. 最终关闭底层套接字
        socket.close();
    }
}

服务端代码改造 #

服务端场景下（通过ServerSocket#accept()获取连接），同样遵循相同流程：

SSLSocket clientSocket = null;
try {
    clientSocket = (SSLSocket) serverSocket.accept();
    // 处理请求并发送完整响应
    
    clientSocket.getOutputStream().flush();
    clientSocket.shutdownOutput();
    
    // 读取客户端发送的close notify
    byte[] buffer = new byte[1024];
    int readBytes;
    while ((readBytes = clientSocket.getInputStream().read(buffer)) != -1) {
        // 消耗输入流
    }
} finally {
    if (clientSocket != null) {
        clientSocket.close();
    }
}

关键验证点 #

1. 确保完全读取业务数据：必须保证HTTP响应的所有内容（包括响应体）被业务层完整读取，否则SSL层会残留未处理数据，导致关闭流程异常。
2. 升级Quarkus原生镜像：ubi-quarkus-native-image:22.2对应的GraalVM 22.2可能存在SSL关闭逻辑的兼容性问题，尝试升级到23.x或更高版本的镜像，验证是否解决问题。
3. 切换SSL实现：在原生镜像中，Quarkus默认使用OpenSSL，可尝试切换为SunJSSE实现，通过添加原生构建参数-Djavax.net.ssl.trustStore=/path/to/truststore或配置quarkus.ssl.native=true调整。

为什么临时方案会失效？ #

之前直接调用shutdownOutput()后立即close的做法，跳过了读取对方close notify的步骤，导致部分服务器无法收到我方已确认关闭的信号，进而判定连接关闭异常。完整流程必须包含读取输入流到EOF的步骤，确保双向通知完成。

内容的提问来源于stack exchange，提问作者ewramner