网络计算实例讲解：从排查延迟卡顿到定位故障点

一次视频会议卡顿的排查经历

上周三下午，公司开远程会议时，销售部的小李一直掉线，画面卡得像PPT。IT同事第一反应是WiFi信号差，但测了信号强度满格，手机上网也正常。问题不在终端，也不在接入层，那就得往网络路径深处查。

我们打开命令行，先ping了会议服务器的IP：

ping 192.168.3.100

结果显示平均延迟148ms，最高飙到320ms，明显不正常。局域网内一般应该在10ms以内才对。

用traceroute定位瓶颈节点

接下来用了traceroute（Windows下是tracert），看看数据包到底卡在哪一跳：

tracert 192.168.3.100

结果发现前两跳都很稳，延迟个位数，第三跳是核心交换机，延迟突然跳到180ms，而且出现了* * * 的丢包。问题缩小到这一段了。

检查交换机端口与流量统计

登录交换机后台，查看对应端口的实时流量。发现该端口带宽占用率持续在95%以上，而其他端口都在30%以下。进一步查连接设备，发现是市场部一台测试用的备份服务器正在跑全量数据同步，占满了上行带宽。

临时断开那台服务器，再测会议系统，延迟降到12ms，小李的画面立刻流畅了。问题根源找到了——不是网络配置错，也不是硬件故障，而是内部资源争抢导致的拥塞。

通过计算验证网络容量是否够用

这时候就需要一点“网络计算”了。假设我们的内网链路是千兆（1000Mbps），减去协议开销，实际可用大约900Mbps。如果某台设备要传50GB的文件：

50GB = 50 × 8 = 400 Gb
400 Gb ÷ 900 Mbps ≈ 444秒，也就是大约7分半钟。

但如果同时有3台机器在传这种大文件，理论总需求就超过链路极限了，必然导致拥堵。实际中还要考虑突发流量和TCP重传，情况更复杂。

所以我们给备份任务加了限速策略，设置最大上传为200Mbps，避免再次抢占关键业务带宽。

另一个例子：DNS解析慢不一定是网络问题

前几天客服反馈官网打不开，但我们这边访问正常。让他们执行：

nslookup www.company.com

发现解析要等5秒以上。换成公共DNS再试：

nslookup www.company.com 8.8.8.8

瞬间返回结果。问题出在本地DNS服务器响应慢。

登陆内网DNS服务器，top命令一看，named进程CPU占了98%。原来是昨天更新了区域文件，有个配置写错了，导致递归查询陷入循环。修正配置后，解析恢复毫秒级响应。

这类问题如果不做分段测试和基础计算，很容易误判成“网络中断”或“网站挂了”。

日常排错可以养成几个习惯

遇到网络异常，别急着重启。先用最简单的工具做分层排查：ping看通断和延迟，tracert看路径，nslookup查DNS，netstat看连接状态。结合一点带宽、传输时间的估算，很多问题能快速定位。

比如你在家传照片到NAS，感觉特别慢。算一下：照片2GB，网络是百兆宽带（约12MB/s），理论上不到3分钟传完。如果花了半小时，那肯定有问题。可能是Wi-Fi干扰、NAS磁盘过载，或者协议选成了SMBv1这种老古董。

网络计算不是非要列公式，而是建立基本的数量级感知——千兆网传10GB文件不可能只花十几秒，Wi-Fi穿三堵墙也不可能保持满速。有了这种常识，排错效率会高很多。