这个命令是干啥的
ping 大概是每个接触Linux的人第一个学的网络命令。它的原理很简单：发一个ICMP（Internet Control Message Protocol）的echo请求包给目标，对方回复echo回复包。通过这个来回，你能知道目标在不在线、网络延迟有多高、有没有丢包。
但"ping不通"不等于"网络不通"。我见过太多人一ping不通就下结论说网络有问题，结果排查一圈发现是防火墙禁ping了，或者目标机器只允许特定协议。我自己刚开始也犯过这种错。
基本用法（3分钟上手）
最简单的用法：
# 持续ping一个地址，按Ctrl+C退出
ping baidu.com
但生产环境一般不会这么用，因为默认会一直ping下去。最常用的参数：
# 发送4次就停，适合快速检查
ping -c 4 baidu.com
# 指定间隔时间（默认1秒），调高频率测延迟
ping -c 10 -i 0.5 baidu.com
# 看IP地址（不加-c默认一直ping）
ping -c 2 114.114.114.114
输出说明：
PING baidu.com (39.156.66.10) 56(84) bytes of data.
64 bytes from 39.156.66.10: icmp_seq=1 ttl=49 time=8.34 ms
64 bytes from 39.156.66.10: icmp_seq=2 ttl=49 time=8.12 ms
--- baidu.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 8.12/8.23/8.34/0.110 ms
重点看几个信息：
- time：往返延迟，单位毫秒。8ms说明网络状况很好
- packet loss：丢包率。超过1%就要关注了
- ttl：生存时间，每经过一个路由器减1。可以用来大概判断跳数
进阶骚操作
指定包大小测网络质量
# 发送更大的数据包，测试网络在较大数据量下的表现
ping -c 5 -s 1472 baidu.com
默认是56字节（加上ICMP头28字节，总共84字节）。-s 1472 是MTU 1500减去IP+ICMP头的28字节，刚好是网络层能发的最大数据。如果大包ping不通但小包通，很可能是MTU问题。
ping延迟波动分析
看延迟比看丢包更有价值。我一般怎么分析：
# 连续ping 100次，测网络抖动
ping -c 100 -i 0.2 baidu.com
看输出最后的统计：
rtt min/avg/max/mdev = 8.12/12.45/120.34/15.23 ms
- ·min/avg/max：最小/平均/最大延迟
- ·mdev：平均偏差，衡量延迟稳定性的关键指标
如果mdev超过10ms，说明网络抖动严重。我遇到过几次mdev到50ms以上的情况，查出来是某个路由器端口有错包重传。mdev值突然飙升，基本等于告诉你"网络不太稳"。
ping不通时的排查流程
我自己总结的排查思路：
1. 先ping 127.0.0.1 -> 看本机网络协议栈是否正常
2. 再ping本机IP -> 看网卡和IP配置是否正常
3. 再ping网关 -> 看是否出得了局域网
4. 再ping外网（8.8.8.8或114.114.114.114）-> 看是否能访问外网
5. 最后ping域名（baidu.com）-> 看DNS解析是否正常
每个阶段都能定位具体的问题范围。
限制ping的次数和超时（适合脚本）
# 脚本里常用的写法：-W 设置超时秒数，-c 设置次数
if ping -c 3 -W 2 10.0.0.1 > /dev/null 2>&1; then
echo "主机在线"
else
echo "主机不在线"
fi
-W 2 表示每个包最多等2秒，总共3次，最多6秒出结果。不加这个参数，默认可能等十几秒。
结合泛洪模式（千万别乱用）
# 不要在生产环境用，会打爆网络
ping -f localhost
-f 泛洪模式，发得越快越好。我一般只在测试交换机性能的时候在内网用。
避坑指南
坑1：ICMP被禁了，ping不通但服务正常
这是我遇到最多的情况。越来越多的云厂商和安全策略禁掉了ICMP。比如阿里云默认的安全组规则是不允许ICMP入站的。这时候ping不通，但不代表HTTP、SSH等服务有问题。
正确的做法是用其他方式检测：
# 用telnet测端口
telnet 10.0.0.1 22
# 用nc
nc -zv 10.0.0.1 22
# 用curl
curl -I http://10.0.0.1
坑2：ping通但有延迟不代表业务正常
ping通只能说明网络层（第三层）可达，但应用层（第七层）可能已经挂了。有个经典案例：服务器ping很稳，1ms延迟，但web服务因为连接数满了，新请求进不去。这时候ping是看不出来的。
坑3：ping域名和ping IP结果不一样
如果ping域名通但ping IP不通（或者反过来），问题可能出在DNS或者路由表上。
有次我排查了一个问题：ping baidu.com 超时，但 ping 39.156.66.10 正常。最后发现是 /etc/resolv.conf 里的DNS配置不对。
坑4：大包ping不通小包通
这通常是MTU问题。比如你的应用用了VPN隧道，隧道封装后增加了包头，导致原始MTU变小。解决方法是在网卡上设正确的MTU值或者在应用层做TCP MSS clamping。
# 检查当前MTU
ip link show eth0 | grep mtu
# 设置MTU（临时）
sudo ip link set dev eth0 mtu 1400
坑5：ping命令可能需要root
有些系统上用普通用户执行ping，可能会报 Operation not permitted。这是因为ICMP原始套接字需要root权限。新系统会在安装时给ping二进制加SUID位。
实战场景（重点！结合真实运维场景）
场景1：线上业务延迟排查
有次业务反馈接口响应慢，我怀疑是网络问题。先用ping看看：
# 先ping内部网关，看内部延迟
ping -c 50 -i 0.1 10.0.0.1
# 再ping外部API服务器
ping -c 50 -i 0.1 api.example.com
发现内部网关延迟只有0.5ms，但到API服务器的延迟从平时的10ms涨到了80ms，而且mdev有30ms。确认网络是瓶颈后，找网络团队排查，发现是某个中间节点的出口带宽被打满了。
场景2：写监控脚本替代简单ping检测
因为很多服务器禁ping，我会用tcp ping（其实就是检查端口）：
#!/bin/bash
# 用nc检查端口是否可达（代替ping）
HOST="10.0.0.1"
PORT=80
nc -zv -w 3 $HOST $PORT > /dev/null 2>&1
if [ $? -eq 0 ]; then
echo "$(date): $HOST:$PORT 可达"
else
echo "$(date): $HOST:$PORT 不可达！"
fi
场景3：mtr代替ping做更精准的链路分析
mtr 结合了traceroute和ping，能告诉你每一跳的延迟和丢包率。
# 实时查看每一跳的网络质量
mtr baidu.com
# 只跑10次就出结果，适合脚本
mtr -r -c 10 baidu.com
输出能看到哪一跳延迟高、哪一跳丢包。有次发现第5跳延迟突增，联系服务商后确认为那个中转节点的设备故障。
安装方式：
# Ubuntu/Debian
apt install mtr-tiny
# CentOS/RHEL
yum install mtr
场景4：写一个批量网络巡检脚本
我每周会跑一遍巡检脚本，检查几十台服务器的网络质量：
#!/bin/bash
# 定义一个数组，里面是要检查的服务器列表
SERVERS=("10.0.0.1" "10.0.0.2" "10.0.0.3" "api.example.com")
for server in "${SERVERS[@]}"; do
echo "=== 检查 $server ==="
# 发3个包看延迟和丢包
ping -c 3 -W 2 $server > /dev/null 2>&1
if [ $? -eq 0 ]; then
# 提取平均延迟
avg=$(ping -c 5 $server 2>&1 | tail -1 | awk -F '/' '{print $5}')
echo "✅ $server 可达，平均延迟: ${avg}ms"
else
echo "❌ $server 不可达"
fi
echo ""
done
今日作业
你的线上服务A（IP: 10.0.0.10）需要访问服务B（IP: 10.0.0.20）的8080端口提供服务，但最近用户反馈响应变慢。
1. 请设计一个排查流程：如何用ping判断是网络问题还是服务端问题？
2. 用ping命令判断网络是否抖动，应该看哪个指标？
3. 如果ping -c 4 10.0.0.20 全部丢包（100% loss），但服务却能正常访问（curl 10.0.0.20:8080 正常返回200），可能是什么原因？怎么处理？
4. 写一个脚本来检查10.0.0.20这台机器的网络延迟是否正常（阈值：延迟 > 50ms 或 丢包 > 5% 就算异常）。
10个月宝宝每天需要喝多少奶粉？
