简介TCPUDP测试工具是一款面向网络工程师与开发人员的轻量级网络协议调试软件主要用于TCP/UDP通信的性能评估、故障排查与协议验证可覆盖网络编程、设备测试和安全检查等场景。资源以rar压缩包形式提供共13个文件其中包含3个exe可执行程序、2个ini配置文件以及htm/css说明页面等整体仅有1.5MB解压后免安装即可运行非常适合在临时测试环境中快速部署。目前已有388人学习浏览。工具支持自定义源/目的地址、指定端口、数据包大小和传输速率可模拟真实网络环境下的TCP可靠传输与UDP低延迟通信同时提供压力测试、吞吐量测试、延迟测试和丢包测试帮助用户评估服务器承载能力、定位传输瓶颈。借助内置可视化配置和案例页面测试过程中还能直观对照协议行为发现不正确的协议实现或配置错误适用于网络调试、课程实验及安全配置检查等场景。1. TCPUDP 测试工具从「能通」到「能测准」要补的五个短板拿到“TCPUDP 测试工具”这个需求大多数人的第一反应是找一个免费软件填上 IP 和端口点一下 Start看到“Connected”就以为完成任务。真正做网络调试的工程师都清楚这种“能通”离“测准”还有很长一段距离TCP 三次握手成功不代表业务数据可靠UDP 收到回包也不代表端口没被防火墙静默丢弃更不用说带宽、抖动、乱序这些指标根本不是一次连接就能看出来的。这篇文章会把 TCP/UDP 测试工具拆成一套可落地的调试方案覆盖选型、最小实现、参数调优和高频踩坑适合嵌入式、运维、工控和客户端开发者照着复现。2. 协议测试的分层逻辑连通性、可靠性、带宽和端口探测不是同一件事2.1 两份协议栈先补课三次握手与无连接的 UDP 各自要验证什么TCP 测试的核心不是“能连上”而是连上之后的所有状态变化。三次握手只是把客户端和服务端的序列号、窗口、MSS 协商好了真正决定业务质量的还有后续的数据传输、窗口收缩、重传和连接关闭。所以 TCP 测试工具至少要能区分几个层次SYN 是否到达、ACK 是否回来、应用层是否返回数据、连接是否能维持足够长时间。很多工具只做到了第二层在自动化测试里这种工具会漏掉一半问题。UDP 是完全相反的逻辑。它没有握手也没有重传发送端把数据报扔给协议栈就结束了。UDP 测试工具真正要捕捉的是两类结果一类是能不能把数据发出去、对方能不能收到另一类是发送路径上有没有 ICMP 不可达报文被悄悄丢弃。由于 UDP 本身无状态测试工具必须自己承担“回应”职责否则你根本分不清是网络丢包、防火墙拦截还是对方协议栈根本没在处理。这也是 UDP 端口测试比 TCP 端口测试复杂的地方。从 TCP/UDP 测试工具的设计角度讲一份工具不太可能同时把这两类验证做到极致但至少要让你明确当前测的是哪一层连通性层、传输层还是应用层。连通性层只需要一个端口探测传输层需要收发数据并判断乱序和重传应用层则需要把业务协议比如 Modbus TCP、自定义报文拼装好再发出去。工具选型之前先回答这个问题比下载任何软件都重要。2.2 四类测试工具的选型矩阵与最小命令常见做法是把工具分成四类端口连通性、通用收发、性能打流、报文分析。端口连通性用 tcping 或 nc 的 -z 参数通用收发用 nc 或自写脚本性能打流用 iperf3报文分析用 tcpdump/Wireshark。它们解决的问题完全不同混用是新手最常犯的错。测试目标推荐工具为什么选它典型场景端口是否开放tcping / nc -z轻量、不建立完整业务连接排查 TCP 端口不通通用 TCP/UDP 收发nc / socat支持双向、可带数据验证自定义协议连通性带宽、丢包、抖动iperf3内置 UDP 打流和 JSON 输出评估链路质量协议栈行为分析tcpdump / Wireshark能看到握手、重传、窗口变化定位 dup ack、乱序先用最小命令把端口连通性查掉。nc 的 -vz 是只探测不发送数据适合快速判断nc -vz 192.168.1.10 9000执行后如果显示Connection to 192.168.1.10 9000 port [tcp/*] succeeded!说明 TCP 握手已经完成。此时的问题是这个结果只能证明服务端有进程在监听不能证明服务端会正常处理你的业务报文。要继续验证收发需要启动一个监听端并主动发数据# 终端 A监听 UDP 9000并把收到的内容打印出来 nc -u -l 9000 # 终端 B发送一段测试文本 echo hello from tcpudp-test | nc -u 192.168.1.10 9000这段命令的逻辑是UDP 没有连接所以必须有一个常驻的接收端。nc -u -l 进入监听模式后发送端使用 nc 向目标端口注入数据。此时如果终端 A 打印出文本说明 UDP 数据报已经穿过网络栈到达应用层。如果终端 A 没反应就要去抓 ICMP 包确认是否被中间设备丢弃了。这比单纯用在线端口扫描工具更能反映真实网络路径。2.3 失败时先改哪几个参数timeout、retry、buffer无论用哪类工具测试结果的可靠性都取决于三个参数超时时间、重试次数、缓冲区大小。TCP 扫描工具的默认超时往往只有几秒放在跨地域链路上一个正常的握手响应需要 3 秒以上工具就会误报失败。我一般会把 TCP 连接超时调到 5 秒以上UDP 探测则必须依赖重试因为 UDP 没有确认机制一次丢包就可能让你误判端口不可达。缓冲区大小对 UDP 测试尤其关键。UDP 协议栈默认接收缓冲区在 Linux 上是几十 KB 到上百 KB 不等如果发送端一次性灌入大报文接收端缓冲溢出后数据报会被直接丢弃测试工具看到的丢包率就会飙升。你需要在工具里把 buffer 设置为与业务报文一致而不是越大越好。例如 Modbus TCP 报文通常只有 260 字节左右测试时用一个 512 字节的 buffer 足够了如果业务走的是视频流才需要按 MTU 或 jumbo frame 来调整。3. 自己动手写一个 TCP/UDP 测试工具Python 双栈脚本与参数落地3.1 服务端与客户端的最小实现很多现成工具不满足定制需求写一个足够小的 TCP/UDP 测试工具反而更顺手。我用 Python 标准库 socket 做过一版没有第三方依赖部署到目标机器时不用装 pip 包。这个脚本分两部分一个是通用服务端既能监听 TCP 也能监听 UDP收到数据后原样返回另一个是通用客户端主动连接并发送自定义内容。下面贴出的是精简后的服务端# server.py - TCP/UDP 通用回环服务端 import argparse import socket def run_tcp_server(port, buffer_size): with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as sock: sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) sock.bind((0.0.0.0, port)) sock.listen(5) print(fTCP server listening on :{port}, flushTrue) while True: conn, addr sock.accept() with conn: print(fconnect from {addr}, flushTrue) data conn.recv(buffer_size) if data: conn.sendall(becho: data) def run_udp_server(port, buffer_size): with socket.socket(socket.AF_INET, socket.SOCK_DGRAM) as sock: sock.bind((0.0.0.0, port)) print(fUDP server listening on :{port}, flushTrue) while True: data, addr sock.recvfrom(buffer_size) sock.sendto(becho: data, addr) if __name__ __main__: parser argparse.ArgumentParser(descriptionTCP/UDP test server) parser.add_argument(--proto, choices[tcp, udp], requiredTrue) parser.add_argument(--port, typeint, requiredTrue) parser.add_argument(--buffer-size, typeint, default1024) args parser.parse_args() if args.proto tcp: run_tcp_server(args.port, args.buffer_size) else: run_udp_server(args.port, args.buffer_size)逻辑说明TCP 分支走经典的 listen-accept-recv 流程客户端连上后服务端收到第一段数据就回显。UDP 分支走 recvfrom-sendto端口固定监听在 0.0.0.0 上这样局域网内任意网卡的请求都能到达。注意 TCP 分支设置了 SO_REUSEADDR目的是让进程重启后端口不会进入 TIME_WAIT 状态导致 bind 失败这在调试中会经常救你一命。buffer_size 这里默认为 1024如果你要模拟 MTU 分片改成 1472 更贴近实际 UDP 负载上限。客户端的实现思路是参数控制协议、目标地址、端口和发送内容并统计耗时# client.py - TCP/UDP 通用测试客户端 import argparse import socket import time def tcp_send(host, port, message, timeout): with socket.create_connection((host, port), timeouttimeout) as s: s.sendall(message.encode()) resp s.recv(1024) print(fTCP response: {resp.decode()!r}) def udp_send(host, port, message, timeout): with socket.socket(socket.AF_INET, socket.SOCK_DGRAM) as s: s.settimeout(timeout) s.sendto(message.encode(), (host, port)) try: resp, addr s.recvfrom(1024) print(fUDP response from {addr}: {resp.decode()!r}) except socket.timeout: print(UDP timeout, no response) if __name__ __main__: parser argparse.ArgumentParser(descriptionTCP/UDP test client) parser.add_argument(--proto, choices[tcp, udp], requiredTrue) parser.add_argument(--host, requiredTrue) parser.add_argument(--port, typeint, requiredTrue) parser.add_argument(--message, defaultping) parser.add_argument(--timeout, typefloat, default5.0) args parser.parse_args() start time.time() if args.proto tcp: tcp_send(args.host, args.port, args.message, args.timeout) else: udp_send(args.host, args.port, args.message, args.timeout) print(felapsed: {time.time() - start:.3f}s)这份客户端代码里最值得留意的是 UDP 分支的 timeout 处理。UDP 发送本身几乎不会报错真正的失败信息只能靠 recvfrom 超时暴露出来。你在写自动化测试脚本时UDP 的结果应该以“是否收到响应”为准而不是以 sendto 是否抛出异常为准。TCP 分支的 timeout 则直接体现在 create_connection 上连不上会抛出 socket.timeout 或 ConnectionRefusedError不需要额外判断。3.2 把脚本变成可复用的命令行工具上面两个脚本只能手动跑在自动化测试里不实用。常见的改进方向是合并成一个命令类似net-tools.py tcp-client --host 10.0.0.2 --port 9000 --message hello并且把输出改成带时间戳的 JSON 行方便下游解析。合并时只需要把 argparse 的子命令加上内部复用刚才的两个函数。另外建议增加“连续模式”。很多偶发问题要跑几千次才出现人工执行一次根本看不出统计意义。我一般会增加--count N和--interval 0.1两个参数让客户端循环执行并汇总成功率、平均延迟和最大延迟。代码结构上不要在多线程里共享 socket直接顺序执行即可这样结果更可控。再加上--log-file把每次结果落盘排查现场问题时能少扯很多皮。参数调优方面TCP 连续连接测试要特别关注 TIME_WAIT。如果每次测试都是客户端主动关闭连接短时间大量新建连接会让客户端端口进入 TIME_WAIT后续 connect 可能抛 “Address already in use”。解法是使用SO_REUSEADDR但注意这只能缓解 bind 冲突真正要避免 TIME_WAIT 堆积更好的做法是让服务端主动关闭或者把连接改为长连接复用。这属于 TCP 测试工具最容易踩的坑后面避坑章节会展开。3.3 用脚本还原三次握手与 dup ack 现象脚本能告诉我们结果但要知道为什么还需要抓包。我在调试 TCP 连接慢时通常会在目标机器上同时跑 tcpdump然后执行客户端脚本再把抓包结果导入 Wireshark。三次握手的三个包分别显示为 SYN、SYN-ACK、ACK这个顺序一目了然。如果只看到 SYN 而看不到 SYN-ACK大概率是目标端口没监听或者防火墙丢包如果 SYN-ACK 到了但最终的 ACK 没回来问题出在客户端协议栈或中间设备上。dup ack 机制在测试工具里怎么验证简单办法是抓包时看 TCP 头部 sequence number。客户端发送大数据时触发快速重传抓包里会出现连续三个相同 ACK 号。我这里有一个快速验证脚本片段它通过循环发送大报文来制造乱序窗口# 注意这段脚本只用来观察 dup ack不要在生产环境跑 import socket s socket.create_connection((192.168.1.10, 9000)) payload bA * 4096 for i in range(200): s.sendall(payload) s.recv(1024)观察方式是在另一个终端执行sudo tcpdump -i eth0 tcp and host 192.168.1.10 -w dup.pcap跑完后打开 dup.pcap用 Wireshark 的 Statistics - TCP Stream Graph 查看序列号曲线。如果曲线出现回折说明确实发生了重传如果出现平直的阶梯说明接收窗口在收缩。这个实验的价值在于很多 TCP 测试工具能告诉你“通了”但只有抓包能告诉你“为什么慢”两者必须配合使用。4. 把玩具升级成工具箱iperf3 打流与端口探测的实战用法4.1 iperf3 的 TCP/UDP 双向打流与参数调优自研脚本适合小报文验证真要看带宽和丢包率我一般直接上 iperf3。它的部署成本极低两端各一个可执行文件就能跑。服务端启动命令iperf3 -s -p 5201客户端先做 TCP 打流默认向服务端发送数据直到指定时间结束iperf3 -c 192.168.1.10 -p 5201 -t 30参数说明-c 指定目标地址-p 指定端口-t 是测试时长秒-t 30 表示打流 30 秒。输出里看三项Bitrate、Retr、Cwnd。Retr 是重传次数如果 30 秒内 Retr 持续增长说明网络有丢包或者接收端缓冲区不够。Cwnd 是拥塞窗口数值不增长往往意味着链路存在瓶颈比如带宽受限或者对端 window 太小。真正能压出 UDP 协议栈问题的是 UDP 打流。UDP 打流必须手动指定带宽因为 iperf3 默认不知道你想要的发送速率iperf3 -c 192.168.1.10 -p 5201 -u -b 200M -t 20 --get-server-output参数说明-u 切到 UDP 模式-b 200M 表示目标带宽 200Mbps-t 20 表示持续 20 秒--get-server-output 让客户端把服务端的统计一起打出来省得来回对账。UDP 模式的输出中会出现 Total datagrams、Jitter、Lost/Total Datagrams 三行丢包率是失包数除以总数比如14234/100000 (14%)通常超过 1% 就要开始排查。Jitter 是抖动单位是毫秒对视频业务来说抖动比平均延迟更重要。丢包率高时先看是不是发送速率超出了链路容量把 -b 降到链路带宽的 80% 再测一轮这叫留余量不是掩盖问题。4.2 从探测到验收tcping、nc、端口扫描iperf3 解决的是“带宽够不够”端口状态还得靠更轻的工具。tcping 比普通 ping 更进一步它做的是 TCP 三次握手所以在禁 ICMP 的网络上也能用。常见用法tcping -t 5 -i 192.168.1.20 8080-t 5 是超时 5 秒-i 是无限循环方便观察端口抖动。如果只测一次去掉 -i。tcping 的用处是快速区分“端口没开”和“网络不通”端口没开会立刻返回 Connection refused网络不通会等到超时时间结束才报错。现场排查时这两个现象对应完全不同的人去处理所以看到结果先别急把拒绝和超时分开记录。端口扫描在生产环境要谨慎。nmap 扫一个 IP 的常用命令nmap -sS -Pn -p 80,443,9000 192.168.1.20-sS 是 SYN 半开扫描只发 SYN 不建连速度比全连接快。-Pn 表示跳过主机发现直接对端口做探测适合处理禁 ICMP 的主机。跑完输出里 open、filtered、closed 三种状态要分清楚open 说明有服务监听filtered 说明被防火墙拦截closed 说明主机可达但没有服务。很多运维只看 open 和 closed漏了对 filtered 的关注这是自动化测试脚本误报的主要来源。在 Modbus TCP 这类工控场景里验收分三步先用 tcping 确认 502 端口可达再用自研脚本发一个标准的 Modbus TCP 读保持寄存器请求最后抓包对比请求响应的 transaction id 和 protocol id。三步都通过才算这个端子处于可服务状态。单一工具测通并不能覆盖业务协议的正确性自动化测试工具链必须这样串起来。4.3 现场问题的三条对照线索在客户现场做过几轮排障后我总结出三条固定对照线索。第一条线索是“TCP 握手成功但业务超时”这种问题往往不在网络而在业务层需要把测试工具切换到应用层协议比如发一个真实的业务心跳包。第二条线索是“UDP 能发不能收”先确认对端有没有 listen再用 tcpdump 抓 ICMP 的 port unreachable如果抓到说明端口确实没监听抓不到就要怀疑防火墙静默丢包。第三条线索是“TCP 连接时好时坏”重点看服务端连接队列是否满了ss -lnt中 Recv-Q 长期大于 0 说明 accept 太慢工具层面怎么调都无效。5. TCP/UDP 测试工具的避坑清单五个高频翻车点与排查步骤5.1 UDP 测试“成功”了但目标端口根本没监听现象是客户端用 UDP 发送数据socket 不报错程序也显示“sent 100 bytes”。去看服务端发现日志里什么都没收到。原因是 UDP 面向无连接数据报发出后本端协议栈不会收到任何反馈如果中间路由器或目标机器防火墙静默丢弃发送端永远感知不到。解决步骤第一在目标机器上用ss -lunp | grep 9000确认进程真的绑定了端口第二在发送端执行tcpdump -i any udp port 9000抓包看报文是否离开本机第三再到接收端抓包如果连续抓一段时间接收端一无所获问题在网络路径或防火墙。解决了这三个位置中的哪一个UDP 测试结果才有意义。5.2 TCP connect 超时UDP 却一直有回应现象是同一台设备上 TCP 端口测试总是超时但 UDP 测试却能收到回包。很多人第一反应是服务端只开了 UDP。真实原因可能有两种TCP 和 UDP 是不同协议栈层级的服务服务端可能只监听 UDP也可能是防火墙只允许 UDP 而拦截了 TCP 的 SYN。排查时先执行nc -vz 目标IP 端口确认是否能拿到 succeeded。如果超时再换一个不常用的端口比如 50000 测试仍然超时基本可以断定是防火墙拦截。若不确定防火墙规则用nmap -sS -Pn -p 9000看端口状态输出是 filtered 就说明中间设备拦了 SYN。此时拿 TCP 测试工具反复重试没有意义正确方向是审计防火墙规则或服务端监听地址。5.3 回环地址测不出防火墙和路由问题现象是测试工具指向 127.0.0.1 或 localhost 时全部通过指向本机局域网 IP 时部分失败指向远程设备时基本失败。原因是回环流量从 lo 接口直接回到协议栈根本不走网卡驱动、防火墙入站规则和路由表所以测不出任何真实网络问题。解决方法是做分层测试先测127.0.0.1验证服务端程序本身可用再测本机局域网 IP验证监听地址是否绑到 0.0.0.0最后测跨主机 IP验证物理链路和防火墙。很多自动化测试工具配置里默认填 localhost上线前必须改成目标机器的真实 IP否则报告全是假阳性。5.4 丢包率忽高忽低顺序乱跳误以为网卡坏了现象是 iperf3 UDP 打流丢包率第一次 2%第二次 30%第三次 0%同时收到的报文顺序完全错乱。原因大概率不是网络坏了而是接收端操作系统的 UDP buffer 溢出。Linux 上 UDP 是尽力而为内核接收队列满后直接丢包而且不会通知应用层。先检查内核参数再下结论netstat -su | grep -i error cat /proc/sys/net/core/rmem_max cat /proc/sys/net/core/wmem_max如果 error 计数持续增长增大缓冲区通常能解决。临时调整可以这样sysctl -w net.core.rmem_max134217728 sysctl -w net.core.wmem_max134217728参数说明134217728 是 128MB适合高吞吐 UDP 测试。但要注意这个值会影响整个主机的内存占用别在低配机器上盲目调大。调整后重新打流如果丢包率明显下降说明问题在接收缓冲而不是链路。换到 Windows 环境时可以用netsh interface tcp show global检查 TCP 全局参数里的接收窗口自动调谐级别UDP 测试则没有对应命令只能靠第三方工具加大接收缓冲这也是 Windows 上 UDP 压测更容易丢包的原因之一。5.5 端口明明开着程序总报 Address already in use现象是服务端进程还在运行重启测试工具时 socket bind 抛 “Address already in use”。原因是上一个连接断开后有大量 TIME_WAIT 连接占用了端口对或者服务端进程没有从内核数据结构里彻底退出。解决方式是设置 SO_REUSEADDR这一点在第 3 章的代码里已经体现。但还有一个容易被忽略的变体如果测试工具同时开多个 socket 并发测试多个 socket 尝试 bind 同一个端口时即使设置了 SO_REUSEADDR 也可能会冲突此时需要用 SO_REUSEPORT。Python 里可以这样写sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) if hasattr(socket, SO_REUSEPORT): sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)加了之后多个进程可以共同监听一个端口内核会自动做负载均衡。不过这只是测试场景的解法生产服务如果不需要多进程监听不要随便开 SO_REUSEPORT会让连接分发变得难以追踪。遇到报错时先看ss -tlnp或lsof -i :端口找出占用方再做对症处理比盲目加参数更省时间。6. 进阶技巧把测试工具接进你的日常脚本与验收流程6.1 批量端口状态脚本与连续监控单机测试工具做得再好也只能解决“点对点”的问题。实际交付时最需要的是一次验证几十台设备的上百个端口。我习惯写一个批量探测脚本用 Python 的 socket 对清单里每个 IP:端口发起 TCP 连接并把结果输出成 CSV。核心片段如下import csv, socket, concurrent.futures targets [(192.168.1.10, 80), (192.168.1.11, 502), (192.168.1.12, 9000)] def check(item): host, port item try: with socket.create_connection((host, port), timeout3): return (host, port, open) except socket.timeout: return (host, port, timeout) except ConnectionRefusedError: return (host, port, refused) with concurrent.futures.ThreadPoolExecutor(max_workers50) as pool: results list(pool.map(check, targets)) with open(port_report.csv, w, newline) as f: writer csv.writer(f) writer.writerow([host, port, status]) writer.writerows(results)逻辑说明ThreadPoolExecutor 用 50 个并发线程同时探测单台设备不会拖垮整批扫描。每个探测的超时时间固定 3 秒如果目标数量很大建议把它做成配置文件而不是硬编码在代码里。6.2 连续监控看抖动还有一种常见场景是自动化测试过程中网络偶尔闪断普通测试工具跑一次无法捕捉。我给自研工具加过连续监控模式每隔 10 秒测一次共测 60 次把每次的耗时和状态写入日志。如果某几次耗时是平时的十倍以上即使没有连接失败这条链路也已经处于不稳定状态需要在交付报告里单独标注。这里要注意监控本身不能影响被测系统间隔别小于 5 秒否则测试流量本身就给链路上加了负载。6.3 我保留的两个习惯与一句忠告做 TCP/UDP 测试工具这两年我养成了两个习惯。第一个习惯是所有测试命令都留档包括参数、目标 IP、抓包文件、时间点不然售后问题来了只能靠回忆非常被动。第二个习惯是测试工具永远保留“原始输出”不要让 UI 或报告层过滤掉关键字段比如 TCP 重传次数、UDP 丢包率、ICMP 错误计数这些才是判断网络质量的硬指标。如果你也正在做类似的调试方案希望这几章的思路和代码能帮到你少踩几个我踩过的坑。本文还有配套的精品资源点击获取