拓冰网站定制 
简介TCPUDP测试工具是一款免安装的传输层协议调试与性能验证软件面向网络工程师、开发人员及运维人员适用于网络编程调试、故障排查、吞吐量、延迟与丢包测试等场景。压缩包共13个文件大小约1.5MB以TCPUDPDbg.exe、update.EXE等可执行程序为核心配合ini配置、dll动态库、htm帮助页面及lastsend.data数据文件可直接解压运行配置入口与界面资源齐全。已有388人浏览学习。工具覆盖TCP面向连接可靠传输与UDP低延迟无连接测试支持自定义源/目标地址、端口、包长和发送速率可模拟真实网络环境同时具备压力、吞吐、延迟、丢包等测试能力帮助定位协议实现与配置缺陷为网络服务可靠性验证和安全性排查提供实用支撑。1. TCPUDP 测试工具先分清你是在测连通性、性能还是协议细节接到“服务连不上”的反馈时我第一反应是拿起 TCPUDP 测试工具链里的第一个命令先确认目标端口在这台机器上活着。但同样的场景换一个人可能拿同一套工具测出完全相反的结论——TCP 明明测通了业务照样报错UDP 测出 90% 丢包业务却跑得正常。这不是工具不行而是 TCP 和 UDP 的测试目标根本不同TCP 要测连接能不能建立、重传多不多UDP 要测数据报能不能被对方应用层收到、抖动大不大。这篇文章不展开协议教科书只讲实战里常用的连通性、性能、协议细节三层测试怎么做、参数怎么设、踩过哪些坑。适合开发、运维、网络工程师以及做 Modbus TCP 或嵌入式联调的人。2. TCP 与 UDP 的测试差异为什么同一个工具不能通吃2.1 先看协议栈TCP 是有状态连接UDP 是无状态数据报TCP 的测试逻辑建立在三次握手之上。客户端发 SYN服务端回 SYN-ACK客户端再回 ACK连接建立后传输的是有序字节流协议栈负责重传、去重、流量控制。所以测 TCP 时工具输出里最有价值的是三件事连接有没有建立成功、传输过程中有没有重传、带宽能不能稳定维持。nc -vz返回 connected本质就是完成了一次真实的 tcp 连接 握手而 tcp 三次握手 一旦失败要么是端口没人听对方回 RST要么是 SYN 被防火墙丢弃超时。UDP 完全是另一套逻辑。它没有连接状态每个数据报独立发送协议栈不保证到达、不保证顺序、不负责重传。这就带来一个测试上的根本差异TCP 测试工具可以用一次握手的结果判断“通不通”UDP 没有等价物。你用nc -u看到的“连接成功”只是本地 socket 进入等待状态不代表对端服务存在。UDP 协议栈 本身不维护对端状态所以 udp 端口测试 必须依赖应用层回包来确认。这也是 udp 和 tcp 协议的区别 里最影响测试方法的一条TCP 的可靠性由协议栈重传保证UDP 的可靠性必须由应用层自己保证——测试工具也只能模拟应用层的探测。另一个容易忽略的点是 TCP 挥手阶段。tcp 三次握手四次挥手 里的挥手过程在大多数测试工具里根本不显示数据传完连接就静默关闭了。你想确认 FIN/ACK 序列是否正确、有没有进入 TIME_WAIT只能靠 tcpdump 抓包不能指望 iperf3 这类工具给你输出。所以我对测试工具的第一条分类标准是测 TCP 的工具看连接状态和字节流测 UDP 的工具看数据报收发和损耗中间没有通用解。2.2 按测试目标选工具连通性、性能、协议细节的常用组合我在实际项目里按测试目标把工具分成四组先连通性、再延迟、再性能、最后协议细节每一层解决一层问题测试目标推荐工具典型命令输出重点端口连通性nc / ncatnc -vz host portconnected / refused / timeout连通性 延迟tcpingtcping host 443每次握手 RTTUDP 收发验证Python socket 自写脚本sendto recvfrom回包内容与超时带宽/丢包/抖动iperf3iperf3 -c host -u -b 100M重传、丢包率、Jitter批量端口探测nmapnmap -sT/-sU hostopen / closed / filtered协议细节tcpdump / Wiresharktcpdump -i eth0 tcp port 80握手、RST、DUP ACK选型逻辑很直接先用 nc 做第一层探测因为它最普及、最快返回信息也足够明确需要延迟样本或防火墙禁 ICMP 时用 tcping要压测就上 iperf3TCP 模式和 UDP 模式分开跑客户端联调阶段自己写 socket 脚本更灵活——常见做法是 Python但涉及嵌入式设备时往往要用 tcp/ip sockets 编程 c语言实现 一个最小客户端逻辑和 Python 版本完全一样只是换成 sendto/recvfrom 的系统调用。最后一层协议细节必须抓包不要靠猜。这里要特意强调一个观点iperf3 的 TCP 模式和 UDP 模式不是同一种测速的两种参数而是回答两个不同的问题。TCP 模式看这条链路可不可靠重传UDP 模式看这条链路实不实时抖动和丢包。把这两个输出混为一谈是做网络测试最常翻车的地方。后面第 4 章会展开讲参数和结果解读。3. 连通性与端口测试用 nc、tcping 把“通不通”测准3.1 用 nc 测 TCP 端口一次真实的 tcp 三次握手先看最小可用命令nc -vz -w 3 192.168.1.10 502 nc -vz -w 3 192.168.1.10 443-v把连接过程打到标准错误输出-z是 zero I/O 模式只做三次握手不发送业务数据-w 3是超时 3 秒。502 是 Modbus TCP 默认端口443 是 HTTPS这两个是 TCP 端口号 探测里最高频的目标。输出解读是这条命令的精髓。看到 connected说明三次握手完成对端端口有服务在监听看到 Connection refused说明对端主机活着、协议栈回了 RST但目标端口没人听看到 timed out说明 SYN 发出去后没有收到任何回应大概率是防火墙丢包或路由不通。refused 和 timeout 的区别本身就是排障信息——refused 把问题定位到应用层timeout 把问题定位到网络路径。很多人一看到超时就反复重启服务完全漏掉了安全组策略。不过要泼一盆冷水nc -vz 返回 connected 只代表 TCP 层连通。做 Modbus TCP 联调时端口通了不代表寄存器读写正常应用层协议还要单独验证。但作为第一步它能快速把问题范围缩到你该关心的地方。另外一个细节是某些服务会对陌生源 IP 做访问控制nc 建立连接的行为和业务连接不同可能出现“nc 通、业务不通”的假象这时候就要进入第 4 章的抓包环节了。3.2 UDP 端口测试为什么更难nc -u 只能证明你能发UDP 没有握手所以nc -u的“连接成功”是假的它只是把本地 socket 绑定到了对端地址服务端是否存在完全没有验证。这是做 udp 端口测试 时必须要先建立的认知也是 udp 网络调试 里最常见的误区。我见过的案例里有人拿 nc -u 测了一整晚以为自己在和服务端通信实际数据全被内核丢进了黑洞。真正可靠的 UDP 探测要自己写脚本逻辑很简单发探测包等服务端应用层回包。下面是一个 Python 实现import socket import sys host sys.argv[1] if len(sys.argv) 1 else 192.168.1.10 port int(sys.argv[2]) if len(sys.argv) 2 else 12345 s socket.socket(socket.AF_INET, socket.SOCK_DGRAM) s.settimeout(3) for i in range(5): s.sendto(bprobe-%d % i, (host, port)) try: data, addr s.recvfrom(1024) print(reply from %s:%s - %r % (addr[0], addr[1], data)) except socket.timeout: print(probe-%d no reply % i) s.close()逻辑说明sendto只是把数据交给本机协议栈内核不保证对端收到要确认服务存在必须等服务端应用层回包。脚本循环发 5 个探测包每个等 3 秒收到回包打印内容超时打印 no reply。这个“发探测、等回包”的模型是所有 UDP 测试工具的底层逻辑iperf3 的 UDP 模式也一样。参数有三个值得注意。第一settimeout要和对端处理时延匹配UDP 回包一般在毫秒级3 秒足够排除正常网络延迟第二UDP 本身会丢包嵌入式设备尤其明显5 个包全丢不一定是服务挂了可以把循环次数调大到 20 再确认第三脚本没有 bind 本地端口客户端源端口是随机的如果服务端配置了回包地址白名单你的探测必然失败——这也解释了后面避坑章要讲的“为什么业务能通但测试探测不到”。3.3 用 tcping 和 nmap 补足延迟与批量探测tcping 解决的场景非常具体防火墙禁了 ICMP传统 ping 完全失效但 TCP 端口放行。这时候 tcping 能拿到每次握手的 RTT 样本tcping -t 5 192.168.1.10 443-t 5表示连续测 5 次每次输出一次握手的耗时输出类似 ping 的序列seq 号加 time。这个工具特别适合确认“端口通但延迟不稳定”的链路——如果 5 个样本里 max 和 min 差得很大链路质量就有疑问下一步直接上 iperf3 压一把确认。批量探测端口号用 nmapnmap -sT -p 22,80,443 192.168.1.10 nmap -sU -p 53,161 192.168.1.10-sT做 TCP 三次握手扫描-sU做 UDP 扫描。UDP 扫描结果有两个状态要分清open 说明有回包open|filtered 表示无回包——可能是服务没回也可能是防火墙丢包。所以 nmap 的 UDP 扫描不能独立下结论只能作为参考最终还是要回到应用层回包验证。这两个命令加上前面的 nc基本覆盖了端口连通性测试的日常需求。4. 性能与压力测试用 iperf3 做 TCP 和 UDP 打流4.1 iperf3 TCP 打流先看重传率再看带宽iperf3 是目前最主流的打流工具没有之一。服务端和客户端分开启动先跑服务端iperf3 -s -p 5201客户端再发起测试iperf3 -c 192.168.1.10 -p 5201 -t 30 -i 5参数说明-c指定服务端地址-p指定端口-t 30打流 30 秒-i 5每 5 秒打印一段汇总。客户端输出里每一段都有 Transfer传输量、Bitrate带宽、Retr重传次数。判断链路健康先看 Retr再看 Bitrate。Retr 不为 0 很正常TCP 链路上偶发重传是常态但如果 Retr 持续增长或者单段重传数超过总包数的 1%链路就开始有问题了。还有人容易忽略的是iperf3 的带宽结果受接收窗口和 socket 缓冲区影响。Windows 上可以先用netsh interface tcp show global看一眼全局参数确认没有开启奇怪的接收窗口限制Linux 上则可以给 iperf3 加-w参数指定窗口大小。我的习惯是先用默认参数测一轮发现带宽明显低于预期再调缓冲区不要一上来就改参数保持初始条件可复现。4.2 iperf3 用 UDP 打流丢包率、抖动和带宽一起测UDP 测试的命令只比 TCP 模式多两个参数但含义完全不同iperf3 -c 192.168.1.10 -p 5201 -u -b 100M -t 30 -i 5-u切换 UDP 模式-b 100M指定目标带宽 100Mbps。注意这个-b必须显式设置iperf3 不加-b时默认只有 1Mbps根本压不出效果。这是 iperf3使用udp打流 最常见的新手翻车点——跑了 30 秒出来一个 1Mbps 的结果以为链路有问题其实只是参数没设对。UDP 模式输出的核心字段是 Jitter抖动、Lost/Total Datagrams丢包数/总包数和丢包率。Jitter 单位是毫秒代表相邻包到达时间差的波动丢包率代表链路有没有过载或瓶颈。这两个指标对语音、视频、工业实时控制类业务是关键因为这些业务不能容忍重传延迟丢包和抖动直接决定体验。怎么把这条命令用好我推荐“阶梯加压”法从链路带宽一半开始测比如百兆专线先-b 50M跑完看丢包率没有明显丢包就加到 80M、90M、100M。丢包率开始明显上升的那个点就是链路的真实可用带宽上限。这个方法比一次拉满 100M 有用得多因为结果能直接告诉你瓶颈在哪一段而不是只给你一个“丢包 20%”的笼统数字。提示先用链路带宽一半起测再逐级加压比一次拉满更容易定位问题。4.3 服务器端的输出怎么读趋势比平均值更值钱服务端 iperf3 会逐段打印客户端连接的汇总信息。很多人只看最后的总平均但平均会掩盖瞬时问题。平均丢包率 1% 看起来还行如果其中某一段区间丢包 10%对应的就是一次瞬时拥塞这种抖动对实时业务的伤害远大于稳定的小丢包。在 TCP 链路上这种瞬时抖动会体现为重传。抓包时你会看到经典的 tcp dup ack 机制——接收方发现序列号跳变立刻发重复 ACK 催发快速重传抖动越大重复 ACK 越密集。所以我会在打流的同时开一个 tcpdump 后台抓包把 UDP 模式的丢包和 TCP 模式的重传事件对应起来看tcpdump -i eth0 -nn host 192.168.1.10 and tcp port 5201 -w /tmp/iperf3_tcp.pcap-w把原始包存成 pcap 文件之后用 Wireshark 打开看重传分布。实际排查里TCP 测试看到 Retr 飙升、UDP 测试看到 Jitter 飙升往往指向同一次链路抖动——两个协议的表现形式不同根源是同一个网络事件。把两种测试串联分析比单看一列数字靠谱得多。5. TCP/UDP 测试工具避坑为什么测出来的结果和业务对不上5.1 nc 测 UDP“通了”但业务收发不到数据现象用nc -u host port启动后显示连接建立但业务端就是收不到任何数据。原因UDP 没有握手nc -u 显示的“连接”只是本地 socket 绑定了远端地址服务端是否存在根本未经验证。数据到了对端、对端有没有进程在监听nc 一概不知道即使服务端收到了也不会自动回包。解决改用自写 socket 脚本做应用层回包验证同时在服务端开 tcpdump 看包有没有到网卡。没有回包基本就是服务没监听或者回包被策略丢了。这类问题在 udp 网络调试 里遇到得最多属于典型的“测试工具假通”。5.2 iperf3 UDP 打流丢包 80%业务却说网络正常现象UDP 模式-b 200M跑出来丢包率 80%但业务方坚持说网络没问题业务确实也跑得动。原因最常见的是测试带宽超过了链路实际能力链路排空导致丢包另一个隐蔽原因是接收端机器 CPU 单核软中断打满网卡中断集中在同一个核心内核来不及收包。后者和链路质量无关单看丢包率会把锅甩给网络。解决先在服务端用mpstat -P ALL 1看软中断占比再把-b降到链路带宽一半重新跑观察丢包率是否归零。归零说明链路没坏只是你把链路压过了不归零再查网卡驱动、中断绑定和 ring buffer。5.3 本机回环全通跨机就 TCP 握手超时现象服务在本机 curl 正常、nc 回环通从另一台机器 nc 就 timeout。原因TCP 握手超时最常见的原因是防火墙或安全组丢入站 SYN或中间网络设备做了访问控制少数情况是服务只监听了 127.0.0.1 而不是 0.0.0.0回环测试根本没经过协议栈的入站路径。解决先检查监听地址用ss -tlnp看具体绑在哪个 IP再用 nc 从近到远分段测试——先同网段内测再跨一层路由测。包在哪一跳消失问题就在哪一段。这个过程不要省分段定位是 TCP 连接排障的基本功。5.4 TCP 端口通但业务报“连接被重置”现象nc -vz 显示 connected但业务端报 Connection reset by peer。原因TCP 三次握手成功只证明传输层通了应用层协议不被接受时对端同样可以立刻发 RST 断开。典型场景是 Modbus TCP 连上 502 端口但功能码或单元号不对服务端直接断开或者 TLS 握手失败导致 RST。很多用 C# 写 Modbus TCP 客户端 联调的工程师在这里栽过跟头——端口测试全通但客户端一读寄存器就报连接重置。解决不要反复测端口直接抓包看握手后的第一个应用层报文。tcpdump 里看到 SYN、SYN-ACK、ACK 之后紧跟 RST说明问题在应用层协议而不是网络路径。这时候再查应用日志和协议报文格式端口测试工具的工作到此为止。5.5 镜像仓库推送报 dial tcp 超时一次典型的传输层排查现象harbor 推送镜像失败报错dial tcp 192.168.209.133:443: connect: connection refused或 timeout。原因这是非常典型的 TCP 层连接建立失败。refused 表示目标端口没有服务在监听timeout 表示 SYN 被丢弃。错误信息本身已经把问题范围缩到了传输层不需要再怀疑业务配置。解决先执行nc -vz -w 3 192.168.209.133 443复现区分是 refused 还是 timeout。refused 就查 Harbor 容器端口映射和本地防火墙放行规则timeout 就顺着链路查安全组和路由设备。按这个思路排查过好几次基本都是端口映射漏配或防火墙策略没放行很少有真正复杂的网络问题。6. 把测试工具串成一条排查流水线从端口到协议细节最后分享一个我自己的习惯把前面所有工具串成一条固定流水线每一步都只回答一个问题。下面的脚本框架可以直接存成文件用# 1 连通性TCP 三次握手能否建立 nc -vz -w 3 $HOST $PORT # 2 延迟样本每个连接 RTT 是否稳定 tcping $HOST $PORT # 3 性能TCP 看重传UDP 看丢包与抖动 iperf3 -c $HOST -p 5201 -t 30 -i 5 iperf3 -c $HOST -p 5201 -u -b 100M -t 30 -i 5 # 4 协议细节握手、RST、DUP ACK 全部落盘 tcpdump -i eth0 -nn host $HOST and tcp port $PORT -w /tmp/debug.pcap这套流程的核心是分层定位先确认连接能不能建立nc再确认延迟稳不稳tcping然后压带宽看丢包和重传iperf3最后抓包看协议行为tcpdump。每一步的结果都能立刻告诉你问题在不在这一层。如果前三步全通过但业务还是不行那 90% 以上是应用层协议问题别继续折腾网络直接抓包找应用层报文。另一个技巧是把这套流水线封装成自动化测试工具的一环。项目里如果有定时的链路巡检需求可以用 shell 或 Python 脚本把这四个命令串起来把输出打到文件里留档哪天业务方来反馈“网络又慢了”直接调出历史数据做对比胜过现场重新排查一遍。最后一条经验是血泪换来的真实业务流量往往是小包多发、带应用层交互iperf3 这种连续大包只能暴露传输层能力测不出应用层逻辑。所以“测试工具全通、业务全部翻车”并不矛盾——测试工具给的是底线不是上限。我现在接到连接类故障永远先 nc 再 tcping 再 iperf3最后 tcpdump 兜底这套流水线帮我少做了很多无用功。希望帮到你。本文还有配套的精品资源点击获取 TCP/UDP测试实战：连通性、性能与协议细节排查指南
简介TCPUDP测试工具是一款免安装的传输层协议调试与性能验证软件面向网络工程师、开发人员及运维人员适用于网络编程调试、故障排查、吞吐量、延迟与丢包测试等场景。压缩包共13个文件大小约1.5MB以TCPUDPDbg.exe、update.EXE等可执行程序为核心配合ini配置、dll动态库、htm帮助页面及lastsend.data数据文件可直接解压运行配置入口与界面资源齐全。已有388人浏览学习。工具覆盖TCP面向连接可靠传输与UDP低延迟无连接测试支持自定义源/目标地址、端口、包长和发送速率可模拟真实网络环境同时具备压力、吞吐、延迟、丢包等测试能力帮助定位协议实现与配置缺陷为网络服务可靠性验证和安全性排查提供实用支撑。1. TCPUDP 测试工具先分清你是在测连通性、性能还是协议细节接到“服务连不上”的反馈时我第一反应是拿起 TCPUDP 测试工具链里的第一个命令先确认目标端口在这台机器上活着。但同样的场景换一个人可能拿同一套工具测出完全相反的结论——TCP 明明测通了业务照样报错UDP 测出 90% 丢包业务却跑得正常。这不是工具不行而是 TCP 和 UDP 的测试目标根本不同TCP 要测连接能不能建立、重传多不多UDP 要测数据报能不能被对方应用层收到、抖动大不大。这篇文章不展开协议教科书只讲实战里常用的连通性、性能、协议细节三层测试怎么做、参数怎么设、踩过哪些坑。适合开发、运维、网络工程师以及做 Modbus TCP 或嵌入式联调的人。2. TCP 与 UDP 的测试差异为什么同一个工具不能通吃2.1 先看协议栈TCP 是有状态连接UDP 是无状态数据报TCP 的测试逻辑建立在三次握手之上。客户端发 SYN服务端回 SYN-ACK客户端再回 ACK连接建立后传输的是有序字节流协议栈负责重传、去重、流量控制。所以测 TCP 时工具输出里最有价值的是三件事连接有没有建立成功、传输过程中有没有重传、带宽能不能稳定维持。nc -vz返回 connected本质就是完成了一次真实的 tcp 连接 握手而 tcp 三次握手 一旦失败要么是端口没人听对方回 RST要么是 SYN 被防火墙丢弃超时。UDP 完全是另一套逻辑。它没有连接状态每个数据报独立发送协议栈不保证到达、不保证顺序、不负责重传。这就带来一个测试上的根本差异TCP 测试工具可以用一次握手的结果判断“通不通”UDP 没有等价物。你用nc -u看到的“连接成功”只是本地 socket 进入等待状态不代表对端服务存在。UDP 协议栈 本身不维护对端状态所以 udp 端口测试 必须依赖应用层回包来确认。这也是 udp 和 tcp 协议的区别 里最影响测试方法的一条TCP 的可靠性由协议栈重传保证UDP 的可靠性必须由应用层自己保证——测试工具也只能模拟应用层的探测。另一个容易忽略的点是 TCP 挥手阶段。tcp 三次握手四次挥手 里的挥手过程在大多数测试工具里根本不显示数据传完连接就静默关闭了。你想确认 FIN/ACK 序列是否正确、有没有进入 TIME_WAIT只能靠 tcpdump 抓包不能指望 iperf3 这类工具给你输出。所以我对测试工具的第一条分类标准是测 TCP 的工具看连接状态和字节流测 UDP 的工具看数据报收发和损耗中间没有通用解。2.2 按测试目标选工具连通性、性能、协议细节的常用组合我在实际项目里按测试目标把工具分成四组先连通性、再延迟、再性能、最后协议细节每一层解决一层问题测试目标推荐工具典型命令输出重点端口连通性nc / ncatnc -vz host portconnected / refused / timeout连通性 延迟tcpingtcping host 443每次握手 RTTUDP 收发验证Python socket 自写脚本sendto recvfrom回包内容与超时带宽/丢包/抖动iperf3iperf3 -c host -u -b 100M重传、丢包率、Jitter批量端口探测nmapnmap -sT/-sU hostopen / closed / filtered协议细节tcpdump / Wiresharktcpdump -i eth0 tcp port 80握手、RST、DUP ACK选型逻辑很直接先用 nc 做第一层探测因为它最普及、最快返回信息也足够明确需要延迟样本或防火墙禁 ICMP 时用 tcping要压测就上 iperf3TCP 模式和 UDP 模式分开跑客户端联调阶段自己写 socket 脚本更灵活——常见做法是 Python但涉及嵌入式设备时往往要用 tcp/ip sockets 编程 c语言实现 一个最小客户端逻辑和 Python 版本完全一样只是换成 sendto/recvfrom 的系统调用。最后一层协议细节必须抓包不要靠猜。这里要特意强调一个观点iperf3 的 TCP 模式和 UDP 模式不是同一种测速的两种参数而是回答两个不同的问题。TCP 模式看这条链路可不可靠重传UDP 模式看这条链路实不实时抖动和丢包。把这两个输出混为一谈是做网络测试最常翻车的地方。后面第 4 章会展开讲参数和结果解读。3. 连通性与端口测试用 nc、tcping 把“通不通”测准3.1 用 nc 测 TCP 端口一次真实的 tcp 三次握手先看最小可用命令nc -vz -w 3 192.168.1.10 502 nc -vz -w 3 192.168.1.10 443-v把连接过程打到标准错误输出-z是 zero I/O 模式只做三次握手不发送业务数据-w 3是超时 3 秒。502 是 Modbus TCP 默认端口443 是 HTTPS这两个是 TCP 端口号 探测里最高频的目标。输出解读是这条命令的精髓。看到 connected说明三次握手完成对端端口有服务在监听看到 Connection refused说明对端主机活着、协议栈回了 RST但目标端口没人听看到 timed out说明 SYN 发出去后没有收到任何回应大概率是防火墙丢包或路由不通。refused 和 timeout 的区别本身就是排障信息——refused 把问题定位到应用层timeout 把问题定位到网络路径。很多人一看到超时就反复重启服务完全漏掉了安全组策略。不过要泼一盆冷水nc -vz 返回 connected 只代表 TCP 层连通。做 Modbus TCP 联调时端口通了不代表寄存器读写正常应用层协议还要单独验证。但作为第一步它能快速把问题范围缩到你该关心的地方。另外一个细节是某些服务会对陌生源 IP 做访问控制nc 建立连接的行为和业务连接不同可能出现“nc 通、业务不通”的假象这时候就要进入第 4 章的抓包环节了。3.2 UDP 端口测试为什么更难nc -u 只能证明你能发UDP 没有握手所以nc -u的“连接成功”是假的它只是把本地 socket 绑定到了对端地址服务端是否存在完全没有验证。这是做 udp 端口测试 时必须要先建立的认知也是 udp 网络调试 里最常见的误区。我见过的案例里有人拿 nc -u 测了一整晚以为自己在和服务端通信实际数据全被内核丢进了黑洞。真正可靠的 UDP 探测要自己写脚本逻辑很简单发探测包等服务端应用层回包。下面是一个 Python 实现import socket import sys host sys.argv[1] if len(sys.argv) 1 else 192.168.1.10 port int(sys.argv[2]) if len(sys.argv) 2 else 12345 s socket.socket(socket.AF_INET, socket.SOCK_DGRAM) s.settimeout(3) for i in range(5): s.sendto(bprobe-%d % i, (host, port)) try: data, addr s.recvfrom(1024) print(reply from %s:%s - %r % (addr[0], addr[1], data)) except socket.timeout: print(probe-%d no reply % i) s.close()逻辑说明sendto只是把数据交给本机协议栈内核不保证对端收到要确认服务存在必须等服务端应用层回包。脚本循环发 5 个探测包每个等 3 秒收到回包打印内容超时打印 no reply。这个“发探测、等回包”的模型是所有 UDP 测试工具的底层逻辑iperf3 的 UDP 模式也一样。参数有三个值得注意。第一settimeout要和对端处理时延匹配UDP 回包一般在毫秒级3 秒足够排除正常网络延迟第二UDP 本身会丢包嵌入式设备尤其明显5 个包全丢不一定是服务挂了可以把循环次数调大到 20 再确认第三脚本没有 bind 本地端口客户端源端口是随机的如果服务端配置了回包地址白名单你的探测必然失败——这也解释了后面避坑章要讲的“为什么业务能通但测试探测不到”。3.3 用 tcping 和 nmap 补足延迟与批量探测tcping 解决的场景非常具体防火墙禁了 ICMP传统 ping 完全失效但 TCP 端口放行。这时候 tcping 能拿到每次握手的 RTT 样本tcping -t 5 192.168.1.10 443-t 5表示连续测 5 次每次输出一次握手的耗时输出类似 ping 的序列seq 号加 time。这个工具特别适合确认“端口通但延迟不稳定”的链路——如果 5 个样本里 max 和 min 差得很大链路质量就有疑问下一步直接上 iperf3 压一把确认。批量探测端口号用 nmapnmap -sT -p 22,80,443 192.168.1.10 nmap -sU -p 53,161 192.168.1.10-sT做 TCP 三次握手扫描-sU做 UDP 扫描。UDP 扫描结果有两个状态要分清open 说明有回包open|filtered 表示无回包——可能是服务没回也可能是防火墙丢包。所以 nmap 的 UDP 扫描不能独立下结论只能作为参考最终还是要回到应用层回包验证。这两个命令加上前面的 nc基本覆盖了端口连通性测试的日常需求。4. 性能与压力测试用 iperf3 做 TCP 和 UDP 打流4.1 iperf3 TCP 打流先看重传率再看带宽iperf3 是目前最主流的打流工具没有之一。服务端和客户端分开启动先跑服务端iperf3 -s -p 5201客户端再发起测试iperf3 -c 192.168.1.10 -p 5201 -t 30 -i 5参数说明-c指定服务端地址-p指定端口-t 30打流 30 秒-i 5每 5 秒打印一段汇总。客户端输出里每一段都有 Transfer传输量、Bitrate带宽、Retr重传次数。判断链路健康先看 Retr再看 Bitrate。Retr 不为 0 很正常TCP 链路上偶发重传是常态但如果 Retr 持续增长或者单段重传数超过总包数的 1%链路就开始有问题了。还有人容易忽略的是iperf3 的带宽结果受接收窗口和 socket 缓冲区影响。Windows 上可以先用netsh interface tcp show global看一眼全局参数确认没有开启奇怪的接收窗口限制Linux 上则可以给 iperf3 加-w参数指定窗口大小。我的习惯是先用默认参数测一轮发现带宽明显低于预期再调缓冲区不要一上来就改参数保持初始条件可复现。4.2 iperf3 用 UDP 打流丢包率、抖动和带宽一起测UDP 测试的命令只比 TCP 模式多两个参数但含义完全不同iperf3 -c 192.168.1.10 -p 5201 -u -b 100M -t 30 -i 5-u切换 UDP 模式-b 100M指定目标带宽 100Mbps。注意这个-b必须显式设置iperf3 不加-b时默认只有 1Mbps根本压不出效果。这是 iperf3使用udp打流 最常见的新手翻车点——跑了 30 秒出来一个 1Mbps 的结果以为链路有问题其实只是参数没设对。UDP 模式输出的核心字段是 Jitter抖动、Lost/Total Datagrams丢包数/总包数和丢包率。Jitter 单位是毫秒代表相邻包到达时间差的波动丢包率代表链路有没有过载或瓶颈。这两个指标对语音、视频、工业实时控制类业务是关键因为这些业务不能容忍重传延迟丢包和抖动直接决定体验。怎么把这条命令用好我推荐“阶梯加压”法从链路带宽一半开始测比如百兆专线先-b 50M跑完看丢包率没有明显丢包就加到 80M、90M、100M。丢包率开始明显上升的那个点就是链路的真实可用带宽上限。这个方法比一次拉满 100M 有用得多因为结果能直接告诉你瓶颈在哪一段而不是只给你一个“丢包 20%”的笼统数字。提示先用链路带宽一半起测再逐级加压比一次拉满更容易定位问题。4.3 服务器端的输出怎么读趋势比平均值更值钱服务端 iperf3 会逐段打印客户端连接的汇总信息。很多人只看最后的总平均但平均会掩盖瞬时问题。平均丢包率 1% 看起来还行如果其中某一段区间丢包 10%对应的就是一次瞬时拥塞这种抖动对实时业务的伤害远大于稳定的小丢包。在 TCP 链路上这种瞬时抖动会体现为重传。抓包时你会看到经典的 tcp dup ack 机制——接收方发现序列号跳变立刻发重复 ACK 催发快速重传抖动越大重复 ACK 越密集。所以我会在打流的同时开一个 tcpdump 后台抓包把 UDP 模式的丢包和 TCP 模式的重传事件对应起来看tcpdump -i eth0 -nn host 192.168.1.10 and tcp port 5201 -w /tmp/iperf3_tcp.pcap-w把原始包存成 pcap 文件之后用 Wireshark 打开看重传分布。实际排查里TCP 测试看到 Retr 飙升、UDP 测试看到 Jitter 飙升往往指向同一次链路抖动——两个协议的表现形式不同根源是同一个网络事件。把两种测试串联分析比单看一列数字靠谱得多。5. TCP/UDP 测试工具避坑为什么测出来的结果和业务对不上5.1 nc 测 UDP“通了”但业务收发不到数据现象用nc -u host port启动后显示连接建立但业务端就是收不到任何数据。原因UDP 没有握手nc -u 显示的“连接”只是本地 socket 绑定了远端地址服务端是否存在根本未经验证。数据到了对端、对端有没有进程在监听nc 一概不知道即使服务端收到了也不会自动回包。解决改用自写 socket 脚本做应用层回包验证同时在服务端开 tcpdump 看包有没有到网卡。没有回包基本就是服务没监听或者回包被策略丢了。这类问题在 udp 网络调试 里遇到得最多属于典型的“测试工具假通”。5.2 iperf3 UDP 打流丢包 80%业务却说网络正常现象UDP 模式-b 200M跑出来丢包率 80%但业务方坚持说网络没问题业务确实也跑得动。原因最常见的是测试带宽超过了链路实际能力链路排空导致丢包另一个隐蔽原因是接收端机器 CPU 单核软中断打满网卡中断集中在同一个核心内核来不及收包。后者和链路质量无关单看丢包率会把锅甩给网络。解决先在服务端用mpstat -P ALL 1看软中断占比再把-b降到链路带宽一半重新跑观察丢包率是否归零。归零说明链路没坏只是你把链路压过了不归零再查网卡驱动、中断绑定和 ring buffer。5.3 本机回环全通跨机就 TCP 握手超时现象服务在本机 curl 正常、nc 回环通从另一台机器 nc 就 timeout。原因TCP 握手超时最常见的原因是防火墙或安全组丢入站 SYN或中间网络设备做了访问控制少数情况是服务只监听了 127.0.0.1 而不是 0.0.0.0回环测试根本没经过协议栈的入站路径。解决先检查监听地址用ss -tlnp看具体绑在哪个 IP再用 nc 从近到远分段测试——先同网段内测再跨一层路由测。包在哪一跳消失问题就在哪一段。这个过程不要省分段定位是 TCP 连接排障的基本功。5.4 TCP 端口通但业务报“连接被重置”现象nc -vz 显示 connected但业务端报 Connection reset by peer。原因TCP 三次握手成功只证明传输层通了应用层协议不被接受时对端同样可以立刻发 RST 断开。典型场景是 Modbus TCP 连上 502 端口但功能码或单元号不对服务端直接断开或者 TLS 握手失败导致 RST。很多用 C# 写 Modbus TCP 客户端 联调的工程师在这里栽过跟头——端口测试全通但客户端一读寄存器就报连接重置。解决不要反复测端口直接抓包看握手后的第一个应用层报文。tcpdump 里看到 SYN、SYN-ACK、ACK 之后紧跟 RST说明问题在应用层协议而不是网络路径。这时候再查应用日志和协议报文格式端口测试工具的工作到此为止。5.5 镜像仓库推送报 dial tcp 超时一次典型的传输层排查现象harbor 推送镜像失败报错dial tcp 192.168.209.133:443: connect: connection refused或 timeout。原因这是非常典型的 TCP 层连接建立失败。refused 表示目标端口没有服务在监听timeout 表示 SYN 被丢弃。错误信息本身已经把问题范围缩到了传输层不需要再怀疑业务配置。解决先执行nc -vz -w 3 192.168.209.133 443复现区分是 refused 还是 timeout。refused 就查 Harbor 容器端口映射和本地防火墙放行规则timeout 就顺着链路查安全组和路由设备。按这个思路排查过好几次基本都是端口映射漏配或防火墙策略没放行很少有真正复杂的网络问题。6. 把测试工具串成一条排查流水线从端口到协议细节最后分享一个我自己的习惯把前面所有工具串成一条固定流水线每一步都只回答一个问题。下面的脚本框架可以直接存成文件用# 1 连通性TCP 三次握手能否建立 nc -vz -w 3 $HOST $PORT # 2 延迟样本每个连接 RTT 是否稳定 tcping $HOST $PORT # 3 性能TCP 看重传UDP 看丢包与抖动 iperf3 -c $HOST -p 5201 -t 30 -i 5 iperf3 -c $HOST -p 5201 -u -b 100M -t 30 -i 5 # 4 协议细节握手、RST、DUP ACK 全部落盘 tcpdump -i eth0 -nn host $HOST and tcp port $PORT -w /tmp/debug.pcap这套流程的核心是分层定位先确认连接能不能建立nc再确认延迟稳不稳tcping然后压带宽看丢包和重传iperf3最后抓包看协议行为tcpdump。每一步的结果都能立刻告诉你问题在不在这一层。如果前三步全通过但业务还是不行那 90% 以上是应用层协议问题别继续折腾网络直接抓包找应用层报文。另一个技巧是把这套流水线封装成自动化测试工具的一环。项目里如果有定时的链路巡检需求可以用 shell 或 Python 脚本把这四个命令串起来把输出打到文件里留档哪天业务方来反馈“网络又慢了”直接调出历史数据做对比胜过现场重新排查一遍。最后一条经验是血泪换来的真实业务流量往往是小包多发、带应用层交互iperf3 这种连续大包只能暴露传输层能力测不出应用层逻辑。所以“测试工具全通、业务全部翻车”并不矛盾——测试工具给的是底线不是上限。我现在接到连接类故障永远先 nc 再 tcping 再 iperf3最后 tcpdump 兜底这套流水线帮我少做了很多无用功。希望帮到你。本文还有配套的精品资源点击获取