抓包工具与网络分析

• 中间人代理（MITM）的工作原理
• HTTPS 证书信任机制与证书安装
• 手机端代理配置与系统/用户信任的差异

HTTPS 抓包本质是中间人代理（Man-in-the-Middle）。客户端通过代理访问时，代理向客户端呈现"代理自签的证书"，同时代理以客户端身份向真实服务器发起真实 TLS 连接并完成握手。这样代理位于加密链路中间，能解密客户端→代理的流量，也能解密代理→服务器的流量，从而看到明文请求和响应。前提是客户端必须信任代理的自签证书：在手机端把导出的 .pem/.cer 证书安装并开启信任。手机端配置步骤为：电脑端 Charles 开启代理（Proxy→SSL Proxying Settings 勾选 host 并添加*:443），记录电脑 IP 与端口（默认 8888）；手机连接同一 Wi-Fi，在 WiFi 高级设置中把代理设为"手动"，填入电脑 IP 和端口；然后用手机浏览器访问 chls.pro/ssl（Fiddler 则访问 http://ip:8888 下载证书）下载并安装证书；Android 7.0+ 需把证书安装到系统证书目录（或通过调试包 user 证书信任），iOS 需在"设置→通用→关于本机→证书信任设置"中开启完全信任。完成后即可在 Charles 中看到明文的 HTTPS 请求与响应。

关键在于理解"中间人"的双向 TLS 握手：客户端信任的是代理证书而非真实服务器证书，因此抓包软件必须能支配客户端的信任链。所有抓包遇到证书错误的根源都在于信任链未建立，排查时应先确认证书是否安装且被完全信任。

• 断点（Breakpoint）改包的流程
• Map Local 与 Rewrite 的区别与适用场景
• 用 Mock 响应对抗性测试的思路

断点改包（Breakpoint）允许在请求发出前或响应返回前暂停流量，手动修改请求参数、响应体、状态码后再放行，用于验证客户端对异常数据的处理。例如把正常 JSON 响应改成报错格式、超长字段、空列表、特殊字符，观察前端是否崩溃或优雅降级。Map Local 是把某个远程 URL 直接映射到本地文件，适合固定返回一份 Mock 响应反复测试；Rewrite 则是对请求/响应做规则的自动重写（如替换 host、去除响应头、改动 body 字段），适合批量场景。健壮性测试场景包括：模拟 500 错误、接口超时、返回重复字段、字段类型错误、图片为空、返回超大 JSON 等，验证客户端有无未捕获异常、空指针、闪退或卡死。

断点属于"人工干预"适合单次精确验证，Map Local/Rewrite 属于"自动化规则"适合可重复的批量验证。测试时应先在真实请求上确认收发包格式，再逐步做破坏性修改，以覆盖正常之外的异常路径。

• 证书未信任的排查与解决
• SSL Pinning 的原理与绕过手段
• 代理绕过与双向认证的处理

证书未信任是首要问题：确认证书已安装并被系统信任，Android 7.0+ 默认只信任系统证书，需要把用户证书移入系统证书目录或使用可调试的应用；iOS 需在"证书信任设置"里完全信任。代理绕过常见于 App 使用 HTTP 直连、忽略系统代理、或基于域名/IP 直连不走代理，可改用强制代理（如透明代理）或配合 VPN 类工具（如 tcpdump + 本地抓包）解决。SSL Pinning 是 App 在内置证书校验之外，把服务器证书或公钥"钉死"在客户端，即使信任代理证书也会校验失败，绕过手段包括：使用 Frida/Xposed 等 Hook 框架禁用校验、重打包 App 移除校验逻辑、使用支持 SSL Pinning 绕过的代理插件（如 Android 的 JustTrustMe、Charles 配合 Frida 脚本）。双向认证（mTLS）要求客户端也提供证书，需获取客户端证书并在代理或抓包工具中配置该证书才能解密。

三类问题本质都是信任链或校验逻辑被"加固"。处理顺序应从最基础的证书信任开始，再处理代理与 Pinning，最后处理双向认证。绕过 Pinning 属于测试加固手段，需评估合规边界。

• Charles Throttle 弱网配置
• DevTools 网络节流（throttling）与自定义配置
• 两种工具适用场景与差异

Charles 通过 Proxy→Throttle Settings 开启限速，可设置带宽、往返延迟（RTT）、丢包率、MTU 等参数，作用范围是经过代理的所有流量，适合移动端 App 真机弱网测试。浏览器 DevTools 的 Network 面板提供 No throttling / Fast 3G / Slow 3G 预设，也可在 Network Throttling 中自定义带宽、延迟与丢包（某些浏览器支持 jitter）。差异在于：Charles 是代理层模拟，作用于真实网络流量，可测 App 与跨端；DevTools 是浏览器内置模拟，仅对当前页面生效，适合快速验证前端资源加载与请求时序。DevTools 更侧重前端性能感知，Charles 更贴近真实网络环境。

