2023年12月7日发(作者：)
实验2 wireshark或sniffer抓包软件使用实
本次实验使用wireshark抓包软件。开启的应用程序有：IE，QQ, QQ音乐。过滤的UDP的报文。
结果：
抓取的报文：
14 2.915765000 tencent_private DFAUT 222.18.168.170 119.177.224.41 UDP 121 Source port: http Destination port: hosts2-ns
即第14号报文，时间为2.915765000，应用程序名称：tencent_private，应用哈希：DFAUT,
应用程序模块：，源地址：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: _bad==1 || um_bad==1 || um_bad==1 ||
um_bad==1 || um_bad==1 || um_bad==1 ||
um_bad==1 || um_bad==1 || _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（不要片段）
< ....=保留位：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字节）
数据：fe4c00004ce926409478f78549ec7bec08ae53…
长度：79
应用程序确定：（第一，233，dfaut cent_private：，，，处理）
名称：tencent_private
散列：dfaut
模块：
导演：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资源。
发布评论