程序员的自我修养
Home » APNs, Scala语言 » APNS HTTP/2 client端遇到的坑

APNS HTTP/2 client端遇到的坑

8条评论2,226次浏览

MAX_CONCURRENT_STREAMS

这个坑排查时间最长。苹果官方文档上没有关于settings的说明,但测试和生产环境中服务器返回的settings是settings={HEADER_TABLE_SIZE=4096, MAX_CONCURRENT_STREAMS=500, MAX_FRAME_SIZE=16384, MAX_HEADER_LIST_SIZE=8000}。而MAX_CONCURRENT_STREAMS=500的意思就是一个channel(就netty而言)最多同时并发500个stream。

若本地不限制stream的并发数,则会报错:Stream does not exist: $streamId。解决方法很简单,自己实现一个Channel进行计数即可。当服务器返回结果时调用decr()。

Connection reset by peer

报错信息就是Connection reset by peer,现象就是channel空闲大约93s的时候会抛出这个异常。

解决方法有2种,1是代码实现中添加ping frame,在connection reset之前ping一次。示例如下:

第二种方法是修改系统的/proc/sys/net/ipv4/tcp_keepalive_time的值,基本上改成60就不会出这个错误了。实际生产环境中,服务器的值通常是60。

openssl版本过低,不支持alpn

若服务器无法升级到openssl 1.0.2及以上的版本就会出现OpenSsl.isAlpnSupported返回false的情况。这种情况下也是2种选择,1是升级openssl;2是采用jdk来实现缺失的alpn部分。其实就是添加对应的jar包,然后启动的时候添加一些额外的命令即可。参考http://www.eclipse.org/jetty/documentation/current/alpn-chapter.html#alpn-starting

发送速度慢,channel频繁超时

建立连接的时候若采用域名,则所有channel的remoteaddress都是同一个ip,会导致发送速度慢,channel频繁超时。可以将连接分散到不同的remoteadress上去:

实测这样做以后,发送速度由2000/s不到提升到最大1.3w/s,且基本上不会出现channel超时的情况。

channel是否要保持不关闭

根据苹果官方文档上所说的,最好保持连接不要关闭,除非是一天发一次这样的频率。

Keep your connections with APNs open across multiple notifications; don’t repeatedly open and close connections. APNs treats rapid connection and disconnection as a denial-of-service attack. You should leave a connection open unless you know it will be idle for an extended period of time—for example, if you only send notifications to your users once a day it is ok to use a new connection each day.

然而实际测试中发现根据域名获取到的最新ip往往发送速度较快。猜测苹果有算法能选出相对比较空闲的服务器。所以这种情况下如果保持连接不断开,下次发送依旧使用这些连接很有可能让请求发送到一台特别繁忙的服务器上去,从而导致发送速度低下。

(转载本站文章请注明作者和出处 程序员的自我修养 – SelfUp.cn ,请勿用于任何商业用途)
分类:APNs, Scala语言
标签:,
8条评论
  1. Sorheart说道:

    同样最近在搞apns的http2接口,最近发现有个奇怪的现象
    每个进程在传输35w条消息后,效率会大大降低,就像是苹果服务器已经不堪重负,博主有遇到这种情况吗

    • yurnom说道:

      测过百万级别的消息,没遇到你说的情况。我这边测试的结果是payload越大发送越慢,channel保持时间越长发送越慢。

      • Sorheart说道:

        最近发消息时频繁出现苹果服务器设置max_cocurrent_stream为1的情况,导致单个连接发送变慢
        Received settings from APNs gateway: {HEADER_TABLE_SIZE=4096, MAX_CONCURRENT_STREAMS=1, INITIAL_WINDOW_SIZE=65535, MAX_FRAME_SIZE=16384, MAX_HEADER_LIST_SIZE=8000}

        很奇怪,之前没遇到这情况,博主没有遇到过?

      • Sorheart说道:

        并且一直收到苹果服务器的goaway frame

        • yurnom说道:

          最近发送速度降的特别厉害,而且大量的connection reset by peer。我和一些开发者交流后大家都有这个现象,最后觉得应该是奥运期间苹果服务器压力太大导致的。

        • yurnom说道:

          看了下日志,确实很多MAX_CONCURRENT_STREAMS=1

  2. Sorheart说道:

    是的,经你这么一说很有道理,我也是速度下降非常明显,同时大量的goaway

  3. Sorheart说道:

    顺带博主可以加个好友吗,我给你邮箱发过邮件的,不过你没回

发表评论


profile
  • 文章总数:79篇
  • 评论总数:339条
  • 分类总数:31个
  • 标签总数:44个
  • 运行时间:978天

大家好,欢迎来到selfup.cn。

这不是一个只谈技术的博客,这里记录我成长的点点滴滴,coding、riding and everthing!

最新评论
  • yurnom: 可能苹果最近又改变了返回值吧,最近没做测试了。 BadDeviceToken一般测试环境和正式环境弄错的情况 下会出现。
  • Anonymous: :razz: 博主,良心贴啊, 最近也在弄apns推送。 有个问题想请教你一下啊。 你博客中写的 Unregistered 错误,有准确的说明吗, 我看你博客中写的:...
  • 一波清泉: 回复邮箱: 1004161699@qq.com 多谢
  • Anonymous: 17/02/09 01:15:02 WARN Utils: Service ‘SparkUI’ could not bind on port 4040. Attempting port...
  • pacificLee: :twisted:
  • 小码: 为什么没有后面的呢,只有前10个
  • Anonymous: :lol:
  • Anonymous: :razz: 楼主是属于会聊天的。 我想问,sqoop发了几个版本了,应该没这些问题了吧。
  • Anonymous: Config.kafkaConfig.kafkaGroupI d 这个是指自己配置的group id 还是从 import org.apache.kafka.common.config .Config 这个类...
  • Anonymous: ZkUtils.getPartitionsForTopics (zkClient, Config.kafkaConfig.topic) 那个方法是在 spark-streaming_2.10 中 kafka...
  • Anonymous: ZkUtils.getPartitionsForTopics (zkClient, Config.kafkaConfig.topic) 你确定 kafka 里面有这个类 ? 个人在kafka 最新 稳定版...
  • Anonymous: :roll:
  • Anonymous: 很不错,试问有java版的吗?
  • Anonymous: 赞
  • Anonymous: 哈哈 看楼主的吐槽乐死了 where子句是可以写的 同样找不到资料 一点点试出来的 select id from xxxx where ${CONDITIONS} and 1=1 and 2=2 limit 4
  • EVIL: 我在运行完C4.5的代码后,显示 defined object DecisionTreeTest 是什么意思?这是有错误吗?运行结果在哪里看?
  • sf: 楼主的问题,我都遇到。。。没办法项目已经定型了,最后都硬着头 皮一个一个的改了源码
  • zz: 我去,楼主你真及时,我们今天上了新的HTTP2 push之后也发现速度曲线很奇怪,开始有200k/min,跟 另一台老的推送协议速度差不多,但是过了一会,立马降到只有几k /min,百思不得其解,我们还用了一个海外代理,在...
  • qi365: :mad: 很可恶,百度助纣为虐~
  • qi365: :? :shock: haha~ very good~