Cronet单链接性能信息收集实践：指标设计与踩坑记录

做客户端网络性能分析，常会遇到一个很尴尬的时刻：错误日志里能看到接口耗时在涨，业务方也反馈页面变慢，但把单个请求拆开看，却发现哪一段都不算慢。这个困惑在切换 Cronet 后变得更明显。Cronet 把所有网络能力都放到了 Chromium 网络栈里，HTTP/2、HTTP/3 的多路复用又让多条请求共享同一条连接，传统的“每个请求记一次 DNS/TCP/TLS 耗时”已经不能回答最核心的问题：这条单链接到底是慢在建立，还是慢在传输，还是连接一直活着但服务器迟迟不回。

基于 cronet 的单链接性能信息收集，就是想把这层窗户纸捅破。我们需要的不是“某个接口慢不慢”，而是“某条连接在哪个阶段消耗了多少时间，承载了多少请求和字节”。这套信息既能直接解释线上偶发的慢请求，也能用来评估 Cronet 的 HTTP/3、连接复用、预连接等策略是否真的生效。下面这篇文章我把完整的落地过程拆出来讲，从指标设计、接口选择、代码实现到实际采集里的各种坑，基本是按我自己趟过一遍的顺序写的。

1. 为什么要把性能指标下沉到“链接”这一层

1.1 请求级指标在 Cronet 下已经失真了

以前用 OkHttp 或者 HttpURLConnection 时，大家习惯的做法是给每个请求打点：DNS 耗时多少、连接耗时多少、TTFB 多少、总耗时多少。这个模型建立在“一次请求大概率对应一次独立连接”的假设上。虽然 OkHttp 也有连接池，也有 HTTP/2 多路复用，但实际业务里大量接口还是 HTTP/1.1，每个请求独占一个连接，请求和连接的关系相对干净。

上 Cronet 之后情况就变了。Cronet 天然把 HTTP/2、HTTP/3 作为一等公民，连接建立成功后，同 host 的多个请求会直接复用到同一个连接上。你的打点系统如果还按请求记，会出现三种很迷惑的数据：

• 第一个请求带着建连耗时，后续并发请求没有 DNS、没有 TCP 连接时间，总耗时看着很低，但吞吐其实被前一个请求占用的带宽拖累。
• 一个 4K 视频分片拆成 20 个并发请求，如果只统计每个请求的 receive 字节和耗时，永远拼不出这条连接的真实带宽。
• 服务器一侧主动断开连接后，下一个请求触发重建连，这个“新建连接”的开销被记在了某个无辜业务请求头上，排查时根本定位不到根因。

本质上，请求是业务层的“流”，连接是传输层的“管道”。单链接性能信息收集要做的事情，是把统计维度从流下沉到管道。

1.2 单链接能回答什么跨层问题

换到连接维度之后，很多以前只能猜的问题可以直接量化了：

• 新建连接平均握手要多长时间？这是判断网络覆盖、DNS 质量、TLS 证书配置最直接的输入。
• 复用连接的比例是多少？如果新建比例过高，说明 Cronet 连接池很难保住空闲连接，客户端可能频繁做无谓握手。
• 连接建立后，每条链接上平均跑了多少个请求、传了多少字节？这决定服务器端对连接数的设计和客户端连接池上限的优化方向。
• 大量请求共用的同一条连接有没有出现长时间空闲、被 RST、被服务器主动关闭？如果单链接生命周期里发现关闭后立刻重建，基本能锁定是代理、网关还是服务端空闲超时。

1.3 信息收集目标要收敛，别想着一步到位

这个项目最忌讳上来就做“全量采集所有连接所有事件”。Cronet 底层事件非常多，真正对线上调优有帮助的，其实就两类：一是连接从“无到有”的建链时间线，二是这条连接从建立到销毁期间承载的所有请求统计。

所以我把范围收敛成：在 Cronet 请求完成回调中拿到每次请求的传输阶段指标，再把这些请求按照“它属于哪条连接”做聚合。对于聚合不准的场景，用 NetLog 做抽样复核，而不是在每台线上设备上长期开 NetLog。这个收敛非常关键，否则项目会因为数据量、解析复杂度、存储成本等问题直接烂尾。

