最近一直在分析数据包。

同时也一直想学python。

凑一块儿了...于是，便开工了。座椅爆炸！

正文

首先要说的是，我知道python有很多解析pcap文件的库，这里不使用它们的原因是为了理解pcap文件的格式细节。使用tcpdump你可以很容易抓取到一系列的数据包，然而tcpdump并没有分析数据包的功能，如果想从这个抓包文件中分析出一些端倪，比如重传情况，你必须使用wireshark之类的软件，用wireshark打开tcpdump抓取的pcap文件，如果你看到了一堆堆的深红色(类似静脉血管里流出的猪血的颜色)的数据包，那么这些包一定是“在协议层看来”异常的数据包，包括但不限于重传，乱序等等，欲知详情，请在wireshark的过滤器中敲进去“tcp.analysis.”然后就会自动补全，这一切简直方便到极点。如果你还想看一些全局的统计数据，那么请点击”统计“菜单的第一个”捕获文件属性“，你会看到更多的信息。虽然数据包早就已经过去，但是雁过留声，我们通过抓取的数据包，还是可以得到更多的信息，多谢有wireshark/tshark(一个字符界面的pcap文件分析工具，类似wireshark，但更适合玩机械键盘的命令行粉们使用)/shookshark(...)这些工具，使得我们真实能够分析pcap文件以获取信息。

然而，这些我觉得还不够。

有一个简单的需求，我想得到在一个TCP连接中，一个端节点一共发送了多少字节的TCP载荷数据，包括正常发送以及重传。我没有在wireshark中找到得到这个数据的功能，于是我迫不及待自己写一个。厨师还怕没肉吃吗？

但有个前提，那就是我必须搞明白pcap文件的格式，因为我想裸分析pcap文件，试图找出每一个感兴趣数据包的TCP载荷(不包括TCP头和IP头)长度，然后将其累加。这样我必须知道pcap文件的格式细节才行。

幸运的是，pcap文件非常简单，就像我几乎10年前分析Windows PE文件一样，如今依然循着老路做着同样的事情。

如果你不善于查文档，那么作为一个编程者，看libpcap的源码也是个不错的选择，几乎和任何文件格式一样，pcap也是一个自描述的格式(这个自描述设计的不够优雅，以至于后来出现了pcapng文件格式，后面我会写一篇文章单独论述之)，整体包括文件头和数据载荷，这里所谓的数据载荷就是网络数据包。在libpcap的pcap.h文件中，结构体pcap_file_header描述了文件头：

[plain] view plain copy

1. struct pcap_file_header {
2. bpf_u_int32 magic;
3. u_short version_major;
4. u_short version_minor;
5. bpf_int32 thiszone; /* gmt to local correction */
6. bpf_u_int32 sigfigs; /* accuracy of timestamps */
7. bpf_u_int32 snaplen; /* max length saved portion of each pkt */
8. bpf_u_int32 linktype; /* data link type (LINKTYPE_*) */
9. };

具体我就不解释了，待会儿我会用一个实例来解析。紧接着这个文件头，后面就是一个个数据包了，为了描述每一个数据包的元信息，每一个数据包都会有一个描述头：

[plain] view plain copy

1. struct pcap_pkthdr {
2. struct timeval ts; /* time stamp */
3. bpf_u_int32 caplen; /* length of portion present 由于tcpdump可以设置-s参数指定抓取的长度，这个字段表示实际抓取的数据包长度 */
4. bpf_u_int32 len; /* length this packet (off wire) 这个字段表示数据包的自然长度 */
5. };

这个结构体描述了数据包抓取的时间信息以及长度信息，在这个结构之后才会是数据包，因此一个典型的pcap文件应该是如下所示：

这简直清晰至极啊，再次看我的那个需求，我想统计的两个量怎么得到呢？

一个TCP连接实际发送的字节数：每一个数据包的TCP载荷长度的加和。

一个TCP理论上应该发送的字节数：结束的TCP序列号与初始序列号之差。

有了上面的论述，我觉得这个需求超级简单就实现了，为了展示一下学习python的出血效果，给出以下的代码：

[python] view plain copy

1. #!/usr/bin/python
2. import sys
3. import socket
4. import struct
5. filename = sys.argv[0]
6. filename = sys.argv[1]
7. ipaddr = sys.argv[2]
8. direction = sys.argv[3]
9. packed = socket.inet_aton(ipaddr)
10. ip32 = struct.unpack("!L", packed)[0]
11. file = open(filename, "rb")
12. pcaphdrlen = 24
13. pkthdrlen=16
14. pkthdrlen1=14
15. iphdrlen=20
16. tcphdrlen=20
17. stdtcp = 20
18. total = 0
19. pos = 0
20. start_seq = 0
21. end_seq = 0
22. cnt = 0
23. # Read 24-bytes pcap header
24. data = file.read(pcaphdrlen)
25. (tag, maj, min, tzone, ts, ppsize, lt) = struct.unpack("=L2p2pLLLL", data)
26. # 具体的LinkType细节，请看：
27. # 网页链接
28. if lt == 0x71:
29. pkthdrlen1 = 16
30. else:
31. pkthdrlen1 = 14
32. ipcmp = 0
33. # Read 16-bytes packet header
34. data = file.read(pkthdrlen)
35. while data:
36. (sec, microsec, iplensave, origlen) = struct.unpack("=LLLL", data)
37. # read link
38. link = file.read(pkthdrlen1)
39. # read IP header
40. data = file.read(iphdrlen)
41. (vl, tos, tot_len, id, frag_off, ttl, protocol, check, saddr, daddr) = struct.unpack(">ssHHHssHLL", data)
42. iphdrlen = ord(vl) & 0x0F
43. iphdrlen *= 4
44. # read TCP standard header
45. tcpdata = file.read(stdtcp)
46. (sport, dport, seq, ack_seq, pad1, win, check, urgp) = struct.unpack(">HHLLHHHH", tcpdata)
47. tcphdrlen = pad1 & 0xF000
48. tcphdrlen = tcphdrlen >> 12
49. tcphdrlen = tcphdrlen*4
50. if direction == 'out':
51. ipcmp = saddr
52. else:
53. ipcmp = daddr
54. if ipcmp == ip32:
55. cnt += 1
56. total += tot_len
57. total -= iphdrlen + tcphdrlen
58. if start_seq == 0: # BUG?
59. start_seq = seq
60. end_seq = seq
61. # skip data
62. skip = file.read(iplensave-pkthdrlen1-iphdrlen-stdtcp)
63. # read next packet
64. pos += 1
65. data = file.read(pkthdrlen)
66. # 打印出实际传输的字节数，以及本应该传输的字节数
67. print pos, cnt, 'Actual:'+str(total), 'ideal:'+str(end_seq-start_seq)

