这是百度网络监控工具 nettools 开源系列的第四篇。前三篇分别介绍了 bitflip/baize（UDP 丢包与改包检测工具和Agent）、lidar（TCP SYN 端口可达性探测），它们解决的都是「服务器之间」「点到点」的探测问题——前提是：探测机和被探测对象，至少有一端在我们手里。

但有一类设备，我们既无法在它上面装 agent，也没法在它对面的机房里放一台探测机。这就是今天的主角 evr 要解决的困境。

这也是我更深入的了解网络包的构造，把网络探测玩出花了来，对我的网络编程的功力大增的一个很好的场景。

项目地址：https://github.com/baidu/nettools
文档：https://nettools.rpcx.io

一、evr 探测的困境：探测机进不去客户机房

先说一个真实的场景。

百度有大量的云客户，我们提供的 EVR（Edge Virtual Router，边缘虚拟路由器） 设备作为客户侧网络接入百度云网络的边界节点。EVR 往上连百度的骨干/城域网络，往下连客户自己的虚拟网络（VXLAN overlay）。

EVR - 边缘虚拟路由器，通常用于在虚拟化环境中实现路由功能。EVR 位于网络的边缘，用于连接内部网络和外部网络（如客户机房）。

现在问题来了：我们需要监控「百度网络 → EVR」这一段链路的健康度——有没有丢包、延迟多大、有没有改包。按照前几个工具的套路，我们的方案应该是：

• 在 EVR 设备上装个 agent？—— 不行。EVR 是网络设备/客户侧设备，我们没有权限往里塞监控程序。
• 在 EVR 对面（客户机房内）放一台探测机，做点到点探测？—— 更不行。那是客户的机房，正常情况我们不可能在客户的物理环境里申请一台探测机常驻。

lidar 那一套「发 SYN，靠对端内核 TCP 协议栈自动回 SYN-ACK/RST」的思路，在这里也不灵——EVR 不是一台服务器，它不会帮你跑 TCP 协议栈三次握手，或者说不允许我们高频的探测。

1
2
3
4
5
6

   百度侧                          边缘设备
┌──────────┐                  ┌──────────────────────┐
│  探测机   │ ───── ??? ─────► │   EVR 设备            │
│ (我们的)  │                  │   (装不了 agent)      │
└──────────┘                  │   对面也放不了探测机    │
                              └──────────────────────┘

困境的本质是：被探测对象不可控，且它对面也无法部署探测机。 我们需要一个 「单边」 就能完成的探测方案——只在百度侧放一台机器，让 EVR 设备自己「帮我们把包送回来」。

答案藏在 EVR 设备的工作原理里：它是一个 VXLAN VTEP（VXLAN Tunnel End Point）。而 VTEP 有一个非常好用的特性——它会忠实地按照内层 IP 头转发解封后的内层帧。这就给了我们「构造一个会被反射回来的 VXLAN 包」的可能。

要理解这个技巧，得先看懂 VXLAN 的包结构。

阅读全文

5000 包/秒高频探测 + 无需时钟同步的单向丢包检测 + 全路径覆盖。内部跑了多年，现在开源了。

先讲一个实际case。

线上服务突然超时，用户投诉电话打爆了。打开监控大盘，一切正常——没有任何告警。折腾两小时，最后发现是某条链路间歇性轻微丢包，丢包率 0.3‰，传统监控压根抓不到。

百度内部，baize 跑了多年：

• 集群间高频探测：机房内跨集群链路fullmesh监控
• 机房间fullmesh探测：机房间,LCC机房链路fullmesh监控()
• 混合云高频探测：A区和C区之间的混合云链路监控，5000 pps，秒级发现异常
• 专线 SLA 监控：运营商专线质量持续监测，为 SLA 考核提供数据支撑
• 网络改造保障：设备割接、链路升级期间持续监控，改造前后对比一目了然
• 故障回切验证：从灾备切回主链路后，确认回切路径无丢包、无 bitflip后再切流

