一、Android6.0的一些修改
因为该问题仅仅出现在Android6.0版本中，因此，考虑是由版本升级引起的。查看Google给出的Android6.0修改文档，发现以下两点：
即：
从Android6.0之后将不再支持HttpClient的使用，建议使用HttpURLConnection代替。
Android6.0之后，在Https请求中，SSL层将不再使用OpenSSL协议，改用自己的BoringSSL协议
在我们的项目中使用的是HttpClient执行Https请求，但是官方升级只是在API文档中删除了HttpClient相关的文件，但是并不影响其使用，用户可以通过以下两种方法继续使用：
使用Android6.0进行编译，则需要添加 org.apache.http.legacy.jar,文件目录：SDK\platforms\android-23\optional；或者是在AndroidStudio中的build.gradle文件中加入：
android {useLibrary 'org.apache.http.legacy'}
使用Android6.0以下版本进行编译。
因此，排除该可能。
因为考虑到是该问题引起的，因此回过头重新对握手失败原因进行查看，发现在之前Log结尾部分忽略了一句话，也正是因为忽略这句话，导致之前思维一直停在可能是HttpClient被取消导致的，浪费了很多时间，握手失败后，在最后边Log中，出现这样的信息：
关键字：BAD_DH_P_LENGTH
经过一番寻找，发现意思应该是Diffie-Hellman的p参数长度错误。主要参考文章：谢谢大神——连接
通过对帖子的阅读和资料的查找，总结其主要原因在于：
Https建立连接之前，会进行多次握手，即单向认证和双向认证。在该过程中，客户端会将自己支持的所有加密方式发送给服务端，供服务端选择，服务端选择好加密程度较高的加密方式后，会以明文或者是客户端私钥加密密文的方式发送给客户端。
具体认证过程可参考我的上一篇文章：Https单向认证和双向认证
在握手过程中，必定会涉及到公钥加密，私钥解密的过程，而该过程中，当服务端选择使用诸如TLS_DHE_RSA_WITH_AES_128_CBC_SHA等算法进行加密时，需要使用到Diffie-Hellman算法进行加密解密，通过阅读Diffie-Hellman算法的介绍，发现在加密解密计算过程中，会使用到两个参数，一个是q，一个是a，而在JDK8之前，服务器端提供的q参数只是用了768bit的长度，而不足1024bit则存在相应的安全漏洞，会被替换后的BroingSSL拒绝，因此出现了Handshake failed错误。
终于找到问题所在了,总结这个纠结的过程，我只想说：一定要认真看Log！！！
通过阅读上边的文档，发现两种可以解决的办法：
升级JDK到8(条件限制，未经过测试)
配置Tomcat服务器，限制加密方式：
修改Tomcat服务器conf/server.xml文件中和Https有关的Connector节点，添加ciphers用于指定密钥：
SSLEnabled="true"
clientAuth="false"
connectionTimeout="20000"
keystoreFile="/usr/xinwei/tienlen/apache-tomcat-https/server.keystore"
keystorePass="xinwei"
maxThreads="150"
port="443"
protocol="org.apache.coyote.http11.Http11Protocol"
redirectPort="8443"
scheme="https"
secure="true"
ciphers="TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,
SSL_RSA_WITH_3DES_EDE_CBC_SHA"
sslProtocol="TLS"
truststoreFile="/usr/xinwei/tienlen/apache-tomcat-https/server.keystore"
truststorePass="密码"
/>
添加完该配置后，重启，测试，Android6.0版本没有再发现Handshake failed错误。