很简单吧！懂python的人都会嘲笑我！

其实，在我看pcap文件格式之前，我曾经一直以为pcap文件是由类似ASN.1组织的，但是看了以后却发现不是，也是挺失望的。我之所以失望是因为，看起来以上描述的这种pcap不能描述除了数据包之外的更多东西，它事实上并不是自描述的，它是一种固定长度格式的文件结构，虽然处理起来很快，但是却十分不灵活不易扩展！彻底的自描述结构就是ASN.1！

......

我们来看一个例子。随便抓一个TCP包获得test.pcap文件，用UE打开这个pcap，请自行脑补！如果你真的理解了pcap的文件组织形式，那么请认真分析，如果不，请理解透彻而不要脑补！

执行python脚本pcap-parser.py，我们一无所获，因为这只是包含一个纯ACK包的pcap，没有携带任何数据，而python脚本旨在得到TCP数据流实际传输的数据量，因此我们不得不抓取一个携带TCP流量的pcap文件，而这非常简单。

两台虚拟机A，B互联，A启动httpd，B上执行wget下载一个文件，同时设置丢包率以获得额外的重传数据量。执行：

pcap-parser.py ./testTCP.pcap 192.168.44.129 out

我们得到了以下结果：

...请自行执行获取

肉眼计算后发现结果是一致的，我认为这个脚本可用了。然而...

然而当我用我写的python脚本去分析一个tshark抓取的数据包的时候，发现解析错了，这个时候魔术字就起作用了，我用UE残忍地打开了这个pcap文件，结果呢？

魔术字都是错的！于是上wireshark网站，知道了这是一个pcapng这个文件格式，同时，也知道了pcapng不能向下兼容。这是令人悲伤的一件事，但是幸运的是，pcapng文件格式要比pcap简单的多，而且，它基本就是类似ASN.1的组织办法。

我们发现pcap的文件格式中，大部分的元描述结构都是固定数量且定长的，以LinkType为例，一次抓包我只能指定一个LinkType，它被记录在pcap文件开始的pcap_file_header中，这意味着，我无法同时在以太网卡和非以太的PPP网卡上抓包并同时得到详细的链路层信息！而pcapng解决了这个问题。

欲知pcapng如何，且看下篇文字。

附录

细节1：Cooked Capture与Ethernet

如果说使用tcpdump -i any参数，我们不会看到标准的以太头信息，我们看到的是Cooked Capture，而不是Ethernet！关键的是，Cooked Capture描述的元信息长度是16字节而不是Ethernet的14字节。以下是Cooked Capture的头示例：

这个信息可以通过LinkType来获取。为什么会有这种Cooked Capture类型的数据包？因为抓包工具在-i any的情况下，无法用一种统一的方式来处理链路层的长度，比如很多协议，内部又区分了很多的子协议，其协议头的长度根据应用层而定，这是内核在抓包层面所处理不了的。pcap文件中，只能在一处指定LinkType，那就是文件头之后的pcap_pkthdr，如果说我指定-i eth0 -i lo -i ppp0 -i tun0，那就彻底没辙了！幸运的是，如果使用pcapng格式来存储抓包文件，那就可以针对这些网卡区别对待了，每一个网卡抓到的包都会关到一个LinkType，你会更轻松处理链路层，不过，大多数人不在乎链路层，也不在乎IP，更多人在乎的是TCP。

细节2：时钟跳变

作为一个pcap文件写的练习，这里有一个关于时钟跳变现象重现的例子。

我们抓包发现了一个奇怪的现象，那就是从客户端抓包上看，中间间隔了几十秒没有收到任何数据，在服务端抓包看来一切正常，总共的数据传输时间也就十几秒，这是怎么回事呢？

当即判断是客户端抓包时发生了时钟的跳变，比如时钟突然后跳了40秒，为了重现这个现象，我拿一个真实的普通正常的TCP下载为例，在收发第900个数据包的时候以及以后，数据包描述头里的时间戳字段统一加上40秒，看看是什么效果...代码非常简单：

[python] view plain copy

1. if pos > 900:
2. data = struct.pack("=LLLL", sec+40, microsec, iplensave, origlen)
3. file_out.write(data)

然后就重现了这个现象：

最后，想学习Python的小伙伴们！

请关注+私信回复：“学习”就可以拿到一份我为大家准备的Python学习资料！

pytyhon学习资料

python学习资料