2. 指标设计：单链接性能记录里到底该放什么字段

2.1 建链阶段的指标才是“单链接”的主菜

如果用户访问一个网站，Cronet 之前没有任何可用连接，那么第一条请求会触发完整建链过程。这个过程产生的阶段耗时是单链接性能信息里最有价值的部分。

我最终打点字段主要分四组：

每条记录还要带一个 socketReused 布尔值。它告诉你这次请求是发生在新建连接上，还是复用了已有空闲连接。这两个场景下，上述阶段指标的含义完全不同，后面代码实现里会继续细说。

2.2 链接承载量指标：把多路复用算清楚

单链接性能不只是握手快不快。HTTP/2 多路复用以后，一条连接可能同时传输多个请求，如果只记录第一个请求的总耗时并把它当作“连接质量”，会严重失真。

所以在聚合时，我额外维护了三个链接级字段：

• requestCountOnLink：这条链接生命周期内承载的请求数。注意并发请求在 RequestFinishedInfo 回调里到达时间有先后，需要按连接标记累加。
• bytesSentOnLink / bytesReceivedOnLink：把该链接上所有请求的 sentByteCount、receivedByteCount 累加，用于计算单链接实际吞吐。
• firstRequestTime / lastFinishTime：链接实际活跃窗口，用来判断“连接活了多久”以及“有没有长时间闲置”。

2.3 模型定义示例

对应 Android 侧数据结构可以长这样：

java复制public class SingleLinkRecord {
    public String host;
    public String protocol;          // negotiatedProtocol: h2, quic
    public boolean isNewConnection;  // socketReused == false

    public long dnsCostMs;
    public long connectCostMs;
    public long handshakeCostMs;
    public long firstByteMs;
    public long totalCostMs;

    public long requestCount;
    public long sentBytes;
    public long receivedBytes;
    public long activeStartTimeMs;
    public long activeEndTimeMs;
}

这个模型不用去覆盖 Cronet 底层所有 Event，只要把每次请求的阶段耗时和字节数归并到所属连接上，就足够形成单链接性能报告了。

3. 数据源选择：RequestFinishedInfo 和 NetLog 怎么配合

3.1 RequestFinishedInfo 是主力数据通道

Cronet 在请求结束后会回调 RequestFinishedInfo，里面挂了一个 Metrics 对象。老版本里完整类名是 org.chromium.net.RequestFinishedInfo，如果走 Android 系统自带 Cronet 或者较新的 androidx 版本，包名可能变成 android.net.http，但方法 shape 基本一致。

监听器挂在 CronetEngine.Builder 上最方便，Engine 所有的请求都会经过它：

java复制private final RequestFinishedInfo.Listener requestFinishedListener =
        new RequestFinishedInfo.Listener(metricsExecutor) {
    @Override
    public void onRequestFinished(RequestFinishedInfo requestInfo) {
        RequestFinishedInfo.Metrics metrics = requestInfo.getMetrics();
        if (metrics == null) {
            return;
        }
        boolean reused = metrics.getSocketReused();
        long dnsCostMs = toMs(metrics.getDnsStart(), metrics.getDnsEnd());
        long connectCostMs = toMs(metrics.getConnectStart(), metrics.getConnectEnd());
        long handshakeCostMs = toMs(metrics.getSslStart(), metrics.getSslEnd());
        long firstByteMs = toMs(metrics.getRequestStart(), metrics.getResponseStart());
        long totalCostMs = toMs(metrics.getRequestStart(), metrics.getResponseEnd());
        // 这里把 (reused, 各阶段耗时) 交给单链接聚合器
        linkAggregator.onRequestFinished(requestInfo, metrics);
    }
};

CronetEngine engine = new CronetEngine.Builder(context)
        .enableHttp2(true)
        .enableQuic(true)
        .addRequestFinishedListener(requestFinishedListener)
        .build();

Metrics 不保证每个字段都有值。DNS 命中缓存时，getDnsStart 和 getDnsEnd 很可能是 -1；连接复用时，connect 和 ssl 相关阶段很可能也没有值。配套的时间换算要写成这样，别直接做差：

