企业官网建设流程全解析

做网络优化的人，大概率都有过这种经历：接口体量不大，服务端响应也快，但线上P99总是偶尔掉链子；抓包一看，TCP握手次数比预期多出好几倍。说白了就是HTTP连接复用没生效，一个本来可以走老连接的请求，偏偏每次都重新建连。我去年排查Cronet相关的问题，最头疼的不是怎么优化，而是“你怎么判断一个请求到底有没有复用已有连接”。Cronet作为一个基于Chromium网络栈的库，连接复用机制和OkHttp、HttpURLConnection完全不同，很多从OkHttp转过来的同学，第一步就懵了。这篇文章我就把“Cronet判断连接是否复用”这件事，从原理、代码、抓包到踩坑，完整讲一遍。

网上关于Cronet连接复用的讨论其实不少，但大多是零散的截图和口述，真正能落地的判断方法，尤其是不依赖外部抓包、能在业务侧直接感知的方案，反而很少。我这次会先从协议层面把连接复用的几种形态理清楚，再按“代码层拿数据”“NetLog看过程”“指标反推结果”三条路分别给出可操作的做法，最后把我在线上遇到过的几个误判场景列出来。如果你现在正在做Cronet接入或网络性能优化，这篇文章应该能帮你少走不少弯路。

1. 先把“连接复用”这件事拆明白：Cronet到底在复用谁

1.1 三层协议，三种复用含义

很多人一听到“连接复用”，第一反应就是Keep-Alive，也就是HTTP/1.1里那个Connection头。在Cronet的语境下，问题远比这个复杂，因为Cronet同时支持HTTP/1.1、HTTP/2和QUIC，而每一种协议里的“复用”含义都不一样。

先说HTTP/1.1。它的连接复用就是我们最熟悉的Keep-Alive：一个TCP连接在响应请求结束后不直接关闭，而是在一段时间内保持空闲，后续请求继续用这条连接。判断一个请求是否复用了连接，标准很简单：后一个请求是否使用了前一个请求的同一个TCP socket。

然后是HTTP/2。HTTP/2在一个TCP连接上可以同时跑多个Stream，每个Stream承载一个请求。所以连续发两个请求到同一个服务端，它们很可能共用同一个TCP连接，但各自有不同的Stream ID。这里有一个容易混淆的点：HTTP/2的“多路复用”是指应用层的请求并发，真正的底层TCP连接复用，还是那条老连接。判断时不能看到两个请求共用连接就说是HTTP/2的特性，还要区分连接和Stream的关系。

QUIC是第三种情况。它基于UDP，把TCP的连接管理和TLS握手合并到了自己的会话层。QUIC的连接复用更像是“session复用”：同一个QUIC Connection ID对应的会话，可以用0-RTT直接发数据，省掉了一次RTT。技术上看，它甚至连“TCP连接”都没有，但从上层请求的视角看，它的确做到了连接复用。包括连接迁移时，Connection ID保持不变，但底层网络路径可能已经换过一条。

1.2 Cronet连接池的组织方式

Cronet底层是Chromium网络栈，它对连接的管理比你想象中还要底层。很多从OkHttp切过来的人以为Cronet也有一个“类似ConnectionPool的类”，然后通过这个类去查连接复用状态——这是个大误区。Cronet负责连接复用的是网络栈内部的HttpStreamFactory、SocketPool和QuicSessionPool，这些核心对象没有对外开放Java API。

Cronet对外暴露的是UrlRequest和BidirectionalStream，你只能发起和取消请求，拿不到底层SocketPool里的连接列表。这带来的直接问题是：判断连接是否复用的难度，比OkHttp大很多。OkHttp里你可以看到connectionPool的connectionCount和idleConnectionCount，Cronet压根没有这种直接入口。所以很多习惯了OkHttp风格的同学，换到Cronet后第一反应就是“我怎么什么都看不到”。

如果把Cronet的连接体系比作一个停车场：SocketPool是车位，HTTP/2 Session和QUIC Session是停好的车，请求就是来找车位的司机。司机来了先看停车场有没有空闲的车位，有就直接停进去；没有就新建一个车位，同时把车开进来。这是最朴素的连接复用逻辑，NetLog里能看到的就是这个“找车位”的过程。

1.3 明确判断目标，才能选对判断方法

