Cronet网络库系列(一)：用例与原理实现详解

背景

对于小程序框架这种既有业务API请求，又有web请求。Android平台上不管是系统HttpUrlConnection还是OkHttp都无法满足完全优化的需求，所以在使用自研webview基础上，有了使用Chromium网络栈优化的想法。以下引用是Cronet官方介绍翻译。

Cronet是Chromium的网络堆栈，已单独编译成库供移动设备使用。这与十亿多人在Chrome浏览器中使用的网络堆栈相同。它提供了一种易于使用，高性能，符合标准且安全的方式来执行HTTP请求。.

Cronet是Chromium网络引擎对不同操作系统做的封装，实现了移动端应用层、表示层、会话层协议，支持HTTP1/2、SPDY、QUIC、WebSocket、FTP、DNS、TLS等协议标准。支持Android、IOS、Chrome OS、Fuchsia，部分支持Linux、MacOS、Windows桌面操作系统。实现了Brotli数据压缩、预连接、DNS缓存、session复用等策略优化以及TCP fast open等系统优化。本文内容基于Chromium 75版本。

独立编译

下载完整的chromium内核的源码：https://www.chromium.org/deve...

调试版

生成ninja文件(类似Makefile)

Android / iOS builds
$ ./components/cronet/tools/cr_cronet.py gn --out_dir=out/Cronet

Desktop builds (targets the current OS)
$ gn gen out/Cronet

编译
$ ninja -C out/Cronet cronet_package

发布版

$ ./components/cronet/tools/cr_cronet.py gn --release
$ ninja -C out/Release cronet_package

集成
生成的库在out/Release/cronet目录下，项目中引入jar包以及libs/armeabi-v7a/libcronet.75.0.3770.150.so(Android)或者Cronet.framework(IOS)．Android平台jar包1M，SO 2.7M．
如果要单独编译dex包做插件加载，建议引入cronet_api.jar作为接口层、其他三个jar打成dex通过classloader动态加载。打dex的方法，Chromium 75已经不支持dx，要用新的d8工具。具体命令是：
java -jar third_party/r8/lib/d8.jar --release --output dex.jar --lib third_party/android_sdk/public/platforms/android-xx/android.jar --lib third_party/android_sdk/public/extras/android/support/v4/android-support-v4.jar cronet_implxxx.jar cronet_implxxx.jar

官方编译参考： https://chromium.googlesource...
多平台编译实践： https://www.twblogs.net/a/5d7...

Android平台功能示例

发起请求基本流程

// 初始化引擎
CronetEngine.Builder myBuilder = new CronetEngine.Builder(context);
CronetEngine cronetEngine = myBuilder.build();

// 创建请求线程
Executor executor = Executors.newSingleThreadExecutor();

// 创建UrlRequest
UrlRequest.Builder requestBuilder = cronetEngine.newUrlRequestBuilder(
        "https://www.example.com", new MyUrlRequestCallback(), executor);
UrlRequest request = requestBuilder.build();

// 发起请求
request.start();

// 网络状态回调
class MyUrlRequestCallback extends UrlRequest.Callback {
  private static final String TAG = "MyUrlRequestCallback";

  @Override
  public void onRedirectReceived(UrlRequest request, UrlResponseInfo info, String newLocationUrl) {
    android.util.Log.i(TAG, "onRedirectReceived method called.");
    // You should call the request.followRedirect() method to continue
    // processing the request.
    request.followRedirect();
  }

  @Override
  public void onResponseStarted(UrlRequest request, UrlResponseInfo info) {
    android.util.Log.i(TAG, "onResponseStarted method called.");
    // You should call the request.read() method before the request can be
    // further processed. The following instruction provides a ByteBuffer object
    // with a capacity of 102400 bytes to the read() method.
    request.read(ByteBuffer.allocateDirect(102400));
  }

  @Override
  public void onReadCompleted(UrlRequest request, UrlResponseInfo info, ByteBuffer byteBuffer) {
    android.util.Log.i(TAG, "onReadCompleted method called.");
    // You should keep reading the request until there's no more data.
    request.read(ByteBuffer.allocateDirect(102400));
  }

  @Override
  public void onSucceeded(UrlRequest request, UrlResponseInfo info) {
    android.util.Log.i(TAG, "onSucceeded method called.");
  }
}

回调状态描述

应用程序调用start（）方法后，生命周期处于“已启动”状态。
服务器可以发送重定向响应，该响应将流转移到onRedirectReceived（）方法。在此方法中，您可以执行以下客户端操作之一：
- 使用followRedirect（）跟随重定向。此方法将请求恢复为已启动状态。
- 使用cancel（）取消请求。此方法将请求带到onCanceled（）方法，其中应用程序可以在请求移动到Canceled final状态之前执行其他操作。
应用程序跟随所有重定向后，服务器发送响应头并调用onResponseStarted（）方法。请求处于Waiting for read（）状态。应用程序应该调用read（）方法来尝试读取部分响应主体。调用read（）后，请求处于读取状态，其中有以下可能的结果：
- 读取response是成功的，但有更多的数据可用。调用onReadCompleted（）并且请求再次处于Waiting for read（）状态。应用程序应再次调用read（）方法以继续读取响应正文。应用程序也可以使用cancel（）方法停止读取请求。
- 读取response是成功的，没有更多的数据可用。调用onSucceeded（）方法，请求现在处于Succeeded最终状态。
- 读取response失败了。调用onFailed方法，请求的最终状态现在为Failed。

流程图如下：

数据上传

MyUploadDataProvider myUploadDataProvider = new MyUploadDataProvider();
requestBuilder.setHttpMethod("POST");
requestBuilder.setUploadDataProvider(myUploadDataProvider, executor);

