ios 推送丢失问题

以下要讨论的推送丢失问题，前提是ios已经成功推送，但到达率不高的现象。

推送的整体实现环境：APP推送 架设 | ios 推送 PHP具体实现

在采用app推送后，一度为了追求最大的推送消息量，而将ios推送的一次推送值设为500条，在使用一段时间，发现ios测试机接受到的推送消息时断时续。

例如：
服务端每天08：00 至 13：00 推送给每台装了app的ios设备 一条关于今天的资讯。
按照一切流程正常（排除ios设备网络问题），ios设备接收到的推送信息间隔很大。
ios设备上有时候一连3天都有接收到推送的消息，有时候隔了3天也没见到一条推送消息。很不稳定。

分析
由于在 APP推送 架设 一文中，我们的服务器推送架设，对推送的过程和结果都进行了记录：
1、每成功推送一批消息给apns，都会将这些推送消息和推送动作记录在数据库里（mongoDb）。
2、每建立一次ssl链接，如果中途断掉，将会在日志里面记录断掉的点。

首先翻了一下，每次建立ssl链接后断掉的断点日志：

[ 2013-05-16 09:00:02 ]  [48]  [ 25 - 67214 ] [ <73bcbf1a ...... b400aba6> ]
[ 2013-05-16 09:01:02 ]  [49]  [ 25 - 66858 ] [ <b297d83a ...... 138dde7a> ]
[ 2013-05-16 09:01:02 ]  [49]  [ 25 - 68162 ] [ <5ae010a0 ...... 3c246137> ]
[ 2013-05-16 09:01:03 ]  [48]  [ 25 - 67128 ] [ <f0a03104 ...... 1d4f4b02> ]
[ 2013-05-16 09:01:03 ]  [106]  [ 25 - 65020 ] [ <cfd51575 ...... 4a155252> ]
[ 2013-05-16 09:02:02 ]  [105]  [ 25 - 67846 ] [ <e0e702e2 ...... b1a43c0a> ]
[ 2013-05-16 09:02:02 ]  [138]  [ 25 - 70190 ] [ <403f9325 ...... ef77f6ce> ]
[ 2013-05-16 09:02:04 ]  [106]  [ 25 - 69698 ] [ <7f39be75 ...... db8aafb1> ]
[ 2013-05-16 09:04:02 ]  [106]  [ 25 - 71787 ] [ <03ed937a ...... ed8d23ff> ]
[ 2013-05-16 09:05:02 ]  [48]  [ 25 - 69847 ] [ <ebf76430 ...... 8a6b874d> ]
[ 2013-05-16 09:06:03 ]  [49]  [ 25 - 72995 ] [ <d01b5016 ...... 4d3e3b51> ]
[ 2013-05-16 09:06:03 ]  [146]  [ 25 - 74817 ] [ <7f9ee669 ...... 7ad56199> ]
[ 2013-05-16 09:07:02 ]  [107]  [ 25 - 73025 ] [ <b9768292 ...... 75bf334d> ]
[ 2013-05-16 09:08:03 ]  [168]  [ 25 - 76533 ] [ <bcbb8ccd ...... e49cfdac> ]
[ 2013-05-16 09:08:03 ]  [48]  [ 25 - 75925 ] [ <8724982a ...... 6268d937> ]
[ 2013-05-16 09:08:03 ]  [48]  [ 25 - 75246 ] [ <5164e2a0 ...... 1ead0d83> ]
[ 2013-05-16 09:09:02 ]  [48]  [ 25 - 74579 ] [ <5a3ee344 ...... 579e3b52> ]
[ 2013-05-16 09:09:03 ]  [48]  [ 25 - 72005 ] [ <fd5b29c2 ...... 6150c7a1> ]
[ 2013-05-16 09:11:03 ]  [108]  [ 25 - 79394 ] [ <8a3865c4 ...... 1791ee20> ]
[ 2013-05-16 09:11:04 ]  [49]  [ 25 - 79431 ] [ <a8d1b8fe ...... 530ccc84> ]
......

---日志参数----：
第一个参数：推送的时间
第二个参数：每次运行推送的消息条数
第三个参数：推送对象在内部的标识
第四个参数：推送对象设备在apns的唯一标识

又翻了好几天的断点日志，发现一个很有趣的现象， 即第二个参数出现48的概率远远超过其他，而且是出现的数值里面最低的。结合发生的ios推送丢失现象，因此大胆推测程序每次和apns建立ssl传输数据，apns最多接受48条，超过48条的数据，即使apns接收了，也不会进行推送。如果这个推测成立就可以很好的解释，为啥ios设备接收到的消息时断时续。

解决
那么就行动吧，在推送服务端将ios每次推送的条数为48条，但是提高推送的频率，让总体的推送量没有因此而减少。
又观察了几天的推送情况：
1、建立的推送断点日志没有再产生
2、好几台ios测试设备每天均收到推送的消息，没有再出现断断续续的现象

至此，ios推送丢失问题基本解决了。可以更大规模的应用了。