Go netlink 消息序号与进程标识有什么区别

我第一次排查 Go netlink 回包时，最容易混在一起的是 Header.Sequence 和 Header.PID：一个像“这次请求排第几号”，另一个却不是普通意义上的进程号。先记住结论：Sequence 用来关联消息，PID 在 netlink 语境里是发送端口标识，也就是 port ID。它们都在消息头里，但职责、生命周期和判断方式不同。

官方地址：https://pkg.go.dev/github.com/mdlayher/netlink

Sequence 与 PID 先分工

Linux 的 nlmsghdr 同时包含 nlmsg_seq 和 nlmsg_pid。前者是序号，后者是发送端的 netlink port ID；Linux 文档还特别强调，这两个字段对 netlink 核心来说都是不透明值，不能把它们当成内核替你完成的全局语义。

Conn.Send 为什么会自动填写零值字段

github.com/mdlayher/netlink 的 Conn.Send 允许把 Header.Length、Header.Sequence 和 Header.PID 留为零。发送成功后，返回的消息副本会带上自动填充后的参数：Sequence 使用该连接的下一个序号，PID 使用 netlink 分配给该 socket 的 port ID。

这也是我更愿意保存 Send 返回值的原因。它是本次发送实际采用的头信息，可以作为后续关联的基线；但它不是跨连接、跨进程都有效的全局 ID。

package main

import "github.com/mdlayher/netlink"

func requestHeader() netlink.Header {
	return netlink.Header{
		// Type 和 Flags 描述请求性质，按具体 netlink family 选择。
		Type:  netlink.HeaderType(0x10),
		Flags: netlink.Request | netlink.Acknowledge,
		// Sequence、PID 留零，让 Conn.Send 按当前 socket 自动填充。
		Sequence: 0,
		PID:      0,
	}
}

这里的 PID: 0 不表示“发送者进程号为零”，而是把 port ID 的选择交给 netlink。若代码需要指定已经绑定的本地端口，则应把它当作 socket 地址的一部分处理，不能从操作系统进程列表反推。

回包匹配要看完整的消息头

收到消息后，我会先把 Sequence 当作“关联线索”，再看 Type 和 Flags。普通应答、NLMSG_ERROR、NLMSG_DONE 以及带 NLM_F_MULTI 的多段结果，本来就不是同一种消息。Sequence 相同，只能说明它们可能属于同一请求上下文，不能单独证明操作成功。

func sameRequest(sent, received netlink.Message) bool {
	// Sequence 用于关联；PID 还要满足同一 socket/port 的语境。
	if sent.Header.Sequence != received.Header.Sequence {
		return false
	}
	if sent.Header.PID != 0 && received.Header.PID != sent.Header.PID {
		return false
	}
	// 真实代码还要按 family 解码 Type，并处理 ACK、ERROR、DONE。
	return true
}

这个示例只展示字段边界，不替代具体 family 的协议解码。使用库的 Receive 时，多段消息会被组合返回，末尾的空多段完成消息会被移除；因此应用层仍应根据业务消息类型和错误值判断结果。

排查“回包对不上”时的检查清单

遇到日志里序号看似正确但结果仍然错配，我会按下面顺序缩小范围：

1. 确认请求和回包来自同一个 Conn 或明确记录了对应 socket 的 port ID。
2. 对比完整的 Sequence、PID、Type 和 Flags，不要只打印一个十进制数字。
3. 如果是通知或内核主动消息，先确认它是否本来就没有对应的用户请求。
4. 如果是多段结果，等到 NLMSG_DONE 或由库完成聚合后再交给业务层。
5. 出现 ENOBUFS 等情况时，按 netlink 语义做状态重同步，不能用 Sequence 补回丢失的消息。

常见问题：两个字段什么时候最容易误判

PID 等于 Go 进程的 os.Getpid 吗？

不一定。netlink Header 的 PID 是 port ID；它可能与进程号看起来相同，但不能据此建立稳定的进程身份判断。

Sequence 一定从 1 开始并且全局递增吗？

不应依赖这个假设。mdlayher/netlink 会按连接自动生成下一个序号，适合当前连接的关联，不是跨连接的全局事务号。

只比较 Sequence 能判断请求成功吗？

不能。还要处理消息类型、ACK、错误消息、多段结束标志和可能的缓冲区丢失；Sequence 只是关联条件之一。

把这两个字段拆开后，netlink 日志会更容易读：Sequence 回答“可能属于哪次消息交互”，PID 回答“这个 port ID 语境是谁发的”。真正的成功与否，仍由完整协议头和 payload 决定。