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

APNS HTTP/2 client端遇到的坑

8条评论4,742次浏览

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说道:

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

发表评论给Sorheart


profile
  • 文章总数:81篇
  • 评论总数:247条
  • 分类总数:32个
  • 标签总数:45个
  • 运行时间:1250天

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

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

最新评论
  • Anonymous: :?: :razz: :sad:
  • Anonymous: 牛
  • Anonymous: 楼主你好,我偶尔也会 遇到Reconnect due to socket error: java.nio.channels.ClosedCha...
  • Anonymous: sdfs
  • Anonymous: :arrow: :neutral: :cry:
  • Anonymous: java.io.NotSerializableExcepti on: DStream checkpointing has been enabled but the DStreams with their...
  • wick: HI,请问一下,U,S,V得到 ,怎么得到近似矩阵 (用spark java),谢谢。
  • Michael Whitaker: Thank you for this blog, it was very helpful in troubleshooting my own issues. It seems that no...
  • Anonymous: :mad:
  • Anonymous: :???:
  • Anonymous: :mad: :mad: :mad:
  • 洋流: 哥们,我问个问题,你 把testOnborrow去掉了。。 如果得到的jedis资源...
  • 洋流: 哥们,我问个问题,你 把testOnborrow去掉了。。 如果得到的jedis资源...
  • Anonymous: :razz: :evil: :grin:
  • 张瑞昌: 有很多,比较常见的是 Jacob迭代法,一次迭代O (n^3),迭代次数不清楚 ...
  • Anonymous: :mrgreen:
  • lc277: 你好 我想问下一般删除节点 要多久,要删除的datano de大概用了1t,解除...
  • Anonymous: 你好 我想问下一般删除节点 要多久,要删除的datano de大概用了1t,解除...
  • Anonymous: :smile: :grin: :eek:
  • 李雪璇: 想要完整代码,可以帮 忙发给我吗