Go gopacket 捕获长度与原始报文长度有什么区别

在 Go gopacket 里，抓到一条报文后经常会同时看到 CaptureInfo.CaptureLength 和 CaptureInfo.Length。它们不是同一个长度：前者表示当前真正读入、可以交给解码器处理的字节数，后者表示原始报文本来有多长。

官方地址：https://pkg.go.dev/github.com/google/gopacket

判断是否被抓包截断，直接比较 CaptureLength 。需要计算当前缓冲区能处理多少内容时看 CaptureLength；需要知道线路上的原始报文大小时看 Length。两者相等，只能说明本次捕获没有体现出长度差异，不能把字段职责混为一谈。

两个字段分别表示什么

CaptureInfo 是 gopacket 在抓包源和离线文件读取器之间统一传递的元数据。它把“读到了多少”和“原包有多大”拆成两个字段，避免调用方把一段被快照长度裁剪的数据误当成完整报文。

• CaptureLength：本次从抓包源或 pcap 文件中实际得到的字节数，通常也对应返回的 data 长度。
• Length：原始报文的字节数。它可以大于当前返回的数据长度。
• len(packet.Data())：当前 Packet 中实际保留的数据量，适合判断手头缓冲区能读到什么，不代替原始报文长度。
• PacketMetadata.Truncated：解码器或元数据判断出数据不足时的截断标记；其中一个直接条件就是 CaptureLength 。

为什么捕获长度可能小于原始长度

抓包并不一定保存报文的全部字节。离线 pcap 文件可能在生成时设置了快照长度，实时抓包也可能通过抓包源的缓冲区上限只保留前半段。此时元数据仍可以记录原始报文长度，但返回的数据只包含允许读取的那部分。

例如原始报文是 1500 字节，抓包快照长度是 96 字节，那么常见结果是 Length == 1500、CaptureLength == 96，而 data 也只有 96 字节。后续 IP、TCP 或应用层内容如果位于 96 字节之后，就不能假设它存在。

如果读取的是没有发生裁剪的报文，通常会看到两个字段相等。但判断完整性时仍应保留比较逻辑，因为同一套代码可能同时处理实时抓包、不同快照长度的 pcap 文件和已经被截断的测试样本。

从 pcapgo Reader 读取时应该看哪一个

离线读取时，pcapgo.Reader.ReadPacketData 返回数据切片和 CaptureInfo。数据切片的长度由捕获长度决定，而原始长度仍放在元数据里。下面的代码只展示字段职责和错误处理，不依赖本机实际抓包文件。

package main

import (
    "fmt"
    "github.com/google/gopacket/pcapgo"
)

func describePacket(r *pcapgo.Reader) error {
    data, ci, err := r.ReadPacketData()
    if err != nil {
        // 读取失败时不要把零值长度当成一条有效报文继续处理。
        return fmt.Errorf("读取报文失败: %w", err)
    }

    // CaptureLength 表示当前 data 真正拥有的字节数。
    fmt.Printf("可用字节: %d, 缓冲区长度: %d\n", ci.CaptureLength, len(data))
    // Length 表示原始报文大小，可能大于当前缓冲区。
    fmt.Printf("原始报文: %d 字节\n", ci.Length)

    if ci.CaptureLength 

这里把 len(data) 与 ci.CaptureLength 并列打印，是为了提醒调用方：当前可读取的数组边界来自捕获数据，而不是 ci.Length。当报文被裁剪时，按 ci.Length 分配访问范围会产生越界或错误的完整性判断。

PacketSource 解码后怎样确认截断

如果使用 gopacket.PacketSource，可以从 packet.Metadata().CaptureInfo 读取原始元数据，同时观察 packet.Metadata().Truncated。这个标记不只关注两个长度字段：解码过程中发现某层声明的长度超过手上数据时，也可能将它标记为截断。

func printMetadata(packet gopacket.Packet) {
    metadata := packet.Metadata()
    ci := metadata.CaptureInfo

    // 数据长度用于约束当前切片访问，不能用原始长度替代。
    available := len(packet.Data())
    fmt.Printf("available=%d captured=%d original=%d\n", available, ci.CaptureLength, ci.Length)

    if metadata.Truncated {
        // 截断时不要把缺失的传输层或应用层字段当成零值结论。
        fmt.Println("当前 Packet 可能缺少完整层数据")
    }
}

实际项目可以把这三个值一起写入日志或指标：available 反映当前 Packet 数据切片，captured 反映抓包源报告的捕获长度，original 反映原始报文长度。这样排查“为什么应用层解析为空”时，能先排除数据根本没有被捕获的情况。

四个容易混淆的判断

特别要注意，CaptureLength == Length 并不等于每个协议层都一定能成功解码。gopacket 还会依据协议头中声明的长度与实际数据做解码判断；因此，长度相等是一个有用信号，但不是所有解析结论的保证。

写回 pcap 时为什么也要保持这个关系

如果把抓到的数据写回 pcap，写入器要求捕获长度与实际写入的 data 长度对应，同时捕获长度不能大于原始长度。换句话说，被截断的报文可以被保留为“捕获了多少、原始有多长”的记录，但不能把 Length 错填成缓冲区长度后再声称它是完整报文。

这也是保留两个字段的工程价值：分析工具可以知道文件里实际保存了什么，后续流程也能知道哪些字节从一开始就没有被采集。对于需要重新组装 TCP、提取应用层内容或计算完整载荷的程序，先判断截断状态，再决定是否继续，是比盲目补读更可靠的边界。

最后记住这条长度关系

读 gopacket 的长度信息时，可以先写下这条关系：CaptureLength 。等号表示当前捕获长度与原始长度一致，小于号表示当前数据可能被快照或抓包缓冲区裁剪。访问字节时服从 CaptureLength 或实际切片长度，解释原始报文规模时使用 Length，判断是否需要对解析结果保持谨慎时结合 Truncated。

相关问题

CaptureLength 和 len(packet.Data()) 一定相等吗？

对常规 PacketSource 数据路径，二者通常对应同一批已捕获字节；但代码仍应以实际切片边界为准，不要只凭元数据构造访问范围。

Length 大于 CaptureLength 时能补回缺失内容吗？

不能。Length 只告诉你原始报文的大小，缺失字节没有随当前捕获结果保存。要获得完整内容，需要重新以更大的快照长度或合适的抓包配置采集。

两个长度相等还要检查 Truncated 吗？

要。长度相等可以排除最直接的抓包裁剪，但解码器仍可能依据协议层声明发现数据不足，因此完整处理链路应同时尊重 PacketMetadata.Truncated。