返回顶部
首页 > 资讯 > 移动开发 >探究Android客户端网络预连接优化机制
  • 767
分享到

探究Android客户端网络预连接优化机制

2024-04-02 19:04:59 767人浏览 安东尼
摘要

目录一、连接复用二、预连接实现三、源码分析四、优化五、问答一、连接复用 对于一个普通的接口请求,通过charles抓包,查看网络请求Timing栏信息,我们可以看到类似如下请求时长信

一、连接复用

对于一个普通的接口请求,通过charles抓包,查看网络请求Timing栏信息,我们可以看到类似如下请求时长信息:

  • Duration 175 ms
  • DNS 6 ms
  • Connect 50 msTLS Handshake 75 ms
  • Request 1 ms
  • Response 1 ms
  • Latency 42 ms

同样的请求,再来一次,时长信息如下所示:

  • Duration 39 ms
  • DNS -
  • Connect -
  • TLS Handshake -
  • Request 0 ms
  • Response 0 ms
  • Latency 39 ms

我们发现,整体网络请求时间从175ms降低到了39ms。其中DNS,Connect,TLS Handshake 后面是个横线,表示没有时长信息,于是整体请求时长极大的降低了。这就是Http(s)的连接复用的效果。那么问题来了,什么是连接复用,为什么它能降低请求时间?

在解决这个疑问之前,我们先来看看一个网络请求发起,到收到返回的数据,这中间发生了什么?

  • 客户端发起网络请求
  • 通过DNS服务解析域名,获取服务器IP (基于UDP协议的DNS解析)
  • 建立tcp连接(3次握手)
  • 建立TLS连接(https才会用到)
  • 发送网络请求request
  • 服务器接收request,构造并返回response
  • TCP连接关闭(4次挥手)

上面的连接复用直接让上面2,3,4步都不需要走了。这中间省掉的时长应该怎么算?如果我们定义网络请求一次发起与收到响应的一个来回(一次通信来回)作为一个RTT(Round-trip delay time)。

1)DNS默认基于UDP协议,解析最少需要1-RTT;

2)建立TCP连接,3次握手,需要2-RTT;

3)建立TLS连接,根据TLS版本不同有区别,常见的TLS1.2需要2-RTT。

Client                                               Server

ClientHello                  -------->

                                                ServerHello

                                               Certificate*

                                         ServerKeyExchange*

                                        CertificateRequest*

                             <--------      ServerHelloDone

Certificate*

ClienTKEyExchange

CertificateVerify*

[ChangeCipherSpec]

Finished                     -------->

                                         [ChangeCipherSpec]

                             <--------             Finished

Application Data             <------->     Application Data

                   TLS 1.2握手流程(来自 RFC 5246)

注:TLS1.3版本相比TLS1.2,支持0-RTT数据传输(可选,一般是1-RTT),但目前支持率比较低,用的很少。

http1.0版本,每次http请求都需要建立一个tcp Socket连接,请求完成后关闭连接。前置建立连接过程可能就会额外花费4-RTT,性能低下。

http1.1版本开始,http连接默认就是持久连接,可以复用,通过在报文头部中加上Connection:Close来关闭连接 。如果并行有多个请求,可能还是需要建立多个连接,当然我们也可以在同一个TCP连接上传输,这种情况下,服务端必须按照客户端请求的先后顺序依次回送结果。

注:http1.1默认所有的连接都进行了复用。然而空闲的持久连接也可以随时被客户端与服务端关闭。不发送Connection:Close不意味着服务器承诺连接永远保持打开。

http2 更进一步,支持二进制分帧,实现TCP连接的多路复用,不再需要与服务端建立多个TCP连接了,同域名的多个请求可以并行进行。

还有个容易被忽视的是,TCP有拥塞控制,建立连接后有慢启动过程(根据网络情况一点一点的提高发送数据包的数量,前面是指数级增长,后面变成线性),复用连接可以避免这个慢启动过程,快速发包。

二、预连接实现

