1. 项目概述为什么我们需要基础网络测试干了这么多年运维和开发我越来越觉得网络问题排查就像医生看病不能光靠“感觉”。你说网络卡是服务器CPU满了还是中间链路丢包了你说端口不通是防火墙没开还是服务根本没起来这时候一堆花里胡哨的监控大屏可能还不如几个最基础的命令行工具来得直接有效。今天聊的“基础网络测试”指的就是利用像ping、telnet、iperf3这些几乎存在于每台设备上的工具对网络的连通性、延迟、带宽和端口可达性进行快速诊断。这不仅是网络工程师的必修课更是后端开发、运维、甚至前端同学在联调时必备的生存技能。很多人觉得这些命令太“古老”了但它们的稳定性和普适性无可替代。当你在凌晨三点被报警电话叫醒面对一个无法访问的生产环境你不可能现场安装一个复杂的网络分析套件。你需要的是最快、最准地定位问题边界是本地问题还是机房问题是网络层不通还是应用层握手失败掌握这些基础测试就是掌握了网络排障的“听诊器”和“血压计”能让你在混乱中迅速理清头绪。接下来我会结合大量实战场景拆解这些工具的核心用法、输出解读和那些手册上不会写的“坑”。2. 核心工具解析从ICMP到Socket连接基础网络测试主要围绕网络模型的下四层物理层、数据链路层、网络层、传输层展开。我们常用的工具也对应着不同的协议和层次。2.1 网络层侦察兵ping命令的深度使用ping大概是所有人学会的第一个网络命令。它基于 ICMPInternet Control Message Protocol协议工作在网络层主要用来测试主机到目标IP地址的连通性和往返延迟。基本用法与输出解读ping -c 4 www.example.com这条命令向www.example.com发送4个ICMP回显请求包。一个典型的成功响应如下PING www.example.com (93.184.216.34): 56 data bytes 64 bytes from 93.184.216.34: icmp_seq0 ttl54 time25.187 ms 64 bytes from 93.184.216.34: icmp_seq1 ttl54 time24.986 ms 64 bytes from 93.184.216.34: icmp_seq2 ttl54 time25.072 ms 64 bytes from 93.184.216.34: icmp_seq3 ttl54 time25.413 ms --- www.example.com ping statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/stddev 24.986/25.164/25.413/0.164 msicmp_seq 序列号用于判断是否有包丢失、乱序。ttl (Time To Live) 生存时间。数据包每经过一个路由器TTL值减1减到0则被丢弃。这个值可以粗略判断经过了多少跳网络设备。初始值通常是64Linux或128Windows。上例中ttl54意味着从目标主机返回到我这里经过了128-5474跳假设目标主机初始TTL为128。time 往返延迟单位毫秒(ms)。这是评估网络质量的关键指标。高级参数与实战场景指定数据包大小 (-s) 默认ping包很小56字节8字节ICMP头。有时需要测试大包的通畅性比如排查MTU最大传输单元问题。ping -s 1472 -M do 192.168.1.1-s 1472设置数据部分1472字节加上28字节的IP和ICMP头总包大小为1500字节这是标准以太网的MTU。-M do表示设置“不分片”标志。如果这个ping不通但-s 1460能通很可能路径上存在MTU小于1500的链路需要调整TCP MSS或启用PMTUD。连续ping与统计 (-c,-i) 故障排查时往往需要持续观察。ping -i 0.5 192.168.1.100 # 每0.5秒发送一个包对于不稳定的网络短时间ping通可能只是侥幸。持续ping一段时间比如5分钟观察丢包率和延迟抖动更能说明问题。源接口绑定 (-I) 服务器有多块网卡时指定从哪个IP出去。ping -I 10.0.0.1 8.8.8.8注意ping不通并不绝对代表网络不通。很多云服务商、企业防火墙会策略性丢弃ICMP回显请求这是出于安全考虑。因此ping失败后下一步应该用telnet或nc测试具体的传输层端口。常见故障与排查ping: sendmsg: No buffer space available 本地系统网络缓冲区已满。可能原因是本地有大量未完成的网络连接或发包速率过高。需要检查系统网络状态如netstat -s或尝试重启网络服务。Destination Host Unreachable 本地系统没有到达目标网络的路由。检查本地路由表route -n或ip route。Request timeout 请求超时。可能是目标主机防火墙丢弃、中间网络断开、或目标主机已关机。2.2 传输层敲门砖telnet与nc的端口测试ping解决了“机器在不在”的问题而telnet和netcat (nc)解决的是“服务在不在”的问题。它们工作在传输层尝试与目标IP的指定端口建立TCP连接。telnet最经典的端口连通性测试telnet 192.168.1.100 8080连接成功 如果端口开放且服务正常响应会显示类似Connected to 192.168.1.100.的提示然后进入一个可交互的会话对于HTTP等服务你可以直接输入原始协议命令。按Ctrl]然后输入quit退出。连接失败Connection refused 目标端口没有进程在监听。可能是服务未启动或者监听在别的端口/IP上。Connection timed out 连接超时。很可能是在网络路径上被防火墙拦截了。这是区别于Connection refused的关键后者通常意味着数据包到达了目标主机但被拒绝而前者是包根本没到。netcat (nc)更强大的“瑞士军刀”nc比telnet更灵活它不仅可以测试TCP还能测试UDP。# 测试TCP端口 nc -zv 192.168.1.100 8080 # 测试UDP端口 (注意UDP是无连接的-z扫描只是发送空包不保证可靠) nc -zvu 192.168.1.100 53参数解释-z表示扫描模式不发送数据-v显示详细信息-u使用UDP协议。实操心得在自动化脚本中我更倾向于使用nc而不是telnet因为nc的命令行输出更规范更容易通过$?上一条命令的退出状态码来判断成功与否成功为0。而telnet连接失败后有时不会立即退出需要处理超时。针对特定协议的高级测试对于像MySQL、Redis、HTTP这样的应用层服务仅仅建立TCP连接还不够还需要验证应用协议是否正常响应。这时可以组合使用printf或echo通过nc发送简单的协议握手包。# 快速测试HTTP服务是否返回正确状态码 printf “GET / HTTP/1.1\r\nHost: localhost\r\n\r\n” | nc 192.168.1.100 80 | head -1 # 预期输出 HTTP/1.1 200 OK3. 性能压测利器使用iperf3进行带宽与丢包测试当连通性没问题后下一个问题往往是“这网络到底能跑多快质量稳不稳定” 这时候就需要iperf3这样的专业带宽测试工具了。它通过创建大量的TCP或UDP数据流来测量网络的最大带宽、延迟抖动和丢包率。3.1 iperf3的工作模式与部署iperf3采用客户端-服务器C/S架构。测试前需要在两端都安装iperf3。# 在Ubuntu/Debian上 sudo apt install iperf3 # 在CentOS/RHEL上 sudo yum install iperf3启动服务器端iperf3 -s默认监听5201端口。-s表示服务器模式。客户端发起测试iperf3 -c 服务器IP地址-c表示客户端模式后跟服务器IP。3.2 TCP带宽测试找到瓶颈点TCP测试会尝试填满网络管道测量出端到端的可持续最大吞吐量。这是最常用的测试场景。# 客户端发起一个持续10秒的TCP测试 iperf3 -c 192.168.1.200 -t 10关键输出部分在最后的总结里[ ID] Interval Transfer Bitrate Retr [ 4] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec receiverTransfer 传输的数据总量。Bitrate 平均比特率即测得的带宽。这里是941 Mbps接近千兆网络的极限。Retr 重传次数。对于TCP重传是丢包或乱序的体现。在稳定网络中这个值应该很小甚至为0。如果重传很多说明网络存在拥塞或不稳定。进阶参数并行连接 (-P) 模拟多线程下载场景有时能突破单TCP流的窗口限制。iperf3 -c 192.168.1.200 -P 4反向流量 (-R) 让服务器端发送数据客户端接收。测试上行/下行带宽时非常有用无需在两端来回跑命令。iperf3 -c 192.168.1.200 -R设置带宽目标 (-b) 用于UDP测试见下文。3.3 UDP带宽与丢包测试评估网络质量TCP测试的是“最大可靠吞吐量”而UDP测试更能反映网络的“原始质量”因为它没有重传机制丢包和延迟抖动会直接暴露出来。# 客户端以50Mbps的速率发送UDP流持续10秒 iperf3 -c 192.168.1.200 -u -b 50M -t 10参数解释-u指定UDP-b 50M设置发送比特率为50 Mbps。务必使用-b参数限制UDP发送速率否则iperf3会试图打满带宽极易造成网络拥塞影响其他业务。UDP测试的输出包含更多质量指标[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 4] 0.00-10.00 sec 59.6 MBytes 50.0 Mbits/sec 0.143 ms 0/42599 (0%) [ 4] 0.00-10.00 sec 59.6 MBytes 50.0 Mbits/sec 0.143 ms 0/42599 (0%)Jitter 抖动即延迟的变化量。单位是毫秒。对于语音、视频等实时应用抖动比绝对延迟影响更大。通常要求小于30ms。Lost/Total Datagrams 丢包数和总包数以及丢包率。上例中0/42599 (0%)表示零丢包。核心技巧网络质量评估“三步法”先用ping看基本连通和延迟。再用iperf3 -u -b [线路标称带宽的80%]测试UDP。观察抖动和丢包。如果丢包率1%或抖动很大说明网络质量不佳存在拥塞或硬件问题。最后用iperf3不加-u测试TCP最大带宽。将结果与UDP测试对比。如果TCP带宽远低于UDP设定的带宽可能是TCP窗口大小、缓冲区或中间设备策略限制。4. 实战问题排查全流程与工具组合拳掌握了单个工具更重要的是在真实故障场景下如何组合使用它们。下面是一个典型的排障流程。4.1 场景用户反馈“网站打不开”第一步本地快速自检 (pingcurl/telnet)ping 目标域名 检查DNS解析是否正常看返回的IP对不对以及网络层是否可达。如果ping不通尝试ping 8.8.8.8Google DNS判断是否是外网全断。telnet 目标IP 80或curl -I http://目标域名 检查Web服务的80/443端口是否开放HTTP协议是否正常响应。Connection refused和Connection timed out指向不同的问题方向。第二步路径追踪 (traceroute/mtr)如果ping超时但telnet也超时问题可能出在中间链路。使用tracerouteWindows是tracert或更强大的mtrMy TraceRoute。mtr -r -c 10 www.example.commtr会持续发送数据包并显示到目标主机每一跳的丢包率和延迟。你可以清晰看到问题出现在第几跳。如果丢包集中在前几跳可能是本地网络或运营商问题如果出现在接近目标时可能是目标机房网络问题。第三步服务端深度检查 (netstat/ss,tcpdump)如果从外部看端口是Connection refused需要登录服务器检查。netstat -tlnp | grep :80或ss -tlnp | grep :80 查看80端口是否有进程监听以及监听在哪个IP上0.0.0.0还是127.0.0.1。检查防火墙iptables -L -n或firewall-cmd --list-all。如果服务监听正常但外部还是连不上可能是安全组云平台或中间防火墙策略问题。此时可以在服务端用tcpdump抓包看请求包是否到达。tcpdump -i any host 客户端IP and port 804.2 场景视频会议卡顿怀疑网络质量定性测试 (ping看抖动)ping -i 0.1 -c 100 会议服务器IP | awk ‘/time/ {print $7}’ | cut -d -f2 | sort -n | head -5这个命令组合会发送100个0.1秒间隔的ping包并输出延迟最小的5个值。如果最小延迟本身很高如100ms那基础延迟就大。更关键的是看ping结果本身的波动是否剧烈。定量测试 (iperf3UDP测试)在本地和会议服务器或同一内网的另一台机器之间进行UDP测试。# 服务器端 iperf3 -s # 客户端以预计视频流码率如2Mbps测试 iperf3 -c 服务器IP -u -b 2M -t 30重点关注30秒测试期间的Jitter抖动和Lost Datagrams丢包。即使平均带宽足够持续的微小抖动和丢包也足以让实时音视频体验变差。排查方向如果抖动和丢包严重尝试用有线连接代替Wi-Fi。使用mtr检查到目标服务器的路径看丢包发生在哪一跳。检查本地是否有其他程序如BT下载、云同步在大量占用带宽。4.3 内置工具之外的补充系统级网络观测基础命令之外操作系统还提供了丰富的内置工具用于深度观测。ss命令 替代netstat更快更详细。ss -t -a显示所有TCP连接状态。在排查“连接数过多”、“TIME_WAIT堆积”问题时非常有用。sar命令 系统活动报告器。sar -n DEV 1可以每秒刷新一次网络接口的流量统计rxkB/s, txkB/s直观看到网卡吞吐。ethtool命令 查看和配置网卡驱动及硬件参数。ethtool 网卡名可以查看链路速度、双工模式、是否有错包Errors/Dropped。如果RX errors或TX errors持续增长可能是网线、网卡或驱动问题。5. 常见陷阱与高阶技巧实录即使是最简单的命令也有不少容易踩坑的地方。这里记录一些血泪教训。陷阱一误判“ping不通”如前所述防火墙丢弃ICMP是常见操作。尤其在云环境AWS Security Groups, Azure NSG, 阿里云安全组中默认规则通常禁止ICMP。因此“ping不通”不能作为网络不通的唯一证据必须结合端口测试telnet/nc。陷阱二localhost、127.0.0.1 与 0.0.0.0 的区别在服务器上测试服务时这个区别至关重要。127.0.0.1 环回地址数据包不会离开本机网卡。localhost 通常在/etc/hosts中指向127.0.0.1。0.0.0.0 表示监听本机所有IP地址包括内网IP和公网IP。 如果服务只监听在127.0.0.1:8080那么从外部网络甚至本机的另一个IP都无法访问。务必使用netstat -tlnp确认服务监听的IP。陷阱三iperf3的“单向测试”误解默认的iperf3 -c测试的是从客户端到服务器的带宽。如果你要测试服务器到客户端的带宽如下行带宽需要在客户端加上-R参数或者调换客户端和服务器的角色。很多人跑完测试发现带宽不对就是因为方向搞反了。陷阱四UDP测试不打流使用iperf3进行UDP测试时如果不加-b参数限制带宽它会默认以1 Mbps的极低速发送这完全无法测试出网络的真实承载能力和质量。UDP测试一定要用-b指定一个接近或超过业务需求的速率。高阶技巧使用Python脚本进行自动化定时测试对于需要长期监控网络质量的情况可以写一个简单的脚本将ping、iperf3的结果记录下来便于分析趋势。#!/usr/bin/env python3 import subprocess import time import json def test_latency(host): try: output subprocess.check_output([“ping”, “-c”, “4”, host], stderrsubprocess.STDOUT, textTrue) # 解析output提取平均延迟和丢包率 # … (此处省略解析逻辑) return {“avg_latency”: avg, “loss”: loss} except subprocess.CalledProcessError: return {“error”: “ping failed”} def test_bandwidth(server_ip): # 运行iperf3客户端测试解析JSON输出 result subprocess.run([“iperf3”, “-c”, server_ip, “-J”, “-t”, “5”], capture_outputTrue, textTrue) if result.returncode 0: data json.loads(result.stdout) sender_bps data[‘end’][‘sum_sent’][‘bits_per_second’] return {“bandwidth_bps”: sender_bps} else: return {“error”: “iperf3 failed”} if __name__ “__main__”: while True: metrics {} metrics[“timestamp”] time.time() metrics.update(test_latency(“8.8.8.8”)) metrics.update(test_bandwidth(“your_iperf_server_ip”)) # 将metrics写入文件或发送到监控系统 print(json.dumps(metrics)) time.sleep(300) # 每5分钟测试一次这个脚本框架展示了如何将命令行工具集成到自动化监控中。iperf3的-J参数可以输出JSON格式的结果便于程序解析。最后一点体会网络问题排查是一个不断缩小怀疑范围的过程。从“整个网站打不开”到“某台服务器的某个端口TCP握手超时”每一步都需要用合适的工具获取证据。ping、telnet、iperf3就是你的初级证据收集工具。它们简单、直接、可靠在任何环境下都能给你第一手的线索。花时间彻底弄懂它们输出的每一个字段的含义比你盲目使用更复杂的图形化工具要有效得多。下次再遇到网络问题不妨先静下心来用这一套“组合拳”打一遍很可能在几分钟内你就能找到问题的方向。
