pcap报文格式和wireshak中的frame层_protocols in frame-CSDN博客

本文链接：https://blog.csdn.net/javajiawei/article/details/80187963

这篇文章是我早期写的，后来为了撰写专栏《wireshark从入门到精通》，我在此文章基础上对内容部分进行了新增和改动，新文章见这里，对于wireshark想深入了解的同学欢迎订阅查看。

本文主要聊一聊pcap报文文件格式以及wireshark frame层的相关内容。

使用wireshark查看报文的时候发现，wireshark解码后所提供的信息除了我们所知道的各种协议的层之外(诸如IP层，TCP层，HTTP层的数据)，其实在最上层还有一个frame层，如图1所示:

这里写图片描述

图1

从图1中可以看出该层所提供的信息包括两类，一类是没有中括号的，这类信息表示的是，从pcap数据报文本身能够提取的一些信息。像Encapsulation type: Ethernet (1)表示以太网的链路;Arrival Time: Apr 15, 2018 10:11:42.583288000以及Epoch Time: 1523758302.583288000 seconds表示获取报文的时间，只是两种不同的时间格式;Frame Length: 255 bytes (2040 bits)表示数据的长度，也就是根据协议这种类格式中length所得到的长度，和后面的Capture Length长度略有不同: Capture Length: 255 bytes (2040 bits)表示在网卡上所捕获的实际数据长度。通常情况下Frame Length和Capture Length 是相同的，但是如果Capture Length所捕获的数据有缺失，则Capture Length要比Frame Length要小一些。另外一类是带有中括号的，这类信息表示的是根据报文整体的分析所给出的辅助性信息。像[Protocols in frame: eth:ethertype:ip:tcp:ssl]这种信息就是根据报文解码分析所得到的，pcap本身并不含有这些字段信息。

上述frame层中这些没有中括号的信息都是从pcap 报文中获取，但是又不是协议所提供的，这些信息不属于网络传输过程中传输协议数据或者传输内容数据的一部分，属于的是诸如winpcap 以及libpcap 这种用于抓取网络数据的库，在抓取数据时候将每一片的报文添加的一些头部信息中的内容，因此有必要简单介绍一些pap文件的构成，如图2所示。
这里写图片描述

图2

在wireshark的官网，这里给出了pcap文件的存储格式，如图2。如同现有的文件格式包括我们所分析的各种协议，其实都有固定的一种模式，那就是tlv意思就是type，length，value。之于文件来说，type就是告诉解码器文件的类型; length就是告诉解码器文件内容长度；value就是具体的内容数据。

如图2所示，可以看到一个总的头部信息Global Header，以及每一片报文会有其对应的头部信息Packet Header，这些信息都是在形成pcap 报文的过程中主动写进去的，剩下的Packet Data表示抓取网络通信中的实际数据内容。分别解释一下Global Header以及Packet Header中个字段的含义。

在wireshark官网中给出的Global Header头部包含如下各字段：

typedef struct pcap_hdr_s {
        guint32 magic_number;   /* magic number */
        guint16 version_major;  /* major version number */
        guint16 version_minor;  /* minor version number */
        gint32  thiszone;       /* GMT to local correction */
        guint32 sigfigs;        /* accuracy of timestamps */
        guint32 snaplen;        /* max length of captured packets, in octets */
        guint32 network;        /* data link type */
} pcap_hdr_t;

给出的Packet Header头部包含如下各字段：

typedef struct pcaprec_hdr_s {
        guint32 ts_sec;         /* timestamp seconds */
        guint32 ts_usec;        /* timestamp microseconds */
        guint32 incl_len;       /* number of octets of packet saved in file */
        guint32 orig_len;       /* actual length of packet */
} pcaprec_hdr_t;

下面的码流为使用sublime打开上述图1中frame38报文效果：

d4c3 b2a1 0200 0400 0000 0000 0000 0000
0000 0400 0100 0000 deb4 d25a 78e6 0800
ff00 0000 ff00 0000 fcd7 33ec 414a 446d
57bb 14a1 0800 4500 00f1 20e2 4000 8006
423e c0a8 0072 b461 216b ced2 01bb 5e7a
21d5 6546 e5be 5018 40b0 c8f6 0000 1603
0100 c401 0000 c003 0389 0bb6 3b80 f388
3965 716e b3d9 c374 258d 6ce3 ca20 6748
68dc d4d0 25e3 f3b2 1e00 001c 8a8a c02b
c02f c02c c030 cca9 cca8 c013 c014 009c
009d 002f 0035 000a 0100 007b baba 0000
ff01 0001 0000 0000 1200 1000 000d 7777

Global Header中magic_number 为文件开始表示，一般为0xd4c3b2a1，同时头部字节需要交换读取顺序，如上述码流所示。如果我们在windows上使用nodepadd++以ANSI 格式编码(由于我使用的是中文操作系统，因此其对应编码方式应该是gbk）查看的时候，会显示前两个汉字为“悦病”，则是因为悦在gbk编码中为Oxd4c3，而病为0xb2a1(好像在gb2312 中病的编码为0xb2a0，这个略有不同）。version_major和version_minor一共4个字节表示大小版本号，即pcap格式版本，当前版本为2.4，如上。thiszone为4个字节的区域时间信息，默认为GMT,其值为0。sigfigs为4个字节的精确时间戳，通常默认为0。snaplen为4个字节的包最大长度描述的是允许抓取的每一片报文的最大长度，一般默认 ffff 0000 ，65535个字节即可以表示通常报文的最大长度，我这里面设置为 0400 0000（头部字节需要交换读取顺序）表示一个比较大的字节大小，如果想限制抓取每一片报文的长度，则可以设置。network为4个字节的链路类型，就是反应在frame 层中的Encapsulation type Ethemet(1)其值为1。

每一片Packet Header中包括ts_sec和ts_usec共8 个字节的时间信息，体现在Frame 中主要是每一片报文的捕获时间，为 deb4 d25a 78e6 0800，转换后的时间为Apr 15, 2018 10:11:42.583288000，在一开始的图中则有体现；incl_len为4 个字节的捕获长度信息，以及orig_len为4个字节的实际长度信息，均为ff00 0000，转换为主机字节序表示255个字节长度。至于incl_len和orig_len的区别，在前面介绍frame层信息的时候已经阐述。

当然frame虽然不是网络协议的一部分，但是wireshark却像各个协议一样为frame层提供了显示过滤器，供筛选报文之用，如图3：
这里写图片描述