图灵社区 : 阅读 : 善用 Web 调试代理工具

善用 Web 调试代理工具

推荐 12 收藏

原文地址：Using Web Debugging Proxies

当我们调试前端代码的时候，通常会在检查CSS和JavaScript如何渲染页面上花费大量时间，但是了解网络请求对页面的影响也同等重要。很多情况下由于我们在本地开发，可能会忽略页面的大小、延迟以及脚本的载入和阻塞对网站用户体验的巨大影响。因此，一套得心应手的网络流量检查工具是必不可少的。

幸运的是，所有主流浏览器都提供了可以查看网络流量的调试工具，而且第三方工具比如 Fiddler 和 Charles 不仅允许查看网络请求，而且还提供了可以跟网站交互的扩展功能。

下面我们会对两种类型的工具分别进行介绍。

基于浏览器的流量嗅探

正如我提过的，每个主流浏览器都有内置的调试工具。它们包括：

• Internet Explorer 的 F12 开发者工具
• Firefox 的 Web开发者工具以及 Firebug 附加组件
• Chrome 的 开发者工具
• Opera 的 Dragonfly
• Safari 的 Web检查器

（译者注：关于这些工具，还可参见译者的另一篇文章。）

每个工具集都有自己独特的功能，并且它们都有搜集网络流量信息的能力。看一下下面几张图，你会发现尽管UI不尽相同，但搜集和显示的数据却非常相像。

最终的结果就是，一个由浏览器下载的资源或数据而产生的网络请求所组成的列表。网络工具可以截获这些请求并将主要的数据展示给你：

• 请求类型（GET，POST 等等）
• 请求的是什么
• URI
• 状态
• 大小
• 完成请求所耗时间

因此，如果我们在 Firebug 中查看结果，可以看到这些请求拉回了主页面以及相关的CSS和JavaScript文件，包括亚马逊AWS上的资源。由于图片的限制，我无法向你展示全部加载内容，不过这里也还返回了图片和Flash swf文件。

深入研究

有了这些信息后，就可以深入查看特定的请求，确定是否接收到了正确的数据，以及查看为什么会有耗时很长的请求。假设我查看Webtrend的JavaScript文件请求。它耗时1.2秒下载，并且我想看看请求是如何被处理的。我可以展开该请求，看看它是使用gzip压缩（是的）：

和是否被最小化压缩（minified）：

本例中的文件并没有被最小化压缩，然后我就可以找开发人员跟进看这样做是否合理。诚然，这只是个2k的文件，不过每个字节其实都很重要，这些信息可以让我们更好地优化网站。

网络计时

网络延时可以成为致命杀手，尤其是对于那些依赖外部API或者多个脚本文件来实现功能的单页面应用（single-page apps）。大部分浏览器会尽可能地异步加载资源，但是有些资源比如JavaScript文件，可以触发阻塞事件。尽可能地限制这些文件，并以此来优化资源加载至关重要。如果我们看一下这张图，就会发现这个文件花费了1.4秒用来加载：

当悬停在时间轴上的时候，会出现一个对话框，展示了请求被处理的分解信息：

部分原因是由于它被阻塞了760毫秒。如果这是个普遍存在的问题，你可以尝试使用脚本加载器（比如 RequireJS）来更好地管理脚本加载和依赖关系。

Ajax请求

由于动态应用无处不在，因此能够查看XHR调用就至关重要了。之前你已经见识过无数的网络请求，试图过滤这些请求并从中找出XHR调用并不高效。因此，大部分工具允许你按请求类型查看。这里我是根据XHR请求过滤的，因此我可以评估请求和响应：

通过深入查看请求信息，我可以获得请求的重要细节，比如请求头、状态、请求方法、cookies，更重要的是可以看到该请求返回的数据：

本例中返回的是HTML，不过响应可以是包括文本、JSON或XML在内的任何内容。更棒的是在我遇到任何问题时，都可以充分地查看请求细节。

Cookies

Cookies真的非常有用，由于我们会广泛地用到它，因此一个方便地查看Cookie值的方法将使生活变得更轻松。开发者工具即可轻松实现这些，它可以展示哪些Cookies被发送或者接收了。

如果你曾经做过服务器端开发而没有客户端工具相伴，你就会知道这有多爽了。

总之，最棒的就是这些功能都内置在你的浏览器中，使开启工具调试和查看细节都变得无比便捷。然而，有时你还需要多一点马力。

第三方HTTP代理工具

