一次IOS通知推送问题排查全过程

手机数码 投稿 45400 0 评论

一次IOS通知推送问题排查全过程

发现问题

在上周一个将要下班的夜晚,测试突然和我打招呼,说IOS推送的修复更新上线后存在问题,后台报错。

重现问题

看到这个报错后,在网上搜索了一下,这种错误一般都是因为客户端不信任服务端SSL证书导致的,回想工作以来,好像遇到这种问题好多次了,只要将证书导入一下就好了。

由于不能冒然在线上修改解决问题,于是获取推送相关信息(如:设备token后,到自己电脑上去测试,看是否能重现问题。

啪啦啪啦,代码修改完毕,点运行坐等错误出现。

5秒钟过后,发现推送消息发送成功了,没有出现报错,有点懵逼!心里想,代码都是完全一样的啊,怎么线上报错,我这却是好的呢???

纠结了一会,于是开始静下心来分析:

  1. 代码肯定是一样的,应该不是表面上的代码原因。

  2. 其次推送设备也是一样的,应该也不是手机问题。

  3. 那么。

就在没有头绪之际,我又扫了一眼工程目录,发现了jdk8,但我们线上系统使用的是jdk7啊。

于是我将自己工程的jdk8换成jdk7试一下,同样的报错终于出现了!

那为什么jdk8没问题,jdk7却报错呢???

寻找原因

围绕着网上的说法和之前的经验,这错误应该是SSL/TLS握手过程中不信任服务端证书导致的,那办法很简单,去苹果官网找到苹果服务端提供的证书,导入到java的证书信任库cacert文件中即可。

于是,下载了证书文件,并用jdk自带的keytool工具将证书导入到cacert文件中,如下:
如上,导入过程中,发现提示已经有这个证书了,当时没想那么多,再导一次试试吧!

导入后,再次运行代码,结果还是报错!

心里又慌乱起来,没招了,于是又百度/google去了,但搜索出来的结论几乎都是证书信任问题,和自己的招式一样!

同时,也了解了一下SSL/TLS协议相关知识,大致握手过程如下:

详细如下:

  1. clientHello消息,告诉服务端我使用的TLS版本与加密套件等。

  2. serverHello消息,告诉自己选择哪个TLS协议版本与加密套件等。

  3. Certification消息,将自己的数字证书(包括服务器名称、CA和公钥)作为消息内容发给客户端。

  4. Certificate verify校验服务器的数字证书的有效性。

  5. Change cipher spec选择加密套件并生成会话密钥(客户端与服务器之间后续的数据传输将使用此会话密钥)。

  6. 客户端、服务器之间发送加密数据。

另外,jvm有一个的参数,可以把SSL/TLS的握手过程都在控制台通过日志显示出来,如下:

Ok,既然知道了握手过程,那就把SSL/TLS的日志显示出来看一下吧,看看是什么阶段出现的问题,如下:

这说明证书确实已经添加到信任库中了,而详细的SSL日志如下:

如上图,报错发生在clientHello发送之后,在读服务端返回的serverHello消息时,却读到的是警告信息,然后SSL握手就中断了,就好像你在和服务器打招呼,然后服务器回复了一个滚蛋一样!

百思不得其解?

准备放弃

一会,我看到测试走了过来。

测试:“问题解决的怎么样了,啥情况啊” 我:“还不知道,本来以为很简单,实际上并没有,jdk8可以,7不行” 测试:“好吧” 我:”要不升级jdk8吧“ 测试:”能行吗“ 我:”......能行,jdk兼容性都很好,而且其它系统都已经升级过了,这个系统本来也计划要升,问题不大“ 测试:”......好的“

于是,测试去升级jdk8了,本来我应该站在测试身后等待问题被解决,但我还是想在这期间查一查根本原因,于是又琢磨了起来。

发现真相

回想起,这个系统以前本来是jdk6,就是因为苹果强制开发者必须使用Https,且需要TLSv1.2版本,而jdk7才开始支持TLSv1.2,所以这个系统才升级到jdk7,那现在这个报错会不会..。

于是,我赶紧使用TLSv1.2试试,添加jvm参数即可强制https使用TLSv1.2版本协议,如下:

加完后再次运行,报错依旧,那还有那里可能会有问题呢?

我突然灵光一闪,使用jdk7运行一次,再使用jdk8运行一次,将两次的SSL日志对比一下,看看哪里不一样,说不定能找到线索!

于是我马上试运行并对比两次SSL日志,发现两次SSL日志中TLS协议使用的加密套件不同,如下图:

jdk7的调试信息如下 :
jdk8的调试信息如下:
jdk8的TLS握手在服务端ServerHello之后,选择的加密套件是,而jdk7中可供选择的加密套件中没有。

问题差不多清晰了,应该是jdk7中的加密套件,苹果服务器觉得太老不安全,都不支持了,那么如果我使用jdk8,并将加密套件强制为jdk7中的加密套件呢,应该也是会报错的!

于是,我还是使用jdk8,并添加了jvm参数,以强制jdk8使用jdk7的加密套件,如下:

再次运行后,果然报错了!所以应该是jdk8支持了一些新的加密套件,而苹果服务端只认这些新的加密套件导致的。

于是,我去jdk官网,查了一下jdk8的新增特性,发现中AES加密算法的GCM模式在jdk8中才支持,如下:

至此,问题原因全部搞清楚了,测试升级jdk8后也报告推送正常,此时已是10点多,两人写写日报赶紧回家去了.....。

编程笔记 » 一次IOS通知推送问题排查全过程

赞同 (40) or 分享 (0)
游客 发表我的评论   换个身份
取消评论

表情
(0)个小伙伴在吐槽