我在Linux实例上的Java 8 JVM中打开了SSL日志记录，该日志记录再现了问题。使用开启SSL日志记录
-Djavax.net.debug=ssl:handshake:verbose。这揭示了一些有用的信息。
该 解决方法 ，我们在生产中使用，并已被证明对我们的工作是建立在JVM上这个参数：
-Djdk.tls.client.protocols=TLSv1
如果您需要更多详细信息，请继续阅读。
在可以重现问题的服务器上（再次只有5-10％的时间），我观察到以下内容：
*** ClientHello, TLSv1.2--- 8<-- SNIP -----main, WRITE: TLSv1.2 Handshake, length = 195main, READ: TLSv1.2 Handshake, length = 1130*** ServerHello, TLSv1.2--- 8<-- SNIP -----%% Initialized: [Session-79, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256]** TLS_DHE_RSA_WITH_AES_128_GCM_SHA256--- 8<-- SNIP -----Algorithm: [SHA1withRSA]--- 8<-- SNIP -----*** Diffie-Hellman ServerKeyExchange--- 8<-- SNIP -----*** ServerHelloDone*** ClientKeyExchange, DH--- 8<-- SNIP -----main, WRITE: TLSv1.2 Handshake, length = 133--- 8<-- SNIP -----main, WRITE: TLSv1.2 Change Cipher Spec, length = 1*** Finishedverify_data: { 108, 116, 29, 115, 13, 26, 154, 198, 17, 125, 114, 166 }***main, WRITE: TLSv1.2 Handshake, length = 40main, called close()main, called closeInternal(true)main, SEND TLSv1.2 alert: warning, description = close_notifymain, WRITE: TLSv1.2 alert, length = 26main, called closeSocket(true)main, waiting for close_notify or alert: state 5main, received EOFException: ignoredmain, called closeInternal(false)main, close invoked again; state = 5main, handling exception: java.io.IOException: SQL Server returned an incomplete response. The connection has been closed. ClientConnectionId:12a722b3-d61d-4ce4-8319-af049a0a4415注意， TLSv1.2
由数据库服务器选择并在此交换中使用。我发现，当有问题的linux服务连接失败时，TLSv1.2始终是所选的级别。但是，使用TLSv1.2时，连接不会总是失败。他们只有5-10％的时间失败。
现在，这是来自服务器的没有问题的交换。其他一切都是平等的。即，连接到相同的数据库，相同版本的JVM（Java
1.8.0_60），相同的JDBC驱动程序等。请注意，在此情况下，数据库服务器选择的是 TLSv1 ，而不是像故障服务器那样选择的TLSv1.2。
*** ClientHello, TLSv1.2--- 8<-- SNIP -----main, WRITE: TLSv1.2 Handshake, length = 207main, READ: TLSv1 Handshake, length = 604*** ServerHello, TLSv1--- 8<-- SNIP -----Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA--- 8<-- SNIP -----%% Initialized: [Session-79, TLS_RSA_WITH_AES_128_CBC_SHA]** TLS_RSA_WITH_AES_128_CBC_SHA--- 8<-- SNIP -----Algorithm: [SHA1withRSA]--- 8<-- SNIP -----****** ServerHelloDone*** ClientKeyExchange, RSA PreMasterSecret, TLSv1--- 8<-- SNIP -----main, WRITE: TLSv1 Handshake, length = 134main, WRITE: TLSv1 Change Cipher Spec, length = 1*** Finishedverify_data: { 26, 155, 166, 89, 229, 193, 126, 39, 103, 206, 126, 21 }***main, WRITE: TLSv1 Handshake, length = 48main, READ: TLSv1 Change Cipher Spec, length = 1main, READ: TLSv1 Handshake, length = 48*** Finished因此，当在Linux JVM和SQL Server之间协商TLSv1时，连接总是成功的。协商TLSv1.2时，我们会遇到零星的连接失败。
（注意：Java 7（1.7.0_51）始终协商TLSv1，这就是使用Java 7 JVM从未发生过该问题的原因。）
我们仍然有未解决的问题：
- 原因是，从2个不同的Linux服务器运行的同一Java 8 JVM总是会协商TLSv1，但是从另一个Linux服务器连接时，它总是会协商TLSv1.2。
- 而且，为什么TLSv1.2协商的连接在该服务器上大多数（但不是全部）时间都成功完成？
2017年6月10日更新：
Microsoft的这篇文章介绍了问题及其建议的解决方案。
资源：
http://www.infoworld.com/article/2849292/operating-systems/more-patch-
problems-reported-with-the-ms14-066-kb-2992611-winshock-
mess.html
http://www.infoworld.com/article/2849292/operating-systems/more-patch-
problems-reported-with-the-ms14-066-kb-2992611-winshock-
mess.html
http://blogs.msdn.com/b/jdbcteam/archive/2008/09/09/the-driver-could-not-
Establishment-a-secure-connection-to-sql-server-by-using-secure-
套接字层SSL加密.aspx
Java
8，JCE无限强度策略和基于TLS的SSL握手
http://blogs.msdn.com/b/saponsqlserver/archive/2013/05/10/analyzing-jdbc-
connection-
issues.aspx
https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#descPhase2
https://blogs.oracle.com/java-platform-
group/entry/java_8_will_use_tls