HTTP代理程序如 Fiddler 和 the Charles Web Debugging Proxy 是基于浏览器的网络流量嗅探工具的老大哥。它们不仅能截获来自浏览器的网络请求，也能截获你机器上其他程序的网络请求，这使得它们在调试方面用途广泛。通常它们也会提供更丰富的特性，比如：

• 带宽限制
• 特定请求的自动响应
• 传输过程中的资源替换
• SSL代理
• 插件生态系统
• 可自定义的脚本
• 记录和回放测试场景

我常用基于Windows的、功能丰富的 Fiddler（免费的！）。由于其强大的特性集合，在微软内部的使用也很广泛。Fiddler的开发者 Eric Lawrence 之前就在微软工作，并且仍然维护着该软件。

如果我们看下界面，就会发现与那些浏览器工具类似的输出。所有的网络请求都按照关键信息显示。

深入查看某个请求，可以看到更多的细节，包括压缩后jQuery源代码：

大部分这种信息也可以通过基于浏览器的工具获取到，但是当你想确定是不是某个库搞垮了你的网站的时候怎么办？你可以直接换掉这些库来进行定位。一个较好的路径就是创建一个Fiddler自动响应器（AutoResponder），拦截并替换掉生产环境中的库。Fiddler会接收这个请求并将其替换为本地文件。下面我们就来一探究竟。

首先，我需要标识出需要替换的URI。在本例中，我看到我的博客主题使用了jQuery v1.2.6。真是疯了，不过在我丢掉它之前，需要看一下jQuery v1.8.3是否能如预期一样正常工作。

我点击 jQuery v1.2.6 这条记录，在 Fiddler 的右栏中，选择“AutoResponder”页卡并选择“Enable automatic responses”。可以直接将URI拖拽到规则编辑器中。你会发现规则是从比较URI开始的。如果匹配，它将以你选择的某个事件作为响应。

由于我想测试的是 jQuery 1.8.3，我希望这条规则可以用我本地的jQuery副本替换生产环境的版本。

保存这条规则并刷新我的页面。最终结果是，尽管URI可能看上去相同，检查结果可以验证 jQuery v1.8.3 实际上已经嵌入了。这样我就可以在不对网站进行任何更改的情况下直接测试了。

从调试的角度来讲，这种功能无比实用，尤其是当你想定位一个藏在老版本框架或库中的bug时候。

附加组件生态系统

Fiddler从它的附件组件生态系统中获益良多，这个系统通过iFiddlerExtension接口为Fiddler扩展功能。目前有如下功能的附加组件：

• 压力测试
• 安全审计
• 流量对比用来对比概况
• JavaScript格式化

对于它本身来说，Fiddler拥有无数特性，实在无法在本文一一列举。这就是为啥有个330页的书来教你如何用好它的原因了。这本书只有10美元，即可让你从内到外掌握这个伟大的工具。

OSX 和 Linux

如果你在用OSX或者Linux，那么最佳选择就是Charles Web调试代理工具。该工具支持广泛并且商业化成熟，每一分钱都花得很值得。我曾寻找过专注于web开发的替代品，而Charles却脱颖而出。

界面跟Fiddler很类似，不过它提供了两种不同的方式查看网络流量：

样式完全随你，我更倾向于结构化视图，因为感觉它更有条理，不过搜寻特定的URI就稍有不便。

与Fiddler类似，Charles也提供了自动响应功能，叫做“Map Local…”，可以通过鼠标右击某个URI呼出。该功能允许你选择一个本地文件进行工作。

当刷新页面后，我的jQuery v1.2.6就被我本机上的jQuery v1.9替换掉了。

Charles另外一个极好的特性就是，它可以抑制网络请求来模拟特定的带宽速度。仍记得使用56K猫时的那些令人捉急的日子，使用这个功能可以让你尽情追忆似水年华：

Chares也提供了一个跨平台的界面，因此也可以在Windows上工作。

该用哪一个

所有这些工具我每时每刻都在用，因为我需要测试每个主流的浏览器，有了这些功能着实可以使问题定位更容易些。当然，是选择基于浏览器的嗅探工具，还是基于应用程序的代理工具完全取决于你的调试需要。

如果你只需要检查某些流量并查看结果，那么基于浏览器的嗅探工具可能是你的最佳选择。

另一方面，如果你需要精确控制URI如何响应，或者希望可以灵活地创建自定义脚本，那么像Fiddler或Charles这种工具才是你需要的。令人欣慰的是，我们有稳定的备选方案可以帮助我们实现这些功能，尤其是当项目复杂度日益增加时，也不会感到无力。