Wireshark 数据分析（二）

数据包概述

下图是笔者我实际中用Wireshark 抓到的HTTP的完整数据包，现分析如下：

网络接口层(物理层和数据链路层) IP头(网络层) TCP头(传输层) HTTP协议+data(应用层)

1. 在链路层
　　由以太网的物理特性决定了数据帧的长度为[46＋18]－[1500＋18]，其中的18是数据帧的头和尾，也就是说数据帧的内容最大为1500（不包括帧头和帧尾），即MTU（Maximum Transmission Unit）为1500

2. 在网络层
　　因为IP包的首部要占用20字节，所以这的MTU为1500－20＝1480

3. 在传输层
　　对于UDP包的首部要占用8字节，所以这的MTU为1480－8＝1472； (note：实验不要求)
　　
4. 在应用层
　　Data最大长度为1472。 （当我们的UDP包中的数据多于MTU(1472)时，发送方的IP层需要分片fragmentation进行传输，而在接收方IP层则需要进行数据报重组，由于UDP是不可靠的传输协议，如果分片丢失导致重组失败，将导致UDP数据包被丢弃）

Note: IP分片、“TCP分片”的区别
　　首先声明：TCP分片应该称为TCP分段. 区别

• IP分片产生的原因是MTU网络层的；TCP分段产生原因是MSS(Max Segment Size), 它们工作在不同的层

• IP分片由网络层完成，也在网络层进行重组；TCP分段是在传输层完成，并在传输层进行重组. //透明性

• 对于以太网，MSS为1460字节（1500 – 20 - 20），而MTU（1500 – 20 ）往往会大于MSS. 其中20字节为IP / TCP 头长。故采用TCP协议进行数据传输，是不会造成IP分片的。若数据过大，只会在传输层进行数据分段，到了IP层就不用分片

• 我们常提到的IP分片是由于UDP传输协议造成的，因为UDP传输协议并未限定传输数据报的大小

　　图中最开始的绿色部分就是24 Bytes的Pcap Header,接下来红色的16 Bytes是第一个消息的Pcaket Header。后面的红色的16 Bytes是第二个消息的Pcaket Header。两块蓝色的部分分别是两个消息从链路层开始的完整内容。在网络上实际传输的数据包在数据链路层上每一个Packet开始都会有7个用于同步的字节和一个用于标识该Packet开始的字节，最后还会有四个CRC校验字节；而PCAP文件中会把前8个字节和最后4个校验自己去掉，因为这些信息对于协议分析是没有用的

---

Frame帧

　　用Wireshark打开一个PCAP数据包，每条消息的所有field会被解析出来并会按照协议层次折叠起来。第一层显示的是FrameXXX，这一级别没有对应某层具体的协议，而是对本条消息的一个概括性总结，描述了一些有用的概括性信息，比如从里面我们可以看到本条消息各种协议的层次关系，展开其它协议层之后对应的是该协议的各个域，如下图所示
　　
　　

• Frame 1: 256 bytes on wire (2048 bits ), 256 bytes captured (2048 bits)
  帧1：无线传输256 bytes (2048 bits)，捕获256 bytes (2048 bits)

• Encapsulation type : Ethernet (1) —— 封装类型：以太帧

• Arrival Time : Mar 18 2014 11:33:40.438113000 —— 到达时间 (经过下面时间戳转化而来的)

• Time shift for this packet:0.000000000seconds —— 此包时移

• Epoch Time：1395113620.438113000 UNIX时间戳：Unix时间戳（英文为Unix time, POSIX time 或 Unix timestamp） 是从Epoch （1970年1月1日00:00:00 UTC）开始所经过的秒数，不考虑闰秒 (在packet Header 里前八个字节可获得)

• Time delta from previous captured frame : 0.0000 second —— 距上一次被捕获帧时间间隔

• Time delta from previous displayed frame : 0.0000 second —— 上一次显示帧的时间间隔

• Time since reference or first frame —— 从参考帧或第一帧时间间隔

• Frame Number : 1 —— 帧号为1

• Frame Length : 256 bytes (2048 bits) —— 实际帧长度为256 bytes

• Capture Length : 256 bytes (2048 bits) —— 捕获帧长度为256 bytes

• Frame is marker : False —— 说明该帧没有被标记

• Frame is ignored : False —— 说明该帧没有被遗漏

• protocols in frame : eth:ethertype:ip:tcp:http —— 这个数据报所用的协议有以太网协议，IP协议, TCP协议，HTTP协议

• Number of per-protocol-data : 1 —— 每个协议所带数据数量为1 (?)

• Hypertext Transfer protocol , key , 0 —— 超文本传输协议 (?)

• Coloring Rule Name :http —— 被着色规则名称为 http

• Coloring Rule String :http || tcp.port ==80 || http2 —— 着色字符串为http, tcp端口为80 ,超文本传输协议

---

Ethernet层

