http://blog.csdn.net/tlq1988/article/details/9612237
首先说明一下，本文只是介绍一些容易被开发者忽视，而导致性能低下问题。并不是介绍如何向苹果设备成功发送一条消息，这里假设所有阅读者已经能够向苹果服务器发送消息，并且成功接收，只是发送效率比较低，并且丢失率很高。如果你不是此类情况，那么绕道吧。PS：伸手党可以直接看标红部分（结论）
最近参与并且完成了公司1000W级的消息推送服务平台重建。此次重构级别解决了消息丢失，并且大幅度提升了推送效率。有些东西我想很多开发者也会碰到，并且难以被开发者所意识到。
先先扫下盲哈。如果你发送消息是一次连接发送一条，那么请你先改成长连接发送--一次连接发送多条数据。粘下PHP代码吧：）
要往下面说我先解释一下这个东东--Broken Pipe，如果你有过大量的数据推送，并且看下你的错误日志那么Writen Broken Pipe你一定不陌生。这个错误产生的原因通常是当管道读端没有在读，而管道的写端继续有线程在写，就会造成管道中断。可以简单的理解为你在向一个已经关闭的连接写数据就会抛出这个错误。
由于Broken Pipe的关系，我们不得不重新和苹果服务器建立连接，这个连接耗时在国内.....（你们懂的3sec+），这个应该是我们推送速度最大的瓶颈了。有很多开发者也许会认为这个是由于国内的网络环境导致，因为他们习惯的“traceroute>你就错了。
我们用大量（10W左右）能保证基本正确的Device Token来做测试，平均一次连接的能写入3W左右的数据，好的情况下能一次写完这10W数据！！！这个测试也就证明平凡出现Broken Pipe不是由于网络原因。既然不是由于网络原因，那么我做个大胆的假设：这个连接是由APNs主动断开的。
那么假设这个猜想是正确的，那苹果什么时候会断开连接了？解释这个问题，我们又做了一个测试：往这10W的Device Token里面均匀插入1000个错误的Device Token。神奇的事情发生了，发送期间平均断开连接900次+。这个实验正好验证了我之前的猜测：产生Broken Pipe是因为APNs服务器主动断开了连接，并且是由于错误的Device Token引起的（或者其他的错误）。苹果的错误类型和代码编号：
| Status code | Description |
|---|---|
| 0 | No errors encountered |
| 1 | Processing error |
| 2 | Missing device token |
| 3 | Missing topic |
| 4 | Missing payload |
| 5 | Invalid token size |
| 6 | Invalid topic size |
| 7 | Invalid payload size |
| 8 | Invalid token |
| 10 | Shutdown |
| 255 | None (unknown) |
我们进一步跟进测试，我们发现一个奇怪的现象，断开连接的时的前一个Token并不是我们所特意设置的错误Token。同时我们也发现消息送达率也变得非常的低（偶尔有设备能收到）。这个很好解释，之前我就有文章提到过（官方也有相应说明）当一次连接先发送一个错误的Token，之后的有效Token的消息是无法送达的(http://blog.csdn.net/hjq_tlq/article/details/8131115)，这就导致了错误的Token后面的正确的Token全部没有收到，从而送达率也就明显下降了。
经过上面的测试，当APNs接收到错误的Token的时候会主动断开连接，但是断开连接之前会有1sec左右的延迟。那么你可以有下面这个例子理解：
你要发送1000条数据并且第20个Token是错误的
当此次连接发到第20个Token的时候苹果认为此次连接终止(但是连接并没有断开，只是APNs将抛弃之后的内容)，并且不处理此次连接之后的消息
1sec左右的时间之后苹果主动断开SSL连接，如果你继续忘此连接写数据，你将可以捕捉到Broken Pipe错误
此时由于1sec左右的延迟，你已经发送到了第123个消息
此时从20以后直至123的消息将全部没有送达
太可怕了.....你竟然不知道是从哪一个错了！！！苹果是SB啊！先不要做这样的结论，我们先看一下苹果官方文档所给出的东东：
Figure 5-1 Notification format
The first byte in the notification format is a command value of 1. The remaining fields are as follows:
Identifier—An arbitrary value that identifies this notification. This same identifier is returned in a error-response packet if APNs cannot interpret a notification.
Expiry—A fixed UNIX epoch date expressed in seconds (UTC) that identifies when the notification is no longer valid and can be discarded. The expiry value uses network byte order (big endian). If the expiry value is positive, APNs tries to deliver the notification at least once. Specify zero (or a value less than zero) to request that APNs not store the notification at all.
Token length—The length of the device token in network order (that is, big endian)
Device token—The device token in binary form.
Payload length—The length of the payload in network order (that is, big endian). The payload must not exceed 256 bytes and must not be null-terminated.
Payload—The> PS：这里苹果到是做了件好事，这个消息结构在早些的文档中显示的是5-2 Enhanced Notification Format，而之前的5-1是Notification Format。区别在于之前的5-1中的消息结构为简单消息结构，没有Identifier和Expiry字段并且Command为0。现在直接把简单的消息体结构给去掉了，这样可以强制开发者加上Identifier，从而得到返回值。
为了方便我直接把官方文档粘过来了哈：）我们需要注意的是Identifier这个东东。没错，这个就是苹果用来提供的给第三方的4唯一标示，如果鸟语不是很好的话他后面的那个注释大致就是说：一个消息的唯一标识。如果苹果服务器不能解释这个消息，那么将在错误中返回这个唯一标示。
可恶的苹果并没有说明这个会有延迟，以及怎么确保我们能收到这个错误。我们现在采用的是每发送100条消息，就检查一下（read）是否有失败的。如果你抓到这个错误，那么果断断开连接，并且重新发送这条错误以后的Token，这样就能保证消息基本能送达。
哦，顺便说一下如何得到错误反馈，如果你发送的时候加上了Identifier，那么此时你一定有一个和APNs的连接吧（废话，没连接怎么write），那么你只要read就好了，如果有就能读到一个二进制数据：）
有一个也需要提一下，就是APNs的FeedBack功能也一定要用上，这个能帮助你更好的剔除错误的Token。
当你的Token基本为正确的时候，如果还有大量的Broken Pipe出现，你可以给我留言，我们一起研究到底哪里出问题了：）
附录：苹果推送官方文档