06 开源与社区

baize 是百度 nettools 工具集的第二个开源工具，MIT 协议。

• GitHub: https://github.com/baidu/nettools
• 使用指南：https://nettools.rpcx.io/baize.html
• 语言：Go 1.26+
• 平台：Linux / macOS，AMD64 / ARM64

内部版还支持从数据库拉配置、推数据到 Kafka 聚合，开源版做了简化，但留了可插拔的 Sender 接口——你可以自己实现，把数据发到 ClickHouse、Prometheus 或者任意后端。

网络监控这件事，不是能不能做的问题，是做得够不够细的问题。

每一条链路、每一个端口、每一个比特，都值得被监控。 这是我们在百度内部坚持的标准，今天开源出来，希望对你有用。

被间歇性轻微丢包折磨过的话，去 GitHub 点个 Star，试试 baize。

目前顶尖的云服务商都包含百万台服务器、数十甚至上百个机房、上万台网络设备、百万级网络链路。单单一个GPU集群，就有上万卡的级别。对这些网络和服务器的监控，一个分钟级别的故障，可能就是上百万资产的损失。

这不是一个ping能解决的问题。

今天，我们将百度物理网络黑盒监控方向的工具集 nettools 开源了（https://github.com/baidu/nettools），第一批放出的是 bitflip 和 bitflip6，用于检测网络丢包和比特翻转，在百度内部跑了很长时间了。

阅读全文

上一个工具 bitflip/baize 解决的是丢包和改包持续检测，在百度baize常常用在点到点之间的常态检测中，比如机房内集群间的监控，专线的检测, 新网络方案测试和灰度观察、核心网络设备的切回前检测等场景。

今天介绍的lidar工具，区别于传统的pingmesh探测方案，是我来百度后创造的第一个特殊的底层网络方案，我将其称之为lidar(激光扫描)方案，是一个很形象的比喻，我会话专门一节详细介绍它的优缺点，在这之前，我们介绍传统的赫赫有名的机房大规模的网络监控方案 pingmesh。

https://nettools.rpcx.io

pingmesh 探测以及为什么我们不用它？

PingMesh（"Pingmesh: A Large-Scale System for Data Center Network Latency Measurement and Analysis"）是微软在SIGCOMM 2015上发表的论文。作者团队来自微软研究院和Azure网络部门。

阅读全文

Go 网络编程，大家第一反应就是 gopacket。但如果你用过 Scapy，你会发现 gopacket 的 API 繁琐得让人抓狂。goscapy 把 Scapy 的优雅搬到了 Go 里——流式构建、自动校验和、协议自动推断、一行代码搞定数据包，还能嗅探、发送、收响应。

最早接触到python生态圈的scapy是两年前，在和交换机的同学搞交换机探针的时候，他写了几行python代码就实现了一个发包探测程序，我立马就被scapy吸引了，居然写网络测试程序可以这么简单？

03 数据包解析：自动协议推断

构造包只是故事的一半，解析包是另一半。

goscapy 的 Dissect 能从原始字节自动推断出完整的协议栈：

1
2
3
4
5
6
7

raw := []byte{0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xaa, 0xbb, ...}
pkt, _ := packet.DissectByProto(raw, "Ethernet")
fmt.Println(pkt.String()) // "Ethernet / IP / ICMP"

// 访问具体层
ipLayer := pkt.GetLayer("IP")
srcIP, _ := ipLayer.Get("src") // net.IP{192, 168, 1, 1}

解析引擎靠注册表驱动。每一层解析完后，查 keyField 找到下一层——Ethernet 看看 type 字段（0x0800 → IP），IP 看看 proto 字段（6 → TCP），TCP 看看 dport（80 → HTTP）。VXLAN 这种隧道协议还能递归解析内层包，最多支持 8 层嵌套。

启发式规则也注册了一大堆：UDP 53 端口 → DNS，TCP 80 → HTTP，UDP 4789 → VXLAN，IP proto 47 → GRE……抓到的包基本都能自动识别到应用层。