网络接口层: 与OSI参考模型中的物理层和数据链路层相对应

字段 前导码 帧开始符 目的MAC地址 源MAC地址 长度/类型 数据和填充 帧校验序列 字段长度/byte 7 1 6 6 2 46~1500 4 目的 同步 标明下一个字节为目的MAC字段 指明帧的接受者 指明帧的发送者 帧中数据的协议类型（长度或类型） 高层的数据，通常为3层协议数据单元。对于TCP/IP是IP数据包 对接收网卡提供判断是否传输错误的一种方法，如果发现错误，丢弃此帧

　　在发送端将上层的IP数据报封装成帧后发送到网络上；数据帧通过网络到达接收端时，该结点的网络接口层对数据帧拆封，并检查帧中包含的MAC地址。如果该地址就是本机的MAC地址或者是广播地址，则上传到网络层，否则丢弃该帧

　　MAC地址用来表示互联网上每一个站点的标识符，采用十六进制数表示，共六个字节（48位）

1. Ethernet II, Src: GemtekTe_85:78:73 (00:26:82:85:78:73), Dst: Tp-LinkT_fd:2c:b9 (d8:15:0d:fd:2c:b9)

• Ethernet II (6个字节的目的MAC地址，6个字节的源MAC地址，2个字节的类型域…) 其实Wireshark只解析了前三个字节，如GemtekTe、Tp-LinkT，后三个字节原封不动的保留在了解析结果里

• 这种解析的理论依据是，六字节的MAC地址其实可以对半分为两部分：前三个字节由IEEE的注册管理机构统一分配，称为OUI(组织唯一标识符)或是Company_id(公司标识符)，一般可以通过这三个字节识别出生产厂商；后三个字节由厂商自行分配，意义不大

• 前 6 位 16 进制数代表网络硬件制造商的编号 , 后 3 位 16 进制数代表该制造商所制造的某个网络产品（如网卡）的系列号

2. Destination: Tp-LinkT_fd:2c:b9 (d8:15:0d:fd:2c:b9)
　　目的mac地址为(d8:15:0d:fd:2c:b9)

• …. ..0. …. = LG bit: Globally unique address (factory default)
  全局唯一地址(厂家默认) ，如：GemtekTe 对应 00:26:82:

• …. …0 …. = IG bit: Individual address (unicast)
  无效单播地址

3. Source: GemtekTe_85:78:73 (00:26:82:85:78:73)

　　分析如上

4.Type: IP (0x0800)

• 指示上层协议类型为IP（0x08、0x00）

---

IP层

网络协议位于网络层，处理分组交换网中的路由选择，传输的是分组，以下IPv4数据包结构

1. Internet Protocol Version 4, Src: 192.168.1.161 (192.168.1.161), Dst: 114.112.67.59 (114.112.67.59)

• IP协议，版本4，源IP地址 192.168.1.161 目的地址：114.112.67.59

2. Version: 4

• IP所使用的版本号为4 (与3构成16进制 0x45)

3. Header Length

• ( 0x45 & 0x0F ) * 4 = 20，首部长度为20字节并不直接表示包头所占用的长度，而是表示包头占用了多少个32位

4. Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))

• 服务类型：优先级标志位和服务类型标志位，被路由器用来进行流量的优先排序，用来进行QoS 服务类型，为在数据传输中选择具体网络类型的摘要描述

• …. 0000 00.. = Differentiated Services Codepoint: Default (0x00)
  DSCP差分服务代码点, 默认Default（BE）0x00 00最不重要的业务是Internet业务，可以放在BE模型来传输。这也是我们为什么老抱怨网络不好

• …. ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
  显式拥塞通知 TOS后两位为：00，表示不支持ECN (详见附录)

5. Total Length: 242

• IP头与数据包中数据的长度 (256 – 14 ) MTU最大1500字节

6. Identification: 0x28e5 (10469) (同一数据流的分片身份序列相同)

• 识别一个数据包或被分片数据包的次序，一个唯一的标识数字

7. Flags: 0x02 (Don’t Fragment) ( HTTP 不分片！！！)

• 标记数据包是否是一组分片数据包的一部分，这里是不分片
• 0… …. = Reserved bit: Not set —— 无保留位，没有设置
• 1.. …. = Don’t fragment: Set —— IP不分片
• ..0. …. = More fragments: Not set —— 其余分段没有设置

8.Fragment offset: 0

• 该数据包是个分片，数据包按分片偏移值顺序重组

9. Time to live ( TTL ): 64

• 用来定义数据包的生命周期，以经过路由器的跳数/秒数进行描述。超过TTL 时间，数据包将被丢弃

10. Protocol: TCP (6) 0x06

• 用来识别在数据包序列中上层协议数据包的类型为TCP

11. Header checksum: 0x992c [validation disabled] //验证禁用

• 首部校验和：一个错误检测机制，用来确认IP头的内容没有被损坏或者篡改。此处为无法确认，即没有传输数据。

