小文章一篇,大家茶余饭后看看。
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线上环境吧
配置 配置 还是配置多一点,代码可配置,流程业务可配置,这个是王者,我们应该多考虑,因为代码上线了 你想改难了。