资源监视器不直接显示TCP丢包率，但可通过“TCP重传/秒”持续高于0（如＞5～10次/秒）判断TCP层丢包，并结合“错误”列、进程排序及netstat -s -p tcp验证。
资源监视器本身不直接显示“tcp丢包率”这个数值，但它能提供关键线索，帮你判断是否存在tcp层丢包，并定位是哪个进程在引发问题。
资源监视器里看什么指标
打开资源监视器（任务管理器 → 性能 → 打开资源监视器 → 网络选项卡），重点关注以下两列：
- “TCP 重传/秒”：该值持续高于 0（比如 >5～10 次/秒），说明本地 TCP 栈正在频繁重发数据包——这是 TCP 层丢包最直接的信号；
- “TCP 连接数”和“错误”列：虽然不标“丢包”，但若某进程对应行中“错误”数值明显偏高（尤其是 Winsock 错误如 WSAECONNRESET、WSAETIMEDOUT），常伴随重传或连接异常中断，间接反映链路不稳定。
结合进程与网络活动交叉分析
资源监视器按进程列出实时网络行为，你可以：
- 排序点击“TCP 重传/秒”列，找出重传最猛的进程（如浏览器、游戏客户端、P2P软件）；
- 右键该进程 → “查看关联的句柄”或“结束进程”，观察重传数值是否骤降，验证是否由它引发；
- 切换到“网络”选项卡顶部的“监听端口”视图，检查是否有异常服务长期处于 SYN_RECV 或 TIME_WAIT 状态过多，可能暗示握手失败或连接堆积。
为什么不能直接看到百分比丢包率
TCP 协议栈内部统计的是重传次数、超时次数、重复 ACK 数等原始事件，Windows 并未将这些换算成“丢包率 = 重传数 / 发送总数”并展示在资源监视器中。真正的丢包率需借助更底层工具（如 Wireshark 抓包后用 Statistics → Protocol Hierarchy 或过滤 tcp.analysis.lost_segment）或命令行工具（如 netstat -s -p tcp 查看 IPv4 TCP 统计中的 “Segments retransmitted” 和 “Segments sent”）。
配合 ping 和 netstat 快速验证
资源监视器发现高重传后，建议立刻补两步：
- 在命令提示符运行：ping -n 20 本机网关 IP，看内网是否丢包（排除物理链路问题）；
- 运行：netstat -s -p tcp | findstr "retransmit"，获取系统级 TCP 重传累计值，对比前后变化趋势。