客户端常用的网络请求框架如OkHttp等,都能完整支持http1.1与HTTP2的功能,也就支持连接复用。了解了这个连接复用机制优势,那我们就可以利用起来,比如在APP闪屏等待的时候,就预先建立首页详情页等关键页面多个域名的连接,这样我们进入相应页面后可以更快的获取到网络请求结果,给予用户更好体验。在网络环境偏差的情况下,这种预连接理论上会有更好的效果。

具体如何实现?

第一反应,我们可以简单的对域名链接提前发起一个HEAD请求(没有body可以省流量),这样就能提前建立好连接,下次同域名的请求就可以直接复用,实现起来也是简单方便。于是写了个demo,试了个简单接口,完美,粗略统计首次请求速度可以提升40%以上。

于是在游戏中心App启动Activity中加入了预连接相关逻辑,跑起来试了下,竟然没效果...

抓包分析,发现连接并没有复用,每次进去详情页后都重新创建了连接,预连接可能只是省掉了DNS解析时间,demo上的效果无法复现。看样子分析OkHttp连接复用相关源码是跑不掉了。

三、源码分析

OKHttp通过几个默认的Interceptor用于处理网络请求相关逻辑,建立连接在ConnectInterceptor类中;


public final class ConnectInterceptor implements Interceptor {
  @Override public Response intercept(Chain chain) throws IOException {
    RealInterceptorChain realChain = (RealInterceptorChain) chain;
    Request request = realChain.request();
    StreamAllocation streamAllocation = realChain.streamAllocation();
​
    // We need the network to satisfy this request. Possibly for validating a conditional GET.
    boolean doExtensiveHealthChecks = !request.method().equals("GET");
    HttpCodec httpCodec = streamAllocation.newStream(client, chain, doExtensiveHealthChecks);
    RealConnection connection = streamAllocation.connection();
​
    return realChain.proceed(request, streamAllocation, httpCodec, connection);
  }
}

RealConnection即为后面使用的connection,connection生成相关逻辑在StreamAllocation类中;


public HttpCodec newStream(
      OkHttpClient client, Interceptor.Chain chain, boolean doExtensiveHealthChecks) {
  ... 
    RealConnection resultConnection = findHealthyConnection(connectTimeout, readTimeout,
        writeTimeout, pingIntervalMillis, connectionRetryEnabled, doExtensiveHealthChecks);
    HttpCodec resultCodec = resultConnection.newCodec(client, chain, this);
  ...
}
​
private RealConnection findHealthyConnection(int connectTimeout, int readTimeout,
      int writeTimeout, int pingIntervalMillis, boolean connectionRetryEnabled,
      boolean doExtensiveHealthChecks) throws IOException {
    while (true) {
      RealConnection candidate = findConnection(connectTimeout, readTimeout, writeTimeout,
          pingIntervalMillis, connectionRetryEnabled);
    ...
      return candidate;
    }
}
  
  
  private RealConnection findConnection(int connectTimeout, int readTimeout, int writeTimeout,
      int pingIntervalMillis, boolean connectionRetryEnabled) throws IOException {
    ...
    
    // 尝试从connectionPool中获取可用connection
    Internal.instance.acquire(connectionPool, address, this, null);
    if (connection != null) {
    foundPooledConnection = true;
    result = connection;
    } else {
    selectedRoute = route;
    }
    
   ...
   
    if (!foundPooledConnection) {
      ... 
      // 如果最终没有可复用的connection,则创建一个新的
        result = new RealConnection(connectionPool, selectedRoute);
    }
  ...
}

这些源码都是基于okhttp3.13版本的代码,3.14版本开始这些逻辑有修改。

StreamAllocation类中最终获取connection是在findConnection方法中,优先复用已有连接,没可用的才新建立连接。获取可复用的连接是在ConnectionPool类中;



public final class ConnectionPool {

