开发HTTPS协议的REST服务客户端库：遇SSL握手错误是否应重试？

作为常年跟SSL/TLS握手问题打交道的开发者，我得说这个问题不能一概而论——Received fatal alert: handshake_failure只是一个表层错误，要不要重试，核心得看触发这个错误的根源是什么。

哪些情况重试是合理的？ #

• 临时网络波动：比如握手过程中出现数据包丢包、服务器临时负载过高导致响应超时，这类偶发的环境问题，重试1-2次大概率能成功。毕竟网络本身就存在不确定性，短时间内重试往往能绕过临时的故障点。
• 服务器端临时状态变更：比如服务器正在滚动更新、切换证书或者临时调整TLS配置的瞬间，刚好撞上了你的握手请求，这种情况下重试可能就会赶上服务器的正常状态。

哪些情况重试完全没用？ #

如果是下面这些本质上的配置不兼容或信任问题，再重试多少次都是白搭：

• TLS版本/密码套件不兼容：比如你的客户端只支持TLS 1.0/1.1，但服务器已经禁用了这些旧版本；或者双方没有共同支持的密码套件，这种情况必须修改客户端的SSL配置，重试解决不了问题。
• 证书信任链问题：服务器使用的证书不受客户端信任（比如用了自签证书、CA不在客户端信任库中），或者证书过期、域名不匹配，这类错误是握手阶段的硬限制，重试只会重复失败。
• 客户端身份验证失败：如果服务器要求客户端提供证书做双向认证，但你没有配置有效证书，或者证书权限不符合要求，握手会直接失败，重试毫无意义。

给你的实操建议 #

1. 先搞清楚错误根源：开启Java的SSL调试日志（添加JVM参数：-Djavax.net.debug=ssl:handshake），仔细查看握手过程的详细日志——到底是版本协商失败？还是密码套件不匹配？还是证书验证环节出了问题？只有定位到根因，才能决定要不要重试。
2. 做针对性的重试策略：
   • 如果日志显示是偶发的网络类错误（比如连接超时、数据包丢失），可以设置有限次数的重试（2-3次），配合指数退避（比如第一次等1秒，第二次等2秒），避免给服务器造成额外负载。
   • 如果是明确的配置不兼容或信任错误，直接抛出清晰的错误提示，不要重试，让使用者去排查配置问题。
3. 绝对不要无限制重试：不仅会浪费资源，还会掩盖真正的问题，让排查变得更困难。

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