简介：TCP&UDPDebug 是一款面向网络编程开发者与运维调试人员的传输层协议测试工具，用于在开发 TCP 服务器、客户端或 UDP 服务时验证连接性能、排查通信异常。工具围绕连接建立与断开、数据收发、丢包检测、顺序校验、错误分析、吞吐量与延迟监控、端口扫描及多线程并发等场景提供支持，帮助使用者直观理解 TCP 可靠传输与 UDP 无连接通信的差异，并据此优化代码与网络配置。资源包共 18 个文件，以 ini 与 xml 配置、jpg 截图、exe 可执行程序为主，另含 htm 说明页、css 样式、data 数据、dll 动态库与 bat 启动脚本，整体约 1.15MB，解压后可直接运行调试。目前已有 1278 人学习下载，适合需要快速搭建协议测试环境、对照分析传输质量并积累排错思路的网络开发者参考使用。
1. 一个调试工具该有的样子：从 TCP/UDPDebug 说起
手头有个 TCP&UDPDebug 类的工具，很多人第一反应是「不就是个发数据的小软件吗」。但真到现场，你会发现它解决的是嵌入式、工控、物联网开发里最磨人的一类问题：设备就在那，网线插着，灯也亮着，可数据就是不通。这时候你需要的不是抓包神器 Wireshark 那种重武器，而是一个能秒开、能手动拼包、能同时盯 TCP 和 UDP 两条链路的轻量调试台。TCP&UDPDebug 这类工具的核心价值就在这——它把「建立连接、发什么、收什么、什么时候断」这四件事压缩到一个窗口里，让你在写业务代码之前先把链路本身验通。适合谁用？写 Modbus TCP 客户端的、调 ESP01S 发 TCP 消息的、做 ZYNQ 以太网 UDP 测试的，以及所有被「地址已在使用」和「连接超时」反复折磨的一线工程师。这一章先把这类工具到底在调什么讲清楚，后面几章再拆怎么用、参数怎么设、坑在哪。
2. TCP&UDPDebug 到底在调什么：连接、端口与协议栈
2.1 TCP 模式下调的是三次握手和连接状态
用 TCP&UDPDebug 建一个 TCP 客户端，点「连接」的那一瞬间，工具底层干的事和你在 C 语言里调socket() -> connect()完全一样。它先发 SYN，等对方回 SYN+ACK，再回 ACK，三次握手完成，连接才算建立。工具界面上那个「已连接」的绿灯，本质就是connect()返回了 0。如果对方端口没开，你会看到连接被拒绝；如果对方 IP 不可达，就是超时。这两种失败在工具里的表现不同，排查方向也完全不同——前者查服务端监听，后者查路由和防火墙。
很多人调 TCP 时忽略了一个关键点：TCP 是字节流，不是消息流。你发两次「ABC」和「DEF」，对方可能一次收到「ABCDEF」。所以用调试工具发 TCP 数据时，如果协议没有自定义长度头或分隔符，接收端根本不知道一条消息从哪结束。这也是为什么 Modbus TCP 要在前面加 6 字节 MBAP 头，里面带长度字段。调试工具本身不帮你解决粘包，它只负责把字节原样发出去，粘包拆包是你业务代码的事。
提示：用 TCP&UDPDebug 发文本时，注意工具是否自动追加换行符。有些工具默认勾选「发送新行」，会在末尾加
\r\n，如果你的协议对字节敏感，这个隐藏字符会让服务端解析直接翻车。
2.2 UDP 模式下调的是端口可达性和数据报边界
切到 UDP 模式，事情简单一半也复杂一半。简单在于没有握手，sendto()发出去就完事，不需要先连。复杂在于你永远不知道对方收没收到。UDP 调试的典型场景是广播发现：设备上电后往255.255.255.255:port发一个探测包，服务端回一个带自己 IP 的响应，客户端才知道设备在哪。用 TCP&UDPDebug 做 UDP 测试时，最关键的两个参数是本地绑定端口和目标端口。本地端口不绑，系统随机分配，对方回包你可能收不到；本地端口绑了但被占用，工具会直接报错。
UDP 还有一个 TCP 没有的特性：数据报边界保留。你发一个 100 字节的包，对方recvfrom()要么收到完整 100 字节，要么啥也收不到，不会出现收 50 字节的情况。所以用 UDP 传结构化数据反而比 TCP 省心，前提是你能接受丢包。调试工具里通常有「十六进制发送」选项，调二进制协议时务必勾上，否则工具会按 ASCII 编码把你的0x01变成字符1的编码0x31，对方解析出来全是错的。
2.3 端口号与地址复用：那些报错到底在说什么
「error response from daemon: ports are not available: exposing port tcp 0.0.0.0」这类报错，本质是端口被占。在 TCP&UDPDebug 里表现为「绑定失败」或「连接被拒绝」。排查顺序很简单：先看工具自己是不是已经开了一个监听没关，再看系统里有没有别的进程占着这个端口。Windows 上用netstat -ano | findstr :端口号，Linux 上用ss -tulnp | grep 端口号，找到 PID 再决定是杀进程还是换端口。
另一个高频问题是 Java TCP 客户端重连时报「地址已在使用」。这不是端口被占，而是上一次的 socket 没正确关闭，处于 TIME_WAIT 状态。TCP 主动关闭方会进入 TIME_WAIT，默认等 2MSL（通常 60 秒）才释放。调试阶段频繁断开重连，很容易撞上这个。解决办法是服务端和客户端都设SO_REUSEADDR，或者干脆换一个本地端口重连。用调试工具时如果反复连同一个服务端，建议每次断开后等几秒再连，别跟 TIME_WAIT 硬刚。
3. 用 TCP&UDPDebug 跑通第一条链路的完整步骤
3.1 TCP 客户端与服务端的最小验证
先做最简单的：一台机器开 TCP 服务端监听，另一台用 TCP&UDPDebug 当客户端连。服务端可以用 Python 一行起，不用装任何东西。
# tcp_server.py # 监听 0.0.0.0:9000，收到什么就回什么 import socket server = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) # 允许地址复用，避免 TIME_WAIT 干扰 server.bind(("0.0.0.0", 9000)) server.listen(5) print("TCP server listening on 9000") conn, addr = server.accept() print(f"connected from {addr}") while True: data = conn.recv(1024) if not data: break print(f"recv: {data}") conn.sendall(b"echo:" + data) # 原样回显，方便在调试工具里确认收发 conn.close()这段代码的关键在SO_REUSEADDR，它让服务端重启时不用等 TIME_WAIT。recv(1024)的 1024 是单次最大接收字节数，调试阶段够用，正式环境按协议最大帧长设。sendall保证数据全部发出，不会像send那样可能只发一半。
然后在 TCP&UDPDebug 里填目标 IP 和端口 9000，点连接。连上后发一句hello，接收区应该出现echo:hello。如果连接失败，先确认服务端print有没有输出connected，没有就是没连上，查 IP 和防火墙；有connected但收不到回显，查发送编码是不是十六进制模式。
3.2 UDP 单播与广播的调试差异
UDP 服务端同样用 Python 起，但绑定方式不同：
# udp_server.py # 监听 0.0.0.0:9001，收到包后打印来源并回复 import socket server = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1) # 允许收广播包 server.bind(("0.0.0.0", 9001)) print("UDP server listening on 9001") while True: data, addr = server.recvfrom(2048) print(f"recv from {addr}: {data}") server.sendto(b"ack:" + data, addr) # 回复给来源地址SO_BROADCAST是收广播包必须开的选项，不开的话广播包会被内核直接丢掉。recvfrom返回的addr是发送方地址，回复时必须带上，否则不知道发给谁。调试工具这边，UDP 模式填目标 IP 和 9001，点发送即可。如果要测广播，目标 IP 填255.255.255.255，但注意有些系统默认禁止发广播，需要在工具或系统层面开权限。
UDP 调试最常见的翻车是「发了没反应」。先确认服务端有没有打印recv from，没有就是包没到，查目标 IP 和端口；有打印但工具收不到回复，查工具本地绑定端口是不是被防火墙拦了。UDP 没有连接状态，工具界面上不会有「已连接」提示，只能靠收发计数判断。
3.3 十六进制发送与接收的配置要点
调二进制协议时，TCP&UDPDebug 的十六进制模式是必选项。以 Modbus TCP 读保持寄存器为例，请求帧是00 01 00 00 00 06 01 03 00 00 00 01，前 6 字节是 MBAP 头，后面是 PDU。在工具里勾选「十六进制发送」，把这串填进去，接收区也切到十六进制显示，才能看到正确的响应帧。
如果忘了勾十六进制，工具会把00当成两个 ASCII 字符0和0发出去，实际线上是0x30 0x30，服务端解析 MBAP 头时长度字段直接错位，返回异常码。这个坑我见过太多次，现象是「明明帧格式对着呢，就是返回错误」，原因就是编码模式没切。
注意：不同调试工具的十六进制输入格式不一样，有的要求空格分隔，有的要求连续写。填完先发一个已知帧，用 Wireshark 抓一下确认线上字节和你预期一致，再继续调业务。
4. 参数怎么设：超时、缓冲区与协议栈调优
4.1 连接超时与重试次数的合理取值
TCP&UDPDebug 里通常有「连接超时」设置，单位毫秒。局域网调试设 1000 到 3000 足够，跨网段或走无线设 5000。设太短，网络稍微抖一下就报超时，你会误以为服务端挂了；设太长，真挂了也要等半天才报错。我的习惯是局域网 2000，4G/5G 链路 8000。
重试次数看场景。调试阶段设 1 次，失败就停下来查原因，别让它自动重试掩盖问题。正式工具里可以设 3 次，每次间隔 1 秒，覆盖偶发丢包。但要注意，TCP 重试是重新connect()，不是在原连接上重发，所以每次重试都会产生新的三次握手。如果服务端有连接数限制，频繁重试可能把连接池打满。
4.2 发送与接收缓冲区的大小影响
调试工具一般有发送缓冲区和接收缓冲区设置。发送缓冲区太小，大帧发不出去；接收缓冲区太小，对方一次发多了会截断。TCP 是流，接收缓冲区小了不会丢数据，但会触发 TCP 窗口收缩，对方发得慢；UDP 是数据报，接收缓冲区小于单个包大小，包直接被丢弃，且没有任何提示。
常见做法是接收缓冲区设 4096 或 8192，覆盖绝大多数工控协议帧。如果你调的是视频流或大文件传输，得设到 64KB 以上。Windows 上单个 UDP 包最大 65507 字节，超过这个数sendto直接报错。调试工具如果没做分片，发大包必失败。
4.3 用 netsh 查看和调整 TCP 全局参数
Windows 下调 TCP 行为，netsh interface tcp show global能看到当前全局参数。调试阶段常关注两个：接收窗口自动调优级别和ECN 功能。自动调优开着一般不用动，ECN 在某些老设备上会引发兼容问题，现象是连接能建但传输极慢。如果怀疑是系统 TCP 参数问题，可以先netsh interface tcp set global ecncapability=disabled关掉 ECN 再试。
Linux 下对应的是sysctl net.ipv4.tcp_rmem和net.ipv4.tcp_wmem，分别控制接收和发送缓冲区的最小/默认/最大值。调试时如果发现吞吐上不去，可以临时sysctl -w net.ipv4.tcp_rmem="4096 87380 6291456"把最大接收缓冲调大。但这些是系统级改动，调完记得改回去，别在生产机上留隐患。
5. 避坑与排查：TCP&UDPDebug 使用中的五个血泪教训
5.1 现象：连接成功但发数据没反应
原因：TCP 连接建立了，但服务端accept()之后没有进入recv循环，或者卡在别的逻辑里。连接成功只代表三次握手完成，不代表服务端准备好收数据了。
解决：在服务端accept()后加日志，确认进入接收循环。调试工具这边看发送计数有没有增加，增加了说明数据发出去了，问题在服务端。
5.2 现象：UDP 广播包发出去收不到回复
原因：服务端没开SO_BROADCAST，或者回复时用了错误的地址。广播包的源地址可能是0.0.0.0，服务端如果直接回0.0.0.0就发不出去。
解决：服务端必须用recvfrom返回的addr回复，不能用固定地址。同时确认服务端 socket 开了SO_BROADCAST。
5.3 现象：十六进制发送的帧被服务端拒绝
原因：工具没切十六进制模式，或者切了但格式不对（空格、大小写、前缀0x）。不同工具解析规则不同，有的把0x01当四个字符。
解决：先用纯 ASCII 发一句test确认链路通，再切十六进制发已知帧，用 Wireshark 抓包对比线上字节。
5.4 现象：反复重连后报「地址已在使用」
原因：上一次连接处于 TIME_WAIT，本地端口没释放。TCP 主动关闭方会占用端口 2MSL。
解决：服务端和客户端都设SO_REUSEADDR；调试工具如果支持，勾选「地址复用」；或者每次重连换本地端口。
5.5 现象：Modbus TCP 返回异常码 0x03 或 0x04
原因：0x03 是非法数据值，0x04 是从站设备故障。常见于请求帧里寄存器地址或数量超范围，或者从站设备没上电。
解决：先用调试工具发一条读单个寄存器的请求，确认从站能回。再逐步加数量，定位到哪一步出错。别一上来就读几百个寄存器，从站可能不支持。
6. 进阶：把调试工具变成协议验证器
调通基本收发之后，TCP&UDPDebug 还能当协议验证器用。核心思路是：把常用请求帧存成模板，每次改几个字节就发，接收区用十六进制对照协议文档逐字段核对。比如调 Modbus TCP，我会存三条模板：读保持寄存器、写单个寄存器、读设备标识。每条模板只改地址和数量字段，其他不动。这样能快速区分是协议格式问题还是业务逻辑问题。
更进一步，可以用调试工具的「定时发送」功能做压力测试。设 100ms 发一次，跑十分钟，看服务端会不会崩、会不会丢包、内存有没有涨。这比写脚本快得多，尤其适合验证嵌入式设备的 TCP 协议栈稳定性。我一般会同时开两个调试工具实例，一个发 TCP，一个发 UDP，观察设备在双链路并发下的表现。很多设备单独跑 TCP 没问题，加上 UDP 广播就死机，这种问题只有并发压测才能暴露。
验证方法上，我习惯用「已知帧 + 抓包对照」双确认。调试工具发出去的字节，Wireshark 抓到的必须一模一样；服务端回的字节，调试工具收到的也必须和 Wireshark 一致。两边对不上，就是工具编码或显示的问题，不是网络问题。这个习惯帮我省了大量扯皮时间——到底是设备没回，还是工具没显示，抓包一看便知。
最后说个习惯：每次调完一个设备，把调试工具里的配置导出或截图存下来，标注设备型号、IP、端口、关键帧。下次再调同类设备，直接导入配置，省得从头填。我吃过亏，半年前调通的参数没记，再调时忘了从站地址是 1 还是 2，白白多花一小时。希望帮到你。
本文还有配套的精品资源，点击获取