“怎么判断连接是否复用”这个问题的难点在于，目标不同，答案完全不同。你是想证明“同一个客户端进程内，多次请求复用了同一条连接”，还是想看“连接建立次数在请求总量中的占比”，又或者是“服务端主动断开后重新建连的频率”？这三个问题对应的判断方法，完全不是一套东西。

我自己的经验是，先给判断目标定个范围，再选手段：

• 如果只想快速确认线上有没有复用：看连接建立次数和请求总次数的比例，指标反推就够了。
• 如果想定位某个请求到底有没有复用老连接：只能靠NetLog，因为它会记录每个请求绑定到了哪个Socket或Session。
• 如果想知道业务在特定场景下的复用表现：可以在RequestFinishedInfo上做采样上报，用代码层的数据辅助分析。

后面三个部分，我会分别把这三条路展开讲。

2. 代码层感知连接复用：从RequestFinishedInfo里挖线索

2.1 RequestFinishedInfo能暴露出什么

Cronet提供了一套请求结束回调：RequestFinishedInfo.Listener。在请求结束之后，这个回调会带着RequestFinishedInfo对象返回，里面包含Metrics、Annotations和FinishedReason三个关键信息。其中最被忽视也最有价值的是Metrics。

Metrics类暴露了请求开始时间、结束时间、首字节时间、发送字节数、接收字节数等数据。这些字段对判断连接复用有什么帮助？关键在于部分版本的Metrics里，还有“连接建立”阶段的时间信息。如果一段流量里，某几个请求的TTFB（时间到首字节）很高，而另几个请求的TTFB很低，低的那部分大概率是走了连接复用。

但这里要特别提醒：Cronet的API一直在演进，不同版本里Metrics暴露的字段差别很大。我最早用的版本里，Metrics连连接信息都没有，只能通过时间间接推断；后来某次升级后，多了ConnectionInfo对象，才总算能拿到协议、RTT、本地IP、远端IP之类的数据。所以依赖Metrics做判断时，一定要先确认你接入的Cronet版本里，RequestFinishedInfo.Metrics到底开放了哪些字段。最好的办法是直接翻本地依赖里的源码，或者写个Demo把所有字段打出来看一眼，不要凭网上的旧文章猜。

2.2 ConnectionInfo里的协议、网络状态和复用痕迹

如果你用的Cronet版本比较新，那么Metrics里会有一个getConnectionInfo()方法，返回ConnectionInfo对象。这个对象里能拿出什么？比较常见的有：

• 协议类型（h2、h3、http/1.1等）
• 本地IP、远端IP
• RTT估算值
• 网络信号相关参数
• 收发字节数

需要注意的是，ConnectionInfo并不是专门为“判断连接复用”设计的，它更偏向网络质量诊断。所以你不会在里面看到一个字段叫reused，或者“是否复用”的布尔值。但你可以拿它做一件事：对比前后两个请求的ConnectionInfo里的本地IP、远端IP和连接相关的标识。如果两个请求的远端IP相同，协议也相同，那它们很有可能复用了同一条连接，再结合耗时就能进一步确认。

不过这条路的局限也很明显：拿不到Socket级别的连接ID，靠IP和协议做“痕迹对比”，只能算间接证据。如果线上有负载均衡、DNS变化、连接迁移等因素干扰，就很可能会出现误判。所以我的习惯是，ConnectionInfo用于线上粗筛，真正要下结论时，还是要靠NetLog。

2.3 一个可用的采集器示例

我分享一下我自己在工程里用的粗筛代码，思路很简单：给CronetEngine加一个RequestFinishedListener，把每次请求的协议、远端IP、TTFB、总耗时、请求URL放进采样数据里，按域名聚合，再观察同域名下“连接建立次数”的变化趋势。

val engine = CronetEngine.Builder(context) .enableQuic(true) .enableHttp2(true) .addRequestFinishedListener(object : RequestFinishedInfo.Listener() { override fun onRequestFinished(requestInfo: RequestFinishedInfo) { val metrics = requestInfo.metrics ?: return val sb = StringBuilder() sb.append("url=").append(requestInfo.url) sb.append("finishedReason=").append(requestInfo.finishedReason) metrics.connectionInfo?.let { conn -> sb.append("protocol=").append(conn.protocol) sb.append("remoteIp=").append(conn.remoteIp) sb.append("rtt=").append(conn.rtt) } sb.append("ttfb=").append(metrics.ttfbMs) sb.append("total=").append(metrics.totalTimeMs) Log.d("CronetReuse", sb.toString()) } }) .build()

