SSL握手问题 [英] SSL handshake problems

问题描述

我们的服务器应用程序在某些客户中极度缓慢。服务器重启会缓慢解决问题，但几周后它就会恢复。

Our server application suffers from extreme slowness at some of the customers. The slowness is solved by server restart, however it returns after a couple of weeks.

Java CPU总是在100％左右（200％以上），所有其他参数都是精细。研究表明，大多数CPU都被HandshakeCompletedNotify-Thread线程所消耗。从tcp dump我们看到SSL握手需要2-8秒，这很长，有时会抛出超时。

Java CPU is always around 100% (out of 200%), all other parameters are fine. Research showed that most of the CPU is consumed by "HandshakeCompletedNotify-Thread" thread. From tcp dump we see that the SSL handshake takes 2-8 seconds, which is very long, sometimes timeout is thrown.

我们的SSL提供商是BSAFE。服务器在Linux（CentOS）上运行，640 MB堆，2个核心。使用Hibernate，spring，Oracle本地数据库

Our SSL provider is BSAFE. Server runs on Linux(CentOS), 640 mb heap, 2 Cores. Hibernate, spring are used, Oracle local db

这种行为可能是什么原因？找到它们可以做些什么？

What could be reasons for such a behavior? What can be done to find them out?

P.S。我们无法在客户处将流量切换到HTTP。

P.S. We can not switch the traffic to HTTP at our customers.

更新：当使用IP表阻止java进程的传出连接时，系统完全释放。在这种情况下释放了什么资源？
我们看到SSL Handshake经常陷入改变密码规范阶段。客户端（我的java进程）尝试重用SSL会话，但服务器完全无状态，每次都会生成新的会话。

Update: The system is completely freed when outgoing connections of java process are blocked with IP tables. What resource is freed in such a situation? We see that SSL Handshake frequently gets stuck at "change Cipher Spec" stage. Client (my java process) tries to reuse SSL session, but the server is completely stateless, it generates new session each time.

推荐答案

这是Sun在6u10推出下一代Java插件时引入的已知错误。 Oracle最终在Java 7u2中修复了它，但他们还没有将它向后移植到Java 6，至少从6u33开始。

This is a known bug that was introduced when Sun rolled out the Next Generation Java Plugin in 6u10. Oracle finally fixed it in Java 7u2, but they have not backported it to Java 6, at least as of 6u33.

可以找到关于bug的详细信息＃7060523 此处。

Details on the bug, #7060523, can be found here.

这篇关于SSL握手问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！