MyUploadDataProvider继承UploadDataProvider．当Cronet发送request body时会调用myUploadDataProvider.read(UploadDataSink uploadDataSink, ByteBuffer byteBuffer)将byteBuffer的数据分段发送，结束写入byteBuffer需要client调用uploadDataSink.onReadSucceeded通知Cronet. 更多细节参考API文档．

配置CronetEngine

Enabling HTTP/2 and QUIC:

    engineBuilder.enableHttp2(true).enableQuic(true);

Controlling the cache:

  engineBuilder.setStoragePath(storagePathString);
  engineBuilder.enableHttpCache(CronetEngine.Builder.HttpCache.DISK,
          1024 * 1024);

NetLog调试日志

client可以通过CronetEngine.startNetLogToFile以及CronetEngine.stopNetLog将网络日志保存，通过chrome://net-internals#import导入日志进行分析．

API以及示例参考资料

Android官方示例： https://developer.android.com...
Android Cronet API： https://developer.android.com...
本地编译Android API: //src/components/cronet/android/api/
IOS Sample: //src/components/cronet/ios/test/
Naitve Sample: //src/components/cronet/native/sample/test/

性能数据

用例１：Cronet 75 vs OkHttp 3.11
1）Http请求耗时。单次请求均值Cronet与OkHttp一致，主要取决于网速。10次并发请求均值Cronet落后于OkHttp。
2) Https请求耗时。单次请求均值Cronet优于OkHttp。10次并发请求均值Cronet与OkHttp一致，但是Cronet先到和后到请求差异较大。

源码：https://github.com/bojie-liu/CronetPerformanceSample
详细数据见：https://docs.qq.com/sheet/DZFhURWR1U1pMaVhO?tab=BB08J2&c=C12A0N0

用例２：蘑菇街实践．针对 Chromium 网络库和系统网络库做了测试，得到了如下数据：
参考资料：https://www.infoq.cn/article/...

用例３：腾讯实践，QUIC对比HTTP2．
参考资料：https://cloud.tencent.com/dev...

原理实现

整体架构

这里从两个角度剖析网络栈实现 (以Android平台为例)．一是架构上从顶至底分层，明确Cronet API到系统socket调用每一层的职责，方便将抽象的需求或功能实现对应到相应的模块相应层级中．二是流程上说明URLRequest.start到数据返回在每一层执行了什么逻辑，方便对细节进行把握．
第一部分：
架构：

平台接口层．提供各平台Cronet API，隐藏底层实现．
平台实现层．负责Cronet库加载，封装系统网络库提供应用选择．负责C层JNI接口与Android Java的适配转换，包括请求类CronetUrlRequest发起请求、将状态回调抛到Client传入的Executor的线程执行．Cronet引擎上下文CronetUrlRequestContext加载库、设置netlog,cache、监听网络状态、管理回调线程的Executor．
共用接口层．一是提供统一的C++接口给各平台上层调用．二是负责C层网络栈接口与JNI层的适配转换，包括CronetURLRequestAdapter将请求抛到内核NetWork线程执行、对C/Java进行数据转换、创建IOBufferWithByteBuffer将返回数据直接放在Java ByteBuffer中避免拷贝．包括CronetURLRequestContextAdapter持有网络栈Context、初始化NetWork线程、数据转换．
网络栈接口层．此层及以下的代码都在/net目录下，负责提供网络请求接口隐藏底层网络协议的实现，上层应用包括Cronet、WebView资源加载、devtools调试请求等。URLRequest创建并执行不同的底层URLRequestJob、提供上层获取网络状态和数据、代理服务器信息等。URLRequestContext网络栈上下文，持有一大堆全局网络模块例如CookieStore、NetLog、HostResolver域名解析、NetworkThrottleManager请求优先级管理等。

流程：
http网络请求

URLRequest::Start首先调用URLRequestJobManager::CreateJob根据不同的scheme创建Job，优先从Cronet Client设置的自定义job_factory创建，没有则从kBuiltinFactories(http/https,ws/wss)中创建。这里是URLRequestHttpJob，然后初始化job并且设置URLRequest状态，最后调URLRequestHttpJob::Start。

URLRequestContext初始化

在URLRequestContextBuilder::Build中对一大堆网络功能的初始化。包括自定义的UA、host_resolver、ssl_config_service、cookie_store、安全证书相关、代理服务配置、http_cache设置、data/file/ftp协议的JobFactory等。

第二部分
架构：

URLRequestxxxJob:负责不同scheme的request/response数据管理，具体网络协议由底层实现。例如DataJob解析url的charset/data构造response返回；HttpJob管理cookie、通过HttpNetworkTransaction拉取response、保存auth_credential等。
TransactionFactory:创建具体的xxxTransaction工厂类。
HttpTransaction:表示一次Http请求响应过程，定义了Start/RestartWithAuth/Read以及回调抽象接口。例如子类HttpNetworkTransaction状态机除了驱动HttpStream建立连接，还负责Http身份验证处理与重试，HttpStream是否keep_alive等。
HttpNetworkSession:http scheme请求过程全局的Context，包括http/quic协议的配置、SocketPool/HostResolver/ProxyService等所有http请求都用到的模块。在URLRequestContextBuilder中创建并保存在URLRequestContextStorage中。
HttpStream:http/quic/websocket协议的共同抽象类，定义了发送请求、读取响应、获取连接状态等接口，由不同协议具体实现。以HttpBasicStream为例，持有读取响应buffer，持有HttpStreamParser状态机调度发送header/body、接收响应，持有ClientSocketHandle具体的socket连接。
StreamFactory:建立HttpStream连接的工厂类。例如HttpStreamFactory的RequestStream里面会解析代理信息(JobController)，创建ClientSocketHandler解析Host、connect服务器，封装在HttpStream中返回给上层。