NetFlow v10和IPFIX本质上是同一套协议，模板机制让导出器不必预先固定字段格式。采集器如果跳过模板解析，只按端口、协议等常见字段硬编码偏移，在碰到防火墙日志、NAT事件或私有元素时会立刻错位。因此，先用Ruby把模板记录读清楚，是后续流量分析、异常检测和计费系统的基础。

IPFIX报文由消息头和若干集合组成。消息头固定16字节，包含版本号、报文总长度、导出时间、序列号和观测域ID。模板集合的Set ID固定为2，里面可以装载多个模板记录。每个模板记录有一个本地唯一的模板ID，后面跟着字段数量，再往后逐条描述信息元素。采集器必须把这些描述缓存起来，因为后续数据集合只携带模板ID和原始字节，本身不再重复字段定义。

模板记录如何描述信息元素

信息元素由IANA注册，常见的有源IPv4地址、目的IPv4地址、源端口、协议号等。模板中的每个字段说明至少包含元素ID和字段长度两个部分。当元素ID的最高位被置为1时，说明这是一个企业私有信息元素，紧接着的4字节是企业号；如果没有置位，就按IANA公共元素表解释。这个细节很容易被忽略，如果只按低15位读取元素ID，就会把企业号误当成后续字段长度。

例如元素ID的第16位为1，在Ruby里可以用id & 0x8000判断。真正元素ID是id & 0x7fff，再读取4字节企业号。对于公共元素，长度字段直接给出字节数；对于变长字段，长度会写成65535，此时数据记录里的实际长度需要从记录内部读取，而不是模板中声明的固定值。

模板缓存建议使用Map或Hash结构，键为观测域ID加模板ID。因为同一个采集器可能接收多个导出器流量，不同观测域的模板ID可能重复，单独用模板ID做键会串数据。完整的键可以写成#{observation_domain_id}:#{template_id}。

用Ruby解析模板集合

先监听UDP 2055、4739等常见端口。Ruby标准库自带的UDPSocket就能完成接收，解析二进制字节可使用String#unpack。读取消息头时，注意网络字节序是大端，使用pack指令中的n表示16位无符号整数，N表示32位无符号整数。

下面这段代码展示了如何从报文中分离消息头和集合。偏移量不要写成固定数值，跟着报文中声明的总长度往前走，可以避免多余字节干扰。

def parse_message(data)
  version, length, export_time, sequence, domain_id = data.unpack('nnNNN')
  raise "unsupported version: #{version}" unless version == 10
  offset = 16
  sets = []
  while offset < length
    set_id, set_length = data[offset, 4].unpack('nn')
    set_body = data[offset + 4, set_length - 4]
    sets << { id: set_id, body: set_body }
    offset += set_length
  end
  { version: version, domain_id: domain_id, sets: sets }
end

模板集合的set_id为2，里面的主体部分需要继续遍历。每个模板记录开头是模板ID和字段数量，模板ID必须大于255，否则属于保留值。接着逐个读取字段说明。字段长度为2字节，元素ID为2字节，如果元素ID最高位为1，再读4字节企业号。

def parse_template_set(body, domain_id)
  templates = {}
  offset = 0
  while offset + 4 <= body.bytesize
    template_id, field_count = body[offset, 4].unpack('nn')
    offset += 4
    fields = []
    field_count.times do
      element_id, field_length = body[offset, 4].unpack('nn')
      offset += 4
      enterprise_number = nil
      if element_id & 0x8000 == 0x8000
        enterprise_number = body[offset, 4].unpack1('N')
        offset += 4
        element_id &= 0x7fff
      end
      fields << {
        element_id: element_id,
        length: field_length,
        enterprise_number: enterprise_number
      }
    end
    templates[template_id] = fields
  end
  templates
end

这里body.bytesize比body.length更可靠，因为Ruby 2.4以后字符串长度和字节长度可能不同。解析全部字段后，把模板缓存到实例变量中，并在收到数据集合时使用。

根据模板解析数据记录

数据集合的Set ID大于等于256，通常Set ID就是模板ID，但更严格的做法是读取集合头中的ID，然后到缓存中查找对应模板。每个数据记录没有固定长度，必须按模板字段列表依次读取。遇到长度为65535的变长字段时，数据记录前部会有一个长度前缀，一般为1字节或3字节，取决于是否超过255。

下面的方法把字段列表和数据缓冲区传入，返回解析后的哈希。代码中read_variable_length会先读一字节，如果小于255，就是实际长度；如果等于255，再读两个字节作为16位长度。

def parse_data_record(buffer, template_fields)
  record = {}
  offset = 0
  template_fields.each do |field|
    length = field[:length]
    if length == 65535
      actual_length = read_variable_length(buffer, offset)
      offset += actual_length[:prefix_bytes]
      length = actual_length[:value]
    end
    raw = buffer.byteslice(offset, length)
    record[field[:element_id]] = raw
    offset += length
  end
  record
end
def read_variable_length(buffer, offset)
  first = buffer.getbyte(offset)
  if first < 255
    { value: first, prefix_bytes: 1 }
  else
    value = buffer[offset + 1, 2].unpack1('n')
    { value: value, prefix_bytes: 3 }
  end
end

原始字节并不一定直接可读，例如IPv4地址需要调用IPAddr.ntop转换，端口用unpack1('n')读取。实际项目中通常维护一个元素ID到名称和类型的映射，让输出更直观。企业私有字段还需要结合企业号才能唯一确定含义。

避免生产环境中的几类问题

第一个问题是模板丢失。导出器在启动或配置变更后会重新发送模板，但采集器如果UDP丢包，对应数据记录就无法解析。常见处理方式是先缓存数据集合，当模板到达后再补解析，或者设置短超时后丢弃。第二个问题是序列号回绕。IPFIX序列号是32位无符号整数，溢出后归零，如果采集器简单判断小于上一包就丢弃，会误伤正常数据。应使用差值计算或宽松处理。

第三个问题是多观测域。一个导出进程可能通过不同观测域发送流量数据，同一个模板ID在不同观测域下代表完全不同的字段布局。所以模板缓存的键必须包含观测域ID。调试时可以用Wireshark抓包，过滤cflow查看模板和数据集合，也能用Ruby打印模板缓存的摘要快速核对字段顺序。

最后，信息元素模板解析是IPFIX采集器的核心前置步骤，做对这一步后，后续的流量统计、安全检测和业务分析才能建立在正确字段边界上。相比使用libfixbuf等C库，Ruby的实现更便于嵌入Web系统或运维平台，性能上也能满足中小规模流量导出需求。