ios - 为什么 Apple 在发送推送通知时出现错误/无效 token 时关闭套接字/TCP 连接？

Question

我今天意识到了这个问题:

http://redth.codes/the-problem-with-apples-push-notification-ser/

是否有关于为什么会这样发生的技术解释，或者只是因为 Apple 对开发人员不友好。他们可以在他们的末端排队通知，并忽略他们服务器上的无效 token ，从而允许使用相同的连接成功发送这批通知。我可以稍后使用反馈服务查询无效 token 。导致连接关闭的无效 token ，进而导致之后的所有通知都没有发送，从 Web 开发人员的角度来看，这对我来说是一种愚蠢的实现。或者可能因为我不喜欢套接字编程，所以我忽略了一些明显的细节。有人可以帮我理解这一点。如果这是套接字的限制，那么可能会像博文中所建议的那样，Apple 应该转向 HTTP。

Answer 1

我也想知道同样的事情，因为 APNS 服务器的这种行为非常烦人，并且使服务器端的实现更具挑战性。

我相信这种行为的原因是我们发送给 Apple 的通知格式是二进制的。

假设您正在使用简单的二进制格式发送两个通知(但解释可以很容易地扩展到更新的格式):

0 0 32 device-token1 payload-length1 payload1 0 0 32 device-token2 payload-length2 payload2

现在，如果 device-token1 的长度为 32 字节，唯一的问题是它无效(即它不匹配当前推送环境中的任何设备)，Apple 可以跳到下一条消息，因为你会喜欢。

但是，如果您遗漏了一个常量字节(命令或负载长度)，或者您传递的设备 token 长度不正确，或者您的负载长度与您提供的负载长度不匹配，Apple 将无法知道下一个通知从哪里开始。因此，他们会关闭连接并希望您在无效消息之后重新发送任何有效消息。