Jetty服务器场景下握手异常与连接拒绝异常的区别及问题分析

嘿，我来帮你把这两个异常的区别掰扯清楚，这样你就能精准定位Jetty服务器流量激增时的问题了：

1. javax.net.ssl.SSLException: Handshake did not complete within 10000ms #

这个异常是SSL握手超时——TCP连接其实已经成功建立了，但SSL/TLS握手的流程（比如客户端和服务器交换证书、协商加密算法、交换密钥这些步骤）耗时超过了Jetty默认的10秒阈值，所以触发了超时。

常见触发场景：

• 流量激增时Jetty线程池过载，负责处理SSL握手的线程被排队阻塞，导致握手流程迟迟无法完成
• 服务器CPU被加密请求占满，握手所需的加密运算速度跟不上
• 网络延迟突然变大，握手过程中的数据包往返耗时超出了超时时间

简单总结：连接已经通了，但SSL握手的步骤没在规定时间内做完。

2. java.net.ConnectException: Connection refused #

这个异常是TCP连接被直接拒绝——连最基础的TCP连接都没建立起来，服务器直接把请求挡在了门外，更别说后续的SSL握手了。

常见触发场景：

• Jetty线程池（甚至操作系统的监听队列）已经满到极限，服务器根本没法接收新的连接请求
• 防火墙拦截了目标端口的流量
• Jetty服务临时挂掉或正在重启（不过如果只在流量激增时出现，大概率是队列满了）

简单总结：连TCP连接都没建立成功，完全没到SSL握手那一步。

快速对比表 #

给你个小建议：你的线程池设了50但还是扛不住突发流量，可以试试调整Jetty的acceptors和selectors参数来优化连接管理，或者优化加密请求的处理逻辑降低CPU消耗。也可以临时调大SSL握手的超时时间，但这只是缓兵之计，解决资源瓶颈才是根本。

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