Pcap文件详解
一、简介
pcap文件是常用的数据报存储格式，可以理解为就是一种文件格式，只不过里面的数据是按照特定格式存储的，所以我们想要解析里面的数据，也必须按照一定的格式。
普通的记事本打开pcap文件显示的是乱码，用安装了HEX-Editor插件的Notepad++打开，能够以16进制数据的格式显示，或者使用sublime打开以十六进制的格式显示。用wireshark这种抓包工具就可以正常打开这种文件，愉快地查看里面的网络数据报了，同时wireshark也可以生成这种格式的文件。
还有一些其他网络分析工具。
二、文件格式
| Pcap header |
|---|
| Packet1 header |
| Packet1 Data |
| Packet2 header |
| Packet2 Data |
如上图所示，pcap文件的总体结构就是文件头-数据包头1-数据包1-数据包头2-数据包2的形式
1.Pcap Header
文件头，每一个pcap文件只有一个文件头，总共占24（B）字节，以下是总共7个字段的含义。（一个字节可以由2个十六进制表示）
Magic(4B)：标记文件开始，并用来识别文件和字节顺序。值可以为0xa1b2c3d4或者0xd4c3b2a1，如果是0xa1b2c3d4表示是大端模式，按照原来的顺序一个字节一个字节的读，如果是0xd4c3b2a1表示小端模式，下面的字节都要交换顺序。现在的电脑大部分是小端模式。
ps：网络字节序一般是大端存储，主机x86字节序一般是小端存储，比如我们经过网络发送0x12345678这个整形，在80X86平台中，它是以小端法存放的，在发送前需要使用系统提供的htonl将其转换成大端法存放
Major(2B)：当前文件的主要版本号，一般为0x0200
Minor(2B)：当前文件的次要版本号，一般为0x0400
ThisZone(4B)：当地的标准事件，如果用的是GMT则全零，一般全零
SigFigs(4B)：时间戳的精度，一般为全零
SnapLen(4B)：最大的存储长度，该值设置所抓获的数据包的最大长度，如果所有数据包都要抓获，将该值设置为65535（0xFFFF）； 例如：想获取数据包的前64字节，可将该值设置为64
LinkType(4B)：链路类型
2.Packet Header
数据包头可以有多个，每个数据包头后面都跟着真正的数据包。数据包头则依次为：时间戳（秒）、时间戳（微妙）、抓包长度和实际长度，依次各占4个字节。以下是Packet Header的4个字段含义
Timestamp(4B)：时间戳高位，精确到seconds，这是Unix时间戳。捕获数据包的时间一般是根据这个值
Timestamp(4B)：时间戳低位，能够精确到microseconds
Caplen(4B)：当前数据区的长度，即抓取到的数据帧长度，由此可以得到下一个数据帧的位置。
Len(4B)：离线数据长度，网路中实际数据帧的长度，一般不大于Caplen，多数情况下和Caplen值一样
3.Packet Data
Packet是链路层的数据帧，长度就是Packet Header中定义的Caplen值，所以每个Packet Header后面都跟着Caplen长度的Packet Data。也就是说pcap文件并没有规定捕获的数据帧之间有什么间隔字符串。Packet数据帧部分的格式就是标准的网络协议格式了。
例子：
红色部分是Pcap Header，蓝色部分是Packet Header，后边是Packet Date
Pcap Header的Magic：d4 c3 b2 a1，表示是小端模式，后面的字节从后往前读 a1b2c3d4 小端模式
Pcap Header的Major：02 00，计算机读的应该是00 02。最大存储长度SnapLen：ff ff 00 00 ，同理计算机读的应该是00 00 ff ff，所以是2的16次方减一，是65535个字节。LinkType：01 00 00 00 ，实际是00 00 00 01，是以太网类型。
蓝色部分的Packet Header我就不一一说了，重点关注Caplen：3c 00 00 00，计算机读的是00 00 00 3c，转换成十进制就是60，所以后面的60个字节都是一个数据帧。之后就又是一个Pcap Header，如此循环。
三、以太网帧（Ethernet）、IP包、TCP、UDP的长度范围
1、以太网帧
MAC地址则是48位的（6个字节），通常表示为12个16进制数，每2个16进制数之间用冒号隔开，如08：00：20：0A：8C：6D就是一个MAC地址。
以太网地址头部：目的地址（6字节）、源地址（6字节）、以太网类型（2字节）
目前以太网帧有5种，交换机之间BPDU（桥协议数据单元）数据包使用的是IEEE802.3/LLC帧，其格式如下：
| 字段 | 长度（字节） | 目的 |
|---|---|---|
| 前导码（Preamble） | 7 | 0x55,一串1、0间隔，用于信号同步 |
| 帧开始符（SFD） | 1 | 1字节0xD5(10101011)，表示一帧开始 |
| 目的MAC地址 | 6 | 指明帧的接受者 |
| 源MAC地址 | 6 | 指明帧的发送者 |
| 长度（Length）/类型（Type） | 2 | 0～1500保留为长度域值，1536～65535保留为类型域值(0x0600～0xFFFF) |
| 数据和填充（Data and Pad） | 46~1500 | 高层的数据，通常为3层协议数据单元。对于TCP/IP是IP数据包（注：如果帧长小于64字节，则要求“填充”，以使这个帧的长度达到64字节） |
| 帧校验序列（FCS） | 4 | 使用CRC计算从目的MAC到数据域这部分内容而得到的校验和 |
以太网MAC帧格式在Linux中，以太网帧头部的结构体如下：/ 10Mb/s ethernet header /
struct ether_header
{u_int8_t ether_dhost[ETH_ALEN]; / destination eth addr /u_int8_t ether_shost[ETH_ALEN]; / source ether addr /u_int16_t ether_type; / packet type ID field /
} __attribute__ ((__packed__));其中的ETH_ALEN为6，因为地址为6个字节，共48位——这个地址就是常说的物理地址，或MAC地址。它的第3个成员ether_type是以太帧类型，有如下这些：/ Ethernet protocol ID's /
#define ETHERTYPE_PUP 0x0200 / Xerox PUP /
#define ETHERTYPE_SPRITE 0x0500 / Sprite /
#define ETHERTYPE_IP 0x0800 / IP /
#define ETHERTYPE_ARP 0x0806 / Address resolution /
#define ETHERTYPE_REVARP 0x8035 / Reverse ARP /
#define ETHERTYPE_AT 0x809B / AppleTalk protocol /
#define ETHERTYPE_AARP 0x80F3 / AppleTalk ARP /
#define ETHERTYPE_VLAN 0x8100 / IEEE 802.1Q VLAN tagging /
#define ETHERTYPE_IPX 0x8137 / IPX /
#define ETHERTYPE_IPV6 0x86dd / IP protocol version 6 /
#define ETHERTYPE_LOOPBACK 0x9000 / used to test interfaces /注：如果帧长小于64字节，则要求“填充”，以使这个帧的长度达到64字节
但是我们观察到这个以太网帧只有60字节，why？
据RFC894的说明，以太网封装IP数据包的最大长度是1500字节（所以，数据链路层的最大传输单元（Maximum Transmission Unit，MTU）是1500字节），也就是说以太网最大帧长应该是以太网首部加上1500，再加上7字节的前导同步码和1字节的帧开始定界符，具体就是：7字节前导同步吗＋1字节帧开始定界符＋6字节的目的MAC＋6字节的源MAC＋2字节的帧类型＋1500＋4字节的FCS。
按照上述，最大帧应该是1526字节，但是实际上我们抓包得到的最大帧是1514字节，为什么不是1526字节呢？原因是当数据帧到达网卡时，在物理层上网卡要先去掉前导同步码和帧开始定界符，然后对帧进行CRC检验，如果帧校验和错，就丢弃此帧。如果校验和正确，就判断帧的目的硬件地址是否符合自己的接收条件（目的地址是自己的物理硬件地址、广播地址、可接收的多播硬件地址等），如果符合，就将帧交“设备驱动程序”做进一步处理。这时我们的抓包软件才能抓到数据，因此，抓包软件抓到的是去掉前导同步码、帧开始分界符、FCS之外的数据，只留下了目的地址，源地址，类型字段，其最大值是6＋6＋2＋1500＝1514。
以太网规定，以太网帧数据域部分最小为46字节，也就是以太网帧最小是6＋6＋2＋46＋4＝64。除去4个字节的FCS，因此，抓包时就是60字节。当数据字段的长度小于46字节时，MAC子层就会在数据字段的后面填充以满足数据帧长不小于64字节。由于填充数据是由MAC子层负责，也就是设备驱动程序。不同的抓包程序和设备驱动程序所处的优先层次可能不同，抓包程序的优先级可能比设备驱动程序更高，也就是说，我们的抓包程序可能在设备驱动程序还没有填充不到64字节帧的时候，已经捕获了数据。因此不同的抓包工具抓到的数据帧的大小可能不同。（比如，wireshark抓到的可能没有填充数据段，而sniffer抓到的就有填充数据段）
2、IP数据包
IP头大小最小为20字节。所以，网络层的MTU=数据链路层的MTU1500-20=1480字节。
由于IP协议提供为上层协议分割和重组报文的功能，在IP头中，用2个字节来描述报文的长度，2个字节所能表达的最大数字就是65535。所以，IP数据包的最大长度就是64K字节(65535)。
3、TCP（传输层）
TCP头部选项是一个可变长的信息，这部分最多包含40字节，因为TCP头部最长60字节，（其中还包含前面20字节的固定部分）。
依靠IP协议提供的报文分割和重组机制，TCP包头中就没有“包长度”字段，而完全依靠IP层去处理分帧。这就是为什么TCP常常被称作一种“流协议”的原因，开发者在使用TCP服务的时候，不必去关心数据包的大小，只需讲SOCKET看作一条数据流的入口，往里面放数据就是了，TCP协议本身会进行拥塞/流量控制。
选项和填充，n4字节，常见的可选字段是最长报文大小 MSS(Maximum Segment Size) 。每个连接方通常都在通信的第一个报文段（为建立连接而设置 SYN 标志的那个段）中指明这个选项，它指明本端所能接收的最大长度的报文段。选项长度不一定是 32 位字的整数倍，所以要加填充位，使得报头长度成为整字数
MTU和MSS值的关系：MTU=MSS+IP Header+TCPHeader
通信双方最终的MSS值=较小MTU-IP Header-TCP Header
4、UDP（传输层）
UDP包的首部要占用8字节，因为UDP提供无连接服务，它的数据包包头，是固定长度的8字节，不存在可选字段，可以减少很多传输开销，所以它无需使用首部字段长，因为它的首部就是固定的。
UDP则与TCP不同，UDP包头内有总长度字段，同样为两个字节，因此UDP数据包的总长度被限制为65535，这样恰好可以放进一个IP包内，使得 UDP/IP协议栈的实现非常简单和高效。
所以UDP包的最大值是：IP数据包的最大长度65535-IP头的大小20-UDP头的大小=65507字节。最小值是0。
这个值也就是你在调用getsockopt()时指定SO_MAX_MSG_SIZE所得到返回值，任何使用SOCK_DGRAM属性的socket，一次send的 数据都不能超过这个值，否则必然得到一个错误。
————————————————
版权声明：转载
参考链接：
https://blog.csdn.net/buside/article/details/92802959?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.control&dist_request_id=1328655.9369.16158574515802585&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.control
https://blog.csdn.net/ytx2014214081/article/details/80112277
https://www.cnblogs.com/caoguoping100/p/3658792.html
https://www.cnblogs.com/sinferwu/articles/7615276.html
