WWDC2016-Session724（APNS新特性）

简要回顾

APNS是苹果的推送服务器，此篇主要讲一下2016年APNS的新特性

苹果的工程师上来就回顾了一下去年在APNS上所推出的改进，例如：

• 支持HTTP/2的API（采用二进制编码）
• 服务器通信可以做到及时响应
• 可以推送的文件内容扩展到了4KB
• 以及简化的证书管理

通过下图可以简要的看一下基于HTTP/2提供的API

1. 客户端通过设备与APNS通信，
2. APNS返回给客户端DeviceToken，
3. 客户端将DeviceToken上传给我们自己的服务器。
4. 接下来我们的服务器与APNS进行通信
5. 每一次服务器将推送信息传递给APNS,都会附带一个DeviceToken的Request,同时APNS也会返回一个Response。

同时还简化了推送证书的管理，不论是开发环境还是发布环境，应用推送，VOIP推送以及并发推送，都用一个证书进行管理，大大的简化了流程

Token Authentication

上文讲到，推送通知的时候会附带一个Token,接下来会讲这个Token认证的问题

新出的Token Authentication

1. 简化了我们的推送服务器与APNS通信的过程
2. 提高了安全性
3. 创建Token很简单
4. 不再有过多的过期证书
5. APNS不会在服务失效时关闭连接
6. 每一次发送通知，都会附件一个客户端证书中的应用标识。

证书验证 和 Token验证

结合上面的两张图，我们仔细的梳理一下证书验证和Token验证通信过程

TLS（是“Transport Layer Security”的缩写），中文叫做“传输层安全协议”。

我们先来看看证书验证

1. 通过开发者账号，生成一个证书
2. 当Provider与APNS通信时，APNS会返回一个证书给Provider服务器。
3. Provider需要对这个证书签名并且信任，然后再将客户端证书返回给APNS。
4. 此时APNS和Privider就构建了一个可信赖的通信通道。

再来看看Token验证

1. 由我们的开发者账号生成一个Service Key，要包含你的Team ID,并且要为他签名
2. Service Key通过加密算法，生成一个加密后的Token

随后每一次Provider向APNS推送信息的时候，所发送的Request都必须有这个Token和推送的内容.

在Provider与APNS通信的过程中：

• 如果Token验证正确，那么接下来处理需要推送的部分，随后再返回状态码等相关信息。
• 如果Token验证失败，直接返回错误码信息。

构建 Token

首先，到开着发中心创建一个 Service Key。

其次，利用Json Web Token构建Token。

上面一共是三个部分，每一个部分都是通过 base-64 编码过的 URL形式

//  “alg”是加密方式，采用的是 ES256 加密
//  "kid"是 Key 的标识符，是用来给 Token 签名的
//  "iss"是Team ID 等团队信息
//  "iat"是初始化的时间戳
//  "signature"是针对上面的内容进行加密以后，再利用 Base64 加密

下图是使用HTTP/2构建的一个使用Token认证的请求

下图是一个错误的Response

注意点

1. 签名的Token需要不定期的生成，原则上是一小时，但考虑到性能因素，如果T欧肯有效就可以继续使用
2. Sign Key是不会失效的
3. 如果Sign Key有错误，可以通过开发者中心进行撤销并重新创建
4. 目前证书认证和Token认证两种方式同时有效