标签：tab 选中 blog control 响应 modified 4.0 fse baidu
Ominpeek一款网络抓包工具，或者说网络协议分析工具。不是管是前端开发、后端开发或都测试人员。为了解数据是否正常的传递，经常会用到网络数据包拦截软件来进行分析。
Ominpeek 与我们常用的HttpWatch、Fildder 略有不同。HttpWatch 是基于浏览器的插件，拦截HTTP的数据包，而Ominpeek是基于网卡底层扫描的。计算机与外界的交流必经过网卡，也就是说它能拿检测到一切经过网络的数据。
Ominpeek 是由Wildpackets 公司研发的网络扫描维护工具，其提供了高效的故障诊断和这定能力，这一特性能够明显缩减日常花费大量寻障和排障时间，使我们有精力去完善日常其他的工作以及学习更多的业务知识。它和Sniffer都是功能非常强大的协议分析工具。
界面介绍
了解一个工具从下载使用开始，所以我们先下载安装一下。关于这款工具除了官网（官网下载要填写注册信息，这是我最讨厌的），其它的下载地址还真不多。
WildPackets OmniPeek 4.1 下载地址： http://download.pchome.net/internet/tools/detail-33252.html
虽然这4.1版本的早已过时了，但对于我们新手来说，足矣！而且它体积也比最新版的也小了很多。
下载完成之后，安装过程就不介绍了，对于windows下的软件安装一般一路NEXT都能成功安装。安装完成后打开软件。下面以就是打开后的主界面。
网络统计窗口
界面的左下角的网络统计窗口有三个刻度盘与相应的数字显示。
* 网络使用率（用百分比的方式表示）
* 数据流量（每秒数据包）
* 误差率（每秒的总误差）
下表显示历史最大（红线）和平均值（黄线）。
下面我们切换到“Value”选项卡，上表显示以下信息：
持续时间：此参数显示经过时间“小时：分钟：秒：“自从你开始收集监测数据格式。
收到的数据包：此参数显示收到的数据包从你开始收集监测统计。
接收的字节数：此参数显示收到的字节从你开始收集监测统计。
组播：此参数显示包处理多播地址从你开始收集监测统计。
广播：此参数显示的数据包广播地址从你开始收集监测统计。
（注：如果此窗口被不小心关掉了，可以点击工具栏上的“network statistics”按钮打开。！）
个人日志窗口
界面的右下角：当程序启动时，一个日志文件（称为Peek.log）在Application Data文件夹中创建。
三种类型的事件会被写入这个日志文件中。
* 程序的启动或停止，或创建一个新的窗口捕捉。
* 在设置对话框中指定的事件。
* 活动指定发送的日志类型通知
窗口的第一行，用不同的图标颜色显示消息总数中的日志和故障的严重程度
Messages: 信息总数
白色i ：表示请求成功的信息。
绿色! ：表示轻微型提示（个人理解）
黄色! ：警告信息
红色x ：错误信息
那么我们可以对这些日志做那些操作呢? （点击某一条信息右键出现菜单）
保存登录：选择此选项将日志保存为一个文本文件（制表符分隔或逗号分隔值）。
打印日志：选择此选项可打印的登录窗口。要更改默认打印设置，选择打印设置...从“文件”菜单上。
复制：选择此选项复制单独的行日志文件为制表符分隔的文本复制到剪贴板。
清除日志：选择此选项可清除或清空日志文件。
最大日志文件大小：选择此选项可打开一个对话框，您可以在其中输入新的日志文件的最大尺寸，以千字节为单位（默认为4MB）。当达到限制时，将删除旧的日志项，以腾出空间给新的。
自动滚屏：选择此选项来切换日志的自动滚动功能。
（注：如果不小心关闭了这个窗口，可以点击工具栏上的View Log 或菜单栏 View > Log Window）
创建一个数据捕捉
你可以在Start Page窗口上点击“new capture”按钮，或在菜单栏File > new..
这里可以设置捕获的名称，文件保存的位置等。
选择你要通过哪个网卡进行捕捉，因为我的是笔记本，所以会有有线和无线两个网卡。你可以用检测无线网卡的方式，找到被别人设置屏蔽掉的无线信号，检测谁在偷用你的无线网络，或者别人无线网络的加密方式进行破解等。
对于协议包的过滤规则，默认情况下所有协议都进行检测抓取。
勾选下面协议类型，选择左边按钮表示，只抓取选中的协议。选择右边按钮表示，选中的协议从抓取的协议列表中去掉。
创建完成后，点击数据捕捉窗口右上角的“Start Capture”按钮。工具开始抓取所有经过网卡的数据包。点击“Stop Capture”停止抓取。
Ominpeek能做哪些分析呢？
那么Ominpeek提供了哪些功能来快速的帮助我们对网络问题进行故障诊断/定位。
1.主机排名，发现网络中通信量最大的主机，对比故障现象与影响范围。
2.协议排名，可以对监控的所有协议进行排名，找到使用最多的协议。
3.主机在使用的协议。查看某一主机在使用哪些协议。（在主机排名界面，双击某一主机，出现下表）
4. 通过PeerMap网络分布图了解主机会话的实时情况
5. 深入解码分析。发现异常后，可以进行深入的解码分析。
通过以上步骤可以很多容易发现浏览异常的主机，不正常的协议通信以及网络中实际传输的内容。从某些角度来说，使用OmniPeek来做协议分析，真是杀鸡用牛刀了。
常见协议分析
下面对一些经见的协议时行简单的分析（我们在抓到的包中可以双击打开抓到的各种协议）：
帧、UDP协议
| Destination: 00:12:00:40:E9:FF | 目的的适配器的mac地址为00:12:00:40:E9:FF |
| Source: 00:E0:81:02:CB:F0Tyan:02:CB:F0 | 传输该帧到LAN上的适配器的mac地址为00:E0:81:02:CB:F0 |
| 协议标识域 Protocol Type: 0x0800 IP | 表明封装协议是IP协议 |
TCP协议
我们都知道TCP协议信息传递（三次握手、四次挥手）
|
第一次握手 |
客户端发送了第一个报文（从IP首部可以看出。202.204.122.236为本机ip） 三次握手的第一个报文 |
|
报文包括了源端口号（Source Port,随机选择）和目标端口号（Destination Port）,目标端口号为80，所以客户端想要请求的服务为HTTP服务。报文还包含了ISN=900514470，客户端还定义了它能从服务器端接收的MSS，第一个报文不包含ACK，TCP Flags中显示No Ack. |
|
第二次握手 |
三次握手的第二个报文 |
|
服务器短发送了第二个报文 此报文附带了SYN和ACK。这个报文有两个目的：一是确认受到了第一个报文，ack号为905144471=上一个报文的ISN905144470+1服务器端也定义了客户窗口的大小是wind :8192；二，这个报文也对服务器的报文段进行初始化，定义MSS大小为1448。 |
|
第三次握手 |
三次握手的第三个报文 |
|
它使用ACK标志和和确认字段来确认收到了第二个报文。ACK1302368427=第二个报文的isn值1302368427+1 |
|
第一次挥手 |
四次分手的第一个报文段 |
|
因为访问的网站为门户网站www.sina.com所以有很多报文信息，为了是环境更加纯净一点，所以插入了一个新的Filter，限定了本机器端的端口号4075与服务器相连的所有报文，经过筛选，所显示的报文数量只有十条。 客户端TCP发送第一个FIN报文段。可以从 图 8 四次分手的第一个报文段 中看出来。FIN 字段显示为1。 |
|
第二次挥手 |
四次分手的第二个报文段 |
|
服务器TCP发送第二个报文段。附带了ACK和FIN，其中ACK1542437602=1542437601+1 |
|
第三次挥手 |
四次分手的第三个报文段 |
|
服务器TCP没有更多的数据发送时就发送发送第三个报文段，FIN报文段。从图中可以看TCP flag中出FIN字段的值为1. |
|
第四次挥手 |
四次分手的第四个报文段 |
|
客户TCP发送第四个报文段，ACK报文段。Ack Number: 3739309153=3739309152+1 |
IP协议
| Version: 4 | 版本为IPv4 |
| Header Length: 5 ( 20 bytes) | IP题头通常大小为20字节，该域值按照4字节的柏树提供。分析器用4字节乘以该值得到正确的IP题头长度值20字节 |
| Differentiated Services: %00000000 | 服务类型域。以便使不同类型的ip数据报能相互区别开来。 |
| Total Length: 60 | ip数据报的总长度（首部加上数据），该字段长为16bit |
| Identifier: 30612 | 与ip分片有关，同一个ip数据报分片成不同的数据报，Identifier是相同的。 |
| Fragment Offset: 0 ( 0 bytes) | 片位移为0 |
| Time To Live: 64 | 该数据报不会永远在网络中循环，每次经过一台路由器时，该字段减1。若TTL字段为0，则该数据报必须丢弃。 |
| Protocol: 1 ICMP - Internet Control Message Protocol | 该字段仅在数据报到大其最终目的地才会用到。该字段指明了IP数据报的数据部分应该 交给哪个运输层的协议。 |
| Header Checksum: 0x77BA | 将首部中的每两个字节当作一个数，用反码运算对这些书求和 |
|
Source IP Address: 202.204.122.2360A071DF18F2E4E6 |
源IP地址 |
| Dest. IP Address: 202.204.122.237 | 目的IP地址 |
| 数据字段：ICMP - Internet Control Messages Protocol | 数据字段也可以承载其他类型的数据，这个字段就承载了ICMP报文段。 |
HTTP 协议
http请求报文
| HTTP Command: GET | 当浏览器请求一个对象的时，使用GET方法 |
| URI: /img/baidu_logo.gif | 在URL字段填写该对象的URL地址本报文中URL请求对象是/img/baidu_logo.gif |
| HTTP Version: HTTP/1.1 <CR> <LF> .. | 浏览器实的是HTTP/1.1版本协议 |
| Connection: Keep-Alive <CR> <LF> | 浏览器告诉服务器希望保活 |
| Host: www.baidu.com <CR> <LF> . | 定义了目标所在的主机。 |
|
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; InfoPath.2; CIBA) <CR> <LF> . |
定义用户代理，即向服务器发送完被请求浏览器的类型。这里的浏览器类型是Mozilla/4.0 |
| Accept-Language: zh-cn <CR> <LF> . | 表示了如果服务器有这样的对象的话，用户想要得到该对象的zh-cn版本，否则使用服务器的默认版本。 |
http响应报文
|
HTTP Version: HTTP/1.1 |
协议版本 |
|
HTTP Status: 200 |
状态码 |
|
HTTP Reason: OK <CR> <LF> . |
相应状态信息，一切正常，即服务器已经找到并正在发送所请求的对象 |
|
Server: Apache/1.3.27 <CR> <LF> |
表明该报文是由一个Apache WEB服务器产生的。 |
|
Last-Modified: Wed, 30 Jul 2008 10:23:00 GMT <CR> <LF> |
对象创建或者左后修改的日期和时间 |
|
Content-Length: 1489 <CR> <LF> |
表明了被发送对象的字节数 |
|
Content-Type: image/gif <CR> <LF> <CR> <LF> .. |
表明了实体中的对象是gif图像。 |
|
Binary Data: (1130 bytes) |
报文的主体，即它包含了所请求的对象本身。 |
当然还有许多协议，如 FTP、SMTP\POP3 、DNS、ARP等很多协议。由于篇幅原因，不再详细介绍了。
标签：tab 选中 blog control 响应 modified 4.0 fse baidu
原文地址：http://www.cnblogs.com/tester-l/p/6032255.html
