go长连接中网卡丢包不触发应用层重传，因tcp协议栈已接管；需关注重传引发的延迟毛刺、连接雪崩或指标失真。tcpdump抓不到重传包是因重传常发生在内核发送队列中，未抵达网卡或被gso/gro篡改，应使用-i any -s抓全接口并禁用offload，配合ss -i和getsockopt(tcp_info)获取真实重传次数tcpi_total_retrans，注意仅对已建连调用且避免高频轮询。
Go长连接中网卡丢包本身不会触发应用层重传——TCP协议栈已接管重传，Go标准库的net.Conn对上层完全透明；真正需要你干预的，是重传引发的延迟毛刺、连接雪崩或指标失真。
为什么tcpdump抓不到重传包？
因为内核 TCP 栈的重传行为常发生在发送队列中，重传包可能根本没走到网卡（比如被tcp_retries2限制住），或被 GSO/GRO 合并后头部失真。直接tcpdump -i eth0会漏掉关键帧。
- 用
tcpdump -i any port <port> -w trace.pcap -S</port>：-S确保显示绝对序列号，否则相对序号在重传分析中无意义 - 配合
ss -i dst <ip>:<port></port></ip>查看连接当前retrans计数器，确认内核是否已记录重传事件 - 禁用网卡 offload：
ethtool -K eth0 gso off tso off gro off，防止硬件篡改 TCP 头部导致序列号/ACK错乱
如何从Go代码里拿到真实重传次数？
net.Conn不暴露底层状态，但 Linux 的getsockopt(TCP_INFO)可读取tcpi_total_retrans字段——这才是内核统计的累计重传量。
- 必须对已建立的连接调用，例如在
http.HandlerFunc中通过req.Context().Value(http.LocalAddrContextKey)获取net.Conn，再转换为syscall.Conn - 错误
EINVAL通常意味着连接尚未完成三次握手，或 socket 类型不是AF_INET/SOCK_STREAM - 优先用
unix.TCPInfo而非手写 struct，避免不同内核版本字段偏移差异 - 不要高频轮询：
tcpi_total_retrans是单调递增计数器，两次采样差值才是本次区间重传量
HTTP长连接下重传如何影响RTT估算？
Go 的http.Transport复用连接，而内核的 RTT 估算是 per-connection 的。一次重传会拉高平滑 RTT（SRTT）值，后续请求的超时判断、连接健康度评估都会被带偏。
- 避免用
http.DefaultClient：它共享 Transport，多个 goroutine 的重传历史会互相污染 - 在
RoundTrip前后用ss -i sport=<port></port>快照比对retrans字段，定位哪次请求触发了重传 - 在
Transport.DialContext回调中，net.Dial返回后立即抓一次TCP_INFO作为 baseline，后续只关注增量 - 一次重传平均增加 ~200ms 延迟（按默认 rtt=50ms + 指数退避），连续 3 次可能触发连接中断
什么情况下重传不是丢包引起的？
常见但易被忽略：接收方因处理能力不足，主动丢弃已接收的数据包（如内核tcp_rcv_space_failed计数上升），导致 ACK 不发出，发送方误判为丢包而重传。
- 检查性能监视器日志中的
Packet Received Discarded计数器，识别非必要重传 - 用
ctsTraffic分析网络跟踪，过滤相同序列号的重复包，区分是原始包丢失还是 ACK 丢失 - 服务端缓冲区溢出（如弹幕系统中
SO_RCVBUF默认仅几十 KB）是高频诱因，需结合netstat -s | grep -i "packet received"确认
重传机制本身没问题，问题在于你是否知道它什么时候悄悄改写了你的延迟分布、连接生命周期和监控曲线——尤其是当tcpi_total_retrans在增长，而你的 Prometheus 里却没有任何告警时。
