wireshark或sniffer抓包软件使用实

实验2 wireshark或sniffer抓包软件使用实
本次实验使用wireshark抓包软件。

开启的应用程序有：IE，QQ, QQ音乐。

过滤的UDP 的报文。

结果：
抓取的报文：
14 2.915765000 tencent_private DFAUT QQMusicExternal.exe 222.18.168.170
119.177.224.41 UDP 121 Source port: http Destination port: hosts2-ns
即第14号报文，时间为2.915765000，应用程序名称：tencent_private，应用哈希：DFAUT, 应用程序模块：QQMusicExternal.exe，源地址：222.18.168.170，目标地址：119.177.224.41，协议：UDP，包长度：121，信息：源端口：http；目的端口：hosts2-ns。

结果说明：链路层：以太网；网络层：IP协议；传输层：UDP；应用层：qq的私有协议。

详细情况：
展开后的情况：
（由于此段最后一项过长不好截图，故将其复制过来了）
Frame 14: 121 bytes on wire (968 bits), 121 bytes captured (968 bits) on interface 0
Interface id: 0
Encapsulation type: Ethernet (1)
Arrival Time: Dec 3, 2013 11:15:50.371006000 中国标准时间
Time shift for this packet: 0.000000000 seconds
Epoch Time: 1386040550.371006000 seconds
Time delta from previous captured frame: 0.010828000 seconds
Time delta from previous displayed frame: 0.010828000 seconds
Time since reference or first frame: 2.915765000 seconds
Frame Number: 14
Frame Length: 121 bytes (968 bits)
Capture Length: 121 bytes (968 bits)
Frame is marked: False
Frame is ignored: False
Protocols in frame: eth:ai:ip:udp:data
Coloring Rule Name: Checksum Errors
Coloring Rule String: eth.fcs_bad==1 || ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1 || sctp.checksum_bad==1 || mstp.checksum_bad==1 || cdp.checksum_bad==1 || edp.checksum_bad==1 || wlan.fcs_bad==1
画面14：121字节线（968位），121个字节（968位）捕获接口0
接口编号：0
封装类型：以太网（1）
到达时间：2013年12月3日50.371006000中国标准时间11:15:
这个包的时间变化：0秒
时间：1386040550.371006000秒
以前捕获的帧时间三角：0.010828000秒
从以前的显示帧时间三角洲：0.010828000秒
由于参考或第一帧的时间：2.915765000秒
帧号：14
帧长度：121字节（968位）
捕获长度：121字节（968位）
帧标记：假
框架是忽视：假
协议的框架：ETH：AI：IP UDP数据：：
着色规则名称：校验和错误
着色规则字符串：ETH。

fcs_bad = = 1 | | IP。

checksum_bad = = 1 | |TCP。

checksum_bad = = 1 | | UDP。

checksum_bad = = 1 | |SCTP。

checksum_bad = = 1 | | MSTP。

checksum_bad = = 1 | |CDP。

checksum_bad = = 1 | | EDP checksum_bad =。

= 1 | | WLAN。

fcs_bad= = 1
以太网II，SRC：dell_cf：A4：C5（84:8f：69：CF：A4：C5，DST）：hangzhou_8d：87：F1（00:23:89:8d：87：F1）
目的：hangzhou_8d：87：F1（00:23:89:8d：87：F1）
地址：hangzhou_8d：87：F1（00:23:89:8d：87：F1）
.... ..0. .... .... .... ....全局地址：单位= LG（厂违约）
.... ...0 ........ .... ....位：个人地址= Ig（单）
资料来源：dell_cf：A4：C5（84:8f：69：CF：A4：C5）
地址：dell_cf：A4：C5（84:8f：69：CF：A4：C5）
.... ..0. .... .... .... ....全局地址：单位= LG（厂违约）
.... ...0 ........ .... ....位：个人地址= Ig（单）
类型：IP（0x0800）
互联网协议第4版，SRC：222.18.168.170（222.18.168.170，DST）：119.177.224.41（119.177.224.41）
版本：4
标题：20字节的长度。

