PSPing实战：用ICMP/TCP/UDP快速定位网络延迟与丢包

凌晨两点被电话叫起来处理“系统卡顿”多数人的第一反应是打开浏览器翻监控面板我的习惯是先敲一行命令。命令行里那把小刀就是PSPing——一个不到 1MB 的单文件可执行程序丢进自己的工具目录、加进 PATH 就能用不装服务、不写注册表、不动系统配置。它是 Windows 平台上少见的能把ICMP、TCP、UDP三种探测方式捏在一个工具里做完的网络诊断程序顺带还能做一个粗糙的 TCP 带宽测试甚至能把自己变成一个监听端。对做网络排障、后端联调、桌面运维的人来说这东西的价值不在于功能多花哨而在于“当场就能给出一个可量化的延迟和丢包数字”而不是靠用户说“感觉有点慢”。这篇内容我会把 PSPing 的四类模式、参数背后的取舍逻辑、实测命令和踩过的坑一次性讲透既适合刚接触命令行网络工具的新手照着抄也适合干了几年、想把手感变成数据的老手对照检查。1. 排障思路拆解为什么是它而不是 ping 和 telnet1.1 传统三件套的三个硬伤在 Windows 上做连通性判断大部分人的工具箱里只有三样东西ping、telnet、tracert。这三样各有明显短板而短板恰好都出现在最需要判断的时刻。ping的问题是它只能走 ICMP。现在大量主机和中间设备对 ICMP 做了限速甚至直接丢弃于是你会看到“ping 不通但业务正常”的诡异局面。更要命的是ping没法验证某个端口是否可达——业务跑在 443 上ICMP 通不通跟 443 能不能握手是两件事。telnet的问题在另一头它只能告诉你“端口开着”或者“连不上”没有延迟、没有丢包率、没有多次采样的极值。TCP 握手慢了 800 毫秒telnet 只会安静地卡一下然后给你一个黑屏你根本不知道这一下卡了多久。tracert只能看路径而且依赖 ICMP 的 TTL 超时报文遇到不回 ICMP 的节点就是一串星号。三件套凑在一起能回答的是“通不通”回答不了“有多慢、慢在哪、稳不稳”。1.2 PSPing 的四种工作模式与能力边界PSPing 把上面这些缺口用四种模式补齐了我按使用频率排一下模式触发方式测的是什么典型用途前提条件ICMP 探测直接跟主机网络层往返时延、丢包判断链路质量、基准延迟对端或中间设备不拦 ICMPTCP 握手主机:端口三次握手完成耗时、端口可达性端口探活、应用层延迟粗测端口处于监听或被明确拒绝UDP 回声-u 主机:端口UDP 路径时延、丢包无 ICMP 环境、UDP 业务联调对端回 ICMP 端口不可达或跑监听端带宽粗测-bTCP 单向吞吐快速判断“是不是带宽打满了”两端可控最好一端跑监听模式这张表里没有写“替代专业压测工具”因为 PSPing 的带宽测试精度有限它是用来做“五分钟内判断量级”的不是用来出验收报告的。理解这一点很重要很多人拿-b的结果去和专线带宽对账然后质疑工具不准其实是用法错位。1.3 选型对比什么场景该换工具我不是逢事必用 PSPing。判断标准很简单需要时序细节就上抓包需要长期趋势就上监控系统需要精确吞吐就上专业压测工具。PSPing 卡在中间那一层——现场、快速、可量化。要看丢包发生在哪一跳tracert或pathping更合适PSPing 只给端到端结果。要看 TCP 重传、窗口、握手细节得上抓包分析PSPing 只给一个总耗时。要连续监测一周写成脚本定时跑、把结果落库比人工敲命令靠谱。要判断“这个 80 毫秒是正常的还是异常的”先在同一网段找一台机器做基线对比PSPing 的绝对值本身没有意义相对值才有。1.4 适用边界什么时候结论会骗人有三类情况我踩过坑必须提前说清楚。第一类是多 IP 目标。一个域名解析出多个地址或者前面有负载均衡你每次测的可能不是同一台机器延迟忽高忽低未必是网络抖动。解决办法是测之前先解析出 IP直接用 IP 测。第二类是中间设备限速。ICMP 在很多设备上被降优先级处理你看到的 200 毫秒可能只是设备对 ICMP 的限速值真实业务流量走的是另一个队列。这种情况下 TCP 握手耗时更可信因为它走的是正常转发路径。第三类是首包偏差。刚开机或刚插网线时第一两个包要等 ARP 解析、路由表收敛延迟会明显偏高。PSPing 提供了预热参数就是干这个用的后面会细说。忽略预热你会得到一条“最大延迟 400 毫秒”的假结论然后白折腾半天。2. 环境准备与参数体系把每个开关的意图搞明白2.1 落地部署单文件、免安装、注意位数拿到手的通常是一个压缩包解开后里面是 32 位和 64 位两个可执行文件。现在的服务器基本都是 64 位系统直接选带 64 字样的那个。我习惯把它重命名成短名字丢进C:\Tools然后把这个目录加进系统 PATH这样任何终端里敲psping都能直接调起来。第一次运行有个小细节这类工具通常会弹一次使用条款确认需要加一个接受条款的参数才能跳过交互否则在自动化脚本里会卡住等输入。我的做法是第一次手动跑一次带该参数的命令之后就一直正常了。# 把工具目录加入当前会话 PATH临时生效 set PATH%PATH%;C:\Tools # 验证可用性 psping -?注意不要把它塞进系统目录也不要覆盖系统自带的网络命令。工具类程序统一放一个自建目录出问题好回滚换机器也好迁移。2.2 参数地图常用开关的用途与坑PSPing 的参数不多但有几个组合起来会产生完全不同的含义必须逐个理解。参数含义默认值常见误用-n探测次数4次数太少丢包率没有统计意义-i两次探测的间隔秒1想快速采样却不知道可以调小-w预热次数不计入统计0不预热首包异常拉高最大值-l请求数据长度字节与模式相关以为 TCP 模式下它会影响握手耗时-q安静模式只输出统计关闭日志里全是明细看不下去-h输出延迟直方图关闭只看平均值漏掉长尾-t持续探测直到手动停止关闭忘了停挂一晚上-u使用 UDP 模式ICMP/TCP对端没开端口又不回 ICMP全丢-4/-6强制 IPv4 / IPv6自动双栈环境测错协议族-b带宽测试关闭拿它当验收工具-s监听模式把自己变成服务端关闭防火墙没放行对端一直超时这里有两个最容易被忽略的点。第一个是-l在不同模式下语义完全不同走 TCP 握手测试时握手过程本身不携带业务数据所以-l对握手耗时没有影响它只在带宽测试和 UDP 模式下改变报文大小。第二个是-w预热它的存在就是为了消化 ARP 解析和路由缓存未命中带来的首包延迟做基线测量时把它设成 2 到 3能让平均值立刻干净很多。2.3 参数怎么定采样次数与间隔的估算过程参数不能拍脑袋我这里给一套我常用的估算逻辑。先看采样次数。假设你想判断“这条链路有没有 1% 的丢包”如果只打 20 个包丢 1 个就是 5%丢 0 个就是 0%两者的真实丢包率可能是 0.2%也可能就是 5%。用二项分布的粗略估算标准误约等于sqrt(p(1-p)/n)取 p1%、n100 时标准误约 1%也就是你测出来的 1% 上下波动一个百分点都算正常。想稳定区分 1% 和 2%样本量得上千。我的经验值是判断“有没有明显丢包”用 50 次判断“丢包率大概几个点”用 300 次做正式基线留档用 1000 次以上。1000 次按默认 1 秒间隔要跑 16 分钟所以要么把间隔调小要么就在后台挂着跑。再看间隔。间隔太小会把本机网卡和协议栈的处理能力也压进结果里间隔太大又可能错过短暂的拥塞窗口。常规排障用 0.2 到 0.5 秒比较合适做长时间观测就用 1 秒。命令里的间隔参数单位是秒是否支持小数以本机帮助输出为准这一点建议先跑一次帮助确认别照着别人的博客硬抄。最后是带宽测试的报文长度。-l设得比链路 MTU 减去报文头还大就会触发分片测出来的吞吐会明显偏低因为分片重组额外消耗。以太网常见 MTU 是 1500减去 IP 头和 TCP 头各 20 字节大约是 1460所以我一般从-l 8192这种整倍数开始试如果结果异常低再往下调一批值对比看是不是分片在捣鬼。3. ICMP 模式实操把延迟和丢包测成数字3.1 基础命令与一份完整输出最朴素的用法就是跟一个地址加次数和预热psping -n 20 -w 3 192.0.2.10输出大致是这样头部版本信息略去Probing 192.0.2.10 with 32 bytes of data: Reply from 192.0.2.10: bytes32 time12.31ms TTL54 Reply from 192.0.2.10: bytes32 time11.87ms TTL54 Reply from 192.0.2.10: bytes32 time13.02ms TTL54 ... Ping statistics for 192.0.2.10: Sent 20, Received 19, Lost 1 (5% loss) Minimum 11.42ms, Maximum 31.28ms, Average 12.06ms读这份输出不要只盯 Average。平均值是给人看的真正决定用户体验的是最大值和最大最小差。上面这组数据平均值 12 毫秒看着很漂亮但最大值 31 毫秒说明有至少一个包在路径上多待了近 20 毫秒——这可能是排队也可能是链路切换。如果是语音通话或者游戏这种对抖动敏感的业务20 毫秒的抖动就是能听出来的卡顿。3.2 从极值推算抖动再让直方图说话只有平均值和极值时抖动可以粗略用(最大值 - 最小值) / 平均值这个比值来感知比值超过 0.5 就值得警惕。但这个算法只用到了两个点中间过程完全看不见。想把分布看清楚加-hpsping -n 500 -i 0.2 -h 192.0.2.10直方图会把 500 次采样的延迟分桶统计你会看到类似“绝大多数落在 10-15 毫秒有一小撮落在 30 毫秒以上”的形态。这种长尾分布是最常见的也是平均值最容易掩盖的问题——99% 的请求很顺1% 的请求慢十倍平均下来只多一点但用户就是在抱怨那 1%。我判断链路好坏的标准一直很简单看 P99不看平均值。如果直方图显示 99% 的样本集中在 10 到 15 毫秒之间只有极个别到 30 毫秒这条链路是可用的如果分布从 10 毫秒一路铺到 80 毫秒没有明显峰值说明路径上存在持续排队早晚要出事。3.3 长时间采样与结果留档做跨天观测或者要留证据给别的团队看就得把结果落成文件。# 持续探测安静模式结果写入文件 psping -t -q 192.0.2.10 d:\logs\icmp_192.0.2.10.txt 21-t会一直跑到你按 CtrlC-q只输出统计行不输出每次明细。这里有个小提醒很多终端里 CtrlC 中断时最后那行统计可能来不及落盘所以我更倾向于用固定次数-n 3600 -i 1跑满一小时自动结束文件内容完整。注意日志文件按小时切分文件名带上时间戳。我见过一次事故排查日志文件只写了目标 IP没写采集时间最后谁也不敢确认那段数据是哪天的。另一个实操心得是别在同一台机器上一边跑 PSPing 一边跑大流量下载。自己的网卡队列被占满测出来的延迟全是你自己造成的。要测链路真实水平采样机上最好没有别的业务流量。4. TCP 模式实操绕过 ICMP 限制的那条路4.1 握手耗时测试的正确姿势用法是在主机后面直接跟端口psping -n 30 -w 2 192.0.2.10:443这一条命令做了三件事向目标 443 端口发起 TCP 连接、记录从发出 SYN 到收到 SYN-ACK 的耗时、立刻断开连接然后重复 30 次。它给出的是三次握手的完成时间大致等于一个网络往返加上对端协议栈的处理时间。所以如果你同一台机器上 ICMP 测出来 12 毫秒、TCP 443 测出来 13 毫秒这是完全正常的两者本来就该接近。但如果 ICMP 12 毫秒、TCP 却要 200 毫秒那就有意思了——可能是对端 SYN 队列积压、可能是中间有设备在做连接跟踪、也可能是应用层在监听但处理不过来。这个差值本身就是一条重要线索。4.2 端口批量探活脚本怎么写才不添乱单端口测通了接下来往往要确认一批端口。PowerShell 写起来最顺手$target 192.0.2.10 $ports 22, 80, 443, 3306, 8080 foreach ($p in $ports) { $r psping -n 3 -q $target:$p 21 if ($r -match Lost 0) { Write-Output $p OPEN } elseif ($r -match 100% loss) { Write-Output $p CLOSED/FILTERED } else { Write-Output $p UNSTABLE } }传统命令行环境里也能写只是循环语法难看一点for %p in (22 80 443 3306 8080) do psping -n 3 -q 192.0.2.10:%p | findstr Lost这里必须强调一句只对自己有管理权限的机器做端口探测。批量扫别人的地址轻则被安全设备记录重则触发封禁属于典型的给自己找麻烦。测试范围严格限定在自有资产内这是底线。还有一个技术细节端口“不通”有两种情况一种是对端明确拒绝回了 RST一种是被防火墙静默丢弃什么都不回。PSPing 在两种情况下都表现为超时或高丢包光看结果分不出来需要配合抓包判断。4.3 带宽粗测两端配合才有意义-b参数会做一次 TCP 吞吐测试。它的默认对端是普通应用端口测出来的数字受对端程序影响极大所以我一般在自己可控的两台机器上做一端跑监听# A 机监听模式占住 5001 端口 psping -s 0.0.0.0:5001 # B 机发起带宽测试缓冲区 64KB psping -b -l 65536 -n 10 192.0.2.10:5001-l在这里的作用是每次读写的缓冲区大小。这个值太小系统调用次数多测出来的数字被 CPU 限制这个值太大又容易受内存拷贝影响。我的经验是从 8KB、32KB、64KB、256KB 各跑一遍取吞吐最高的那个组合说明这个尺寸下缓冲区刚好匹配链路。结果解读上要留个心眼千兆链路理论吞吐大约 118 MB/s 左右实测能到 110 就已经不错了但如果只测出 30 MB/s先别急着报故障检查一下是不是磁盘在写、是不是杀毒软件在做流量检查、是不是网卡在节能模式。这几个原因造成的“带宽不足”我遇到过的次数远多于真实链路问题。5. UDP 模式与延迟分布那些 TCP 看不到的东西5.1 UDP 回声探测的运作前提UDP 模式加-u参数psping -u -n 50 -l 512 192.0.2.10:9999它的工作方式和 ICMP 模式其实很像但走的是 UDP 报文。这里有个不太直观的地方如果目标端口没有程序监听对端协议栈通常会回一个“端口不可达”的 ICMP 消息PSPing 把这个回包当作“应答”从而算出往返时延。所以UDP 模式在没有任何服务端配合的情况下也能测这是它比 TCP 模式更适合某些场景的原因。但也正因为依赖这个机制一旦中间设备把 ICMP 全拦了UDP 模式就会显示 100% 丢包而实际上包已经送达了目标。这时候别急着下结论换 TCP 模式再测一次交叉验证。真正需要精确结果时还是两端配合一端跑监听模式另一端用-u打过去这样回包是应用层真实产生的时延里包含了完整的处理链路。5.2 报文大小与分片一个小实验UDP 模式最实用的地方是做报文尺寸对丢包影响的实验。同样是 50 次探测分别用 512 字节和 1500 字节psping -u -n 50 -l 512 192.0.2.10:9999 psping -u -n 50 -l 1500 192.0.2.10:9999如果小包几乎不丢、大包丢得厉害基本可以确定路径上某一段的 MTU 有问题或者有设备对大包做了特殊处理。这个结论用 ICMP 的ping -l也能得到但 PSPing 的好处是能直接指定端口配合 UDP 业务联调时更贴近真实场景。至于-h直方图在 UDP 模式下的用法和 ICMP 完全一样我最常用它来确认“长尾是偶发还是常态”。偶发长尾可以接受常态长尾说明链路容量已经贴着上限在跑。6. 常见问题与排查技巧实录6.1 现象与原因速查表这张表是我这几年攒下来的遇到问题先对照一遍能省掉一半的试错时间。现象最可能的原因下一步动作100% 丢包但浏览器能打开目标ICMP 被拦或端口未监听改用 TCP 模式测实际业务端口丢包率个位数但业务卡顿明显采样量不足或问题在应用层加大-n同时抓包看重传首次探测延迟特别高ARP 未解析、路由未收敛加-w 3预热再看统计延迟曲线呈阶梯状中间设备队列或限速策略分段测对比不同网段基线TCP 端口测试全部超时本机或对端防火墙拦截换端口验证检查出站规则带宽测试结果远低于链路标称分片、磁盘、安全软件检查调-l关闭无关程序复测IPv6 地址测不通未加-6或本机无 v6 路由显式指定协议族后重测脚本里命令卡住不动首次运行的条款确认交互先手动跑一次完成确认6.2 抓包交叉验证让结论闭环PSPing 给的是端到端结果抓包给的是过程证据两者结合才能定性。Windows 自带的能力就够用不必装额外软件。启动抓包、复现问题、停止抓包、导出四步搞定然后在分析工具里看 SYN 有没有重传、应答时间戳差多少。我常用的判断逻辑是这样的PSPing 显示 TCP 握手平均 200 毫秒抓包看到 SYN 发出后 180 毫秒才收到 SYN-ACK而且期间有重传那结论就是链路上有丢包导致握手重试如果抓包显示 SYN-ACK 很快就回来了但 PSPing 依然报高延迟那问题在本机——可能是网卡驱动、可能是安全软件的流量检查模块。注意抓包文件里可能包含地址和报文内容作为排查材料传递时注意范围只给需要的人。6.3 几个只有踩过才知道的细节第一个坑域名和 IP 混着测。用域名测的时候每次连接都可能解析到不同地址结果自然对不上。我的规矩是先用名字确认能解析之后所有测试统一用 IP。第二个坑以为-l能改变 TCP 握手耗时。前面说过握手不传数据-l在这个模式下没有意义。有同事为了“加大包让测试更真实”在 TCP 模式里把-l调到 60000然后疑惑为什么结果一点没变——因为根本没用到。第三个坑忘了-q。一次跑 1000 次探测明细刷满屏幕终端缓冲区直接滚丢前面的内容回头看日志发现只剩最后几十行。长跑一律加-q输出重定向到文件。第四个坑在虚拟化环境里测物理链路。虚拟机网卡的队列、宿主机的虚拟交换、宿主机自身的负载全都会混进结果里。要评估物理链路就在物理机上测要在虚拟环境里评估就明确说明这是虚拟化路径下的数据。第五个坑把一次测量当成结论。网络状态随时在变。我的习惯是同一条命令在早高峰、午间、晚间各跑一次三次结果接近才敢下结论。单次测量只能用来判断“现在是不是有问题”不能用来判断“这条链路好不好”。第六个坑忽略出口方向。很多链路上行和下行的质量完全不同尤其是接入侧。测的时候两边都测一遍别只测一个方向就下判断。6.4 把命令固化成随手可用的小工具排障频率高的话值得花二十分钟做个小封装。我的做法是写一个批处理或 PowerShell 函数接收目标地址和端口两个参数自动完成“预热 ICMP 基线 TCP 端口 直方图”四件事输出一段固定格式的摘要直接贴到工单里。这么做的好处不是省那几下键盘而是保证每次测量口径一致。口径一致历史数据才有可比性才能回答“比上周慢了还是快了”这种真正有价值的问题。我见过太多团队每次排障用的命令都不一样攒了一堆数据却没法横向比较。另外一个实用的小技巧是利用退出码。PSPing 执行完毕后会返回状态码成功和失败不同脚本里可以直接判断不用去解析文本输出。批量探活的时候用退出码判断比正则匹配字符串可靠得多也不会因为输出格式微调而出错。最后分享一个我在实际排查里反复验证过的判断顺序先用 ICMP 拿一个链路基线延迟再用 TCP 打业务端口拿一个应用层延迟两个数字差得不多就说明网络层没问题、往应用层查差得很多就说明中间有设备在干扰、往链路层查。这个二分法不复杂但它把“感觉慢”变成了两个可以对比的数字绝大多数时候一次就能把方向定下来。PSPing 的价值也就在这儿——它不解决任何问题它只是让你在最短时间内知道自己该往哪个方向解决问题。