OpenShift代理SSL连接重置解决方法

本文旨在深入探讨在OpenShift平台上，Java应用通过代理进行API调用时，针对大响应体（长时间请求）出现`javax.net.ssl.SSLException: Connection reset`错误的根源与解决方案。核心问题在于OpenShift Ingress Router的默认30秒超时限制。文章将通过日志分析定位问题，并提供调整路由超时配置的具体步骤，同时给出相关注意事项与最佳实践，帮助开发者有效解决此类代理连接中断的困扰。

问题现象与初步排查

在一个Java应用中，我们使用Unirest库通过API（例如https://www.quantumaxis.com.br/apibasic）进行数据库的定时更新。当API响应体较小，请求在30秒内完成时，一切运行正常。然而，对于那些需要传输大量数据，导致响应时间超过30秒的请求，客户端会抛出javax.net.ssl.SSLException: Connection reset异常。

一个关键的发现是，如果移除Unirest请求配置中的代理设置，即使响应时间超过30秒，请求也能成功完成。然而，由于应用程序部署在OpenShift容器平台上，出于网络安全和访问策略的考虑，所有对外部域的请求都必须通过代理进行。这使得移除代理并非一个可行的长期解决方案。

以下是Unirest请求的示例代码：

try {
    response = Unirest
        .get(url)
        .header("Authorization", "Basic ")
        .header("cache-control", "no-cache")
        .socketTimeout(500000) // 客户端socket超时设置
        .connectTimeout(500000) // 客户端连接超时设置
        .proxy(proxy, Integer.valueOf(proxyPort)) // 代理配置
        .asObject(QuantumDTO.class);
} catch (Exception e) {
    LOGGER.info(e.getMessage());
}

尽管代码中设置了较长的客户端socketTimeout和connectTimeout，但问题依然存在，这暗示问题可能不在客户端应用本身。

错误日志分析

当出现连接重置错误时，详细的堆栈跟踪日志提供了重要的线索：

kong.unirest.UnirestException: javax.net.ssl.SSLException: Connection reset
    at kong.unirest.DefaultInterceptor.onFail(DefaultInterceptor.java:43)
    ...
Caused by: javax.net.ssl.SSLException: Connection reset
    at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:127)
    ...
    at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:839)
    ... 98 more
    Suppressed: java.net.SocketException: Connection reset by peer: socket write error
        at java.base/java.net.SocketOutputStream.socketWrite0(Native Method)
        ...
        at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:351)
        ... 120 more
Caused by: java.net.SocketException: Connection reset
    at java.base/java.net.SocketInputStream.read(SocketInputStream.java:186)
    ... 116 more

日志中的关键信息是Suppressed: java.net.SocketException: Connection reset by peer: socket write error。这明确指出连接是由“对等方”（peer）重置的，而不是客户端应用程序主动关闭。在这种通过代理进行通信的场景下，“对等方”很可能指的是代理服务器、OpenShift的Ingress Router或更下游的网络设备。考虑到只有在使用代理且请求时间超过30秒时才出现问题，代理或OpenShift路由是主要嫌疑对象。

根本原因：OpenShift Ingress Router 超时

根据OpenShift平台的特性，Ingress Router（路由）是处理外部流量进入OpenShift集群的关键组件。OpenShift Ingress Router有一个默认的超时设置，通常为30秒。当一个HTTP/HTTPS请求通过OpenShift路由转发时，如果整个请求-响应周期超过这个默认超时时间，路由可能会主动关闭连接，从而导致客户端收到Connection reset错误。

这与我们观察到的现象完美吻合：

1. 30秒阈值： 问题发生在请求时间超过30秒时。
2. 代理相关性： 当使用代理时，请求流量会经过OpenShift路由，因此受其超时设置影响。不使用代理时（例如在本地开发环境），请求不经过OpenShift路由，自然不受此限制。
3. “对等方”重置： Ingress Router作为中间代理，它关闭连接的行为会被客户端识别为“对等方”重置。

解决方案：调整OpenShift路由超时配置

要解决此问题，需要调整受影响的OpenShift路由的超时设置，将其延长至足以覆盖最长请求响应时间的合适值。

可以使用oc annotate route命令来修改路由的注解，从而配置HAProxy（OpenShift路由底层通常使用HAProxy）的超时时间。

命令格式：

oc annotate route  --overwrite haproxy.router.openshift.io/timeout=

参数说明：

• ：需要调整超时的OpenShift路由的名称。
• ：新的超时值，例如60s（60秒）、5m（5分钟）。
• ：时间单位，可以是ms (毫秒), s (秒), m (分钟), h (小时), d (天)。

示例：将路由超时设置为5分钟

假设你的路由名称是my-api-route，你可以执行以下命令：

oc annotate route my-api-route --overwrite haproxy.router.openshift.io/timeout=5m

执行此命令后，OpenShift Ingress Router会重新加载配置，新的超时设置将生效。之后，长时间运行的代理请求应该能够成功完成，而不再因30秒限制而被中断。

注意事项与最佳实践

1. 超时值的合理性： 虽然可以设置很长的超时时间，但应根据实际业务需求和API响应时间预期来确定一个合理的值。过长的超时可能导致资源长时间占用，而过短则会再次遇到连接重置问题。
2. 多层超时考量：
   • 客户端超时： (如Unirest的socketTimeout, connectTimeout) 确保客户端自身不会过早超时。
   • OpenShift路由超时： (如本文讨论的haproxy.router.openshift.io/timeout) 这是最常见的中间件超时。
   • 代理服务器超时： 如果你的应用和OpenShift路由之间还有额外的企业级代理服务器，也需要检查这些代理的超时配置。
   • 后端服务超时： API提供方（后端服务）自身也可能有请求处理超时。 确保所有这些环节的超时设置都协调一致，且能满足最长请求的需求。
3. 幂等性设计： 对于长时间运行且可能因网络或超时问题中断的API调用，建议后端API设计为幂等操作。这样，即使客户端需要重试，也不会导致数据重复或不一致。
4. 监控与告警： 在生产环境中，应部署完善的监控系统来跟踪API请求的延迟和错误率。当出现大量连接重置或超时错误时，应及时触发告警，以便快速响应和处理。
5. 逐步排查： 当遇到类似的连接问题时，始终建议从日志入手，结合网络拓扑图，逐步缩小问题范围，从客户端到服务器端逐层排查。

总结

javax.net.ssl.SSLException: Connection reset在通过代理进行长时间HTTP/HTTPS请求时是一个常见问题，尤其是在OpenShift等容器平台环境中。通过详细分析错误日志，我们可以识别出连接重置是由“对等方”发起的。结合OpenShift Ingress Router的默认30秒超时机制，可以确定问题根源在于路由的超时配置。通过使用oc annotate route命令调整路由的haproxy.router.openshift.io/timeout注解，可以有效解决这一问题。在处理此类问题时，全面考虑客户端、中间件（代理、路由）和后端服务的多层超时设置，并结合幂等性设计和完善的监控体系，是确保系统稳定性和可靠性的关键。