这里有一个判断技巧：如果连续访问同一个域名多次，前面一两次的TTFB明显高于后面几次，且后面的远端IP没有变化，那基本可以判定连接复用生效了。反过来，如果每个请求的TTFB都很平均地高，或者远端IP每几次就换一次，那就要怀疑连接复用压根没匹配上。

记得给采样上报加上开关。线上全量打日志会把输出打爆，我一般只在Debug包或者线上特定版本开一个小比例采样，定位问题足够了。

3. 用NetLog把连接的一生看个清清楚楚

3.1 开启NetLog，拿到最底层证据

如果说代码层是“看体检报告”，那NetLog就是“看监控录像”。NetLog是Chromium网络栈自带的事件日志系统，Cronet把它暴露给了Android。开启方式很直接：

val builder = CronetEngine.Builder(this) builder.enableNetLog( File(filesDir, "cronet_netlog.json").absolutePath, 50 * 1024 * 1024 ) val engine = builder.build()

这个方法的第一个参数是日志输出路径，第二个参数是日志文件的最大体积。看效果的话，建议开到几十MB起步，不然高并发场景日志很快就截断了。需要注意的是，不同版本里enableNetLog的接口有过变化，有些版本还在Builder上，有些则挪到了别的扩展方法；而且这个方法主要是给排障用的，线上不建议长期开启，否则磁盘写入有点疼。

日志文件是JSON格式，直接用文本编辑器打开也能看，但事件太多，人眼根本扫不过来。最好用Chromium的netlog viewer（也就是chrome://net-export那个工具）加载，它会按时间线把所有事件渲染出来，还可以按事件类型过滤。

3.2 在NetLog里找“复用”的关键事件

NetLog记录的是底层事件流，里面有几个关键事件，直接对应连接复用的判断。

最核心的是URL_REQUEST_START_JOB。这个事件发生在请求真正开始创建网络任务时，它的参数里经常会带一个叫做reused_socket的字段。如果这个字段为true，说明这次请求复用了已经存在的Socket；为false则说明新建了一条连接。这个字段可以说是我判断连接是否复用最直接的依据。

除此之外，请求事件和连接池事件之间还有source_dependency关系。你会看到一个URL_REQUEST的source_id依赖了一个HTTP_STREAM_JOB，而这个HTTP_STREAM_JOB又可能依赖某个SOCKET_POOL事件。追踪这条依赖链，你就能知道当前请求到底绑在哪条连接上。

举个我实际排查过的例子：线上反馈某个域名的请求经常出现高延迟，我抓了NetLog一看，URL_REQUEST_START_JOB里reused_socket字段大量出现false。进一步顺着source_dependency看，每个请求都新建了Socket，而且新建完很快就因为某些原因被回收了。这就不是复不复用的问题，而是连接根本活不过一个请求生命周期，后面排查发现是服务端主动关闭了连接，客户端还没来得及复用就被断掉了。

3.3 不同协议下的NetLog事件差异

很多同学拿到NetLog后不知道看什么，主要是因为HTTP/1.1、HTTP/2、QUIC的事件名称不一样。这里我列一张典型的对照表，方便你按协议类型快速定位：

我一般不会逐条看NetLog，而是用脚本先按source_dependency做聚合，找出每个请求依赖的最底层Socket或Session的ID，然后看这些ID在不同请求之间有没有复用。如果10个请求里9个依赖同一个Socket ID，连接复用率就是90%。这个思路不依赖具体字段名，换成什么协议都好使。

4. 指标反推法：不依赖API也能判断连接复用

4.1 连接建立次数 vs 请求次数

有时候你只是想快速评估“连接复用”在线上整体做得怎么样，没必要给每个请求都上NetLog，那样太费了。最简单有效的方法是统计连接建立次数和请求次数的比例。

怎么统计连接建立次数？Android端最常见的做法是抓包，tcpdump或者Wireshark看TCP握手报文。如果你只是想验证某一个测试场景，手动抓包是最直观的：连续发10个HTTP请求，看抓包里出现了几次SYN包。出现1次，那说明连接全部复用；出现10次，那说明每个请求都在重建连接。

