简介：TCP&UDP测试工具是一份免安装的网络调试实用程序，面向网络工程师、嵌入式开发人员和协议学习者，用于验证TCP/UDP通信、排查网络故障并评估传输性能。压缩包共13个文件，体积仅1.5MB，包含TCPUDPDbg.exe主程序、XTP9700Lib.dll运行库、update.EXE辅助更新程序、config.ini与UpdateLang.ini配置文件，以及intro.htm网页说明、style.css样式和若干图片等，结构精简，解压后即可运行。工具支持自定义源/目标地址、端口、数据包大小与传输速率，并可进行吞吐量、延迟、丢包等测试，既可模拟真实网络压力，也能帮助发现协议配置漏洞。目前已有380人学习下载，适合在网络调试、服务端性能评估及安全测试场景中快速搭建测试环境，提升排错效率。 做嵌入式、上位机或者设备联调的工程师，桌面上绝对少不了网络调试工具。今年年初我调试一批Modbus TCP设备的协议对接时，用网上下载的工具总觉得差口气——有的只支持TCP不支持UDP，有的切个模式要重启程序，还有的界面停留在十年前。后来我索性自己写了一个TCP&UDP测试工具，支持TCP服务端/客户端、UDP单播收发、Hex/ASCII显示、定时发送和压力打流，陆陆续续用到现在，帮同事解决了不少奇怪的网络问题。这篇就把工具的设计思路、核心代码和实测中踩过的坑整理出来，给打算自己动手做同类工具的朋友一个参考。
1. 为什么还要自己写一个TCP&UDP调试工具
市面上的网络调试助手其实不少，我过去常用的几款各有各的问题。有一些是只支持TCP，UDP部分要单独下载另一个工具，甚至干脆不支持广播；有一些虽然TCP和UDP都能测，但切换模式的时候必须重启程序，参数配置每次都要重新填一遍，在设备调试的高频操作场景下非常烦人。最关键的是，大部分老牌工具基本不更新了，Windows 11高分屏下界面模糊、DPI缩放错位，看着难受，用着更难受。
这不是说现成工具不能用，而是在真实调试场景中，你需要的不只是一个"能发能收"的窗口，而是一个能配合你的节奏、能按你的思路来布局的工具。比如我调试设备时最常用的操作流程是：先UDP广播搜设备、拿到设备IP后切TCP连接、发十六进制命令、看返回帧。市面上几乎没有工具能把这三步流畅串起来。自己写一个，才能真正按自己的习惯来。
另一个原因是学习价值。网络调试是一个典型的"原理清楚但实操容易翻车"的领域，TCP三次握手、四次挥手、粘包、广播、防火墙拦截，这些概念背得再熟，真到了设备连不上、数据收不到的时候，还是得靠工具一层层排查。自己动手写一遍收发逻辑，比看十遍协议文档管用得多。
2. 工具的核心设计：先分清TCP和UDP的脾气
写这个工具之前，我先把TCP和UDP两种协议的特性差异理了一遍，因为这直接决定了界面怎么布局、代码怎么写、底层的socket收发逻辑怎么组织。
2.1 TCP必须做连接状态管理
TCP是面向连接的、可靠的字节流协议。所谓"面向连接"，体现在通信之前必须通过三次握手建立连接，通信结束要四次挥手释放连接。这个特性放在测试工具里，意味着你必须有完整的连接状态机：监听中、已连接、连接断开、重连中，每一种状态都要有清晰的UI展示，不能只让用户看到一个socket句柄。
实际体验下来最痛的一点是TCP的数据流没有边界。你用一次send调用发200个字节，对方收的时候可能分两次收，一次收120字节，一次收80字节。这对调试工具来说意味着：显示层要能区分"这是同一个流里的哪一段"，得靠工具里记录起始位置、加上时间戳和接收序号。很多新手第一次用TCP调试工具看到数据被拆成好几条，还以为是丢包了，其实是TCP流式传输的正常现象。
2.2 UDP是无连接不等于不需要管理
UDP就简单粗暴多了，没有握手、没有连接，一个socket绑定好本地端口之后，谁来都能发，谁发都能收。但也正因为无连接，调试工具需要额外处理两件事：一是对端地址和端口的记录，UDP包每个报文都可能来自不同地址，工具要把来源IP和端口带出来显示，否则收了一堆包根本不知道是谁发的；二是广播地址的支持，搜设备、发现服务这类的场景经常要向255.255.255.255发广播，socket必须设置SO_BROADCAST，否则直接报错。
还有一点容易被忽略：UDP虽然不保证可靠，但它保留消息边界。发一个报文收一个报文，多少字节发的就多少字节收到，不可能出现TCP那样的"半包"。这个差异在界面设计上体现为：TCP模式下接收区适合按"流"来渲染，UDP模式下更适合按"报文"一条一条列出来。
2.3 界面布局按调试流程来
我最终把界面分成了三个核心区域：
- 连接参数区：协议类型选择（TCP客户端、TCP服务端、UDP单播、UDP广播）、本机地址和端口、目标地址和目标端口、连接/断开按钮。
- 数据收发区：接收区在上、发送区在下，每条数据带时间戳。Hex和ASCII双模式切换按钮放在正中间，随手就能点。
- 状态与日志区：显示连接状态变化、socket错误信息、发送/接收字节计数、收包速率。
这个布局比那些把所有配置塞进弹窗的工具直观得多。参数调整、发送数据、看返回三个动作在同一屏里完成，鼠标移动距离最短，实测在设备联调场景下效率提升非常明显。
3. 技术选型与关键实现逻辑
工具的价值在设计，落地的关键在实现。我梳理一下几个核心决策背后的考量。
3.1 为什么选Python + PyQt5
方案对比过几个：
- C++ + Qt：性能好、编译成独立exe体积小，但开发效率低，改一个UI布局要重新编译，调试迭代太慢。
- C# + WinForms/WPF：Windows下体验不错，但跨平台要折腾Mono或.NET Core，而且我主要开发环境并不全在Windows上。
- Python + PyQt5：开发速度快、跨平台、socket库成熟、PyInstaller打包方便。虽然Python的GIL和解释器性能有上限，但网络调试工具瓶颈通常在UI刷新和数据渲染上，不在socket收发本身。
我最后选了Python + PyQt5。实际用下来，代码量比C++版本少一半不止，UI调整只需改布局后直接运行，调试效率完全不是一个量级。性能方面，在千兆局域网内做高速UDP打流测试时，接收线程丢包率比UI线程刷新率低得多，瓶颈在QPlainTextEdit的文本渲染上，这个后面有专门的优化方案。
3.2 收发线程与UI解耦是重中之重
这是整个工具最容易翻车的地方。如果你把socket的recv循环直接写进UI线程，一旦数据量大或者对端不发数据，界面立刻卡死，按钮点了没反应，窗口拖动都成问题。正确做法是把socket收发放到QThread后台线程里，数据通过信号量跨线程传递给UI线程更新。
下面是UDP接收线程的核心代码，我把关键部分贴出来：
import socket import select from PyQt5.QtCore import QThread, pyqtSignal class UdpWorker(QThread): data_received = pyqtSignal(bytes, str, int) # 数据、来源IP、来源端口 def __init__(self, local_addr, local_port, parent=None): super().__init__(parent) self.local_addr = local_addr self.local_port = local_port self._stop = False self.sock = None def stop(self): self._stop = True def run(self): self.sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) self.sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) self.sock.bind((self.local_addr, self.local_port)) while not self._stop: ready = select.select([self.sock], [], [], 0.1) if ready[0]: data, addr = self.sock.recvfrom(65535) self.data_received.emit(data, addr[0], addr[1]) self.sock.close()这里有两个细节值得说明。第一，用select.select而不是socket.settimeout来控制超时。select的第四个参数传0.1秒，意味着每100毫秒检查一次是否有数据到达，没有就继续循环，同时顺手检查self._stop标志位。这样线程退出时最多延迟100毫秒，不会出现recvfrom永远阻塞导致程序无法退出的问题。第二，绑定socket前设置SO_REUSEADDR，这个选项能避免端口被之前的进程占用时bind报错，在Windows和Linux下的行为虽然略有差异，但对调试场景来说利大于弊。
TCP线程的结构类似，只不过多了一个accept步骤。TCP服务端模式下，线程里先listen，然后accept阻塞等待客户端连接，连接建立之后走和UDP一样的select循环收数据。
3.3 Hex/ASCII双模式显示的数据处理
做协议调试的人应该都有体会：Modbus、私有串口转网络协议动不动就是二进制帧，看ASCII全是乱码，这时必须切成Hex视图。而调试HTTP、MQTT这类文本协议时，Hex视图又不够直观，要看ASCII。
我的实现是在UI层维护一个字节缓冲，收到数据先追加到缓冲，然后根据当前模式重新渲染显示区。这里做了一个性能优化：当显示模式切换时，不需要重新从socket拿数据，只需要把同一个缓冲区用不同的编码方式渲染一遍。TCP的调试工具几乎都支持这个，但很多工具实现得很粗糙——切换模式时把历史数据清空了，非常坑，你调试了半天突然发现之前收到的关键帧没了。
渲染逻辑其实不复杂，核心思路是每行限制显示16字节，类似Wireshark的排版：
def format_hex_dump(data: bytes) -> str: lines = [] for i in range(0, len(data), 16): chunk = data[i:i+16] hex_str = ' '.join(f'{b:02X}' for b in chunk) ascii_str = ''.join(chr(b) if 32 <= b <= 126 else '.' for b in chunk) lines.append(f'{i:08X} {hex_str:<48} {ascii_str}') return '\n'.join(lines)每行左边是偏移量，中间是十六进制字节，右边是对应ASCII可打印字符。这样一条完整的报文几百个字节也不会显得乱，一眼能看出帧头、长度、CRC这些关键字段的位置。
3.4 发送功能的设计
发送区我做了三件事：定时发送、循环发送、发送计数。定时发送的间隔可以精确到毫秒级，用QTimer实现；循环发送和定时发送的区别是循环发送在收到响应后才发下一条，适合做请求-响应模型的协议压力测试。这三件事合在一起，才能在真实调试场景里覆盖"手动发一条看看返回"、"按固定频率持续灌数据"、"请求-响应循环压测"三种不同的需求。
4. 实测场景：这些坑都是用真金白银踩出来的
工具写完之后，我在几个真实场景里做了验证。每个场景都出过一些幺蛾子，最后定位到的原因都记录在这里。
4.1 WSL2与Windows的UDP互通
热搜词里有一条是"wsl2的ubuntu与window的udp通讯"，这个场景我确实碰上了。WSL2默认走NAT模式，虚拟网卡和宿主机不在同一个二层网络里，直接按传统局域网思路配IP是行不通的。实测下来最稳的做法是：Windows上的调试工具监听某个端口，WSL2里的进程直接往宿主机的IP发UDP包。这里有个陷阱——Windows这边如果防火墙拦截了UDP入站，WSL2发过来的包会被静默丢掉，工具啥都收不到。排查这一层花了我半天时间，最后在防火墙的高级设置里给Python进程放行了专属网络的入站规则才解决。
反过来测也一样：WSL2里跑UDP服务端，Windows里用工具去连localhost加对应端口就能通，这是WSL2的localhost转发机制在起作用。但如果工具连的是虚拟机IP而不是localhost，就得先确认WSL2的IP有没有变化——WSL2重启后IP通常会变，写脚本自动化的时候这个坑会反复踩到。
4.2 Modbus TCP调试
这个场景是最能体现Hex视图价值的。我调试一台支持Modbus TCP的传感器时，用工具模拟Modbus客户端，手动构造读保持寄存器的请求帧：00 01 00 00 00 06 01 03 00 00 00 01。前两个字节是事务标识符，第三个字节是协议标识符（Modbus固定为0），第5和第6字节是后续长度，然后依次是单元号、功能码、起始地址和寄存器数量。这些字段拆开看非常清晰，但在ASCII视图下直接显示成一段乱码。
实测出问题的点是：很多Modbus从站设备在收到格式错误的请求时会直接静默丢弃，不做任何响应。发送端看起来"发出去了"，但接收区永远空着。这时候工具里的收包计数就派上用场了——如果你确认发送计数在增加但收包计数一直是0，多半是对端设备根本没处理你的请求，要么帧格式有问题，要么功能码不支持，或者设备配置里没开启Modbus TCP服务。有了计数区分，排错范围大大缩小。
4.3 TCP服务端模式下的设备主动连接
有些设备是客户端模式，主动向你的服务端发起连接。这时候工具的TCP服务端模式就很重要。我调试过一款工业扫码枪，设置好目标IP和端口后它会主动连接。但头疼的是设备固件有bug：只有每次重启后才能连上一分钟，之后连接就断掉且不再重连。这个场景里，工具必须清晰展示连接状态变化的时间点、断开时是否有socket错误信息，以及能否自动监听等待设备重新连接。
实测下来，服务端模式监听成功后，工具会显示"等待客户端接入"，设备连上后变成"已连接 192.168.1.50:5000"，断开时记录断开时间点和错误码。配合日志区，很快就定位到是设备侧在连接建立后发送了一个非法握手包，导致我这边的服务端把连接关掉了。要不是工具把socket错误信息完整记录出来了，光靠抓包软件排查，花费的时间绝对是翻倍的。
4.4 局域网设备发现的UDP广播
搜设备是UDP广播最常见的用途之一。我在工具里做了广播模式：发送目标地址填255.255.255.255，自动设置SO_BROADCAST，点击发送后局域网内所有监听该端口的设备都会响应。
这个场景的坑是设备响应回来后，你要能分辨它到底是从哪个IP发的包。UDP接收必须把来源IP和端口显示出来，我在接收区每一行前面都加了来源IP:端口前缀，这样设备的广播搜索响应一到，立刻就能看到设备地址，不用再另开一个抓包工具去查。这个设计帮我节省了大量时间，也成了我在调试其他设备时最依赖的功能。
5. 踩坑实录：从这几个问题里提炼的经验
5.1 端口绑定的冲突与SO_REUSEADDR
写过网络程序的人对这类报错应该不陌生：error: listen tcp 127.0.0.1:11434: bind: only one usage of each socket addre。这是Windows上的典型错误——上次进程没有正常关闭，或者端口处于TIME_WAIT状态，导致bind的时候地址被占用。
测试工具这类经常要反复启动退出的程序尤其容易踩中。我的解决办法有两层：第一，socket创建后立即设置SO_REUSEADDR，C语言里是setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt))，Python里就是前面代码里的sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)。第二，工具启动时如果检测到bind失败，自动弹出提示并把端口号加1再试一次，减少手动改参数的次数。
5.2 大流量打流时界面完全卡死
用iperf3的人都知道，UDP打流能轻松跑到几百Mbps。如果测试工具在打流的同时把每个收到的包都实时显示到QPlainTextEdit里，界面卡死是必然的。因为文本控件的刷新效率远跟不上网络包到达的速度。
我实测跑100Mbps UDP打流时，接收线程每秒收到约8000个包。如果每个包子都触发一次UI刷新，控件根本渲染不过来。解决方案是引入缓冲和刷新合并：接收线程收到数据后只往Python队列里塞，UI线程用QTimer每200毫秒批量取一次队列里的数据，一次性批量追加到显示区。这样即使数据量很大，界面也只是每隔200毫秒刷新一次，不会逐包刷新导致卡顿。
这里还有一个隐藏问题：在打流场景下全部字节都显示本来就毫无意义，重点看的是速率、丢包率、有没有错序。所以我给工具加了一个"统计模式"，开启后接收区不再逐字节显示，而是显示当前接收速率、累计字节数、包计数。这样既能完成打流测试的观测需求，又彻底绕开了UI渲染瓶颈。
5.3 TCP粘包/半包在调试工具里的呈现
测试工具经常被不懂TCP流特性的人冤枉。我在给同事演示时，经常听到"怎么我发一次它显示出来两条？"这种问题。TCP是流协议，底层会把多次send的数据合并（粘包），也可能把一个大数据块拆成多段（半包）。这是TCP的固有行为，不是工具或者设备的bug。
工具能做的是把这些信息呈现得更清楚。我实际的方案是：TCP接收区每条记录都加上"第N次接收、N字节、时间戳"，同时在日志区提示"数据可能被分片到达"，让用户在调试时能意识到这是TCP流特性。真正要做协议解析的人，应该在自己代码里做缓冲和帧重组，而不是指望调试工具帮你把TCP流还原成完整的应用层报文——这不是调试工具的职责范围。
5.4 WSL2场景的防火墙是隐藏杀手
前面提到WSL2与Windows互通时，防火墙是最大的隐藏杀手。Windows防火墙默认对入站UDP非常敏感，即便程序绑定的是局域网内网IP，也可能被拦。WSL2里访问Windows宿主机的UDP端口时，实际上是从虚拟交换机发往宿主机网卡，这条路径上防火墙规则有时会对非localhost的入站流量生效。
排查时可以临时在防火墙的高级设置里新增一条入站规则，或者直接把专用网络（Private network）的防火墙关掉试一下。关掉防火墙只是为了定位问题，定位确认之后要记得开回来并配置好精确的放行规则，不要图省事一关了之。
5.5 高频定时发送的精度陷阱
定时发送我一开始用time.sleep()来实现，实测发现误差很大。原因很简单：sleep的精度受系统调度影响，Windows下最低精度约15.6毫秒，意味着你想发100Hz的包，实际可能只有60Hz左右，而且抖动明显。
后来改用QTimer，精度好了一些，但QTimer本质上依赖事件循环，UI线程阻塞时它也会跟着不准。可靠的做法是把定时发送逻辑移进专门的发送线程，用threading.Timer或者自己维护一个基于time.perf_counter()的发送调度循环。实测下来，基于perf_counter的循环在Windows上可以把100Hz发送的抖动控制在1毫秒以内，这对于做协议级压测足够用了。
6. 一次完整的典型调试流程
把工具怎么用串起来讲一遍，新手拿到手也知道从哪里下手。
假设场景：要调通一个支持Modbus TCP的温控器，设备型号和通信参数未知。流程是这样的：
第一步，用UDP广播模式向255.255.255.255发一条固定的搜索指令，等待设备回应，从响应里拿到设备的IP地址和端口。
第二步，切换到TCP客户端模式，目标地址填设备的IP和端口，点击连接。连接成功后发送区输入Modbus请求帧（Hex模式），看返回帧是否符合协议文档预期。
第三步，如果对方是客户端主动连上来，就切到TCP服务端模式，监听本机指定端口，等待设备连接。连接建立后，从设备发来的数据会在接收区实时显示。
这三步覆盖了绝大多数设备联调场景。剩下的时间基本花在排查网络不通的原因上，而工具的日志区会把这些原因一一记下来——是连接被拒绝、超时、还是防火墙拦截，每一条都有对应的socket错误信息。
7. 后续可以再加的能力
做完第一版之后我一直在想还能加什么。目前最实用的是流量统计功能，比界面实时显示更能反映链路质量。另一个方向是记录回放：把一端收到的数据完整保存成文件，之后可以按原速或加速重放，复现某些偶发问题。自动应答也很有用——设置好匹配规则和响应内容，工具就能模拟一个简易的服务端，配合设备调试。
第三个想法是从协议模板库方向扩展。不同行业用的协议帧结构差异很大，但调试工具的逻辑是通用的——按模板解析帧头、功能码、数据段、校验位，高亮显示各个字段。之前调Modbus TCP、CANopen over TCP这些协议时，纯Hex视图配合手动拆帧效率还是略低，如果工具能根据模板自动拆解字段，调试效率能再上一个台阶。这个功能我目前只实现了最粗的模版配置，后面有时间打算完善成独立的协议分析模块。
我个人的体会是，网络调试工具这类软件，无论别人做得再怎么好，都不如自己手里这套顺手。因为只有你自己才最清楚调试时的动作路径长什么样，最清楚哪个按钮应该放在哪里、哪种显示模式最常用的、哪个坑你反复踩过。把这个工具打磨到符合自己使用习惯的过程，本身就是一次很好的网络编程实践。有类似折腾经历的朋友，也建议从自己最不顺手的地方出发，做一个"用着痛快"的版本，你会发现调试效率的提升比想象中大得多。
本文还有配套的精品资源，点击获取