  private final Runnable cleanupRunnable = () -> {
    while (true) {
      long waitNanos = cleanup(System.nanoTime());
      if (waitNanos == -1) return;
      if (waitNanos > 0) {
        long waitMillis = waitNanos / 1000000L;
        waitNanos -= (waitMillis * 1000000L);
        synchronized (ConnectionPool.this) {
          try {
            ConnectionPool.this.wait(waitMillis, (int) waitNanos);
          } catch (InterruptedException ignored) {
          }
        }
      }
    }
  };

  // 用一个队列保存当前的连接
  private final Deque<RealConnection> connections = new ArrayDeque<>();
  
  
  
  public ConnectionPool() {
    this(5, 5, TimeUnit.MINUTES);
  }

  public ConnectionPool(int maxIdleConnections, long keepAliveDuration, TimeUnit timeUnit) {
  ...
  }
  
  void acquire(Address address, StreamAllocation streamAllocation, @Nullable Route route) {
    assert (Thread.holdsLock(this));
    for (RealConnection connection : connections) {
      if (connection.isEligible(address, route)) {
        streamAllocation.acquire(connection, true);
        return;
      }
    }
  }

由上面源码可知,ConnectionPool默认最大维持5个空闲的connection,每个空闲connection5分钟后自动释放。如果connection数量超过最大数5个,则会移除最旧的空闲connection。

最终判断空闲的connection是否匹配,是在RealConnection的isEligible方法中;



  public boolean isEligible(Address address, @Nullable Route route) {
    // If this connection is not accepting new streams, we're done.
    if (allocations.size() >= allocationLimit || noNewStreams) return false;

    // If the non-host fields of the address don't overlap, we're done.
    if (!Internal.instance.equalsNonHost(this.route.address(), address)) return false;

    // If the host exactly matches, we're done: this connection can carry the address.
    if (address.url().host().equals(this.route().address().url().host())) {
      return true; // This connection is a perfect match.
    }

    // At this point we don't have a hostname match. But we still be able to carry the request if
    // our connection coalescing requirements are met. See also:
    // https://hpbn.co/optimizing-application-delivery/#eliminate-domain-sharding
    // https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/

    // 1. This connection must be HTTP/2.
    if (http2Connection == null) return false;

    // 2. The routes must share an IP address. This requires us to have a DNS address for both
    // hosts, which only happens after route planning. We can't coalesce connections that use a
    // proxy, since proxies don't tell us the origin server's IP address.
    if (route == null) return false;
    if (route.proxy().type() != Proxy.Type.DIRECT) return false;
    if (this.route.proxy().type() != Proxy.Type.DIRECT) return false;
    if (!this.route.socketAddress().equals(route.socketAddress())) return false;

    // 3. This connection's server certificate's must cover the new host.
    if (route.address().hostnameVerifier() != OkHostnameVerifier.INSTANCE) return false;
    if (!supportsUrl(address.url())) return false;

    // 4. Certificate pinning must match the host.
    try {
      address.certificatePinner().check(address.url().host(), handshake().peerCertificates());
    } catch (SSLPeerUnverifiedException e) {
      return false;
    }

    return true; // The caller's address can be carried by this connection.
  }

这块代码比较直白,简单解释下比较条件:

如果该connection已达到承载的流上限(即一个connection可以承载几个请求,http1默认是1个,http2默认是Int最大值)则不符合;

如果2个Address除Host之外的属性有不匹配,则不符合(如果2个请求用的okhttpClient不同,复写了某些重要属性,或者服务端端口等属性不一样,那都不允许复用);

如果host相同,则符合,直接返回true(其它字段已经在上一条比较了);

如果是http2,则判断无代理、服务器IP相同、证书相同等条件,如果都符合也返回true;

整体看下来,出问题的地方应该就是ConnectionPool 的队列容量太小导致的。游戏中心业务复杂,进入首页后,触发了很多接口请求,导致连接池直接被占满,于是在启动页做好的预连接被释放了。通过调试验证了下,进入详情页时,ConnectionPool中的确已经没有之前预连接的connection了。

四、优化

在http1.1中,浏览器一般都是限定一个域名最多保留5个左右的空闲连接。然而okhttp的连接池并没有区分域名,整体只做了默认最大5个空闲连接,如果APP中不同功能模块涉及到了多个域名,那这默认的5个空闲连接肯定是不够用的。有2个修改思路:

