真实网络延迟应测tcp三次握手而非icmp，go中用net.dialtimeout可测dns+tcp建连耗时，需预解析dns、禁用连接复用；http测全链路延迟需配置http.client超时及transport参数并禁用连接池。
用 net.DialTimeout 测单次 TCP 连接延迟
真实网络延迟不能只看 ICMP（ping），很多服务走的是 TCP，比如 API、数据库、Redis。Golang 里最直接的方式是用 net.DialTimeout 模拟一次连接建立过程，它返回的误差通常在毫秒级，足够做基准参考。
注意：这不是“发包测 RTT”，而是测三次握手完成时间 —— 更贴近实际业务建连开销。
-
net.DialTimeout的超时参数不是“最多等这么久”，而是“整个拨号过程（DNS 解析 + TCP 握手）必须在该时间内完成”，设太短会误判为失败 - DNS 解析耗时也计入其中，如需排除 DNS 影响，应先用
net.LookupIP预解析，再传 IP 地址给net.DialTimeout - 避免复用
net.Conn：每次测试都新建连接，否则测的是复用连接的写入延迟，不是建连延迟
conn, err := net.DialTimeout("tcp", "example.com:443", 2*time.Second)
if err != nil {
log.Printf("connect failed: %v", err)
return
}
_ = conn.Close() // 立即关闭，不发送任何应用层数据
用 http.Client + Timeout 测 HTTP 请求端到端延迟
多数后端服务暴露的是 HTTP 接口，这时候需要测完整请求链路：DNS → TCP → TLS → HTTP request/response。Golang 的 http.Client 默认不带全局超时，必须显式配置 Timeout 或更细粒度的 Transport 设置。
- 直接设
Client.Timeout是最简方式，但它会中断整个流程（包括读响应体），适合测“首字节到达时间” - 若想单独控制连接建立时间，应配置
http.Transport的DialContext和TLSHandshakeTimeout，否则 TLS 握手慢会被算进连接超时里 - 务必禁用连接池复用（
Transport.MaxIdleConnsPerHost = 1），否则第二次请求可能复用连接，测出来是 0ms
client := &http.Client{
Timeout: 5 * time.Second,
Transport: &http.Transport{
MaxIdleConnsPerHost: 1,
TLSHandshakeTimeout: 3 * time.Second,
},
}
resp, err := client.Get("https://api.example.com/health")
批量并发测延迟时，小心 time.Now() 和 GC 干扰
跑 1000 次并发延迟采样时，容易得到一堆 0ms 或负值，常见原因不是网络快，而是测量方式有问题。
立即学习“go语言免费学习笔记（深入）”；
- 不要在 goroutine 启动前或启动后才调
time.Now()：goroutine 调度延迟可能达数十微秒，必须在实际 I/O 操作前后打点 - 避免在循环中频繁分配
time.Time或结构体；用预分配切片存结果，减少 GC 压力对延迟分布的干扰 - 高并发下系统时钟可能被调整（NTP step），建议用
time.Now().UnixNano()而非time.Since()做差值，后者依赖单调时钟但某些容器环境不保证
Linux 下绕过 Go runtime 的 syscall 开销：用 socket + connect 系统调用直测
当需要亚毫秒级精度（比如测内网 RDMA 或低延迟金融链路），Go 标准库的封装会引入不可忽略的开销（约 10–50μs）。这时可借助 golang.org/x/sys/unix 直接调系统调用。
- 用
unix.Socket创建 socket，unix.Connect发起连接，unix.Close关闭 —— 整个路径无 Go runtime netpoll 参与 - 必须手动处理地址族（IPv4/IPv6）、套接字类型，且不自动重试，错误码需查
errno - 这种方式无法测 TLS 或 HTTP，仅适用于纯 TCP 连通性与握手延迟基线定位
这种测法已经接近 ping -c1 或 tcpping 的精度，但代价是失去跨平台性和易维护性 —— 仅建议在关键链路压测或性能归因时使用。
