ARTICLE DETAIL

资讯详情

深耕编程入门与网站建设的一线实战洞察。

五款抓包工具深度对比:Charles、Wireshark、Fiddler、Proxyman、TraceEagle选型指南

五款抓包工具深度对比:Charles、Wireshark、Fiddler、Proxyman、TraceEagle选型指南 做研发这些年我有个特别深的感触抓包工具这东西平时你不觉得它有多重要一旦碰到接口莫名其妙返错、App 在真机上登录失败、前端说后端返回的数据不对、后端又说前端参数没传全这类问题手边没有一个顺手的抓包工具排查效率至少低一半。我自己是从 Fiddler 入门的后来因为换到 macOS 办公又用上了 Charles 和 Proxyman中间为了分析 TCP 重传和 VLAN 问题没少在 Wireshark 里跟 pcap 文件死磕最近团队里也有同事在尝试 TraceEagle 这类比较新的工具。五款工具用下来各自的脾气和适用场景差异其实挺大的。这篇文章不打算把五款工具的所有功能重抄一遍而是从实际使用角度出发把 Charles、TraceEagle、Wireshark、Fiddler、Proxyman 各自的定位、核心用法、典型坑位和选型思路讲清楚。你可以直接拉到对应章节看想知道的工具也可以从头读理解不同工具在整套排障流程里分别扮演什么角色。不管你是刚入行的小白还是已经在用其中一两款、想再横向对比一下的工程师这篇应该都能提供一些有价值的参考。1. 先搞清楚五款工具各自在解决什么问题1.1 两类抓包思路代理转发与旁路采集很多人一上来就纠结哪款工具最强其实先想清楚一件更重要的事你手里的流量到底属于哪一层。Charles、Fiddler、Proxyman 这三款本质上是同一类东西——HTTP(S) 代理工具。你让手机、浏览器或者整个系统把网络请求统一发给工具监听的一个端口工具再替你跟真实服务器通信。由于请求流量都经过它它就能把明文 HTTP以及通过中间人方式解密的 HTTPS 内容完整记录下来还能在中间拦截、修改、模拟。这种方案的优点是应用层信息非常干净URL、Header、Cookie、响应体一目了然特别适合接口联调和前后端排障缺点是你只能看到走代理的流量抓不到纯 UDP也看不到 TCP 层重传、握手这种偏底层的数据。Wireshark 走的是另一条路线——旁路采集。它直接跟网卡打交道把进出设备的所有报文原样复制下来一帧一帧地分析。你不仅能看到 HTTP 请求还能看到 TCP 三次握手、TCP 重传、窗口变化、DNS 查询、ARP 广播这些底层细节。代价是它默认不帮你做 HTTPS 解密你看到的是加密后的密文流需要额外配置密钥导出才能还原明文内容。TraceEagle 从目前公开的资料和使用反馈看更接近轻量化的一体化抓包分析工具既能做报文采集和常见协议解析安装体积和上手门槛又比 Wireshark 低一些适合快速排障。具体差异在后面章节展开。1.2 选型不是找最强而是找最贴场景搞清楚工具分类之后选型就变成一个对号入座的问题。我一般会按下面几个维度来筛平台你在 Windows 还是 macOS 上工作Fiddler Classic 只支持 WindowsProxyman 对 macOS/iOS 最友好Charles 两平台都能用。抓包对象是纯 Web 页面、手机 App、桌面客户端还是智能家居这类需要旁路抓包的终端协议深度只需要看 HTTP 返回内容还是需要分析 TCP、UDP、DNS 这类底层协议附加功能要不要 Mock、弱网模拟、请求改写、团队协作成本免费开源、试用版还是商业授权我的经验是没有一款工具能覆盖所有场景真正高效的组合是代理类工具负责日常调试 Wireshark 负责深水区问题。至于 TraceEagle 和 Proxyman 怎么插进组合里下面逐个说。2. Charles移动端接口调试的常青树2.1 Charles 当家的四个能力Charles 在移动端调试领域的地位有点像拍照界里的默认相机——不一定是参数最强的但绝大多数场景下够用、顺手生态成熟。第一个核心能力是 HTTPS 解密。Charles 通过安装并信任它自签发的根证书对 SSL/TLS 流量做中间人解密。打开 Proxy SSL Proxying Settings添加需要解密的 host 和端口通常写*:443就可以覆盖大多数 HTTPS 请求。配置好之后手机上的 App 请求在 Charles 里会以明文形式呈现 URL、请求头、响应体排接口问题非常直接。第二个是 Map Local / Map Remote。Map Local 可以将某个请求直接映射到本地文件前端在后台接口没开发完时可以先用本地 JSON 模拟接口非常常用。Map Remote 则是把请求转发到另一个地址适合做环境切换和灰度验证。这个功能我几乎每个迭代都在用。第三个是 Throttle Settings也就是弱网模拟。在 Proxy 菜单里开启后可以设置带宽、延迟、丢包率用来验证客户端的超时处理、加载占位和重试逻辑。做客户端测试的人应该都体会过真机弱网难复现的痛点用这些预设能把场景稳定地造出来。第四个是 Breakpoints。开启断点后请求或响应到达时可以暂停手动改掉请求头、请求体或响应内容再放行适合测试异常分支。比如把接口返回里的success改成false看前端是否会有正确提示。2.2 手机抓包的完整配置流程这个流程被问过太多次我直接列一份可以照抄的操作清单以 iPhone 为例macOS 和手机连接同一个局域网。打开 Charles确认 8888 端口正常监听。在有防火墙的电脑上第一次启动时记得允许 Charles 接受传入连接。在 Charles 菜单 Proxy SSL Proxying Settings 勾选 Enable SSL Proxying并添加*:443。在手机 Wi-Fi 设置里手动配置 HTTP 代理服务器填 Mac 的局域网 IP端口填 8888。用手机浏览器访问chls.pro/ssl下载并安装 Charles 根证书。iOS 比较特殊光装证书还不够必须去设置 通用 关于本机 证书信任设置里把 Charles 证书的完全信任开关打开。打开任意 App 或者 SafariCharles 里应该就能看到请求了。Android 的情况略有不同。Android 7.0 之后应用默认不信任用户安装的 CA 证书你在系统里装的证书对很多 App 是不生效的。便宜的办法是抓浏览器和允许用户证书的 Debug 包或者用模拟器、测试机做调试。2.3 Charles 抓不到手机包的排查清单很多人卡在最常见的坑手机代理设置完了Charles 里就是没有流量。我建议按下面的优先级查手机和电脑是否真的在同一网段。公司网络如果开了 AP 隔离即使连同一个 Wi-Fi 也互相访问不通。填的 IP 是不是电脑的局域网 IP而不是 127.0.0.1。手机里填 127.0.0.1 指向的是手机自己当然不通。电脑防火墙有没有放行 8888。macOS 第一次提示时没允许可以在系统设置里手动补。确认手机当前的网络确实有请求。可以先用浏览器打开一个普通网页验证链路通不通再切到 App 去验证密文解密。如果能看到请求但都是SSL Handshake Failed大概率是证书没装全或者 App 做了证书固定Certificate Pinning。后者在 Charles 里会表现为根本看不到明文只能看到握手失败或被伪装成其他名字的 session需要客户端主动放开调试环境。另外说句实在话网上流传的charles 汉化版注册码生成器我都不建议碰。抓包工具本身要处理大量敏感流量用来源不明的修改版等于把流量白送到别人手里。官方提供试用版单次半小时虽然烦了点但足够临时调试需要长期用花点钱买授权是值得的。3. Wireshark协议分析的底层硬核工具3.1 为什么有些问题只能靠 WiresharkCharles 这类工具把 HTTPS 解开之后看起来很美好但有一类问题是它永远答不了的为什么请求发出去了 2 秒才回来为什么同一个接口偶尔会失败为什么内网文件传输速度上不去这些问题的答案藏在 TCP 层。Wireshark 的作用就是把这层打开给你看。它直接捕获网卡上的原始数据包从二层以太网帧、三层 IP、四层 TCP/UDP一直到七层应用数据都有对应面板。你可以看到一次 HTTP 请求背后是不是发生了 TCP 重传、有没有快速重传、窗口是不是被填满进入拥塞避免。TLS 明文展示方面Wireshark 不像 Charles 那样做中间人而是通过读取客户端导出的密钥文件来解密。操作路径是 Edit Preferences Protocols TLS然后配置(Pre)-Master-Secret log filename。Chrome 和 Firefox 可以通过设置环境变量SSLKEYLOGFILE把会话密钥写到文件Wireshark 再用这把钥匙还原明文。注意这里解密的只是当前抓包会话里有密钥的那部分流量不是万能解密。3.2 两套过滤器千万别用混Wireshark 最容易让人犯迷糊的就是它有两套过滤器捕获过滤器Capture Filter和显示过滤器Display Filter。捕获过滤器在抓包之前设置用 BPF 语法特点是速度快、节省内存因为不符合规则的包直接不存。常用写法有tcp port 80、host 192.168.1.1、udp port 53。它有个限制一旦开始抓包你是不能再改的。显示过滤器是针对已经抓下来的包做过滤语法完全不同比如http.response.code 200、tcp.flags.syn 1、ip.src 192.168.1.100 tcp.port 443。它随时可以增删而且支持字符串偏移、函数等高级写法写错了也只是显示为空不会重抓。新手最常见的错误就是把显示过滤器语法填到捕获过滤器栏里然后发现怎么一条包都抓不到。我的建议是默认情况下你根本不需要设置捕获过滤器直接抓全部流量然后用显示过滤器来筛灵活很多。只有当你明确知道要抓一个大文件、担心磁盘写满才考虑用捕获过滤器前置收敛。另外 Wireshark 4.0 以后界面默认变成三栏布局显示过滤器带了语法高亮和自动补全对新手友好不少。配合显示过滤器的高频操作还有两个右键 Follow TCP Stream可以直接看到一条连接内的完整数据省得在无数同 IP 包里来回翻Statistics Flow Graph能画出一个连接的时间线对分析三次握手耗时、确认时序特别直观。3.3 经典场景TCP 实验与 pcap 排障实战很多人第一次被 Wireshark 劝退是因为不知道拿它干嘛。这里分享一个很靠谱的上手路径教材自带的 pcap 文件刷题。网上常见的wireshark-traces-9e.zip、tcp-wirehack-trace-1.pcap是《计算机网络自顶向下方法》第九版配套的实验数据。打开这类文件配合题目要求你会用到非常关键的操作先用tcp或者具体 stream 号过滤出目标连接再分析三次握手里 SYN、SYN-ACK、ACK 的序列号和确认号关系观察窗口字段变化在 Statistics 里分析 RTT如果有丢包还能看到 TCP Retransmission 标记。这套练习做完你对 TCP 的理解绝对比只看书要靠实得多。真实排障时思路也是同一套。之前线上反馈App 里整页图片都加载很慢CDN 厂商说没问题后端也说接口很快最后拿 Wireshark 在客户端电脑上抓包发现大量图片响应出现 DUP ACK 和 Retransmission而接口类小文件没事。顺着线索定位到大文件下载路径上有中间设备限速和丢包才把问题解决。这种问题你用 Charles 看一百遍接口响应时间都发现不了。4. FiddlerWindows 生态里的老牌代理4.1 Fiddler Classic 和 Fiddler Everywhere 怎么选Fiddler 是老牌工具它的麻烦在于Fiddler这个名字底下现在其实有两款产品很多人下载时搞不清。Fiddler Classic 是经典的免费版只支持 Windows界面停留在十年前但核心功能一点不少HTTP/HTTPS 抓包、AutoResponder、Composer、弱网模拟、FiddlerScript 扩展全都有。对于 Windows 环境日常调试来说它是一个零成本的可靠选择。Fiddler Everywhere 是官方后来推出的跨平台版本基于 Electron界面现代了不少支持 macOS、Windows、Linux也加了团队协作功能。但它的免费版有请求数量限制需要完整功能就得订阅付费。我的建议很简单你主要用 Windows、不想付费直接上 Fiddler Classic你需要跨平台或者想和团队分享会话再考虑 Everywhere。不管选哪个要记住 Fiddler 默认监听端口是 8888启动时它会把自己设为 Windows 系统代理。这意味着它一旦退出系统代理应该被还原但很多奇怪的问题恰恰出在这个应该上。4.2 弱网测试与 Composer 的实际用法Fiddler 有个很老的入口Rules Performance Simulate Modem Speeds勾上之后会模拟当年拨号上网的龟速。但这个预设太重了现实中的弱网没有那么极端更可控的做法是用 FiddlerScript 自定义延迟。在 FiddlerScript 的 OnBeforeRequest 和 OnBeforeResponse 里可以通过 trickle-delay 控制延迟比如给所有响应加 150ms 延迟if (oSession.isTunnel) return; oSession[request-trickle-delay] 300; oSession[response-trickle-delay] 150;这段脚本的意思是每个包之间都做延迟模拟出的效果和真实弱网比较接近。实际要作用在特定域名可以在脚本里加if (oSession.HostnameIs(api.example.com))的判断避免影响正常调试流量。Composer 则是 Fiddler 里被很多人忽略的好功能。它像一个内置的接口调试客户端你可以手动输入请求方法、URL、Headers 和 Body 然后发送也可以从抓包列表里把一个请求拖进 Composer 改完再重放。联调时反复改参数测试接口比在代码里改完重启快得多。4.3 卸载后上不了网这个坑必须写清楚搜 Fiddler 相关内容时卸载后上不了网绝对是个高频关键词我自己也帮同事处理过两次。原因一句话就能讲清Fiddler 把系统代理设到了 127.0.0.1:8888卸载过程中它没有把系统代理设置改回去。之后 Windows 上所有走 WinINET 的流量都试图连一个已经不存在的代理浏览器自然全部失败。解决办法分两步。第一步打开Internet 选项 连接 局域网设置取消勾选为 LAN 使用代理服务器。第二步在管理员命令行里执行一次netsh winhttp reset proxy这会清掉 WinHTTP 层残留的代理配置。完成后重启浏览器就应该恢复正常。如果你装过其他代理类工具建议也检查它们有没有类似残留。这个教训同样适用于 Charles 和 Proxyman这类代理工具本质上都是靠系统代理生效的关闭或卸载时最好手动确认一下代理设置已经复位。5. TraceEagle后起之秀值不值得追5.1 TraceEagle 是什么凭什么被讨论坦白说TraceEagle 出现在大众视野里的时间不算长网上系统性教程也不多大量内容是下载分享和基础使用介绍。软件本身主打轻量化的抓包和流量分析安装包比 Wireshark 小不少打开速度也快。对很多只需要快速看一眼流量里发生了什么的人来说是个低门槛的替代方案。我试用下来最大的感受是它把 Wireshark 里最常用的几个功能做成了更直观的界面抓包入口一目了然常见的 HTTP、TCP、UDP、DNS 协议自带解析不需要记过滤语法也能找到关键信息。对于刚学网络的新手或者平时不做深度协议分析、只是偶尔需要排障的开发者这种设计确实比 Wireshark 友好。要提醒的是因为它比较新社区资料和排错经验远不如 Wireshark 丰富遇到疑难问题时能查到的答案不多。如果你把 TraceEagle 当日常快速查看的工具用问题不大但如果你要做深度协议研究、解析 Wireshark 插件生态里那些冷门协议它暂时还替代不了。5.2 实际用下来它的差异化优势我提炼几条 TraceEagle 相对区别于其他四款工具的特点启动和资源占用控制得比较好。抓包是长时间占资源的活Wireshark 抓大数据包时内存经常会飙升TraceEagle 在同等流量下要轻不少。会话流展示更接近人话。它会把一次 TCP 会话里往来的数据按顺序列出来有点像 Charles 的 Response 面板比在 Wireshark 一堆包里找 Follow TCP Stream 更直观。支持导出 pcap/pcapng。这意味着你可以先用它做快速定位遇到疑难杂症再把数据导出交给 Wireshark 做深度分析两者并不冲突。个人体验上它对 DNS 故障和 DHCP 这类网络基础问题的定位很直接适合排查电脑突然上不了网IP 获取异常这类场景。以上特征是基于我自己的试用和团队同事反馈整理的具体到你的机器上建议还是下载后拿真实场景验证一下。另外注意工具免费不代表可以随便商用下载使用前留意一下软件授权说明。5.3 谁适合优先考虑 TraceEagle如果满足下面几条我建议可以给 TraceEagle 一点时间你是网络新手想通过抓包理解网络原理但被 Wireshark 界面劝退你的需求主要是定位某个服务通不通、DNS 解析对不对、端口通不通而不是深度协议分析你需要一个启动快、资源占用低的抓包工具在旧电脑上也能顺畅跑。反过来如果你的工作涉及复杂的 TCP 调优、无线协议分析或者要依赖 Wireshark 的插件生态还是老老实实用 Wireshark。工具之间从来不是淘汰关系而是补位关系。6. ProxymanmacOS 用户的高效率选择6.1 Proxyman 的设计理念与体验差异Proxyman 是这几个工具里最现代的一个原生 macOS 应用UI 精美、操作顺滑。它解决的问题和 Charles 高度重合但打动我的主要是体验上的几个细节。首先是 iOS 设备接入极顺滑。在顶部菜单栏点击 iOS 设备Proxyman 会自动弹出引导它会告诉你在 Mac 上生成的代理地址和端口并把下一步——下载证书、安装描述文件、开启证书信任——一步步列出来。这个引导做得比 Charles 友好太多我第一次给新 iPhone 配置几乎没看文档。其次是它对 WebSocket 和 HTTP/2 的支持很完整。现在很多 App 用 WebSocket 做实时消息Charles 看这类流量体验一般Proxyman 里 WebSocket 帧和文本消息可以直接分开展示排查实时通信的问题很直观。第三是脚本功能。Proxyman 内置 JavaScript 脚本面板你可以在请求发出前或响应返回后对流量做自动改写。比如同一个请求前端需要模拟三种不同返回不用手动打断点写一段脚本按条件替换即可。下面是加自定义请求头的一个简单示例// Proxyman Scripts在请求上添加自定义头 request.headers[X-Env] test; return request;这种脚本化的思路很符合现代开发者的习惯灰度环境切换、批量改写请求头都变得很轻量。最后提一句默认端口。Proxyman 代理默认监听 9090跟 Charles、Fiddler 的 8888 错开因此在一台机器上同时装 Charles 和 Proxyman 不会因为端口冲突而打架这个细节值得点个赞。6.2 iPhone 抓包的完整配置Proxyman 抓 iPhone 的流程非常简单跟着引导走就行但证书信任这一步还是很多人漏掉。完整来说Mac 和 iPhone 连同一个 Wi-Fi。打开 Proxyman点击顶部的 iOS/Android 设备按钮。Proxyman 会显示 Mac 的局域网 IP 和端口 9090。在 iPhone 的 Wi-Fi 设置里填入 HTTP 代理的服务器和端口。用 Safari 打开 Proxyman 提供的证书下载地址一般会跳转到描述文件安装页。安装完描述文件还必须在设置 通用 关于本机 证书信任设置里打开 Proxyman 证书的完全信任开关。回到 Proxyman打开 SSL Proxying 开关然后随便用一个 HTTPS 请求验证。Android 设备配置思路类似需要在客户端里装证书。Android 7 及之后系统同样是系统 CA 信任问题面向生产环境的 App 一般不会信任用户安装的证书这个坑和 Charles 一模一样不用指望换个工具就能绕过去。6.3 Proxyman 的进阶玩法除了基础抓包Proxyman 有几点我觉得很值得深挖。Map Local / Map Remote 和 Charles 用法一致但它有一键打开本地目录的入口配合前端打包工具做动态 Mock 特别方便。Rewrite 功能则是把常见的改请求头、改 Host、加响应头这类操作做成了规则面板不用每次都要写脚本。断点功能也保留了适合手动改包。还有一个我很喜欢的性能视图。它会把每个请求的 DNS 解析时间、TCP 连接时间、TLS 握手时间、首字节耗时分阶段展示出来。之前排查一个接口数据返回慢的问题用这个视图一眼看到 TLS 握手占了 80% 耗时方向一下子就明确了。团队协作方面Proxyman 的脚本和规则可以导出成文件给同事方便大家一起复现同一套 Mock 环境。不过这特性一般团队用 Charles 也能做到差别主要在体验和生产效率上。7. 横向对比一张表帮你定位最合适的工具7.1 五款工具核心参数对比工具支持平台默认端口核心定位HTTPS 解密数据范围上手难度价格模式CharlesmacOS / Windows / Linux8888移动端代理调试、Mock、弱网支持代理的应用层流量中收费可试用TraceEagle视版本而定通常无固定代理端口轻量抓包与协议解析、快速排障视配置网卡层常用协议低免费为主注意授权WiresharkmacOS / Windows / Linux无代理端口全量报文采集与深度协议分析需配合 SSLKEYLOGFILE二层到七层高开源免费FiddlerWindows / macOS / Linux8888代理调试、AutoResponder、Composer支持代理的应用层流量中Classic 免费Everywhere 有订阅ProxymanmacOS / iOS 优先9090原生体验代理调试、WebSocket、脚本支持代理的应用层流量低中收费可试用7.2 按场景快速选型清单用实际问题来选比记参数更直观今天要调试 App 接口手机在边上公司电脑是 Mac优先 Charles 或 Proxyman。电脑是 Windows想不花钱搞一套能用的抓包Fiddler Classic。需要把请求 Mock 成本地文件来开发页面Charles 的 Map Local、Fiddler 的 AutoResponder、Proxyman 的 Map Local 都可以。要模拟弱网、超时、丢包Fiddler 的 trickle-delay 最灵活Charles 的 Throttle Settings 最省事。怀疑是域名解析、TCP 握手、重传、VLAN 这类底层问题直接用 Wireshark。想快速看一个设备发包发得对不对不想研究过滤语法TraceEagle。团队要跨平台共享整套抓包环境Fiddler Everywhere 或 Proxyman 的脚本/规则导出。我的个人习惯是代理工具管白天、Wireshark 管疑难杂症、TraceEagle 当作快速体检器。你可以根据自己的工作重心调整。8. 常见问题排查与避坑实录8.1 HTTPS 开了解密还是看到一堆密文这类问题在三款代理工具里都很常见排查顺序一般是证书装了吗装了之后信任了吗iOS 要额外去证书信任设置打开开关Android 7 以上还要考虑用户 CA 信任策略。SSL Proxying 作用域配了吗很多工具默认只解密白名单里的域名你要确认目标域名在解密列表里最粗暴的写法就是加一个*:443。App 是不是做了证书固定如果应用内置了服务端证书或者公钥指纹中间人证书会被直接拒绝表现就是握手失败或流量直接消失。这种情况只能让客户端开调试模式支持第三方证书或者接受这个 App 的工具抓不了的事实。工具本身版本太旧对 TLS 1.3 支持不好。遇到新协议先升级工具再排查。排查的时候我会先用浏览器访问一个 HTTPS 明文站点验证工具的基础解密能力再用目标 App 做二次验证。这样能把工具配置问题和App 特殊处理快速分开。8.2 代理工具退出后系统流量被绑架这是 Fiddler 卸载问题的大范围版本。任何代理类工具Charles、Fiddler、Proxyman 都一样它们都是通过设置系统 HTTP 代理来接管流量的。如果工具崩溃、强退、卸载不干净系统代理设置可能残留之后浏览器和很多客户端都会继续尝试把流量发给一个已经不存在的端口表现就是其他软件都好好的浏览器就是打不开网页。处理办法macOS 上打开系统设置 网络 代理把 HTTP/HTTPS 代理关掉Windows 上去Internet 选项 连接 局域网设置取消勾选代理再执行netsh winhttp reset proxy。检查完代理设置再看 hosts 和 DNS基本就能恢复。我自己的习惯是每次关工具之前先看一眼它的关闭时是否还原系统代理选项确认勾选。防患大于事后折腾。8.3 多款工具共存怎么避免互相打架同一台机器上装多款工具很正常但有几个冲突点要注意端口冲突。Charles 和 Fiddler 默认都是 8888不能同时监听同一端口。要么同一时间只开一款要么给其中一款改监听端口。系统代理互相覆盖。后启动的工具会覆盖前一个设置的系统代理导致你以为在抓 A 工具的流量实际系统流量已经走到 B 工具上了。所以多工具并行时要养成看当前系统代理指向谁的意识。手机端只能配一个代理。手机连了 Charles 的代理另一边又开了 Proxyman 想在电脑上抓只能先把手机代理改过来。Wireshark 属于旁路模式不抢系统代理所以它和任何代理工具都能共存这也是它适合做深水区补位的原因之一。还有个小建议同一时间只让一款代理工具参与接管系统代理这件事其他工具要么退出要么改成非系统代理的监听模式。这样能省掉很多莫名其妙的排查时间。说一个我自己的习惯吧。每次有同事问我哪个抓包工具最好用我的答案都不是某个具体名字而是一套组合日常联调用 Charles 或 ProxymanWindows 环境用 Fiddler碰到应用层工具解释不了的问题就切到 Wireshark想快速验证网络状态时用 TraceEagle。工具的价值不在于能列出多少功能而在于你熟悉它之后能快速缩小问题范围。去年排查一次 App 图片加载慢Charles 看接口毫无破绽最后是 Wireshark 里的 DUP ACK 暴露了链路丢包——那次之后我就更坚定这个思路了。建议你也别急着选边站先用一两周在真实项目里把一款工具用熟再慢慢扩展。手上有好工具心里才有底。
返回列表