1, 8月31日凌晨我们系统与平安系统正式对接（业务大概是他们把订单信息传到
我们的ftp服务器上，然后我们定时去解析，配送完成后，将订单配送结果通过https 返回给平安系统）
晚上订单数据如期到达我们系统，一切都是那么的顺理成章，可是后面的事让人匪夷所思。
大概9点到了公司发现数据不能反馈，一反馈就报异常，很无语。异常大概是
java.net.SocketException: Unexpected end of file from server
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:769)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:766)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1072)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:373)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:318)
所以赶紧网上搜索一番，给出的解释大部分是，客户段被服务段端中断，网络太差也会中断，还有其他原因
shit为什么要中断的我的请求，我很无语。难道说上天非要这样抓弄我么？
我接着迅速开始代码走查，发现不该加密的代码加密解密了，线上没有cer证书文件，以为问题找到了
赶紧走hotfix然后sa帮忙mkdir 文件夹上传文件，重启15分钟过去了，依旧还是那个异常，未果。
中间还n多次没走流程，时间一晃而过，到了晚上10点还没有搞定，我托着疲惫的身体回家了，
还好老婆已经做好了饭，这点要非常谢谢我老婆。
2， 9月1日早上很早到了公司，大概8点多一点，office没有一个人，不过外面鸟语花香，我也心里暗暗的
很自信今天一定要把问题解决，我怀疑是不是linux线上环境对某个文件夹有权限限制，所以我找了看看我们证书
所在的目录发现都是deploy用户所有的，应该不是这个问题造成的，然后陷入了了深深的沉思。
这个时候我想在本地测试测试吧，结果也不能反馈平安，我赶紧联系平安 是否证书有问题？
结果证实怀疑是对的，证书主题弄错了，真是坑爹啊，不过之后平安还是很给力，下午4点给我新的证书
然后我再本地测试环境上连了线上数据库居然惊奇的反馈成功了，期待很久的http返回码200，做开发都知道，报文也正常收到
心里异常的开心，赶紧hotfix吧
下午7点半左右hotfix上去了，不过结果依然让我和同事们都很失望，我无语了，再次潜入深深的思考，久久不能自己，我
到底哪里错了？平安it你不要玩我啊，大家都是做it的，相煎何太急啊。。。。又是一个不眠夜。。。。
3，9月2日早上我7点半早早来了公司，都说是黑色星期五，回想起来还真的确实的黑，黑的看不见你和我的心。
今天我调整了策略，让两位同事也帮忙一起来测试，结果就我一个人的机器可以反馈平安，真是奇诡了，
我怀疑还是代码的问题，结果顾在发现一段代码读取的字节数组并不是utf-8的，迅速fix后，重启电脑
奇迹般的他的电脑也可以反馈了，我们立马上staging测试，结果依然还是那个异常，饿滴神那。我好惨
然后我和同事不甘心，把staging的jdk，tomcat都下载下来放到我们的测试linux上，居然可以奇迹般的反馈
彻底的崩溃了，为什么会这样？玩人也不带这样的啊，不过生活还是要继续，bug还是要修复，
这个时候我深知要好好分析一下，我和同事再认真分析了一下，认为肯定是环境的原因??
但是 都认为是系统级别的，环境啊环境啊你搞的我苦，这期间还请教it3的犇哥，他也不得其法，没有遇到过。
这一夜将无法入眠。外面很安静，我睡不着，我们公司不能被平安鄙视啊。
4， 9月3日-4日，周末，天气不错，可是没心情出去玩，早上8点半给老大打了电话说了这个事，老大安慰我慢慢来，不要急，事情总是
能解决的。
一天就这样晚上搜索相关的文章，最近7点多的时候，我想了能不能分析我们系统出口的数据包是否有证书？
如果有那就是被平安拦截了，再经过一番周折之后，sa同事欣然答应了，他帮忙截取出口的数据包和进口的数据包
发现一款叫什么E什么的工具能分析数据包，数据包截取了开始分析了，发现一次https请求居然24次主动发出
16次服务器反馈，期间有三次握手，
1）小伙子你是平安吗？ 是的啊 xx公司
2）我是反馈给你配送信息的？ 哦 是你啊 ，好久不见了
3）密码是！@##￥￥%………………&&&%%%%？ 你的密码貌似不对啊，你是黑客吧，赶紧闪，不然我找hold姐吓死你
原来分析数据包这么复杂，再经过一番周折之后发现貌似很难分析出 里面带不带证书主题，只知道
一些头信息，内容都是加密的，相当的安全啊，我后怕了。。。。。
这个时候已经凌晨1点多了，算了还是我去研究一下加密的知识吧，
无意中在javaeye找到一位高人的blog： http://snowolf.iteye.com/
可谓密码方面的专家啊，我研读他的blog后，知道了pfx文件意味个人信息交换文件，里面有私钥与公钥
JKS文件（通常为*.jks或*.keystore，扩展名无关）可以通过Java原生工具——KeyTool生成
凌晨还下了一单他写的书java加密与解密的艺术，京东也很给力周日8点半就送到了
此时我还在梦游周公呢，不过还好他叫醒了我的耳朵，这个时候迫不及待了匆匆洗漱之后
研究起此书，临时抱佛脚啊，试试呗，没办法了，看到平安配送经理期待的眼神我很有信心，
知道了base64不是加密算法，keystore truststore可以自己来看是否加载成功？DES是什么算法，
MD5早被破解了，居然还是个女的（虽然这个我认为是假新闻，居然书也这么说，看来是真的）。
看的我心急如焚的，说时急那时快，终于看的差不多了，感觉这个有点复杂了以后慢慢研究吧，还是找sa再问问吧
再问问staging 与我们公司其他部门与平安对接的机器有什么不同吧
出口ip都是一样，jdk6的，tomcat urlencoding都是 utf-8，linux 字符集都是uft-8都是一样的配置，
我提议sa帮忙换一个 新的ip，不要跟现在一样的出口ip测试测试吧，sa欣然同意试一次，死马当活马医了，
就是这个历史的时刻，奇迹出现了，他进球了，他不是一个人再踢球，我也不是一人在写代码。。。
不过我是庆幸的，https返回了状态码 200 ，你懂的 。。。问题 终于解决了，我奔走相告。。。。
此种心情不能言语。。。
总结一下：最终的问题出再对方的ip与证书有匹配，而对方不告诉我，让我忙了4天3夜，希望其他同事可以借鉴分享
我觉得遇到这类问题，考虑可以从以下几个方面来考虑，可以事半功倍，
1） 代码走查，分析代码 代码不会骗人，有问题一定在那里
2）环境问题，jdk版本tomcat版本，打包ant？数据库版本9i，10g，11g，
操作系统，程序是否有权限去访问文件？ 是否文件放在正确的位置
3）网络，是个最奇怪的问题? 是否数据过滤，是否路由问题？虽然我们写应用程序不太了解，但是可以去浅浅的学习
对我们分析问题有很大的帮助。。
日志日志还是日志，日志多一点，特别是项目上线没有日志是可怕的，你不可能去debug线上环境吧
配置 配置 还是配置多一点，代码可配置，流程业务可配置，这个是王者，我们应该多考虑，因为代码上线了 你想改难了。