Linux下应调用系统ping命令解析统计行获取丢包率和延迟：用-c限制次数、-W设置超时，正则匹配“(d+)% packet loss”和“rtt.*/(d+.d+)/”提取；Windows需处理GBK编码或强制UTF-8，避免原始套接字。
Linux下用ping解析输出获取丢包率和延迟
标准C++不提供直接读取网络QoS指标的API，必须依赖系统工具。Linux最可靠的方式是调用ping并解析其统计行——它稳定、无需root、且结果与netstat或ss互补（后者不暴露丢包率）。
关键不是执行ping，而是让它输出可解析的格式：ping -c 4 -W 2 google.com会返回类似：
--- google.com ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 12.3/14.7/16.8/1.8 ms
注意两点：必须加-c限制次数，否则阻塞；-W设超时（非-w，后者是总耗时上限，易误判）。
解析建议用std::regex匹配两行：
立即学习“C++免费学习笔记（深入）”；
- 丢包率：匹配
(\d+)% packet loss，提取第一个整数 - 平均延迟：匹配
rtt min/avg/max/mdev = [^=]+/([^/]+)/，提取第二个浮点数
别用std::string::find硬切——不同locale下空格数可能变，正则更鲁棒。
Windows需用ping并处理中文/编码问题
Windows的ping输出默认是GBK编码（尤其在中文系统），而C++std::system或_popen读取的是原始字节流。直接std::string构造会导致乱码，进而regex匹配失败。
解决方法只有两个：
- 强制cmd用UTF-8：
chcp 65001 >nul && ping -n 4 -w 2000 google.com（chcp必须前置，且要捕获完整输出流） - 或用
MultiByteToWideChar(CP_ACP, ...)转宽字符再搜索——但得链接user32.lib，增加构建复杂度
别信“设置控制台代码页”这种方案——子进程继承父进程代码页不可靠，尤其IDE调试时行为不一致。
延迟单位仍是ms，但Windows输出格式略有不同：最短 = 12ms，最长 = 16ms，平均 = 14ms。regex要适配中文关键词，或统一用英文locale启动cmd：set LANG=C && ping -n 4 google.com。
避免用ICMP原始套接字自己发包
有人想用socket(AF_INET, SOCK_RAW, IPPROTO_ICMP)手动构造ping包——这在Linux需root，在Windows Vista后默认禁用（需管理员权限+调整SeLoadDriverPrivilege），且跨平台维护成本极高。
真实场景中，以下问题会让自实现失效：
- 防火墙/云主机常屏蔽ICMP入向响应，导致
recvfrom永远阻塞 - Linux的
icmp_echo_ignore_all内核参数可能关闭响应 - 容器环境（Docker/Podman）默认禁用RAW socket，报错
Operation not permitted
除非你明确控制全链路网络策略（比如嵌入式设备调试），否则没必要碰原始套接字。用系统ping是经过三十年验证的兼容方案。
丢包率≠网络质量，延迟值要注意采样偏差
ping统计的丢包率只是ICMP层的瞬时快照，不能等同于TCP实际业务丢包（例如HTTP请求失败）。很多CDN或负载均衡器会限速ICMP响应，导致显示100%丢包但网页完全正常。
延迟值同样有陷阱：
- 单次
ping -c 4样本太少，建议至少10次，剔除最大最小值后取中位数 - 不要用
std::chrono::steady_clock自己测往返——用户态时间戳无法扣除内核协议栈排队延迟，误差常达毫秒级 - 如果目标域名DNS不稳定，
ping前的解析耗时会被计入首跳延迟，应单独用getaddrinfo预热DNS缓存
真正影响用户体验的是应用层RTT（如HTTP GET耗时），ICMP延迟只适合做粗略基线对比。拿它直接告警或降级决策，容易误伤。
