简介面向IT开发、测试及运维人员的TCP/UDP网络调试工具包用于网络通信质量验证、传输异常定位、服务性能评估与协议学习实践。压缩包共收录14个文件整体大小约1.5MB以可执行主程序为入口配套动态链接库、初始化配置、图片素材、网页说明及文本说明等组件结构清晰、免安装解压即可运行。工具内建服务器与客户端模拟、自定义数据包收发、端口扫描、流量分析、丢包率与延迟计算等模块同时支持高并发压力测试可覆盖从基础连通性检查到复杂负载模拟的典型场景帮助定位网络瓶颈与数据异常。包内附带配置文件和使用文档便于快速掌握操作要点。已有2888人学习下载适合正在调试网络应用、开展TCP/UDP协议实验或负责网络环境维护的开发者、测试工程师与网管人员。1. TCPUDP测试工具不是“能通就行”是三层验证需求标题里的 TCPUDP 测试工具业内一般叫网络调试助手或 Socket 测试工具实际上一整类产品。做嵌入式、上位机、网关联调的人迟早会遇到这种时刻Modbus TCP 从站连不上、UDP 组播收不到、上位机收发大包就卡死。这时候手边没有趁手的 TCP/UDP 测试工具排查只能靠猜靠猜的生产效率是最低的。这类工具解决三层需求TCP 连接与三次握手是否正常、UDP 网络调试时包能不能发出去并收回来、吞吐量是否达标对应 iperf3 使用 UDP 打流这类指标。适合手里有网卡驱动、嵌入式协议栈或工业网关要验证的开发者。下面按选型、TCP、UDP、避坑、回归脚本的顺序落地每步都给可复现的命令。2. 从 SocketTool 到 iperf3TCP/UDP 测试工具的选型分界线2.1 连通性、打流、协议分析TCP/UDP 测试工具的三类定位与取舍先把话说清楚不存在一款工具能覆盖所有测试诉求。TCP/UDP 测试工具按用途分三类关注点完全不一样。第一类是连通性工具典型的有 SocketTool、NetAssist 这类图形界面助手还有 nc、ncat 这种命令行工具第二类是吞吐量工具代表作是 iperf3用来测带宽、丢包、抖动也支持 TCP 和 UDP 打流第三类是协议分析工具比如 Wireshark 和 tcpdump它们不主动发包而是抓包并把协议栈行为展开给你看。很多新手拿着 SocketTool 测吞吐拿着 iperf3 找握手问题方向从一开始就错了。我的习惯是先判断需求如果只是验证设备能不能建立 TCP 连接、能不能互发一条自定义报文图形工具和 nc 足够如果要回答“这个网关能不能跑满 100M”必须用 iperf3 这类打流工具因为图形工具是手动发包没有吞吐量和重传统计如果连得上但业务不通就要进第三类抓包看看到底是握手问题还是应用协议问题。工具类别代表工具适合回答的问题不适合连通性验证SocketTool、NetAssist、nc、ncat能建连吗能互发吗吞吐量、抖动、重传吞吐量测试iperf3带宽多少丢包率重传协议语义、报文格式协议分析Wireshark、tcpdump握手了吗报文结构ACK 顺序主动发包、压力测试选型还要看被测对象。目标设备是单片机这类资源受限设备时优先用命令行工具因为它没有图形界面额外开销也不会因为界面刷新影响发包节奏。Windows 下 nc 可以用 ncatNmap 套件里的版本替代参数基本一致。联调现场还有个隐性成本图形工具点一下发一包统计口径不统一而命令行工具的输出天然是文本方便直接归档这一点在写回归脚本时会体现出来。2.2 iperf3 做 TCP 打流三个必调参数与一组可靠命令iperf3 是所有 TCP/UDP 测试工具里我最先装的。它一个进程做服务端一个进程做客户端默认走 TCP测的是 TCP 流量能跑到多大。先看一组最常用的命令# 服务端先启动 iperf3 -s -p 5201 # 客户端压测 60 秒每 5 秒输出一行 iperf3 -c 192.168.1.100 -p 5201 -t 60 -i 5 -P 4第一个必调参数是 -p指定监听端口。默认 5201设备上容易跟别的服务撞建议显式写一个。第二个是 -t控制测试时长默认只有 10 秒。测无线或者波动大的链路建议拉到 60 秒以上否则采样样本太小结果不具代表性。第三个是 -i输出间隔设 5 秒能把过程曲线拉出来而不是只给一个最终值。最后 -P 是并发连接数4 条并发能看出设备的多连接处理能力但注意不是越大越好很多嵌入式设备的协议栈并发上限很低拉到 8 可能直接触发资源不足。如果被测设备是服务端客户端连过去要测设备往客户端发包的方向加 -R 参数做反向。常见误用是忽略 -R只看到设备侧接收带宽高就以为设备发送没问题实际上很多设备的收发能力不对称。读 iperf3 输出时注意三个字段Bitrate 是瞬时带宽Retr 是 TCP 重传次数Cwnd 是拥塞窗口。局域网里 Retr 应该接近 0如果持续增长先怀疑网线、网卡协商速率再怀疑对端协议栈接收缓冲区太小至于 MSS/MTU 不匹配导致的半连接和重传风暴在这类场景里概率低但也要排掉。2.3 自研测试工具的两种路径Python 够了C# 什么时候值得上商用工具再好遇到私有协议或者特殊报文格式时还是免不了自己写。自研 TCP/UDP 测试工具最省钱的方式是 Python标准库 socket 就够了。下面这个例子是一个带 echo 功能的 TCP 服务端验证设备能不能正确处理连接和回包。import socket # TCP 服务端监听 0.0.0.0兼容本机与局域网访问 srv socket.socket(socket.AF_INET, socket.SOCK_STREAM) srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) srv.bind((0.0.0.0, 9000)) srv.listen(5) while True: conn, addr srv.accept() data conn.recv(1024) print(frecv from {addr}: {data!r}) conn.send(bok) # 收到什么回什么用于联调 conn.close()逻辑说明这段代码先建 IPv4 TCP socketSO_REUSEADDR 允许端口被重复绑定listen(5) 表示内核里最多排队 5 个待 accept 的连接。recv(1024) 并不保证一次收全TCP 是字节流这条在后面的粘包小节会展开。bind 的地址用 0.0.0.0 而不是 127.0.0.1目的是让局域网设备也能连进来这是联调现场最容易踩的坑之一。上位机或者 Windows 桌面上更常见的是 C#。C# 的优势在于多线程方便异步收发写起来比 Python 直观而且如果要处理 C# UDP 发送分包组包、可视化波形这类需求C# 的生态更合适。但 C# 自研工具的启动成本高要建工程、处理依赖不如 Python 一个文件就能跑。我的建议是少于 200 行的验证逻辑用 Python需要打包分发、跟硬件交互复杂的再上 C#。工具本身不必有界面很多联调场景下控制台程序比窗体程序可靠界面刷新反而可能影响发包时序。3. 用日志和抓包验证 TCP 三次握手先排除协议栈再排业务3.1 本地跑通一个 TCP 连接nc 最小命令与验证步骤TCP 测试的第一步是在本机先把连接跑通排除网络因素。用 nc 是最快的# 终端 A监听 8080 端口 nc -l 8080 # 终端 B连接本机 nc 127.0.0.1 8080终端 A 出现 nc 进程不退出说明 TCP 连接已经建立。这时从终端 B 敲一行字符终端 A 能收到说明数据通路也是通的。这个最小步骤能验证本机协议栈和防火墙状态。注意如果终端 A 的 nc 立即退出通常不是连接失败而是端口被占用或者防火墙把入站连接丢了接下来要用抓包判断。这里要区分 connect 和 accept 两个概念。测试工具显示的 TCP 连接建立指的是三次握手完成即客户端收到服务端的 SYN-ACK 并回出 ACK 的时刻。对服务端而言TCP 连接还要经过 accept 才进入可读写状态。有些工具把 listen 成功也标成已连接这是误读。联调时设备侧日志往往只打到 accept没显示 recv而电脑侧工具已经显示 Connected这不矛盾是两边对“连接”的定义不同。端口号的选择也有讲究。低于 1024 的端口在 Linux 下需要 root 权限绑定Windows 下有些端口被系统服务保留。联调时我一般选 8080、9000、10000 这类高位端口避开 Modbus TCP 的 502、HTTP 的 80 这类知名端口防止别的服务干扰判断。如果用的是 W5500 这类硬件协议栈芯片TCP 连接状态对应用不可见只有几个寄存器状态位这时候 nc 的外部观察就更重要。3.2 从测试工具日志与抓包反推三次握手细节当工具显示连接成功但业务不通时最可靠的办法是抓包。Windows 下用 WiresharkLinux 下用 tcpdump命令如下# 抓 eth0 上访问 8080 端口的所有包不解析域名 sudo tcpdump -i eth0 tcp port 8080 -nn -S -c 20参数说明-i eth0 指定网卡-nn 不做域名和服务名解析直接显示 IP 和端口号-S 显示绝对序列号而不是相对序列号-c 20 抓到 20 个包自动退出。抓包结果里最该注意的是前三个包对应 TCP 三次握手22:09:33.440126 IP 192.168.1.10.50000 192.168.1.100.8080: Flags [S], seq 1000 22:09:33.440187 IP 192.168.1.100.8080 192.168.1.10.50000: Flags [S.], seq 2000, ack 1001 22:09:33.440191 IP 192.168.1.10.50000 192.168.1.100.8080: Flags [.], ack 2001第一个包 Flags [S]SYN客户端发起握手第二个包 Flags [S.]服务端回 SYN-ACK 并捎带 ACK第三个包 Flags [.]客户端回 ACK。看到这三个包TCP 连接才算真正建立。如果只有前两个第三个丢了多半是客户端发出的 ACK 被本地防火墙拦掉或者客户端协议栈重置了连接界面上的表现就是连接卡在 connecting。现实中常见的第二种情况是第二个包重传多次说明服务端根本没收到 SYN或者网卡驱动把包丢了。工具界面看不到这些只能靠抓包定位。如果业务层有自定义协议还需要在抓包里看应用层长度字段对不对。很多接口测试工具会在功能设计里内建抓包能力就是因为黑盒联调时应用日志经常不够用。TCP 测试工具做得好不好看它能不能在三次握手之后继续把数据面抓清楚而不只是画一条连接成功的绿线。3.3 粘包与拆包TCP 测试工具最容易误判的现象TCP 是字节流协议没有消息边界。测试工具按固定 recv 大小收数据就可能出现两条应用消息粘在一起粘包或者一条消息被拆成两截拆包。这不是 bug是 TCP 的固有行为。测试工具如果把 recv 到的一段数据直接当一条消息解析日志就会错乱。复现粘包很容易写一个循环向同一个 TCP 连接连续发送多条短消息接收端一次性 recv就可能合并收到。下面这段服务端代码专门展示这个现象import socket srv socket.socket(socket.AF_INET, socket.SOCK_STREAM) srv.bind((0.0.0.0, 9001)) srv.listen(5) conn, addr srv.accept() # 一次 recv 可能收到多条业务消息也可能只收到半条 buf conn.recv(1024) print(frecv {len(buf)} bytes: {buf!r}) conn.close()这段代码的问题在于用 recv(1024) 一次读取的数据作为消息边界。客户端连续发送 bhello 和 bworld服务端一次 recv 很可能拿到 bhelloworld这就是粘包。反过来客户端发一条 3000 字节的消息服务端 recv(1024) 只能拿到前 1024 字节必须循环读取。C# 的 NetworkStream 也一样Read 方法只保证读到数据不保证读全消息C# TCP 粘包处理的常规方案是自定义长度前缀或结束符。验证工具有没有处理粘包可以故意构造连续短消息观察工具的解析结果。如果工具把两条消息的内容拼在一起说明它没有做边界处理。这一条在 TCP 测试工具选型时特别值得留意很多开源小工具在这一步就翻车。协议栈是 lwIP 这类嵌入式实现时粘包现象会更频繁因为设备侧往往一收到数据就立刻上报不攒包细微的收包时序差异都会影响测试工具的判断。4. UDP 网络调试的实测路径从打流指标到组播绑定4.1 iperf3 的 UDP 打流带宽、抖动、丢包率怎么设UDP 和 TCP 不一样没有握手、没有重传、没有拥塞控制。这带来一个直接后果测试工具看到的丢包率不一定是链路的真实丢包率也可能是接收端处理不过来丢的。iperf3 在 UDP 模式下的输出有三个关键指标带宽Mbits/sec、抖动Jitter、丢包率Lost/Total Datagrams。# 服务端 iperf3 -s -p 5202 -u # 客户端限制 20Mbps报文 1400 字节测 30 秒 iperf3 -c 192.168.1.100 -p 5202 -u -b 20M -l 1400 -t 30 -i 3参数说明-u 切到 UDP 模式-b 20M 限制发送码率-l 1400 指定 UDP 负载长度-t 30 测 30 秒-i 3 每 3 秒输出一次。为什么把负载设成 1400因为常见 MTU 是 1500IP 头 20 字节、UDP 头 8 字节留给 UDP 负载最多 1472 字节。设 1400 留了余量避免物理帧触发 IP 分片。如果设超过 1472比如 2000发送端会把 UDP 报文拆成多个 IP 数据报片接收端重组时只要一片丢了整包就丢丢包率会被严重放大。解读结果时的常见误区链路丢包率应该看 Lost/Total Datagrams 的比例而不是 Jitter。Jitter 反映到达时间间隔的均匀程度对 VoIP 这类实时应用重要对文件传输不重要。-b 设得太高时 iperf3 显示丢包率飙升不代表链路差只说明发送速率超过了链路或接收端处理能力。正确做法是逐步抬高 -b找到丢包率开始抬头的临界点这个值才是链路的实际可用带宽。Windows 下如果还同时看到 read udp: unknown error (code10054)底层往往是收到了 ICMP Port Unreachable也就是对端没有进程监听这个端口不是链路问题不要在防火墙排查上浪费时间。4.2 超过 MTU 的 UDP 包C#/Python 分包与组包的常规做法设备联调中常有“发大包”的需求比如一帧 4KB 的传感器数据封装进 UDP。操作系统允许你一次 sendto 发送 4KB底层会自动做 IP 分片但这会引入两个坑分片重组有超时限制丢一片毁全包。可靠的 UDP 网络调试方案是在应用层主动分包把 4KB 数据切成每片不超过 1472 字节的块每片带序号接收端按序号拼接。下面用 Python 演示最小分包发送逻辑。实际工程里 C# UDP 发送分包组包的做法类似区别在 Socket 类型和字节处理 API逻辑一致。import socket, struct data bytes(range(256)) * 16 # 4KB 模拟业务数据 MAX_PAYLOAD 1400 udp socket.socket(socket.AF_INET, socket.SOCK_DGRAM) seq 0 for off in range(0, len(data), MAX_PAYLOAD): chunk data[off:off MAX_PAYLOAD] # 帧头2 字节序号 1 字节标志0x01 表示还有后续0x00 表示结束 frame struct.pack(HB, seq, 0x01 if off MAX_PAYLOAD len(data) else 0x00) chunk udp.sendto(frame, (192.168.1.100, 9002)) seq 1逻辑说明struct.pack(HB, ...) 把序号和结束标志打包到帧头H 是 2 字节大端无符号整数B 是 1 字节无符号整数。分包粒度不能压在 1472 极限因为某些路由器会额外加 VLAN 标签或 PPPoE 头负载按 1400 留余量是安全做法。seq 从 0 递增接收端靠它判断分片是否乱序、是否丢失。接收端要按序号把分片塞进缓冲区等收到标志为 0x00 的结束片后拼起来。这里有个取舍等所有分片到齐再拼还是先拼已到的。工业应用一般选择先等因为 UDP 没有重传机制完整帧才上报业务层否则丢弃整帧并计数。测试工具必须把这种“整帧丢弃”设计进去不能收到一片就上报一条消息。C# 里组包常用 Dictionaryushort, byte[] 做分片缓存注意设置超时清理防止序号越界。4.3 IGMP 组播测试地址、端口与网卡绑定三件事UDP 组播在设备联调里很常见多台设备同时监听一个组播地址就能收到同一条数据。IGMP 负责管理组成员关系测试工具要做组播必须处理三件事选对组播地址、加入组播组、绑定正确网卡。组播地址常用 239.0.0.0/8 这个管理范围段或者 224.0.0.0/24 的本地链路段。区别在路由器是否转发本地链路段组播包不会被路由器转发适合局域网239 段要看路由器 IGMP 配置。测试前先想清楚目标设备在哪个网段否则出现“工具显示发送成功设备没反应”就无从下手。发送端在常见 Linux 发行版上不 join 组也能 sendto而接收端必须 join 才能收到这是很多 UDP 工具界面上不提示的隐藏逻辑。多网卡机器上加入组播必须指定网卡 IP。下面这段代码是标准做法import socket, struct # 接收端加入组播 sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) sock.bind((0.0.0.0, 9003)) # 指定从这个网卡加入组播组多网卡环境必须写 mreq struct.pack(4s4s, socket.inet_aton(239.1.1.1), socket.inet_aton(192.168.1.10)) sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq) while True: data, addr sock.recvfrom(2048) print(frecv {len(data)} bytes from {addr})参数说明IP_ADD_MEMBERSHIP 把 socket 加入组播组mreq 里第二个 IP 是本地网卡地址。bind 地址必须写 0.0.0.0 而不要写 192.168.1.10否则设备只会收发往本机 IP 的包导致收不到组播包。SO_REUSEADDR 在 UDP 组播里几乎是必需的否则多个进程同时监听同组会报端口占用。实际联调中组播“收不到”的第一排查点不是防火墙而是 join 组时有没有绑对网卡。Windows 下用 ipconfig 确认网卡 IP再对照 mreq 里的地址。5. 避坑TCP/UDP 测试工具最常见的 5 个翻车现场5.1 现象connect 成功但业务不通发出去对方没反应测试工具显示 TCP 连接已建立但发什么对端都没回。最常见的原因是对端 accept 之后没有进入收发循环连接只是挂在半空或者对端是自定义协议栈因为窗口大小协商不一致直接丢弃数据。用 lwIP 这类嵌入式协议栈时资源紧张还会出现连接被半开、内核收下数据但应用层取不到的情况。解决先用 tcpdump 在两端分别抓包看数据有没有进入对端网卡。进了但没回问题在对端应用层比如 Modbus TCP 的单元标识符对不上、帧长度算错。如果没进问题在中间设备或防火墙。关键经验是不要因为 connect 成功就跳过抓包三次握手只保证连接建立不保证应用层协议正确。5.2 现象UDP 丢包率忽高忽低同一参数重复测结果差异很大原因是多数 UDP 测试工具不做流量控制发太快时接收端 UDP 接收缓冲区溢出内核直接丢包。缓冲区大小由系统参数决定Linux 下是 net.core.rmem_max 和 net.core.wmem_maxWindows 下默认值常常只有几十 KB。解决先看测试工具有没有缓冲区设置。iperf3 用 -w 设置窗口大小对 UDP 也有效。如果缓冲区已调到最高还是丢再逐步降低发送速率 -b找到稳定区间。不要用一次测试结果下结论至少取三次看丢包率方差方差大基本可以断定是接收端处理不过来而不是链路质量问题。Windows 下如果报错 read udp: unknown error (code10054)也是对端不可达的 ICMP 反馈不是丢包率本身。5.3 现象本机测试结果好得可疑带宽打满、零丢包用 127.0.0.1 或 localhost 做性能测试结果几乎都是虚高。原因在于回环接口不走物理链路也不经过网卡驱动MTU 限制基本不存在操作系统直接把数据从一个 socket 拷到另一个 socket。解决凡是涉及吞吐量、丢包率的测试地址必须写对端设备的局域网 IP不要用 localhost。连通性验证可以用回环性能测试绝对不能用。如果两端在同一台电脑但属于两个不同网卡比如虚拟网卡和物理网卡那还有点意义但也测不出真实网络设备的行为。这一条是很多人翻车后才发现的基础认知测试报告里一定要标注地址。5.4 现象UDP 组播在 Windows 上收不到但 ping 同一个组播地址却能通Windows 防火墙默认会拦截入站的 UDP 组播流量即使你放行了某个固定端口的 TCP组播也不受影响地挡在门外。另一个隐蔽原因接收端没有加入组播组就开始 bind部分网卡驱动不重新加载时不会主动补发 IGMP 报告。解决先在防火墙里放通 UDP 端口或临时关闭防火墙做对照测试确认是防火墙再按端口放行。其次接收端必须先 join 组播组再进入接收循环同时确认接入交换机有没有启用 IGMP snooping开启后没有及时上报成员关系的端口会被过滤掉组播包。5.5 现象bind 报“地址已被占用”服务明明没启动TCP 连接断开后主动关闭的一端会进入 TIME_WAIT 状态持续约 2 分钟这期间端口并未释放。测试工具频繁重启服务端时最容易撞上这个窗口表现为 bind 失败但 netstat 里看不到 LISTEN 状态的进程。解决代码里加上 SO_REUSEADDR 选项Python 和 C# 都支持。命令行工具如 nc 一般不支持这个选项那就等 TIME_WAIT 超时或者换个端口继续测。区分方法是 netstat -ano 看端口是 TIME_WAIT 还是 LISTEN两种情况处理方式不同不要一上来就杀进程。6. 把 TCP/UDP 测试固化成一个 5 分钟可判读的回归脚本上面这些操作都是手动过程但 TCP/UDP 测试工具真正的价值在于自动化。我把联调中常用的验证动作固化成一个 bash 脚本每次改完协议栈或者固件都跑一遍5 分钟内得到一份客观结果#!/bin/bash # 1) TCP 连通性探测 nc -z -w 3 192.168.1.100 502 echo TCP 502 OK || echo TCP 502 FAIL # 2) TCP 吞吐压测 30 秒结果落盘 iperf3 -c 192.168.1.100 -p 5201 -t 30 -i 5 tcp_result.txt # 3) UDP 打流 50Mbps观察丢包 iperf3 -c 192.168.1.100 -p 5202 -u -b 50M -t 30 udp_result.txt # 4) 抓包留档备查 sudo tcpdump -i eth0 tcp port 502 -nn -c 50 -w tcp_502.pcap脚本的重点是第 2 步和第 3 步的判读。我一般不看单个数字而是定三条边界TCP 重传次数不超过 5 次UDP 丢包率不超过 0.1%带宽不低于链路理论速率的 80%。三条里有两条不过就直接打开保存的 pcap 文件分析不再重复手动点工具。这个流程我现在每个项目都在用。它的价值不是替代调试而是把重复劳动变回验证把每次的问题留在归档里供下次对比。用熟了以后你会发现真正耗时间的往往不是工具本身而是把工具用对的过程。希望帮到你。本文还有配套的精品资源点击获取