我今天意识到这个问题：
http://redth.codes/the-problem-with-apples-push-notification-ser/
是否有这样的技术解释，或者只是Apple不是开发人员友好的。他们可能已将通知排在最后，并忽略了服务器上的无效令牌，允许使用相同的连接成功发送批量通知。我可以稍后使用反馈服务查询无效令牌。从Web开发人员的角度来看，导致关闭连接的无效令牌会导致所有未发送的通知，这对我来说有点愚蠢。或者可能是因为我没有进入套接字编程，因此我忽略了一些明显的细节。有人可以帮我理解这一点。如果这是套接字的限制，那么可能正如博客文章中所建议的那样，Apple应该转移到HTTP。
答案 0 :(得分：1)
我想知道同样的事情，因为APNS服务器的这种行为非常烦人，并且使服务器端的实现更具挑战性。
我认为这种行为的原因是我们发送给Apple的通知格式是二进制的。
让我们假设您使用简单的二进制格式发送两个通知（但解释可以很容易地扩展到更新的格式）：
0 0 32 device-token1 payload-length1 payload1 0 0 32 device-token2 payload-length2 payload2
现在，如果device-token1的长度为32个字节，唯一的问题是它无效（即它与当前推送环境中的任何设备都不匹配），Apple可以如您所愿，跳到下一条消息。
但是，如果缺少其中一个常量字节（命令或有效负载长度），或者传递长度不正确的设备令牌，或者有效负载的长度与您提供的有效负载长度不匹配，Apple将无法知道下一个通知的开始位置。因此，他们会关闭连接，并希望您重新发送无效消息后面的任何有效消息。