  • 重写ConnectionPool,将连接池改为根据域名来限定数量,这样可以完美解决问题。然而OkHttp的ConnectionPool是final类型的,无法直接重写里面逻辑,另外OkHttp不同版本上,ConnectionPool逻辑也有区别,如果考虑在编译过程中使用ASM等字节码编写技术来实现,成本很大,风险很高。
  • 直接调大连接池数量和超时时间。这个简单有效,可以根据自己业务情况适当调大这个连接池最大数量,在构建OkHttpClient的时候就可以传入这个自定义的ConnectionPool对象。

我们直接选定了方案2。

五、问答

1、如何确认连接池最大数量值?

这个数量值有2个参数作为参考:页面最大同时请求数,App总的域名数。也可以简单设定一个很大的值,然后进入APP后,将各个主要页面都点一遍,看看当前ConnectionPool中留存的connection数量,适当做一下调整即可。

2、调大了连接池会不会导致内存占用过多?

测试:将connectionPool最大值调成50,在一个页面上,用了13个域名链接,总共重复4次,也就是一次发起52个请求之后,ConnectionPool中留存的空闲connection平均22.5个,占用内存为97Kb,ConnectionPool中平均每多一个connection会占用4.3Kb内存。

3、调大了连接池会影响到服务器吗?

理论上是不会的。连接是双向的,即使客户端将connection一直保留,服务端也会根据实际连接数量和时长调整,自动关闭连接的。比如服务端常用的Nginx就可以自行设定最大保留的connection数量,超时也会自动关闭旧连接。因此如果服务器定义的最大连接数和超时时间比较小,可能我们的预连接会无效,因为连接被服务端关闭了。

用charles可以看到这种连接被服务端关闭的效果:TLS大类中Session Resumed里面看到复用信息。

这种情况下,客户端会重新建立连接,会有tcp和tls连接时长信息。

4、预连接会不会导致服务器压力过大?

由于进入启动页就发起了网络请求进行预连接,接口请求数增多了,服务器肯定会有影响,具体需要根据自己业务以及服务器压力来判断是否进行预连接。

5、如何最大化预连接效果?

由上面第3点问题可知,我们的效果实际是和服务器配置息息相关,此问题涉及到服务器的调优。

服务器如果将连接超时设置的很小或关闭,那可能每次请求都需要重新建立连接,这样服务器在高并发的时候会因为不断创建和销毁TCP连接而消耗很多资源,造成大量资源浪费。

服务器如果将连接超时设置的很大,那会由于连接长时间未释放,导致服务器服务的并发数受到影响,如果超过最大连接数,新的请求可能会失败。

可以考虑根据客户端用户访问到预连接接口平均用时来调节。比如游戏中心详情页接口预连接,那可以统计一下用户从首页平均浏览多长时间才会进入到详情页,根据这个时长和服务器负载情况来适当调节。

以上就是探究Android客户端网络预连接优化机制的详细内容,更多关于Android客户端网络 预连接优化的资料请关注编程网其它相关文章!

--结束END--

本文标题: 探究Android客户端网络预连接优化机制

本文链接: https://lsjlt.com/news/128468.html(转载时请注明来源链接)

有问题或投稿请发送至: 邮箱/279061341@qq.com    QQ/279061341

猜你喜欢
软考高级职称资格查询
编程网,编程工程师的家园,是目前国内优秀的开源技术社区之一,形成了由开源软件库、代码分享、资讯、协作翻译、讨论区和博客等几大频道内容,为IT开发者提供了一个发现、使用、并交流开源技术的平台。
  • 官方手机版

  • 微信公众号

  • 商务合作