pcap结构pcap_pkthdr len vs caplen
我们在linux上使用libpcap嗅探数据包，我们在每个数据包上得到的报头如下：
struct pcap_pkthdr {
struct timeval ts; /* time stamp */
bpf_u_int32 caplen; /* length of portion present */
bpf_u_int32 len; /* length this packet (off wire) */
};现在，我的理解是caplen是我们捕获的数据的长度，而len是网络上数据包的长度。在某些情况下(例如，当打开pcap设备时将snaplen设置得太低时)，我们可能只捕获数据包的一部分，该长度将是'caplen'，而'len‘是原始长度。因此，caplen应该等于或小于len，但决不能大于len。
这是一种正确的理解吗？我们在一些机器上看到caplen > len
回答 3
Stack Overflow用户
发布于 2009-09-29 16:11:30
您的理解是正确的，至少根据pcap手册页是这样的。
caplen是捕获中可用的数据量。len是数据包的实际长度。
我不知道有什么情况会给你一个卡普伦>伦。我通常认为它们是相等的，因为我的snaplen足够高。
Stack Overflow用户
发布于 2013-01-03 00:22:26
是的，你的理解是对的，Caplen总是小于Len。有时我们不需要捕获整个数据包。但是为什么不给你一个机会来捕获整个包呢？因为在网络流量很大的情况下，这不是一个好主意。如果我们不捕获出现在网络上的整个数据包，我们不是实际上丢失了宝贵的数据吗？不是的。实际上这取决于你的目的，如果你只是想根据协议和它要去的应用对数据包进行分类，你只需要大约14字节(以太网)+ 20字节( Ip )+另外20字节( Tcp )，因此你显然只需要54字节的数据来根据协议对数据包进行分类，所以将处理大小从pcappkthdr->len减少到pcappkthdr->caplen可以节省大量的负载和时间:)
如果数据包中的报头被破坏(这意味着如果headerlength值以某种方式弄乱了)，那么捕获的长度将大于数据包的实际长度。
Stack Overflow用户
发布于 2013-01-06 06:21:28
如果caplen > len，这是一个bug；您使用的是什么版本的libpcap？
https://stackoverflow.com/questions/1491660
复制相似问题
腾讯云开发者
