简要回顾
APNS是苹果的推送服务器，此篇主要讲一下2016年APNS的新特性
苹果的工程师上来就回顾了一下去年在APNS上所推出的改进，例如：
- 支持
HTTP/2的API（采用二进制编码） - 服务器通信可以做到及时响应
- 可以推送的文件内容扩展到了4KB
- 以及简化的证书管理
通过下图可以简要的看一下基于HTTP/2提供的API
- 客户端通过
设备与APNS通信， -
APNS返回给客户端DeviceToken， - 客户端将
DeviceToken上传给我们自己的服务器。 - 接下来我们的
服务器与APNS进行通信 - 每一次
服务器将推送信息传递给APNS,都会附带一个DeviceToken的Request,同时APNS也会返回一个Response。
同时还简化了推送证书的管理，不论是开发环境还是发布环境，应用推送，VOIP推送以及并发推送，都用一个证书进行管理，大大的简化了流程
Token Authentication
上文讲到，推送通知的时候会附带一个Token,接下来会讲这个Token认证的问题
新出的Token Authentication
- 简化了我们的推送服务器与
APNS通信的过程 - 提高了安全性
- 创建
Token很简单 - 不再有过多的
过期证书 -
APNS不会在服务失效时关闭连接 - 每一次发送通知，都会附件一个客户端证书中的应用标识。
证书验证 和 Token验证
结合上面的两张图，我们仔细的梳理一下证书验证和Token验证通信过程
TLS（是“Transport Layer Security”的缩写），中文叫做“传输层安全协议”。
我们先来看看证书验证
- 通过
开发者账号，生成一个证书 - 当
Provider与APNS通信时，APNS会返回一个证书给Provider服务器。 -
Provider需要对这个证书签名并且信任，然后再将客户端证书返回给APNS。 - 此时APNS和Privider就构建了一个可信赖的通信通道。
再来看看Token验证
- 由我们的开发者账号生成一个
Service Key，要包含你的Team ID,并且要为他签名 -
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
注意点
- 签名的Token需要不定期的生成，原则上是一小时，但考虑到性能因素，如果T欧肯有效就可以继续使用
-
Sign Key是不会失效的 - 如果
Sign Key有错误，可以通过开发者中心进行撤销并重新创建 - 目前
证书认证和Token认证两种方式同时有效