04 嗅探和收发包：Scapy 的 sr/srp 到 Go

写过 Scapy 的人一定对 sr() 和 sr1() 不陌生——发一个包，自动等响应，还能做协议级匹配。goscapy 把这套逻辑完整搬过来了。

发包

1
2
3
4
5
6
7
8
9

// 构造结构化的 Packet 对象（不是 Build 出 []byte）
pkt := goscapy.NewEthernet().
    DstMAC("ff:ff:ff:ff:ff:ff").
    Over(goscapy.NewIP().SrcIP("192.168.1.1").DstIP("8.8.8.8")).
    Over(goscapy.NewICMP().Type(8).Code(0)).
    Packet()

sendrecv.Send(pkt, "eth0")   // L3 发送（IP 层，OS 补 Ethernet）
sendrecv.Sendp(pkt, "eth0")  // L2 发送（完整以太网帧）

发包收响应

1
2
3
4
5
6

// 类似 Scapy 的 sr1()：发 ICMP Echo，等第一个响应
sent, reply, err := sendrecv.Sr1(pkt, "eth0", 3*time.Second, nil)
if reply != nil {
    ipLayer := reply.GetLayer("IP")
    srcIP, _ := ipLayer.Get("src") // 8.8.8.8 的回复
}

DefaultMatch 自动匹配响应包——ICMP Echo Request 配 Echo Reply（ID 匹配），TCP SYN 配 SYN-ACK（端口翻转 + ack = seq+1），UDP 配端口翻转，DNS 匹 transaction ID，ARP 配 IP 交换。不用写一行匹配逻辑。

gopacket 更适合：需要解析冷门协议、对 pcap 文件读写有强需求、已经重度依赖 libpcap 生态的项目。

goscapy 更适合：网络工具开发、安全扫描、协议测试、网络监控探测——任何需要快速构造和收发数据包的场景。纯 Go 部署简单，API 用起来舒服。

10 性能：零拷贝序列化

goscapy 在序列化上做了不少优化：

• SerializeInto：直接写入目标 buffer，无额外堆分配
• BuildInto：用户提供 buffer，整个包一次序列化完成
• RecvInto：收包直接读入用户 buffer，减少一次拷贝
• 校验和零拷贝：checksumIPv4Pseudo 直接折叠多个内存区域，不拼接
• WireSize：预计算序列化大小，一次分配精确大小的 buffer

1
2
3

// 零拷贝发送
buf := make([]byte, 1500) // MTU 大小的 buffer
result, err := pkt.BuildInto(buf) // 直接写入，无额外分配

还有 Linux 特有的高性能接收模式——AF_PACKET mmap、零拷贝 (PACKET_QDISC_BYPASS)、io_uring 原始套接字——适合高频探测场景。这些在 examples 目录里有完整示例（23-packet-mmap、21-zerocopy、22-uring-raw-socket）。

11 丰富的示例库

goscapy 自带了 50+ 个示例，覆盖从基础到高级的几乎所有场景：

• 基础：ping、traceroute、TCP SYN 扫描、ARP 扫描
• 协议：DNS 客户端、DHCP 客户端、NTP 客户端
• 隧道：VXLAN 封装、GRE 隧道、ERSPAN
• 高级：PCAP 读写、TCP 流重组、BPF 过滤
• 性能：零拷贝收包、io_uring、packet mmap、批量发送
• 无线：802.11 WiFi 帧、蓝牙 HCI/L2CAP、Zigbee、LoRaWAN
• 安全：p0f 指纹、端口扫描、ARP 扫描

每个示例都是可编译运行的小程序，直接 go run 就能跑。

项目地址：github.com/smallnest/goscapy

纯 Go，MIT 协议，零 C 依赖。go get github.com/smallnest/goscapy 就能用。

如果你在做网络工具、安全扫描、协议测试、监控探测——试试 goscapy，可能会让你重新爱上 Go 网络编程。