弱网测试关注的是客户端在资源加载慢、请求超时、连接中断时的表现。选用哪种工具取决于被测对象：纯前端用 DevTools 更快，包含 App 网络层或后端配合则用 Charles。

• Timing 瀑布各阶段含义
• 状态码与响应头解读
• 用指标判断问题归属

Network 面板中每条请求的 Timing 瀑布图展示 Stalled、DNS Lookup、Initial connection（含 TLS）、Request sent、Waiting (TTFB)、Content Download 各阶段耗时。TTFB 长通常说明后端处理慢或网络慢；DNS 长说明解析问题；Content Download 长说明资源体量大或带宽受限。状态码用于判断性质：2xx 正常、4xx 客户端问题（参数/权限/URL）、5xx 服务端问题，配合响应头（如 cache-control、Retry-After、Location、CORS 头）可进一步排查。请求头能确认参数、Cookie、认证信息是否按预期发送，响应头能确认缓存策略、重定向、跨域配置。通过组合这些指标，可快速把问题归到 DNS/网络层、后端、还是前端渲染。

定位接口问题遵循"先看是否发出请求（Request Headers 是否正确）→ 再看状态码与响应头 → 再看 Timing 各阶段"的递进逻辑。瀑布各阶段耗时长短直接暴露瓶颈所在层级。

• SSL 代理与证书配置的工程要点
• 移动端系统版本差异
• 抓包涉及隐私与合规的红线

工程配置要点包括：在 Charles/Fiddler 开启 SSL Proxying 并配置需解密的 host（*表示全部）；导出并安装根证书；Android 需区分系统/用户证书且 targetSdk 27+ 默认不信任用户证书，需 debug 包或改包添加 networkSecurityConfig；iOS 需在证书信任设置开启完全信任。合规边界在于：抓包会实际记录到用户隐私数据（账号、密码、手机号、支付信息、业务数据），必须控制抓包范围、按最小必要原则仅抓取被测接口、脱敏展示、抓包文件及时销毁、禁止在未授权环境抓取他人或生产敏感数据；绕过 Pinning、重打包、Hook 等手段可能违反服务条款或法律法规，需在授权范围内用于自身产品或测试环境。

工程配置解决"能不能抓到"，合规边界解决"能不能随便抓"。测试人员应明确抓包目的与授权范围，避免过度采集与数据泄露。

• Wireshark 常用过滤器语法
• TCP 重传与 RTT 的解读
• 时间线分析定位网络问题

常用过滤器：ip.addr==x.x.x.x && tcp 按主机过滤，tcp.analysis.flags 或 tcp.analysis.retransmission 查看重传，tcp.analysis.ack_rtt 查看 ACK 往返时延，tcp.flags.syn==1 查看握手报文。弱网问题通常表现为：重传次数多、RTT 波动大、TCP 窗口变小、重复 ACK/DUP ACK 增多、丢包率高。通过"追踪 TCP 流"（Right-click→Follow TCP Stream）可还原完整会话，结合时间线观察 SYN 重传、ZeroWindow 等异常，可判断是丢包、拥塞还是对端处理慢。Filters 与时间线组合能区分是网络层丢包还是服务端响应慢。

Wireshark 是协议分析底层工具，能看 TCP 层最真实的状态。弱网定位先数重传与检查 RTT，再用 Follow TCP Stream 还原会话，判断问题在传输层还是应用层。

• 抓包定位问题的方法论
• 请求-响应链路的还原
• 多工具协同分析

完整流程为：先复现问题并抓包，记录触发前后完整流量；再定位到目标请求（按 URL/域名/时间过滤），解析请求行、请求头、请求体与响应状态、响应头、响应体；随后还原请求-响应链路，即把"客户端→边界/网关→应用→数据库"各环节的报文与时间线对齐，判断失败发生在哪一跳。Wireshark 负责 TCP/IP 层与握手、重传等底层分析，Charles/Fiddler 负责 HTTP/HTTPS 应用层内容。若涉及 HTTPS，需先解密；若跨服务，需结合 traceId 关联各服务日志。最后把分析结论用于定位缺陷归属（前端、后端、网络、数据）。

抓包还原链路的核心是"从终端用户看到的表象，逐层剥到协议报文"，利用时间戳与 traceId 把分散的请求串成一条完整链路。工具选择上底层用 Wireshark、应用层用 Charles/Fiddler。

