Charles实战：如何精准设置round-trip latency (ms)进行网络性能调优

---

背景痛点：为什么非得在本地“造”延迟？

做微服务最怕什么？不是 500，而是“时好时坏”的 200。
线上用户反馈“页面卡”，日志里却全是 200 ms 内的响应——真实网络里那一两百毫秒的 RTT（Round-Trip Time）被内网千兆环境抹平了。
结果就是：

• 超时阈值设得过低，移动用户直接触发重试，雪崩；
• 缓存穿透保护在 0 丢包环境测不到，一上 4G 全爆；
• HTTP/2 多路复用“队头阻塞”在局域网根本复现不了。

一句话：不在调试阶段把延迟“演”出来，上线后它就“演”你。

工具对比：Charles 凭什么胜出？

工具	粒度	动态脚本	可视化	缺点
Fiddler (Win)	单连接 1 ms 精度	JScript.NET，语法旧	有	跨平台靠 Mono，不稳定
tc (Linux)	0.1 ms 精度	bash + iproute2	无	整网卡一刀切，配错直接断网
Charles	单请求 1 ms 精度	ES6 + Rhino	实时瀑布图	收费，CLI 弱

结论：要“指哪打哪”给某条请求加延迟，同时让产品同学也能秒懂瀑布图，Charles 最趁手。

核心配置：Throttling 面板 5 步走

1. 打开Proxy → Throttling Settings
2. 勾选Enable Throttling
3. 在Throttle Preset选“Custom…”
4. 关键字段一次填到位：
   • Bandwidth（kbps）：下行 20 000 ≈ 20 Mbps，上行 5 000 ≈ 5 Mbps
   • Round-trip latency (ms)：写 150，表示每条请求固定 +150 ms
   • Reliability (%)：100 表示不随机丢包，想测 2 % 就填 98
   • Stability (%)：100 表示不随机断链
5. 点Add把需要延迟的 Host 加白，其余流量直通，避免把 IDE 插件也拖慢。

小提示：latency 设 0 时 Charles 仍会给 1 ms 的“软件损耗”，所以真正“零延迟”请关 Throttling。

代码级实践：把延迟写进文件、写进脚本

1. Map Local 静态延迟文件

场景：App 启动接口/config必须卡 300 ms，让骨架屏多飞一会。

步骤：

1. 抓一条真实响应，Save Response →config.json
2. 在该请求右键Map Local…，Local Path 指向config_delay.json
3. 在Tools → Rewrite里加规则：
   • 匹配 Path：/config
   • 类型：Response
   • 动作：Delay 300 ms（Charles 原生支持）

JSON 文件内容就是普通业务报文，无需改结构，延迟由 Rewrite 动作注入，干净可回滚。

2. Scripting 动态延迟（ES6）

场景：A/B 实验，50 % 用户 100 ms，50 % 用户 400 ms，看转化率。

// Charles 4.6+ 内置 Rhino，支持 ES6 语法 function onRequest(context, request) { // 随机数决定桶 const bucket = Math.random() <0.5 ? 'fast' : 'slow'; // 把桶名写进请求头，方便日志关联 request.setHeader('X-Latency-Bucket', bucket); } function onResponse(context, response) { const bucket = response.request.header('X-Latency-Bucket'); if (bucket === 'slow') { // 慢桶：额外再加 300 ms response.setDelay(300); // 单位 ms } else { response.setDelay(100); }

脚本保存为latency_ab.js，Tools → Scripting勾选即可。
setDelay只影响当前连接，不会拖慢其他并行请求，比 tc 的 netem 安全得多。

生产环境考量：别让“假”延迟触发“真”重传

1. TCP 重传阈值
   Linux 默认tcp_retries2=15，在 150 ms RTT 网络里约 13 s 才判定断线。
   你把 Charles latency 调到 1000 ms 却不改重传，会堆积大量 RTO，导致吞吐量暴跌，测试失真。
   建议：

   • 延迟 < 300 ms 时保持系统默认；
   • 延迟 > 500 ms 时，把服务器net.ipv4.tcp_retries2降到 5（≈ 3 s）。

2. HTTP 版本差异

   • HTTP/1.1：串行请求，延迟线性叠加，200 ms × 6 张图 ≈ 1.2 s 白屏；
   • HTTP/2：多路复用，1 条 TCP，延迟只算 1 次 RTT，但队头阻塞仍在 Stream 层；
   • HTTP/3 (QUIC)：UDP 0-RTT，若 Charles 延迟设在 50 ms 以内，基本无感；> 150 ms 时拥塞控制开始限窗。

   结论：别用同一套延迟值去验所有协议，至少分 3 组跑数据。

避坑指南：三条红线别踩

1. 阈值红线
   单请求 > 1 s 会触发浏览器“连接已重置”提示，测试变成测心跳，失去意义。
   推荐阶梯：

   • 4G 模拟：150 ms
   • 3G 模拟：300 ms
   • 弱网模拟：500 ms
     再高请直接丢包 5 % 而不是硬拉 latency。

2. SSL 代理忘了装根证书
   延迟规则对 HTTPS 生效的前提是Proxy → SSL Proxying Settings把对应 Host 加进去，否则 Charles 只能旁路转发，Delay 不生效。

3. 忘记关 Throttling
   曾经把 2 s 延迟留给“拍照上传”接口，结果下班继续刷剧，全公司 Git 拉代码 20 kb/s。
   养成习惯：工具栏小乌龟图标变绿 = 延迟开着，用完即关。

延伸思考：给业务做“分层延迟”体检

1. 接入层：给 CDN 静态资源加 50 ms，看是否阻塞首屏；
2. 逻辑层：给 Gateway /config 加 200 ms，验骨架屏超时；
3. 数据层：给慢查询接口加 400 ms + 2 % 丢包，验熔断和降级；
4. 端到层：用 Charles 外部代理模式串连 2 台手机，模拟“用户 A → 服务器 → 用户 B”双程延迟，测实时对战体验。

把每一层的“疼痛阈值”记下来，形成自己业务的《延迟基线表》，以后任何版本先跑一遍基线，再谈发版。

---

写完这篇，我把自用的 150 ms/300 ms 两套配置直接 export 成*.xml，下次需求评审现场 3 分钟就能给产品“演”一次弱网，再也不用“口算”等待时间。

如果你也想从零搭一个会“说话”的 AI，同时让它在真·弱网环境还能低延迟回你，不妨顺路试试这个动手实验：
从0打造个人豆包实时通话AI
我跟着做了一遍，把 Charles 的 200 ms 延迟脚本直接套到 WebRTC 通道上，AI 的应答依旧丝滑，才发现原来“耳朵+大脑+嘴巴”链路也可以这么玩。小白也能 30 分钟跑通，比自己写 tc 命令香多了。

---