net.dialtimeout测的是tcp连接建立耗时，非rtt；真测ping需用icmp，linux需cap_net_raw权限，macos需sudo或udp替代，容器需--cap-add=net_raw，且id/seq/校验和须合规。
用 net.DialTimeout 测延迟，但不准？
直接拿 net.DialTimeout 当 ping 用，结果经常超时或返回 0ms —— 它测的是 TCP 连接建立耗时，不是网络往返延迟（RTT），更不反映丢包或中间链路抖动。真要模拟 ping 行为，得自己发 ICMP 包。
- Go 标准库不支持 ICMP（
syscall.IP_PROTO_ICMP在 Windows/macOS 上受限，Linux 需 root） -
golang.org/x/net/icmp是官方推荐替代，但必须用 raw socket，非 root 用户在 Linux 下会报operation not permitted - 如果只是探测服务端口连通性，
net.DialTimeout没问题；但想看“像 ping 一样”的毫秒级 RTT，它本质就不对路
Linux 下无 root 权限跑 ICMP 探测？用 cap_net_raw
硬加 root 太重，也不安全。实际部署中更常用的是给二进制文件授权：
- 编译完工具后执行：
sudo setcap cap_net_raw+ep ./latency-probe - 之后普通用户就能发 ICMP 包，且无需 sudo 启动
- 注意：Docker 容器默认 drop 了
NET_RAWcapability，得显式加回来：docker run --cap-add=NET_RAW ... - macOS 不支持
setcap，只能走sudo或改用 UDP 探测（如向8.8.8.8:53发 DNS 查询，再算time.Since()）
golang.org/x/net/icmp 构造 echo request 的关键点
不是调个函数就完事，ICMP 报文结构、校验和、ID/Seq 管理都得自己操心，漏一步就收不到 reply：
- ID 字段建议用当前进程 PID（
os.Getpid()），避免多实例冲突 - Seq 字段必须递增，否则收到 reply 时无法匹配请求（尤其是并发探测多个目标时）
- 校验和必须按 RFC 792 计算：先置 0，再对整个 ICMP header + payload 做 16-bit one's complement sum
- 别忘了设置 socket 的
ReadDeadline，否则conn.ReadFrom()可能永久阻塞
msg := icmp.Message{
Type: ipv4.ICMPTypeEcho, // 注意是 ipv4，不是 icmpv4
Code: 0,
Body: &icmp.Echo{
ID: os.Getpid() & 0xffff,
Seq: atomic.AddUint16(&seq, 1),
Data: make([]byte, 32),
},
}
容器内探测宿主机或其它 Pod，延迟值为什么虚高？
不是代码写错了，而是网络栈路径变了：从容器发出的 ICMP 包，要经过 CNI 插件（如 Calico、Cilium）的 iptables 规则、veth pair、网桥、甚至 eBPF hook，每一层都加开销。
立即学习“go语言免费学习笔记（深入）”；
- 实测常见 CNI 下，同节点 Pod → 宿主机的 ICMP RTT 比物理机直连高 0.2–0.8ms
- 跨节点时，额外增加 VXLAN 封装/解封装、底层物理网络跳数，RTT 波动更大
- 若用
hostNetwork: true模式运行探测工具，可绕过 CNI，拿到更接近真实链路的数值，但失去网络隔离 - 真正要定位瓶颈，得配合
tcpdump -i any icmp在宿主机抓包，看 delay 是卡在入口、转发还是出口
ICMP 的 ID/Seq 匹配、capability 授权、容器网络栈透传——这三个地方没对齐，测出来的数字就只是“看起来像延迟”，不是实际可用的观测依据。
