您的位置:首页 > 移动开发

移动互联网实战--Apple的APNS桩推送服务的实现(2)

2014-08-25 15:35 691 查看
前记:
  相信大家在搞IOS推送服务的开发时, 会直接使用javapns api来简单实现, 调试也直连Apple的APNS服务(产品/测试版)来实现. 很少有人会写个APNS的桩服务, 事实也是如此. 只是当时我所面临的应用场景有些特殊, 为了测试服务的性能和调试功能方便, 特地写了APNS的桩服务(其实主要原因是当时的iphone测试机, 被小组长"霸占"占为己用, ⊙﹏⊙b汗). 在此写一篇关于APNS桩服务的文章, 以此纪念逝去的"青春", 也希望对读者有所帮助.
  有些事情回想起来, 历历在目, 清晰异常, 仿佛发生在昨天. 犹记一年前, 开发IOS的APNS推送后端服务, 吐血三升...

秉承:
  上一篇文章, 详见: Apple的APNS桩推送服务的实现(1)
  文章简要介绍了APNS协议/证书管理/JSSE的API的一些基础概念和实现原理.

需求分析:
  从开发者的角度去理解和分析需求. 对于IOS的消息推送的功能和性能测试, 大致可分为如下几种:
  1). 推送平台QPS/RT的性能指标
  2). Bad Device Token对服务的影响评估
  3). 证书对服务的影响评估
  4). 推送可靠性评估(推送弱ack机制, 丢消息和消息重复之间的折中)
  通过记录日志来评估QPS/RT和服务的质量, 引入黑名单机制来模拟bad device token对推送服务的影响评估.

技术分析:
  对APNS服务的理解和自身的功能/性能测试需求:
  1). APNS推送服务采用SSL长连接/二进制流/异步的方式来实现, 追求推送消息的吞吐量.
  2). APNS支持V1/V2两种二进制协议, 遇到异常时, APNS的默认行为不一样.
  3). APNS客户端是TSL(SSL)的单向认证(客户端携带证书, 服务端信任检查).
  结合桩的定位, 我们采用One Connection Per Thread的线程池模式去模拟处理它, 一方面能基本满足需求, 另一方面实现高效简单. 同时为了方便测试, 服务端关闭对客户端认证机制.

服务实现:
  APNS模拟桩的实现过程
  1). 服务端证书引入

keytool -genkey -v -alias ssl-server -keyalg RSA -keystore ./server_ks -storepass server -keypass 123456 -dname "CN=Unknown"


  生成效果如图



  2). 自定义TrustManager的实现类

private class MyX509TrustManager implements X509TrustManager {

  @Override
  public X509Certificate[] getAcceptedIssuers() {
    return null;
  }
  // 对服务端证书的认证, 抛出异常表示不通过
  @Override
  public void checkServerTrusted(X509Certificate[] chain, String authType)
      throws CertificateException {
  }
  // 对客户端证书进行认证, 抛出异常表示不通过
  @Override
  public void checkClientTrusted(X509Certificate[] chain, String authType)
      throws CertificateException {
  }

}; 


  评注: 这边提供空实现, 对客户端的证书不进行任何校验
  3). 创建SSLServerSocket代码片段

SSLContext ctx = SSLContext.getInstance("SSL");

// *) 创建KeyManagerFactory类实例
KeyManagerFactory kmf = KeyManagerFactory
    .getInstance(KeyManagerFactory.getDefaultAlgorithm());

// *) 初始化KeyStore, 这边的KEY_PASSWORD为"123456"
KeyStore ks = KeyStore.getInstance(KeyStore.getDefaultType());
ks.load(ApnsStubServer.class.getResourceAsStream("/server_ks"), null);
kmf.init(ks, KEY_PASSWOR.toCharArray());

// *) 进行SSLContext类的初始化工作
ctx.init(kmf.getKeyManagers(),
    new TrustManager[] { new MyX509TrustManager() },
    new SecureRandom());

// *) SSLServerSocket的生成
SSLServerSocket serverSocket = (SSLServerSocket) ctx
    .getServerSocketFactory()
    .createServerSocket(serverPort);
serverSocket.setReuseAddress(true);
// *) 设置Client认证开关关闭
serverSocket.setNeedClientAuth(false);


  评注: 把server_ks代码放到classpath目录下, 同时这边的key_password为"123456", 而不是keystore的密码"server", 注意keypass和storepass的区别
  4). 服务端连接处理代码

// One Connection Per Thread的机制
ExecutorService workerPools = Executors.newCachedThreadPool();

while ( true ) {
  final Socket cliSocket = sslServerSocket.accept();
  workerPools.execute(new Runnable() {
    @Override
    public void run() {
      onHandle(cliSocket);
    }
  });
}


  评注: serverSocket用于接受客户端连接, 并放入工作池去处理
  onHandle函数定义如下:

private void onHandle(Socket cliSocket) {

  DeviceTokenManager dtm = apnsStubController.getDeviceTokenManager();

  DataInputStream dis = new DataInputStream(cliSocket.getInputStream());
  int ch = 0;
  while ( (ch = dis.read()) != -1 ) {
    IVResult<ApnsMessage> result = ApnsProtocolUtility.readMessage(ch, dis);
    ApnsMessage message = result.getValue();
    // 属于不同版本的消息, 进行分发和处理
    if ( ApnsVersion.APNS_BINARY_PROTOCOL_V1 == message.getVersion() ) {
      // *) 如果属于bad device token黑名单
      if ( dtm.judgeBadDeviceToken(message.getDeviceToken()) ) {
        break;
      }
      printMessage(message);
    } else if ( ApnsVersion.APNS_BINARY_PROTOCOL_V2 == message.getVersion() ) {
      // *) 如果属于bad device token黑名单
      if ( dtm.judgeBadDeviceToken(message.getDeviceToken()) ) {
        // 8 为令牌错误, 就是bad device token
        ApnsProtocolUtility. writeResponse(8, message.getIdentifier(), cliSocket.getOutputStream());
        break;
      }
      printMessage(message);
    }
  }
}


  5). 黑名单的引入和接口定义

  由外置黑名单文件来指定

public class DeviceTokenManager {

  // 用于配置参数的初始化
  public void init(Properties prop);

  // 判断是否为bad device token
  public boolean judgeBadDeviceToken(String deviceToken);

  // 载入bad device token 名单
  private void loadBadDeviceTokenFile(String filename);

}


  总结: 难点在于JSSE和证书的理解, 至于APNS的网络协议, 处理还是相对简单的.

APNS推送服务平台:
  对于APNS推送服务平台, 还是有些优化技巧, 这边并不深入展开, 仅从个人的观点描述几个.
  1). 对gateway.push.apple.com的ip地址解析, 挑选rrt时间最短的服务ip进行连接
  


  2). 引入队列异步化/构建DadDeviceToken仓库
  作为推送服务, 对于推送请求, 作简单的校验(消息格式合法/是否属于bad device token). 然后储存消息于队列中, 由后端worker慢慢消化. 不再等待真实的APNS服务反馈(APNS服务弱ACK机制), 立即返回结果(允许一定程度的推送成功误报率).
  构建自己的Bad Device Token仓库, 一方来自Feedback服务接受, 一方来自APNS推送的响应结果收集.

后记:
  感觉自己还是没有把自己想表达的事情说清楚, 甚是遗憾. 无论如何, 还是希望对读者有些帮助, 对我而言, 则是充满了回忆. Fighting, Let it go!!!
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: 
相关文章推荐