• 状态码语义与归属判断
• 缓存头与 CORS 头的解读
• 用响应头定位前端/后端问题

状态码 4xx 表示客户端请求有问题（400 参数格式、401 未认证、403 无权限、404 路径不存在、429 限流），倾向客户端或配置问题；5xx 表示服务端异常（500 服务器内部错、502 网关/代理错、503 暂时不可用、504 网关超时），倾向后端。缓存头（Cache-Control、Expires、ETag、Last-Modified）决定资源是否被缓存、是否命中缓存，能解释"页面更新但显示旧数据"或"接口重复请求却未变化"。CORS 头（Access-Control-Allow-Origin 等）可解释跨域请求被浏览器拦截的问题，属于前端请求被浏览器层阻断而非后端失败。通过三者的组合可快速划分问题归属并给出下一步排查方向。

状态码给"方向"，缓存头给"数据的时效性线索"，CORS 头给"浏览器层拦截线索"。三者结合能一次判断问题在客户端、传输层还是服务端。

• 性能瀑布图各阶段解读
• TTFB 与前后端判定
• 资源加载瓶颈分析

资源瀑布图把请求拆成 Stalled/DNS/TCP/TLS/请求发送/TTFB(Wait)/下载各阶段。DNS 慢→域名解析问题；TCP/TLS 慢→连接建立或握手问题（可复用 keep-alive 优化）；TTFB 长→服务器处理慢或网络往返慢，通常指向后端；Content Download 长→资源体大或带宽受限，通常指向前端资源优化。判定前后端慢的核心：TTFB 大而下载快，问题在后端；TTFB 小但整体渲染慢，问题在前端渲染或资源加载。还可对比多接口、多资源的瀑布，找出瓶颈集中点。

性能瓶颈判定的关键是"分段定位"：把总耗时拆到传输、处理、下载各环节，用 TTFB 作为前后端的分界指标。TTFB 以内归后端，以外归前端/网络。

• 重放验证幂等与限流
• 动态参数修正
• 重复提交测试

抓包重放用于验证接口幂等性（相同请求重复提交结果一致）、限流（高频重放触发限制）、重复提交防御（双击/并发提交是否产生脏数据）。重放时需修正动态参数：时间戳（换成当前时间或固定值）、签名（用当前时间戳重新计算签名）、token（替换为有效的新 token）、自增 ID、随机数、session 等。可通过脚本（如 Charles 的 Repeat、Postman 的 Runner、jmeter/shell 脚本）批量重放并统计结果。若签名依赖时间戳，需先重新计算再重放，否则会因签名失效被拒。

重放的核心难点是"动态参数"——直接重放旧请求往往因时间戳/签名/token 过期而失败。工程化做法是参数化动态字段，用脚本在重放前实时刷新。

• 加签/加密请求的应对
• 获取或绕过加密的手段
• 与开发协作验证

应对策略包括：向开发确认加签/加密算法与密钥，在测试环境使用可读的密钥或关闭加密开关；使用支持解密的代理或脚本（如 Frida Hook 拿到密钥后在 Charles 中解密）；通过改包时重新计算签名来验证防篡改逻辑；对加密请求重点验证签名正确性、防重放、防篡改等安全用例。若密钥不可得，可基于加密后的报文做黑盒测试（如固定报文、对比响应），并配合开发在测试环境输出明文日志。关键是区分"测试加签正确性"与"测试业务逻辑"，前者需要可控密钥，后者可用黑盒。

加签/加密属于接口安全加固，测试的核心是"能否在可控前提下验证"，优先向开发获取测试环境密钥，其次才用 Hook 等逆向手段，并注意合规边界。

• 抓包数据与代码的对应
• 责任归属判定
• 与开发协作定位

从抓包反推责任归属的关键是"看请求与响应是否符合契约"：若请求参数错误（少了必填、格式错、值超范围），责任在前端；若请求正确但响应 4xx/5xx 或返回数据错误，责任在后端；若响应正确但页面展示错误，责任在前端渲染。抓包后应把请求/响应报文与接口文档（契约）比对，再结合代码定位：前端查发参逻辑与渲染，后端查 controller/service/DAO 与 SQL。把抓包报文作为证据提交，能显著加快开发定位。联动方法上，可用 traceId 把抓包报文与后端日志、断点对应起来。

抓包是"客观证据"，代码定位是"去向确认"。先以契约为准判定责任，再带着报文去查代码，避免互相推诿，也避免全凭经验猜测。

• 常见绕过手段
• 工程与法律风险
• 合规测试策略