这只适用于HTTP/1.1和HTTP/2场景。QUIC没有TCP握手，得看UDP层面有没有新的QUIC握手包。相比之下，HTTP/2的判定更容易，因为一个TCP连接内的请求都带相同四元组，看报文源端口就够了。

有人会问：能不能在业务代码里统计连接建立次数？理论上可以通过反射或者Hook拿到Cronet内部状态，但那是内网API，很不稳定，Cronet升级一次可能就要改一次。我的建议是：线上不要硬刚，把NetLog采样做一个轻量统计脚本，每次采样500条请求，统计一下同样协议同样远端IP下，不同Socket ID的数量，基本就能算出复用率了。这个方法比反射稳定太多。

4.2 用耗时分布定位异常

连接复没复用，在耗时分布上有一个非常明显的特征：首次请求要经历DNS、TCP握手、TLS握手，耗时会比较长；后续复用连接的请求，省掉握手阶段，TTFB会明显下降。所以你把同域名请求按“首次”和“非首次”分组，对比分组TTFB的P50和P90，如果P50差距不到10ms，那说明“每次都在建连”，复用可能失效；如果P90差距明显但P50很小，说明大多数请求拉平了，只有部分连接重建导致尾部变差。

我有一个线上监控的实践：针对某个核心域名，把每个请求是否“可能复用”定义为首字节时间低于该域名P25的一个阈值。低于阈值就标记为“疑似复用”，高于阈值标记为“疑似新建连接”，然后按小时统计疑似复用比例。这个指标虽然不能替代NetLog，但作为线上趋势监控非常管用，能第一时间发现服务端调整连接超时参数导致复用率暴跌的情况。

4.3 从Cronet的trace事件和内部指标辅助定位

Cronet还提供了一些实验性的trace和性能指标能力。这些能力在不同版本里差异很大，有的通过ExperimentalCronetEngineBuilder开启，有的需要编译期的flag打开，普通业务方很难直接使用。我在排查时用过一种讨巧的办法：结合Cronet自带的Bandwidth和RTT estimation接口做一个“连接健康度”标记。

思路是这样的：Cronet会根据历史请求维护RTT和带宽估计。如果一个请求的RTT变化很小，带宽估计也稳定，说明它大概率走的是一个稳定的连接状态；如果RTT突然跳高一个量级，那很可能是新建连接或者路径变了。这个方法不精确，但在没有NetLog的情况下，能辅助判断连接复用的稳定性。

真正需要精确定位时，还是回到NetLog，用脚本做事件聚合。以下是我常用的一段Python脚本逻辑：解析NetLog里的URL_REQUEST_START_JOB事件，提取每个请求的reused_socket、source_dependency和连线，然后用集合去重计数。

import json with open("netlog.json", "r") as f: data = json.load(f) events = data["events"] url_requests = [] for event in events: if event.get("type") == "URL_REQUEST_START_JOB": params = event.get("params", {}) url_requests.append({ "id": event["source"]["id"], "reused_socket": params.get("reused_socket"), "dep": params.get("source_dependency"), }) reused = [r for r in url_requests if r["reused_socket"] is True] new_conn = [r for r in url_requests if r["reused_socket"] is False] print(f"总请求: {len(url_requests)}, 复用socket: {len(reused)}, 新建连接: {len(new_conn)}")

注意NetLog的JSON结构在不同Cronet版本里略有差异，不保证脚本每个版本都能直接跑通，但思路是一致的：找事件，看复用标志，聚合统计。写一遍，以后换版本修下字段路径就能接着用。

5. 判断连接复用时最容易踩的坑

5.1 QUIC连接迁移让“连接ID不变”变成假象

如果你判断连接复用的唯一依据是QUIC Connection ID，那你就掉进了一个大坑。QUIC设计了一个很优秀的特性叫连接迁移，它允许Connection ID保持不变，但底层网络路径、甚至网络类型（WiFi和蜂窝之间切换）发生变化时，连接依然可以存活。从业务层看，请求确实复用了同一个QUIC session，但你关心的“连接”可能已经悄悄换了一条物理通路。

在NetLog里，连接迁移通常表现在QUIC_SESSION_CONNECTED之后又出现了网络路径变化相关的事件，RTT值也会跟着突变。所以我判断QUIC场景下的连接复用，不会只盯着Connection ID，而是会同时看RTT和路径信息。如果你发现了Connection ID没变但RTT显著升高的现象，不要轻易下“复用正常”的结论，要排查一下是不是连接迁移触发了路径切换。