java复制private static long toMs(long start, long end) {
    if (start <= 0 || end <= 0 || end < start) {
        return -1;
    }
    return TimeUnit.NANOSECONDS.toMillis(end - start);
}

这些时间戳来自同一套单调时钟，我们只需要阶段差值，不关心它们对应 wall-clock 的哪个绝对时刻。这一点要特别注意，千万别把 Cronet 返回的时间戳当成 epoch 毫秒去跟服务器日志对齐，否则会出现“请求完成时间比服务器开始时间还早”的诡异问题。

3.2 NetLog 用来做连接维度的精确归因

RequestFinishedInfo 只提供请求维度的数据，不会明确告诉你这条请求具体服务端 socket 是哪一个。要精确回答“哪些请求在同一条连接上”，靠 socketReused 只能猜大概，这时就该让 NetLog 出场。

Cronet 原生支持把内部事件导出成 JSON NetLog：

java复制engine.startNetLogToFile("/sdcard/cronet_netlog_" + System.currentTimeMillis() + ".json", false);
// ... 跑一批测试请求
engine.stopNetLog();

NetLog 里能看到 URL_REQUEST 事件和底层连接/会话事件的关联关系。比如一次 QUIC 请求通常能追到某个 QUIC_SESSION 的 source id，同一条 session 下再出现的请求就属于同一条单链接。对于 HTTP/2，也能通过连接级 source 把多条 URL_REQUEST 归到同一条 TCP 连接上。

NetLog 文件非常大，且会记录请求 host、path 等敏感信息，所以线上长期全量开不现实。我的建议是把 NetLog 定位成“抽样复核工具”：日常线上用 RequestFinishedInfo 做轻量打点，出问题时按用户、时间窗口打开定向 NetLog 采集，这样才能看清 RequestFinishedInfo 聚合链路是否准确。

3.3 双通道结合时的数据对齐问题

两个通道的数据天然没打通。RequestFinishedInfo 里的 Metrics 没有暴露连接 ID，NetLog 里也没有直接把 Metrics 时间戳逐个对应进去。我在项目里是这么处理的：

• 线上常规统计完全依赖 RequestFinishedInfo，用“新连接标志 + host + 时间窗口”做粗粒度聚合。
• 专项测试或用户问题复现时，同时开 RequestFinishedInfo 打点和 NetLog。
• 事后拿 NetLog 解析出的连接 ID 作为 ground truth，验证粗粒度聚合的误差。

这套双轨设计避免了“数据不准却无人知道”的情况。单链接信息收集如果没有兜底校准机制，聚合逻辑很容易在复杂网络场景下悄悄出错。

4. 代码实现：没有连接 ID，就自己维护“连接代际”

4.1 用 socketReused 识别新连接

Cronet 的公开 API 没有直接给每条连接发一个递增 ID，那聚合怎么落地？最实用的破局点是 Metrics.getSocketReused()。

当一次请求的 socketReused == false，基本可以认为 Cronet 为这次请求新建了一条到目标 host 的连接。此时开始一个新的“连接代际”。之后那些 socketReused == true 的请求，大概率是在这条已有连接上跑的。实现时可以用一个以 host 为 key 的代际计数器：

java复制public class HostLinkTracker {
    private final Map<String, AtomicInteger> hostLinkSeq = new ConcurrentHashMap<>();
    private final Map<String, SingleLinkAggregator> activeLinks = new ConcurrentHashMap<>();

    public SingleLinkAggregator onRequestFinished(String host, boolean reused) {
        AtomicInteger seq = hostLinkSeq.computeIfAbsent(host, k -> new AtomicInteger());
        if (!reused) {
            seq.incrementAndGet();
        }
        String linkKey = host + "#" + seq.get();
        return activeLinks.computeIfAbsent(linkKey, k -> new SingleLinkAggregator(linkKey));
    }
}

这里有一个非常关键的前提：如果同一时刻有多个并发请求同时发出，且 Cronet 决定创建多条新连接，那这些请求会各自看到 socketReused == false，它们会被错误地归到多个代际里。所以这种方案只适合“一个 host 一个观察窗口内串行请求”或者“本身就希望观测第一条新建连接”的场景。