常见绕过手段：使用 Frida/Xposed 等 Hook 框架在运行时禁用证书校验函数；重打包 App，在其代码中移除或替换 Pinning 校验逻辑；使用代理插件（如 JustTrustMe、Android 的 SSL Unpinning）在框架层注入；使用支持 Pinning 绕过的流量代理（如 mitmproxy 搭配脚本）。工程考量：Hook 涉及运行时逆向、重打包需重新签名，可能影响包完整性校验与稳定性；涉及他人未授权 App 时，可能违反服务条款、破坏软件完整性，甚至触犯法律（如反不正当竞争、刑法侵入计算机信息系统）。合规做法是仅在授权范围内、对自有或被测产品进行安全性测试，并记录测试范围与目的。

Pinning 绕过本质上是对"安全加固"的对抗，测试价值在于验证客户端安全，但必须限定在授权与合法范围内。测试前应评估手段的强度与风险，优先使用公司内部授权工具。

• 新协议抓包的工具支持
• decode 与解密配置
• 各协议调试注意点

WebSocket 抓包：Charles/Fiddler 的 WebSocket 面板可直接查看帧消息，DevTools Network 的 WS 标签可看收发帧；注意其长连接与 HTTP 升级的区别。HTTP2 抓包：Charles/Fiddler 支持 HTTP2 但需先在 SSL Proxying 中启用，注意 HTTP2 为二进制帧且多路复用，需按 stream 查看。gRPC 抓包：gRPC 默认基于 HTTP2 + protobuf 二进制，需配合 grpcurl、grpc-web 或 gRPC 插件（如 mitmproxy 的 gRPC 支持、Wireshark 的 protobuf + HTTP2 解码）；解密需先配置 TLS 密钥或使用支持 TLS 的代理。解密配置核心是"让代理持握 TLS 会话密钥或客户端信任代理证书"，对 HTTP2 还需处理 ALPN 协商。

新协议普遍基于二进制与多路复用，比传统 HTTP 文本更难直接读。调试思路是"找协议对应工具 + 正确解密配置"，必要时用 tcpdump 抓底层再按协议解码。

• 抓包数据的敏感风险
• 脱敏与销毁方法
• 数据安全规范

抓包数据可能包含账号密码、token、手机号、身份证、支付信息、Cookie 等敏感数据，且通常以明文保存，存在泄露风险。风险管控措施：按最小必要原则只抓取被测接口，避免整站全量抓包；在抓包工具中配置过滤规则（如排除敏感域名、只记录响应头）；对展示与导出数据做脱敏（掩码手机号、替换 token、清除 Cookie）；禁用或限制自动保存；抓包文件加密存储、限制访问权限、开启自动清理；测试结束后及时删除或移交，并遵守数据安全与保密规范。对生产环境敏感数据要格外谨慎，必要时仅看脱敏版本。

抓包工具本身是"数据供应商"，风险在于明文敏感数据被留存。治理核心是"范围最小化 + 展示脱敏 + 存储加密 + 及时销毁"。

• 时间线对齐方法
• traceId 关联
• 端到端链路还原

联合分析的核心是"以时间为轴，以 traceId/requestId 为键"把分散信息串起来。抓包工具记录请求发出与响应返回的时间，服务端日志记录应用处理过程，数据库慢日志/执行计划记录数据操作。做法：从抓包拿到请求的 traceId 与时间戳，再到 ELK/grep 中按 traceId 检索服务端日志，按时间把"请求到达→鉴权→业务→SQL→响应"各环节对齐；结合 DB 慢查询日志定位耗时点。若系统有分布式链路追踪（如 SkyWalking、Zipkin、Jaeger），可直接按 traceId 拉出完整调用链。对齐后能区分耗时在网关、应用还是数据库。

单独看抓包只能看到"两端"，联合日志才能看到"中间的全过程"。时间戳是横轴、traceId 是关联键，二者结合才能还原真实链路。

• 代理抓包与自动化集成
• 请求断言与导出
• 失败现场留存

可将代理抓包工具（如 mitmproxy、Charles 的 API、BrowserMob Proxy、Playwright 的 HAR 记录）嵌入自动化框架。实现方式：测试启动时启动代理并配置为被测应用/浏览器的代理；测试过程中代理记录全部请求；测试结束后导出 HAR 或自定义格式的请求响应，用于断言（如校验接口状态码、响应字段、请求参数、调用次数）与失败现场留存（保存报文、截图、录屏）。Playwright/Puppeteer 可直接监听网络请求并断言；mitmproxy 提供 Python API 可拦截、修改、断言流量。失败时自动保存 HAR 与关键报文，便于回归定位。

抓包自动化把"被动观察"变成"主动断言与证据留痕"。核心三要素是"代理能记录、框架能断言、失败能留存"。