原创文档，转载请将原文url地址标明

HttpWatch是强大的网页数据分析工具，集成在Internet Explorer工具栏。包括网页摘要、Cookies管理、缓存管理、消息头发送/接受、字符查询、POST 数据和目录管理等功能及报告输出等,本篇文档简要介绍httpwatch的相关功能的使用。

关于这个软件的下载请大家自行在baidu搜索，安装也比较简单，本篇文章仅仅做一个简单介绍，后面还会专门介绍这个工具的使用。

一．启动httpwatch

Httpwatch集成到ie中，因此必须先启动ie浏览器后，在启动httpwatch（新版本的httpwatch已经提供了其他浏览器的插件例如firefox，但是笔者没用过，这里仍然用ie系列介绍），如下图

启动ie后，在工具栏上面点击httpwatch的图标，即可。有的ie这个图标不可见，看看工具栏是否有向下的箭头等。有时候ie会隐藏些图标等等。这个应该不是难题

二．录制http请求

通过httpwatch进行http分析的第一件事情就是录制http的相关请求，如下图

图中，

位置1：处button是录制http请求的按钮

点击这个按钮后，通过这个浏览器访问的http请求，包括ajax的请求都会被记录下来（当然不包括：applet，activex技术的非http的网络请求，或者未通过浏览器的其他网络请求）。

相关录制信息在按钮下面白色部分区域显示出来，默认按照请求的先后顺序显示，用户可以根据标题行进行排序。

位置2：处button是停止录制http的按钮

点击停止录制后，将不在录制http相关请求等数据，但是已经录制好的数据仍然存在。

一般情况由于网站都比较复杂，做过多的录制反而不容易发现问题，数据太多，用户会沉浸数据中找不到出路啦。因此一般都是找到特定页面，比如认为有问题的，或者有特别要求等的页面，然后录制，录制一段数据后就点击停止按钮，这样http内容就固定了，不在增长，这个时候用就可以专心分析已有数据了，否则数据列表总是在变化，有时候你也不找分析道哪里了。

位置3：处按钮清楚已经录制的http信息的按钮， http的录制状态不发生变化

清除按钮清除当前录制的屏幕，有时候，录制的http数据很多，但是这些数据又不是当前想看的，或者这些数据是分析过的，没有问题，想看看后面的内容，这个时候，适当清除当前数据是非常必要的。

注意：这里是非常重要的看红色大字体。从开始录制也可以减少http列表中数据的数量。但是同清除是非常有差别的。有时候一些问题是用户要在一个也没操作若干次后才出现的，而一开始是没有问题的。因此若是从头开始录制http等信息，很可能看不到问题的。需要长时间录制的，但是长时间录制，列表中数据又非常多，因此需要在录制一段时间后，在问题出现之前清除没有用或者不关心的http数据，然后后面专心分析可能有问题的数据。因此这个清除按钮是非常必要的。

三．查看http资源

我们这里以本站www.iigrowing.cn为例，进行录制，录制结果如下：

大致可以分为3个区域

区域1：是浏览器的正常显示区域

区域2：是httpwatch录制下来的相关http信息，默认以时间调用为先后顺序，用户可以自行排序，排序方法非常简单，双击标题栏，这个大家都都懂得。

区域3：是某一个http的具体相关详细信息，默认情况下是列表中第一个项目的详细信息（请求的总体情况）。

四．查看http信息

如下图，显示http的总体信息

如上图，鼠标单击红色区域部分，然后检查下面蓝色区域部分：

网络部分情况：

Elapsed Time：相关网络请求花费时间，上图看总体花费时间4.5秒钟

Network Round Trips: 大致上是网络请求次数，网络请求次数54次左右

Downloaded Data：下载的数据，上图网络数据量4.1M左右

Uploaded Data：上传的数据量，上图上传数据量 19k左右

Http Compression Savings：采用http压缩方式节约的网络流量，节约的流量55k

DNS Lookups：dns查询次数

Tcp connects：tcp连接次数

初步分析，从上面数据了解，总体网络请求在54次左右，就是用户在浏览器中输入一次网址后，系统为了显示相关页面进行了54次的http请求，并且这些请求都没有相关的cache。本次由于我们第一次访问故没有cache是正常的。通常情况下，我们一般都要访问网址两次，检查cache的相关情况，确认cache的设置是否正常，这里不在进行测试了。

本次下载了数据量为4M，下载时间大概 4.5秒钟，因此网络速度大概4M/4.5 约 1m/秒，这样的网络速度要求是较高，有很多地方网络速度是 100k/秒的，这样初次访问时间大概就40秒多啦，若是网络部好就更慢了。

从http的压缩数据的节约情况看，非常小，因此可以了解http流量中大部分都是二进制数据，这些数据一般不可以压缩了，特别是图片数据。一般网络的文本数据是可以有很大压缩比的，可以节省很多流量。因此从这里面的情况看，没有太多的节约。文章后面一个问题可以证实这个情况。

其中还有很多其他菜单项目可以检查，本次先不讨论了，后续我们在慢慢补充。

五．警告信息查看

本次我们看另外一个菜单项，如下图

如上图，双击蓝色区域标签卡，系统显示红色区域信息

在红色区域双击鼠标，显示如下图

HW1002 Performance HTTP compression increased the size on the content in the HTTP response message（http压缩方法在实际中增加了http相应消息的大小，就是压缩前尺寸小于压缩后的尺寸，这个情况其实是有的呀）

另外，在上面页面中，双击黄色区域标签卡，显示如下图

注意：

区域1: 是本次http请求的发生时，从客户端发送的数据列表，已经解析成相应数据

区域2：是本次http请求server端返回的数据，注意区域2包括3及4等整个窗口，这里仅仅圈住了部分区域。

区域3：（红色的区域）是本次http请求server端返回数据的类型，从上面数据可以看出是png格式的图片数据。

区域4：是本次数据的编码格式，从内容来看是gzip格式的。

好了，好像问题已经出来了，对于png这些图片格式，采用gzip这个无损数据压缩格式一般是无法压缩的，甚至会压缩后尺寸大于压缩前的，这个就是本警告的内容了（对于压缩需要在server端消耗cpu时间进行压缩，然后网络传输，然后客户端在用cpu进行解压缩，压缩目的是减少网络的传输时间，但是由于本次压缩没有压缩变小反而变大，网络传输时间变长了，同时客户端及server端cpu的消耗就是白白浪费了！！）。

一般情况，对于网站，动态资源及静态资源时分离的，图片，js，css等都是静态资源需要单独处理，并且进行特定处理。

Httpwatch还有很多功能，我们下次再慢慢聊了！