实际业务里，Cronet 对同 host 的 HTTP/2 会倾向于复用同一条连接，并发度不高时误差很小。但对并发请求明显的 App，我会在聚合器里短暂延迟合并，例如以 50ms 内到达的首批 socketReused == false 当作同一批连接代际，再配合协议类型做修正。这个阈值需要各自调，不能照搬。

4.2 把请求统计拼成链接快照

拿到每一条请求的 Metrics 后，聚合器要做的工作是把请求的字节数和阶段耗时“叠加”到当前代际记录上。核心逻辑大概这样：

java复制public void addRequest(boolean reused, long sentBytes, long receivedBytes,
                       long sendStartMs, long responseEndMs) {
    if (!reused) {
        // 新链接：记录建链耗时，重置链接承载量
        this.requestCount = 0;
        this.sentBytes = 0;
        this.receivedBytes = 0;
        this.firstRequestStartMs = sendStartMs;
    }
    this.requestCount++;
    this.sentBytes += sentBytes;
    this.receivedBytes += receivedBytes;
    this.lastFinishMs = Math.max(lastFinishMs, responseEndMs);
}

需要注意 requestCount 不可能在回调里真正等于连接创建初期的一个个请求数，因为并发请求的 onRequestFinished 回调顺序不等于请求在连接上的开启顺序。对聚合结果影响不大，但对准确度要求高的场景，仍需用 NetLog 去校准。

4.3 上报节奏控制

链接聚合器会持续累积，不能在每次请求完成时都上报一次完整快照，否则会产生大量重复数据。我的方案是在聚合器里设置一个“上报区间”，例如：

• 新连接诞生后的第一个请求完成时，立即上报一次“建链完成记录”，包含 DNS、connect、握手阶段耗时。
• 聚合器持续运行，每累计 10 个请求或 30 秒上报一次累计小计。
• 链接空闲超过 2 分钟，或检测到下一个 socketReused == false 时，上报最终累计记录并清空状态。

这样既保留了单链接的完整生命周期，又不会把每次请求都重复刷一遍，消息量可以控制在可接受范围内。

5. 踩坑记录：这些细节会让数据整体失真

5.1 不能假设 Metrics 一定存在

部分请求失败得特别早时，比如域名解析直接失败、请求被立即取消，RequestFinishedInfo 虽然被回调，但 getMetrics() 可能返回 null。我们的第一版代码没判断空指针，导致明明失败请求没有打点，聚合器误以为这条连接一直空闲，后续连接主动超时关闭时完全找不到原因。

后来我把这个分支单独拆出来：metrics == null 时只记录 requestFinishedReason（成功/失败/取消），不进聚合模型。正是因为失败请求大量存在，单链接平均指标的渲染才更有意义。

5.2 -1 字段的缺失语义绝对不是 0

这是项目里最容易被误解的点。早期同事把 Metrics 里的 -1 当 0 处理，算出来的 DNS 平均耗时被拉低，新建连接比例也完全对不上。Cronet 在“当前请求没有发生过该阶段”时返回 -1，而不是该阶段耗时是 0。

例如连接复用场景下根本没有 TLS 握手，sslStart 和 sslEnd 都会是 -1。如果不区分缺失和真 0，统计出的握手耗时会被大量复用请求拖到离谱的低，误判为 TLS 层表现优秀。正确做法是：对 -1 一律标记为“不适用”，在报表里和 0ms 分开展示。

5.3 “冷引擎”和“热引擎”的差别会污染单链接实验

如果拿同一个 CronetEngine 反复做单链接性能测试，第一次请求很可能命中了连接池里残留的空闲 HTTP/2 连接，测出来的不是“新建连接的性能”。这不是 Cronet 的 bug，而是连接本就该跨请求复用。

类似地，测试机如果恰好刚跑完一轮流量，DNS 缓存和 TLS 会话缓存都还是热的，新建连接也只是表面新建，实际握手用的还是缓存会话。做单链接对比实验时，必须保持引擎、进程、甚至设备网络环境都处于同样冷启动条件，否则数据可比性很差。

