APNS HTTP/2 client端遇到的坑 | 程序员的自我修养

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()。

class H2Channel extends NioSocketChannel {
  private val streamCounter = new AtomicInteger(0)

  override def writeAndFlush(msg: AnyRef): ChannelFuture = {
    streamCounter.incrementAndGet
    super.writeAndFlush(msg)
  }

  def isAvailable: Boolean = {
    streamCounter.get < 500
  }

  def decr() = {
    streamCounter.decrementAndGet
  }
}

class H2Channel extends NioSocketChannel {

private val streamCounter = new AtomicInteger(0)

override def writeAndFlush(msg: AnyRef): ChannelFuture = {

streamCounter.incrementAndGet

super.writeAndFlush(msg)

}

def isAvailable: Boolean = {

streamCounter.get < 500

}

def decr() = {

streamCounter.decrementAndGet

}

Connection reset by peer

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

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

@throws(classOf[Exception])
  override def userEventTriggered(ctx: ChannelHandlerContext, evt: AnyRef) {
    evt match {
      case _: IdleStateEvent =>
        val pingDataBuffer: ByteBuf = ctx.alloc.ioBuffer(8, 8)
        pingDataBuffer.writeLong(System.currentTimeMillis())
        this.encoder.writePing(ctx, false, pingDataBuffer, ctx.newPromise)
          .addListener(new GenericFutureListener[ChannelFuture]() {

            @throws(classOf[Exception])
            def operationComplete(future: ChannelFuture) {
              if (future.isSuccess) {
                pingTimeoutFuture = future.channel.eventLoop.schedule(new Runnable() {
                  def run() {
                    error.error("Closing channel due to ping timeout.")
                    future.channel.close
                  }
                }, 30, TimeUnit.SECONDS)
              } else {
                error.error(s"Failed to write PING frame. ${future.cause().getStackTraceString}")
                future.channel.close
              }
            }
          })
        ctx.flush
      case _ =>
    }
    super.userEventTriggered(ctx, evt)
  }

@throws(classOf[Exception])

override def userEventTriggered(ctx: ChannelHandlerContext, evt: AnyRef) {

evt match {

case _: IdleStateEvent =>

val pingDataBuffer: ByteBuf = ctx.alloc.ioBuffer(8, 8)

pingDataBuffer.writeLong(System.currentTimeMillis())

this.encoder.writePing(ctx, false, pingDataBuffer, ctx.newPromise)

.addListener(new GenericFutureListener[ChannelFuture]() {

@throws(classOf[Exception])

def operationComplete(future: ChannelFuture) {

if (future.isSuccess) {

pingTimeoutFuture = future.channel.eventLoop.schedule(new Runnable() {

def run() {

error.error("Closing channel due to ping timeout.")

future.channel.close

}

}, 30, TimeUnit.SECONDS)

} else {

error.error(s"Failed to write PING frame. ${future.cause().getStackTraceString}")

future.channel.close

}

})

ctx.flush

case _ =>

}

super.userEventTriggered(ctx, evt)

}

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

sudo sh -c 'echo 60 >/proc/sys/net/ipv4/tcp_keepalive_time'

1	sudo sh -c 'echo 60 >/proc/sys/net/ipv4/tcp_keepalive_time'

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上去：

  private val addArray: Array[InetAddress] = InetAddress.getAllByName(PRODUCTION_HOST)

  private def getAddress: String = {
    addArray(Random.nextInt(addArray.length - 1)).getHostAddress
  }

private val addArray: Array[InetAddress] = InetAddress.getAllByName(PRODUCTION_HOST)

private def getAddress: String = {

addArray(Random.nextInt(addArray.length - 1)).getHostAddress

}

实测这样做以后，发送速度由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 ，请勿用于任何商业用途）

jyqwejzq: https://hydra.onion-shop24.com сайт hydra
jyqwejzq: https://hydra.onion-shop24.com hydra сайт
Weldondouff: company website гидра зеркало
亚博体育官网: 不赖!真的不赖!
ascend: Error:(36, 29) wrong number of type parameters for overloaded method value createDirectStream with...
Anonymous:
Anonymous:
Anonymous:
Anonymous:
Anonymous: 运行报错：java.lang.Abstr actMethodError
Anonymous:
Anonymous:
Anonymous:
Anonymous:
zzg: 请问zz你问题核实了没� ��我也遇到了这个奇葩� ��问题，我们也是基�...
Anonymous:
kuyuzasur: what do i tell doctor to get viagra. edhelprie.mdhelpserv.com – how long we can take viagra,
Anonymous: 这个问题可以忽略。不影响
Anonymous:
Anonymous: 牛

8条评论

Sorheart说道：

2016年7月25日下午6:13

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

回复
- yurnom说道：
  
  2016年8月12日上午11:06
  
  测过百万级别的消息，没遇到你说的情况。我这边测试的结果是payload越大发送越慢，channel保持时间越长发送越慢。
  
  回复
  - Sorheart说道：
    
    2016年8月13日下午1:12
    
    最近发消息时频繁出现苹果服务器设置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说道：
    
    2016年8月13日下午3:23
    
    并且一直收到苹果服务器的goaway frame
    
    回复
    - yurnom说道：
      
      2016年8月15日下午3:46
      
      最近发送速度降的特别厉害，而且大量的connection reset by peer。我和一些开发者交流后大家都有这个现象，最后觉得应该是奥运期间苹果服务器压力太大导致的。
      
      回复
    - yurnom说道：
      
      2016年8月15日下午3:50
      
      看了下日志，确实很多MAX_CONCURRENT_STREAMS=1
      
      回复
Sorheart说道：

2016年8月15日下午8:20

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

回复
Sorheart说道：

2016年8月15日下午8:28

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

回复

发表评论

点击这里取消回复。