区分服务域：0x00（DSCP 0x00：违约；ECN：0x00：非（not ECN能够运输等））0000 00..区分服务codepoint =：违约（0x00）
.... ..00 = explicit拥塞通知：非等（不可运输（ECN）0x00）
总长度：107
标识：0x1b5d（7005）
标志：0x02（不要片段）
0... .... =保留位：not set
.1.. .... =不要片段：set
..0. .... =更多的片段：not set
胶印片段：0
存活时间：64
UDP协议：（17）
首部校验和：[错误，应0x408d（可能是由于“IP校验和卸载”？）]
好：假
坏：真实的
专家信息（错误校验）：校验和错误
坏消息：校验和
严重程度：错误
组：校验
来源：222.18.168.170（222.18.168.170）
目的：119.177.224.41（119.177.224.41）
源GeoIP：未知
目的GeoIP：未知
用户数据报协议，源端口：HTTP（80），DST端口：hosts2 NS（81）源端口：HTTP（80）
目的端口：hosts2 NS（81）
长度：87
校验和验证：0xdf00 [禁用]
好：错误校验和
校验和错误：错误
数据（79字节）
数据：fe4c00004c0130020502e926409478f78549ec7bec08ae53…
长度：79
应用程序确定：（第一，233，dfaut qqmusicexternal.exetencent_private：，，，处理）名称：tencent_private
散列：dfaut
模块：qqmusicexternal.exe
导演：Up
该编号：233
L7序列：1
结论：a）.以太网的目的地址：Hangzhou_8d:87:f1 (00:23:89:8d:87:f1)；以太网的源地址：Dell_cf:a4:c5 (84:8f:69:cf:a4:c5)；
b）.ip包的目的地址：119.177.224.41 (119.177.224.41)；ip包的源地址：222.18.168.170 (222.18.168.170)；头部长度：20 bytes；检查和：0x0000 [incorrect, should be 0x408d (may be caused by "IP checksum offload"?)]；总长度：107；数据类型：UDP。

c）.UDP，UDP首部：源端口http (80) 目的端口hosts2-ns (81)长度87 检验和0xdf00 [validation disabled]
d）.传输层的数据长度79。

分析：本次抓包实验中出现了错误的首部检验和，表现为：header checksum == 0x0000。

经过查找资料等找出了其原因和检验方法。

经过实际操作确实解决了此问题，下面开始加以说明。

原因：在使用WireShark等截取数据包时，往往会出现错误的CheckSum，这主要是因为网卡开启了CheckSum Offload(硬件校验和) 功能，系统将CheckSum的计算工作交由网卡去计算，在高速网络交换的情况下可以大大减轻CPU的工作负荷。

具体：网卡驱动的高级配置中，一般有两项叫做Rx Checksum Offload和Tx Checksum Offload ：如图：
其中的“IPv4硬件校验和”即对应了这两个选项，它的可选项有“Rx & Tx 开启、Rx 开启、Tx开启和关闭”四个。

默认的配置往往是 Rx & Tx 开启。

它表示网卡会帮应用进行计算ip头的checksum字段，这样一来，操作系统的ip协议栈无须进行额外的checksum运算，它只需封装好ip 数据报后甩给网卡即可。

甩给网卡的原始ip报文的checksum字段值，原则上是无意义的，即随机的，但是根据windows上的表现来看，这个值一直是固定0x0000。

将选项选为关闭就能解决这个问题了。

接下来是比较具体的解释（以下为摘抄）：
在windows系统中的Checksum Offload过程如下：
如果网卡支持，在高级选项里可以设置Checksum Offload是否对Rx或Tx有效，也可以设置为对两者都有效。

对于Tx，设置Checksum Offload有效之后，Windows的传输层将随机填充TCP校验和，因此在本机上抓取的数据包是Bad CheckSum。

然后，网卡会自动计算正确的校验码然后发送，因此对方收到的仍然是正确的TCP包。

对于Rx，设置Checksum Offload有效之后，网卡在接收数据时，会填充一个NDIS_TCP_IP_CHECKSUM_PACKET_INFO 结构并设置标志位；如果由于某种原因失败，则不设置标志位，由Windows里的TCP/IP协议栈来完成数据校验。

CheckSum Offload实际上是将传输层的一部分工作交给了硬件完成，以节约系统的CPU资源。

微软的测试表明它可以最多节约30%的CPU资源。

IBM里AIX的文档则指出：对于PCI接口的千兆网卡来说还不如让400Mhz以上的CPU来计算校验和，而PCI-X的千兆网卡启用此项后可以达到线路速度，从而节约CPU资源。