• 头部报文的校验和，据说跟TTL有关？TTL在每一条改变，那么它就重新校验一次。

• Good: False Bad: False —— Wireshark 分析的 (如果Header checksum 为 correct, 则Good : True)

12. Source: 192.168.1.161 (192.168.1.161) —— 发送数据包主机IP地址

13. Destination: 114.112.67.59 (114.112.67.59) —— 数据包目的地IP地址

14. Source GeoIP: Unknown —— GetLocation IP, 给予IP查询的源地理位置

15. Destination GeoIP: Unknown —— GetLocation IP, 给予IP查询的目的地理位置

/****** 上共20字节) ********/

16. 选项 (Options): 保留作额外的IP选项。它包含着源选路和时间戳的一些选项

17. 数据 (Data)： 使用IP传递的实际数据

Note:
a) 数据在 IP 层称为 Datagram ，分片称为 Fragment
b) 数据在 TCP 层称为 Stream，分段称为 Segment
c) 数据在 UDP层称为 Message

Header checksum: 0x992c [validation disabled]验证禁用：这是因为Wireshark总是常常抓取正在运行自己的PC的网络帧，通常的结果是校验和溢出帧不正确，因为它们被Wireshark记录后又被网卡仅仅对传播计算。( This usuallu results in the checksums of outgoing frames being incorrect since they are only calculated for transmission by the network card after they were already recorded by Wireshark). 为避免频繁的提示校验值出错，默认验证禁止

---

附录——显式拥塞通知ECN剖析

1. 基本原理
　　路由器在出现拥塞时通知TCP。当TCP段传递时，路由器使用IP首部中的2位来记录拥塞，当TCP段到达后，接收方知道报文段是否在某个位置经历过拥塞。然而，需要了解拥塞发生情况的是发送方，而非接收方。因此，接收方使用下一个ACK通知发送方有拥塞发生，然后，发送方做出响应，缩小自己的拥塞窗口
　　
2. IP层对ECN的支持 （返回）
　　在网络层，一个发送主机必须能够表明自身能支持ECN与否，路由器在转发时必须能够表明它正在经历拥塞。IP首部中的8位服务类型域（TOS）原先在RFC791中被定义为发送优先级、时延、吞吐量、可靠性和消耗性等特征。在RFC2474中被重新定义为包含一个6位的区分服务码点（DSCP）和两个未使用的位。DSCP值表明一个在路由器上配置的队列的和队列相关联的发送优先级。IP对ECN的支持用到了TOS域中剩下的两位

• TOS后两位为：00，表示不支持ECN
• TOS后两位为：01，表示支持ECN
• TOS后两位为：10，也表示支持ECN
• TOS后两位为11，表示路由器发生了拥塞

一个支持ECN的主机发送数据包时将ECN域设置为01或者10。对于支持ECN的主机发送的包，如果路径上的路由器支持ECN并且经历拥塞，它将ECN域设置为11。如果该数值已经被设置为11，那么下游路由器不会修改该值。当路由器检测到拥塞时，设置ECN域为11

３. TCP层对ECN的支持
　　TCP使用6位保留位（Reserved）的后两位来支持ECN。 两个新的标志CWR、ECE含义如下：　　

• ECE有两个作用，在TCP三次握手时表明TCP端是否支持ECN；在传输数据时表明接收到的TCP段的IP首部的ECN被设置为11，即接收端发现了拥塞

• CWR为发送端缩小拥塞窗口标志，用来通知接收端它已经收到了设置ECE标志的ACK。
  当两个支持ECN的TCP端进行TCP连接时，它们交换SYN、SYN+ACK、ACK段。对于支持ECN的TCP端来说，SYN段的ECE和CWR标志都被设置了，SYN的ACK只设置ECE标志。从tcp连接上控制：

define TCP_ECN_OK 1     /* 本端支持ECN */  define TCP_ECN_QUEUE_CWR 2    /* 本端被通知了拥塞，此时作为发送方define TCP_ECN_DEMAND_CWR 4 /* 通知对端发生了拥塞，此时作为接收方

4. 处理流程
　　一个支持ECN的TCP主机在支持ECN的TCP连接上发送设置了IP首部为10或者01的TCP段。支持ECN的路由器在经历拥塞时设置IP首部的ECN域为11。当一个TCP接收端发送针对收到一个设置ECN位为11的TCP段的响应时，它设置TCP首部中的ECE标志，并且在接下来的ACK中也做同样设置
　　当发送主机接收到了设置ECE标志的ACK时，它就像感知到丢包一样，开始减小发送窗口。在下一个数据包中，发送者设置CWR标志。在接收到新的设置CWR标志的包时，接收着停止在接下来的ACK中设置ECE标志

---

关于以太帧数据包概述分析请见Wireshark 数据分析（一）

关于以太帧数据包中 TCP 分析请见Wireshark 数据分析（三）