5.2 HTTP/2的多路复用容易把Stream当成连接

这是我在团队里被问过最多的一次。有同事拿着抓包结果说：“你看这个请求复用了连接，stream_id是7，上一个请求是5，下一个又变成9，这不是复用得挺好的吗？”我一看，这只能说明HTTP/2在同一TCP连接上开了多个Stream，根本不等于每个HTTP请求都是一次“新建连接”。Stream是复用TCP连接之上的逻辑流，Stream ID变化是正常的，不代表TCP连接发生了重建。

判断HTTP/2的连接复用，要看的是TCP四元组和TLS会话，不是Stream ID。在NetLog里也要注意，HTTP2_SESSION_POOL_INITIALIZED事件只代表Session初始化，不代表每个请求都新建连接。正确的方法是，统计请求依赖的HTTP2_SESSION ID是否一致，不能依赖Stream ID。

5.3 连接池的空闲策略和过期时间造成的误判

即使你抓到了复用的证据，也不能保证下一次请求还能复用到。服务端和客户端都有自己的连接空闲和过期策略。Chromium网络栈会关闭空闲太久的连接，服务端也会根据Keep-AliveTimeout主动断连。于是你可能会遇到一种奇怪的规律：前5个请求全部复用连接，第6个请求突然reused_socket变为false，后面又恢复复用。

这种周期性断连不是Cronet的bug，而是空闲连接被清理了。如果你在统计连接复用率时没有按时间窗口细分，这种周期性波动会被平均掉，很难发现问题。我的做法是：把采样NetLog按分钟切片，分片统计每个窗口内新建连接数量。如果新建连接数量呈现固定周期波动，就去看服务端的空闲连接超时参数，往往一找一个准。

5.4 版本升级导致的判断逻辑失效

Cronet是Chrome团队维护的，版本迭代快，API变化也快。我在项目里就遇到过这么一次：旧版本里NetLog的URL_REQUEST_START_JOB事件里还能看到reused_socket字段，升级到新版本后，这个字段被改名了，脚本直接解析不到数据。更麻烦的是，RequestFinishedInfo.ConnectionInfo在不同版本里的字段也不完全一样，之前的粗筛代码在新版本里拿不到RTT。

所以在做连接复用判断的过程中，数据的准确性是以“和当前Cronet版本匹配”为前提的。我的经验是每次升级Cronet后，都要先跑一遍解析脚本，看看字段路径有没有变化；同时保留升级前的NetLog样本，方便对比解析结果。别图省事，这一步跳过了，后面排查问题时会把自己坑死。

5.5 多域名和DNS轮询下的连接匹配

最后提一个容易被忽略的问题：Cronet的连接复用是按“地址组”来匹配的，简单理解就是同一个host、同一个IP、同一个端口，才可能复用连接。如果你的域名开启了DNS轮询，同一个域名解析出来的IP每次都不一样，连接复用率就会很低。从NetLog里看，你会发现URL_REQUEST_START_JOB里出现新的IP，即使前面刚发过这个域名的请求，也没法复用老连接。

这种情况不是Cronet能解决的，得从业务侧做改造，比如接入HTTPDNS和IP端口直连，把域名解析稳定下来，才能让连接复用真正生效。判断的时候，也不能只看域名复没复用，必须把IP也纳入对比。我之前就吃过这个亏，盯着域名看了半天，发现IP一直在变，回过头才意识到是DNS轮询在捣乱。

个人用这套方法排查下来，最大的感受是：连接复用不是一次配好就完事的静态指标，而是一个受客户端、服务端、网络路径共同影响的动态过程。有效判断的核心不是某个单一API，而是把代码层、NetLog、指标反推三条路结合起来，互相印证。尤其是线上问题，我一般先用指标监控抓趋势，再用RequestFinishedInfo粗筛样本，最后用NetLog精确定位，整个链路跑下来，基本上不会误判。

如果你正在做Cronet接入，建议提前把NetLog解析脚本写好，版本升级时也顺手更新一下，等线上真出问题的时候，你就能比别人快一步。这套判断连接复用的经验，至少在目前我接触过的Cronet版本里是通用的，希望对你有帮助。