|
Apple has recently updated the protocol push notifications delivery service, called APNS. The newer version of this protocol is based upon HTTP/2 and JSON, which signals a huge improvement compared to the older binary protocol. News HTTP/2 based APNS ProtocolServerServerAPNSAPNSHTTP/2 TLS ConnectionSend Push Notification PN1200 OK PN1Send Push Notification PN2Send Push Notification PN3400 Invalid Token PN2200 OK PN3... New features and capabilities:
苹果最近更新了他们的推送提醒服务协议，APNS。这个新版本的协议基于HTTP/2和JSON，相比于旧的二进制协议，新的协议有了巨大改进。 新的APNS协议基于HTTP/2：
新的特性和功能：
苹果最近推出了APNS，更新了他们的推送提醒服务协议。这个新版本的协议基于HTTP/2和JSON，相比于旧的二进制协议，新的协议有了巨大改进。 新的APNS协议基于HTTP/2
新的特性和功能：
Old APNS Binary ProtocolServerServerAPNSAPNSTLS Socket ConnectionSend Push Notification PN1Send Push Notification PN2Send Push Notification PN3Send Push Notification PN4Invalid Token PN2DisconnectTLS Socket ConnectionResend Push Notification PN3... The old binary APNS protocol was very idiosyncratic. Basically, the push delivery server had to open a socket to the APNS gateway server, and keep on writing to the socket. With this old model, you wouldn’t receive a response if you were successful, but if there were any errors (for example in case of an Invalid Push token) then the server sent back an error code and closed down the socket. On top of that, you had to resend all notifications that you had sent after this invalid token. As a result, you could never be sure if your push was accepted successfully by the server. Many systems used tricks like sending an invalid token on purpose. All of these hacks resulted in lower performance for the system. Apple has a "feedback" service, which you can call periodically to get a list of invalid tokens. The main problem with this service is that you could only call it once to get a list of invalid tokens. So, if an app is using multiple push notification providers, they are going to compete in order to get the list of invalid tokens. The more invalid tokens you have, the lower your performance is, as APNS drops connection for any error. 译者信息
旧的APNS二进制协议
旧的二进制APNS协议有点奇特，一般来说，推送分发的服务器要打开一个同APNS网关服务器的socket连接，并保持这个连接。在旧的协议下，如果服务器响应成功的话，你将不会收到任何回应，但是如果服务器响应失败（例如，使用了一个非法的Push token），服务器将返回了一个错误编码，并关闭这个socket。最重要的是，你必须重新发送使用这个无效token以后发送的所有通知。因此，你可能一直不能确定你的推送是否成功的被服务器接收。许多系统使用这个漏洞，故意发送一个错误的token，这些黑客行为将导致系统性能低下。苹果有一个名为"feedback"的服务，我们可以定时调用这个服务来获取invalid tokens的列表。这个服务你只要调用一次就可以获得所有的invalid tokens 列表。所以，如果一个应用有许多推送通知提供商，他们将会争夺资源去轮询查找invalid tokens列表。invalid token越多，你系统性能将越低，所以APNS只要一发生错误就关闭这个连接。 Some other limitations are still present. It is a complex process to obtain the TLS certificates. There are poor store-and-forward capabilities - APNS stores only a single notification on its server if the device is offline. In addition, there is no upstream messaging from the device back to the server. Google Cloud Messaging has all of these capabilities. There is a bit of competition with GCM and APNS, especially considering the fact that GCM now has added support for iOS. Let's hope for additional APNS features in 2016 译者信息
不过仍然还有一些限制。获取TLS证书比较复杂，而且存储-转发能力弱爆了，APNS在设备下线的时候只保留一个通知，并且设备上线之后也不会向服务器上传信息，Google Cloud Messaging就有所有这些特性。 考虑到GCM现在也支持iOS设备了，那么APNS和GCM现在形成了竞争关系。让我共同期待APNS在2016年的新功能吧。 译者信息
新的协议还是存在一些限制。要想获取TLS证书相当复杂，并且在存储-转发能力上也比较弱（在设备下线时，APNS仅保留最后一条通知，而且当设备上线后，之前丢失的信息也无法继续发送）。Google Cloud Messaging 就不会有这些问题。 考虑到现在GCM也开始支持iOS，与APNS形成了竞争关系。让我们期待在2016年APNS会有更多新的特性吧。 |
|
|