我在项目里为这类实验专门做了一个 debug 入口：允许把 Engine 完全重建、清空 Cronet 缓存，再顺序跑请求。线上代码不会走这个路径，只有压测和复现环境才开。

5.4 不要用总耗时直接当“响应快慢”

HTTP/2 多路复用下，一个请求的 totalCostMs 可能包含了等待连接上空闲窗口的时间，并不等于服务器处理该请求的时间。你在 Cronet 上看到某个请求耗时 1 秒，但 NetLog 里服务器响应可能只花了 30ms，剩下 970ms 都在等这条连接的带宽或流控窗口。

所以单链接信息收集里的 totalCostMs 只能作为兜底字段，真正做根因分析要看两个更精确的窗口：

• responseStart - sendStart：请求发出去到收到响应首字节的时间，近似包含网络传输和服务端处理。
• responseEnd - responseStart：响应体下载阶段，受带宽、接收窗口、RTT 影响更明显。

这两个字段结合单链接上并发请求数量和总字节数，才能还原“慢是慢在网络还是慢在服务端”。

5.5 executor 必须独立且要有缓冲

RequestFinishedInfo.Listener 会在指定 executor 上执行回调。如果回调里的聚合逻辑直接操作数据库或上报，碰到弱网流量洪峰时会迅速把线程池占满，甚至会反向拖慢 Cronet 的网络处理。

我的 executor 用了有界队列：

java复制ExecutorService metricsExecutor = new ThreadPoolExecutor(
        1, 1, 0L, TimeUnit.MILLISECONDS,
        new ArrayBlockingQueue<>(200),
        new DiscardOldestPolicy());

回调里只做最轻量的内存聚合，把最终记录丢到另一个上报队列，由上报线程批量写日志或发到监控平台。宁可丢弃几瓶边缘数据，也不能让打点系统影响用户实际请求。

6. 单链接数据怎么用于线上监控和调优

6.1 最重要的三个派生指标

数据采集回来不是为了躺在数据库里，我最终是从单链接记录里产出三个监控指标：

这三个指标再叠加网络类型、协议类型、服务端机房维度，基本就能看出 Cronet 对用户实际体验的影响。哪些场景下走 HTTP/3 减少握手、哪些场景下需要服务端调长空闲连接超时，数据里都有答案。

6.2 一个实际案例：连接反复新建比握手慢更可怕

这套系统上线后我们很快抓到过一个典型问题：某接口的请求成功率不低，但每次都触发新建连接。单链接聚合记录显示，这些请求 DNS 和 TCP 阶段的耗时都正常，TLS 握手也只花了 30ms 左右，但每次请求都带着 socketReused == false。

顺着 NetLog 一看，原来是服务端某个边缘网关的空闲连接超时设得太短，客户端连接池里那条 HTTP/2 连接超过几秒就被网关静默断开。Cronet 在发下一个请求时发现连接不可用，只能重新建链。从用户体感上，这个“重连开销”不算大，但高频接口每一轮都要多几次 RTT，P95 就悄悄上去了。

如果没有单链接层面的复用率监控，只盯着单请求耗时，会以为网络慢，实际是服务端连接保活策略和客户端不匹配。

6.3 后续可扩展的方向

当前这套实现已经能满足线上单链接性能评估，但我还在持续补两个方向：

第一个是 QUIC 连接迁移场景。移动网络下 Wi-Fi 切蜂窝时，QUIC 会尝试连接迁移，请求级 Metrics 不太容易体现这个迁移到底成功没有、中间丢了多少包。这个需要在 Cronet 增加连接级事件回调或者借助 NetLog 的 QUIC 事件解析。

第二个是把单链接记录和“网络诊断”联动。当单链接指标里出现 DNS 时间异常或握手时间剧增时，自动触发一次主动 NetLog 和 ping/MTU 探测，把问题现场完整保存下来，而不是等用户截图反馈。

说白了，基于 cronet 的单链接性能信息收集，最难的不是写出第一个打点回调，而是想清楚每条指标到底是谁的性能、用什么方法去验证它没有被别的层干扰。把“请求”和“连接”这两层彻底分开，网络问题排查的效率和准确度会明显提升。