企业官网建设流程全解析

做嵌入式、上位机开发或者搞物联网的人，应该都有过这种经历：串口时代的调试，一把 USB 转串口线加个 SSCOM 或者 XCOM，看着十六进制数据在界面里滚动，心里特别踏实。可一旦把通信方式从串口迁移到网口，面对 TCP 连接、三次握手、端口监听这些概念时，很多人会突然发现手里的调试工具不顺手了，甚至不知道该用哪个软件去发一条 TCP 消息。

这种情况我见过太多。产品从串口升级到以太网，代码要从裸机收发改成 Socket 编程，硬件要跑 lwIP 协议栈，而调试工具却还停留在串口思维里。于是有人在网上搜“TCP调试助手”，下载了一堆工具，挨个试，有的界面像上个世纪的古董，有的装完就报毒，有的连不上还找不到原因。这篇内容就是想把这些年我实测过的 TCP 调试助手、用它们排查过的典型问题，以及嵌入式/上位机场景下的组合玩法，一次性讲清楚。不管你是刚接触 tcp/ip 的新手，还是被粘包、端口占用折腾过的老手，都能从这里找到能直接抄作业的方案。

1. 从串口到网口：TCP调试助手的角色定位

1.1 为什么不能继续用串口调试助手处理 TCP 数据

很多新手会问：串口调试助手能发十六进制，能收字符串，为什么不能拿来调 TCP？这个问题背后其实是对两种通信模型差异的不理解。

串口是一种物理层通信方式，数据通过 UART 引脚一根一根地发送，调试助手下发的每个字节直接进到硬件寄存器，通信双方几乎没有“连接”和“会话”的概念。而 TCP 是传输层协议，建立在 IP 之上，它有一整套状态机：连接要三次握手，关闭要四次挥手，丢了包要重传，收得快了要流控。串口调试助手根本没有状态机概念，它只能帮你在 COM 口上收发原始字节流，无法完成“我作为客户端去连接对方端口”“我作为服务器监听等待对方连入”“连接建立后我观察握手过程”这些最基本的 TCP 调试动作。

我见过有人用串口调试助手去调试 ESP01S 的 TCP 透传，结果发现 AT 指令返回的 “CONNECT OK” 和后面的数据混在一起，判断不了连接是否真实建立，最后只能靠单片机上的指示灯间接判断。这就是典型的“用错工具”。TCP 调试助手要解决的核心问题，就是在不写代码的情况下，把一个 TCP 客户端或服务器跑起来，让你能观察连接状态、发送数据、接收数据、统计收发字节数，必要时还能把抓到的报文导出成日志。

1.2 TCP调试助手的核心能力清单

市面上的 TCP 调试助手五花八门，但评判一个工具能不能打，我一般只看这六个能力：

• 双模式：能主动作为客户端去 connect，也能作为服务器 listen 并接受多个连接，两者切换要方便。
• 双协议：至少支持 TCP 和 UDP，因为调试过程中经常需要对比两种协议的行为差异，只支持 TCP 的工具会限制排查思路。
• 收发格式：字符串、十六进制、ASCII 混合显示都要有，发送时可以切换，接收区最好能同时显示两种。
• 多连接管理：服务器模式下一个工具能同时挂多个客户端，并且可以单独选中某个客户端发送数据，这个能力在调试 Wi-Fi 设备多台上线时特别重要。
• 日志保存：能按时间戳保存收发记录，最好带收发方向标识，出了问题可以回去翻日志而不是靠截图。
• 辅助分析：发送定时器、字节数统计、自动换行、快捷发送面板，这些看似不起眼的功能，实际排查问题时能省一半时间。

基于这个能力清单，下面我分别聊几款我用得比较多的工具，风格差异和适用人群我会说得比较直白。

2. 四款主流TCP调试助手横向实测

2.1 网络调试助手 NetAssist：最流行的老牌选择

国内做嵌入式的人，几乎没人不知道 NetAssist，也就是大家常说的“网络调试助手”。这个工具早年在 51 单片机、STM32 上网项目的帖子里出现频率极高，界面布局非常符合国内工程师的使用习惯：左侧配参数，中间接收区，底部发送区，上手零成本。

我实测下来，NetAssist 最稳的是它的 TCP 服务器模式。在调试 ESP8266 这类 Wi-Fi 模块时，我用 PC 开一个 TCP Server，监听 8080 端口，模块作为客户端连上来，工具右侧会列出当前已连接的客户端 IP 和端口，我选中任意一个就能单独发数据，这个体验比很多国外工具都顺手。它还支持“接收区 HEX 显示”和“发送区 HEX 发送”，在调试私有协议时非常重要，因为很多时候二进制帧用肉眼没法看，必须切成 16 进制。

当然，它也有明显的短板。首先是长时间高负载收发时偶尔会界面卡顿，毕竟核心是单线程 UI 程序；其次是没有报文时间戳的详细级别选项，导出日志后看高频收发时不容易定位具体哪条消息先到；最后是它对 IPv6 的支持约等于没有。如果是拿来做嵌入式原型验证、产品联调，这些缺点可以接受，但不建议拿它做长期压力测试。官方原版来自大工或者周立功系，网上各种修改版、去广告版很多，建议下载时校验一下文件哈希，避免下到捆了推广软件的版本。

2.2 SocketTool：轻量、多模式切换

SocketTool 是另一款我常备在 U 盘里的工具，体积比 NetAssist 还小，界面更紧凑。它的特色是模块化主窗口，左侧是 TCP Server、TCP Client、UDP Server、UDP Client 四种模式的切换按钮，右侧是当前模式下的参数配置和数据收发区。这种设计比“下拉菜单选协议”直观得多，我经常在一个窗口里同时开多个实例，分别模拟客户端和服务器，直接在同机回环测试自己的 Socket 代码。

SocketTool 在同类工具里最让我满意的一个细节是“定时发送”。我在调试某个设备的心跳报文时，需要每隔 5 秒发一条固定格式的 keepalive 数据，用 SocketTool 的定时发送功能配合时间戳日志，能清楚地看到设备端是不是超时踢掉了连接。它的数据统计也做得不错，收发总字节数、累计包数一目了然，对判断“数据是否真的发出去了”很有帮助。

不过 SocketTool 的老版本在一些新 Windows 系统上会有 UI 缩放问题，高分屏下字体发虚。我用的是 Win11 笔记本，需要右键属性里改“高 DPI 缩放替代”才能正常显示。另外，它对 IPv6 的支持也比较弱，如果项目需要调纯 IPv6 环境，建议换个工具。总体而言，SocketTool 适合追求轻量、喜欢多实例并行调试的工程师。

2.3 Hercules：国外开源党最爱的多协议回放利器

Hercules（全称 Hercules SETUP Utility）是 HW group 公司出的免费工具，主打 TCP、UDP、串口、Modbus 多协议支持。它的界面是典型的英文选项卡风格，第一次用的人可能不太习惯，但只要理解了它“把一个协议当作一个会话页”的思路，会发现它非常强大。

Hercules 最值得一提的能力是“TCP Client 和 TCP Server 可以在同一个界面里管理多个会话”。我调试过一个跑 lwIP 的 RT-Thread 板卡，板卡做 TCP Server，PC 上用 Hercules 开三个 TCP Client 连接，分别模拟三个上位机同时请求数据。工具底部会列出所有连接，我可以选择任意连接并查看它单独的数据流。这种多会话能力，很多国产免费工具做不到。

另一个让我离不开 Hercules 的功能是数据回放（Replay）。调试 Modbus TCP 时，我会先把设备返回的响应报文保存成文件，然后用回放功能反复发送同一帧数据，验证设备端的解析逻辑是否稳定。这个功能在做协议兼容性测试时极其好用，比每次手工输入十六进制数据高效得多。

它的缺点同样是明显的：界面信息密度高，新手容易迷失；接收区的编码处理偏老派，对 UTF-8 中文的支持不如国产工具自然，调试纯中文 JSON 报文时偶尔会显示乱码。所以我通常把它定位成“进阶辅助工具”，而不是日常主打。

2.4 命令行为王：nc、telnet、curl 如何顶上

图形工具好用，但有些环境里你根本没有图形界面，或者只装了 Linux 服务器，这时候命令行工具就是救命的。

最常用的肯定是 nc（netcat）。Ubuntu 下可以直接apt install netcat-openbsd，然后一行命令起一个 TCP Server 在 12345 端口监听：

nc -l -p 12345

客户端模式连接一个远程端口：

nc 192.168.1.100 8080

我在排查“设备上报数据到服务器不通”的问题时，经常先在服务器上开一个 nc 监听端口，再看设备端能不能连上来、数据能不能收到。这个过程相当于把“TCP 调试助手”简化成命令行的最小化版本，不依赖任何 UI，非常符合“先定位是网络问题还是应用问题”的排查逻辑。

curl 则适合调 HTTP 之上的 TCP 服务。比如我怀疑 Docker 拉镜像报dial tcp: lookup registry-1.docker.io是网络问题，我会用curl -v https://registry-1.docker.io/v2/看解析和握手细节，判断是 DNS 解析挂了还是 TCP 连接被阻断。telnet 也还能打，虽然它既不加密也不支持二进制友好显示，但用来快速验证某个 TCP 端口是否开放，至今仍是无可替代的招数。

命令行工具的价值不仅仅在于“能干活”，更在于它天然适合同步进脚本。我在做回归测试时，会用 Python 的 socket 模块写一段几十行的脚本，模拟几十个 TCP 并发连接，这时候再好的图形助手也顶不上一个脚本。所以我不建议你迷信图形工具，命令行功底该练还得练。

2.5 选型小结：一张表看明白

我把上面的工具按使用场景整理成一个对比表，方便你按需挑选：

如果你只让我推荐一个先下下来试试，那我会说 NetAssist；如果你经常要在 Modbus TCP 和串口 Modbus 之间来回切换调试，那 Hercules 更值回票价；如果你工作流里本来就有很多命令行操作，学会用 nc 解决 80% 的临时调试需求完全没问题。

3. 从三次握手到粘包：TCP调试必须搞懂的底层知识点

工具选好了，但很多人依然调不明白，问题往往不是出在工具上，而是对 TCP 的几个关键行为理解不够。这一节我挑几个和调试强相关的知识点聊，它们直接决定你怎么看数据、怎么判断故障。

3.1 TCP三次握手与四次挥手：状态机视角下的连接

TCP 是面向连接的协议，连接建立必须经历三次握手。第一次握手，客户端发 SYN；第二次握手，服务器回 SYN+ACK；第三次握手，客户端再发 ACK。这个过程不是形式主义，它保证了两端都确认“我能发、我能收”，为后续可靠传输铺底。而连接关闭则是四次挥手：主动关闭方发 FIN，被动方回 ACK，被动方再发 FIN，主动方回 ACK。

很多调试助手的界面上都不直接显示握手报文，你看到的只是“连接成功”或“连接断开”。但如果你对状态机有概念，看到一个客户端 connect 后长时间处于 SYN_SENT 状态，就知道八成是对端根本没监听端口或者被防火墙拦了；如果连接建好后过一会儿设备发来 FIN，说明设备端主动断开，可能是应用层超时判活逻辑导致的，而不是网络不通。

调试 TCP 时我建议你开一个 Wireshark 在旁边抓包，工具负责“发和收”，Wireshark 负责“看底层报文”。比如你怀疑三次握手的第二次握手被中间设备丢掉了，单靠调试助手看不出来，抓包文件里却能清清楚楚看到 SYN 有去无回。这种“上层工具 + 底层抓包”的组合，是我排查 TCP 问题最常用的姿势。

3.2 粘包与半包：调试中最常见的“假故障”

在嵌入式里做 TCP 通信的工程师，十有八九都要面对“粘包”。TCP 是字节流协议，它不像 UDP 那样有消息边界。也就是说，发送方调用一次 send 发送 10 个字节，接收方可能一次 recv 收到这 10 个字节，也可能只收到 3 个，还可能在第二次收到 7 个的同时把下一次发送的前几个字节也带过来。这就是粘包和半包问题的根源。

我调一个 ESP32-S3 连接 WiFi 接收 TCP 消息的项目时，收到的 JSON 数据经常被截断或者拼接在一起，第一反应是“设备端发送逻辑写错了”。后来加了\n作为应用层分隔符，在接收缓冲区里按行解析，问题立刻消失。这个经验值得刻在脑子里：调试助手发数据只是把你输入的字节推到网络上，它不会帮你维护消息边界，应用层协议必须自己设计分隔符、固定长度或者类型长度值（TLV）结构。

出现粘包时，很多新手会怀疑调试助手，认为数据发错了。实际上你可以在调试助手里手动模拟“半包”场景：发送一封拆成两截的数据，观察接收方的处理逻辑是否健壮。这个做法能有效区分“网络层乱序”和“应用层组包不够健壮”两个完全不同的问题。

3.3 TCP与UDP先分清：别用TCP思维调UDP业务

调试助手大部分同时支持 TCP 和 UDP，但这两个协议在调试方法上有本质差异。TCP 有握手、有确认、有重传，调试时你会看到一个稳定的连接对象；UDP 则没有连接概念，客户端只管往目标 IP:端口丢报文，服务器能不能收到、收到后怎么回，全是应用层的事。

我遇到过有人拿着 TCP 调试助手去调 UDP 组播场景，结果工具界面里根本没有“加入组播组”的配置，怎么配置都收不到组播数据，最后换了专门的 UDP 工具才解决。所以选工具前先想清楚：你的设备是 TCP Server 还是 TCP Client？是 UDP 单播还是组播？有些助手虽然叫“TCP调试助手”，实际上 UDP 复杂度远超 TCP，组播支持更是分水岭。另外 HTTP 也是 TCP 之上最常见的应用协议，调试 POST/GET 接口时可以直接用调试助手模拟原始报文，也可以配合浏览器开发者工具看请求响应，但要注意 HTTP/1.1 默认开启 keep-alive，同一个 TCP 连接上会有多个请求响应交错，分析日志要结合 Content-Length 分帧。

4. TCP调试助手的实战场景：从嵌入式到上位机

工具和原理都聊完了，下面直接上场景。这些都是我自己做过的项目或帮朋友排查过的真实问题，每个场景都能直接落地。

4.1 场景一：ESP32/ESP8266 连接WiFi后与PC/手机的TCP通信

物联网模块接入 WiFi 后，最常用的调试方式就是让模块作为 TCP Client 主动连接到 PC 上的调试助手。以 ESP01S 为例，先用串口发送 AT 指令配置 WiFi 联网，拿到模块的 IP 地址后，在 PC 上打开 NetAssist 的 TCP Server，监听 8080 端口；再给模块发 AT 指令AT+CIPSTART="TCP","192.168.1.10",8080，模块返回 CONNECT OK 时，可以在调试助手里看到客户端的 IP 和端口出现在列表中。

这里有一个非常实用的验证点：模块上报的数据在接收区显示后，你在调试助手里给模块回一条字符串，模块的串口端就能通过 AT 指令的+IPD消息收到。这个双向通路一旦打通，说明模块的网络通路、AT 固件、透传状态全部正常。后续再做自己的云平台协议对接时，把调试助手当成模拟服务器，先用它验证完所有协议分支，再去对接真实服务器，出错概率能降一半。

如果你用的是 ESP32-S3 并跑 ESP-IDF 或 Arduino 的 Socket API，同样的方法成立，只是模块端代码里你要把服务器 IP 和端口换成调试助手的监听参数。我还遇到过用手机端 App 配合 TCP 调试助手做联调的情况，手机上的 TCP 客户端 App 连接 PC 的 Server 监听端口，效果和电脑端工具一样，适合在现场没有电脑但需要快速验证的场景。

4.2 场景二：Modbus TCP调试与 FINS TCP 兼容性

工控领域绕不开 Modbus TCP。很多人先接触的是 Modbus RTU，串口调试助手发01 03 00 00 00 02 C4 0B这类报文，看到 CRC 校验位就觉得会了。可一旦切换到 Modbus TCP，报文格式完全不同，MBAP 报文头替代了 CRC，地址变成了单元标识符，调试工具也要跟着换思路。

我调试 Modbus TCP 时的标准动作用 Hercules 完成：服务端监听 502 端口，模拟一个 Modbus TCP Server；或者作为 Client，连接 PLC 的 502 端口，发送功能码03读保持寄存器。用调试助手的好处是，MBAP 头里的事务处理标识符、协议标识符、长度字段都能一帧一帧地对着看，出问题能立刻定位是哪个字节组错了包。相比用 Modbus 专用上位机软件调试，通用 TCP 助手能更清晰地看到原始报文，尤其适合学习阶段和私有不兼容场景。

如果你在 RT-Thread Studio 里跑 lwIP + FreeModbus TCP 模式，调试方法相同。先确保 PC 能 ping 通板卡 IP，再做 502 端口连通性测试，最后用调试助手发功能码报文验证寄存器读写。FINS TCP 是欧姆龙的协议，调试思路更接近“先建 TCP 连接，再在连接上发送 FINS 命令帧”，Wireshark 里有专门的 FINS 解析器，但调试助手只看得到原始字节流，判断帧格式还是要自己对协议文档。我的建议是：调试助手负责模拟和收发，抓包工具负责协议解码，两个一起用效率才是最高的。

4.3 场景三：上位机与Docker/本地服务的TCP端口联调

上位机开发场景里，最常见的需求是调试本机或局域网内的 TCP 服务。比如我本地开了一个 Web 服务监听 8080 端口，用浏览器能访问，但用代码去访问却失败。这时候用 TCP 调试助手连接127.0.0.1:8080，发一个最简单的 HTTP GET 请求，看服务端返回什么，就能区分是浏览器代理的问题还是服务本身的响应问题。

Docker 环境下的排查也很典型。启动容器时端口映射没配对，或者容器内进程没监听对应端口，外部客户端连接就会失败。我常用 SocketTool 起一个 TCP Client，连接宿主机的映射端口，如果连不上再进容器用nc -lp监听一次，逐步缩小范围。还有adb调试时 5037 端口经常出现could not read ok from adb server的报错，多半是端口被占用或者 adb 版本不一致，先用调试助手试连 5037 端口看是否能建立 TCP 连接，能快速判断是 adb 服务异常还是端口被其他程序抢占，再配合任务管理器找到占用进程解决掉。

从这个场景能看出，TCP 调试助手的价值早就不限于嵌入式，只要是走 TCP/IP 的应用，它都能作为一个“裸 TCP 客户端/服务器”介入，绕开业务层直接看传输层状态。

4.4 场景四：TCP/IP 五层模型视角下的故障定位

很多教程爱画 TCP/IP 四层/五层模型示意图，但真正用这个模型指导调试的人不多。我遇到“TCP 连接建立失败”时，习惯按层来切分故障：

• 物理层/数据链路层：先用ping看 IP 层通不通，如果 ping 不同，检查网线、Wi-Fi 信号、VLAN 配置。
• 网络层：ping通则再看路由，跨网段时检查网关和路由表。
• 传输层：IP 通但 TCP 端口不通，用调试助手或 nc 测试目标端口，如果连接超时，要么对端没监听，要么防火墙丢包。
• 应用层：TCP 能连上但数据乱、断连，重点看应用协议设计，比如粘包处理、超时重传逻辑。

这个分层思路非常管用。有一次我调一块跑 lwIP 的板子，设备能 ping 通 PC，但 TCP 连接死活建不起来，抓包发现设备发的 SYN 一直在重传。按照分层逻辑，先怀疑传输层，又查了服务器监听地址，最后发现是服务器端程序监听在 IPv6 地址上，设备用 IPv4 去连自然失败。这种问题如果不按层拆，光靠猜能猜一整天。

5. 调试中的高频报错与排查思路

工具用多了，什么样的报错都能遇见。这一节我挑几个最常出现的，给出我的排查路径，你可以直接当速查表用。

5.1 端口占用：bind 提示 only one usage of each socket address

这个报错的信息长这样：

error: listen tcp 127.0.0.1:11434: bind: only one usage of each socket address

意思是端口 11434 已经被其他进程占用了，新的监听程序无法绑定到同一个地址。这个报错在 Windows 上特别常见，因为默认 Windows 对端口绑定的处理规则比较严格，TCP 连接处于 TIME_WAIT 状态时再次绑定同样端口也有可能失败。

我的排查顺序是：先用netstat -ano | findstr 11434看谁占用了端口，再用任务管理器找到 PID 对应进程，杀掉后重新监听。如果杀不掉或者不能杀，就换一个端口，把调试助手的监听端口改成 11435 之类即可。Linux 下对应的是ss -lp 'sport = :11434'或lsof -i:11434。

这个报错里值得提一句的是 TIME_WAIT 状态。TCP 四次挥手后，主动关闭方要等 2MSL（报文最大生存时间）才能完全释放连接，目的是防止旧连接的延迟报文污染新连接。调试时如果你频繁地断开重连，发现端口还“被占用”，多半就是 TIME_WAIT 还没结束。这时候最简单的办法是换端口，或者设置 socket 的SO_REUSEADDR属性，但调试助手里一般没有这个开关，所以不要在同一个端口上死磕。

5.2 连接超时/被拒：从 ping 到 TCP 层的逐步定位

“连不上”分很多种，误判方向会浪费大量时间。我一般分三句话问自己：目标主机通不通？目标端口通不通？应用层是否有响应？

先 ping 目标 IP，通则继续；不通就查网络配置、防火墙、网线。IP 段通但端口不通，用telnet IP 端口或者调试助手试连一下，如果提示“目标计算机积极拒绝”，说明端口是开放的但服务没监听；如果一直卡在连接中，说明防火墙丢包或者 SYN 被丢弃。我在一台 Ubuntu 服务器上排查 Docker 拉镜像报dial tcp类错误时，先用 nc 测试了目标域名的 443 端口，再用curl -v看 TLS 握手，最后定位是 DNS 域名解析到了一个不可达的 IP，跟 Docker 本身一点关系都没有。

这类问题里最坑的是镜像源、DNS 和防火墙三者的顺序。我建议先做 DNS 解析测试，再做 TCP 端口连通性测试，最后看应用层日志，这个顺序能避免很多无效操作。arp 缓存、路由表这类底层细节，等前几步都排除了再查，不然就是给自己加戏。

5.3 乱码与编码：ASCII、Hex、UTF-8 来回切换的存储

TCP 调试助手里收到的数据，本质都是字节流，显示成字符串还是十六进制取决于你的设置。很多所谓“乱码”，其实是工具把 UTF-8 编码的中文按 GBK 或 ASCII 显示导致的。字符串里一个汉字在 UTF-8 下占 3 个字节，在 GBK 下占 2 个字节，同一个字节序列用不同编码解析，显示结果完全不同。

我的习惯是：先切到 HEX 模式看原始字节，确认数据是不是完整；再切回文本模式，对比字符编码。如果双方约定了 JSON/UTF-8，调试之前先在助手里把编码设置对，就能避免一半的“乱码冤案”。另外要提醒一句：HEX 模式下每条消息之间有没有换行，取决于工具的实现，有些工具的“接收 HEX”和“发送 HEX”是两个独立开关，别只看一边就下结论。

5.4 调试助手的“隐形坑”：回车换行、定时发送、状态显示

很多人在调试助手卡了半天，结果不是协议问题，是工具配置没搞对。列举几个最常见的隐形坑：

• 发送时自动追加换行。有的助手在字符串末尾自动加\n，你要是按固定长度的二进制帧发送，多出来的一个字节会把整个帧解析搞乱。发送二进制测试报文前，先确认“发送新行”是关着的。
• 定时发送的间隔精度。GUI 的定时器精度本身不高，短于 10ms 的定时发送基本不可靠，如果你要测试高频率下发，建议用脚本而不是图形工具。
• 服务器模式的监听地址。有些工具默认监听127.0.0.1，局域网内其他设备根本连不进来，必须手动改成0.0.0.0或者本机实际 IP。这个坑极其常见，我在调 ESP32 连接 PC 时反复踩过。
• 接收区的自动滚动。数据量一大，自动滚动会把前面的关键报文推到视线之外，建议调成暂停或按时间筛选，避免漏看。

这些坑单拎出来都不大，但组合在一起就容易让新手怀疑人生。我的原则是：先让工具处于“最朴素的默认状态”，排除这些隐形因素后，再去做协议层分析。

6. 一些实测后的心得与补充技巧

最后这节，我不打算做什么总结，就分享几个我实测后觉得特别值得记住的点。

6.1 用TCP调试助手做简易压力测试与稳定性验证

很多人只把调试助手当“手动发数据”的工具，其实它也能做轻量级压力验证。SocketTool 和 Hercules 都支持定时发送，你可以构造一个包含递增序号字段的报文，用定时发送功能每 20ms 发一次，持续十几分钟，再回看接收日志里设备端的响应是否丢包、乱序、掉线。这个办法虽然比不了专用压测工具，但在项目早期用来发现明显稳定性问题，成本几乎为零。

我用这个方法发现过一块板卡在 20ms 高频请求下会在约十分钟后停止响应的问题，后来定位到是接收缓冲区溢出和一个资源没释放的 bug。如果没有这个定时发送功能，手动发很难坚持到十分钟。另外，如果你要做并发测试，建议还是写脚本，毕竟图形工具的多线程能力有限。

6.2 日志保存与 Wireshark 配合抓包是最好的组合

图形调试助手自带的日志功能，能记录应用层收发数据，但记录不了握手、重传、丢包这些 TCP 状态信息。真要定位“连接为什么老是断”这类问题，必须上 Wireshark 抓包。我的工作习惯是：调试助手负责产生数据流，Wireshark 负责在旁边全量抓包，抓到 pcapng 后按 IP、端口过滤，重点看 TCP 的 Flags、Sequence Number、Retransmission 标记。

有一次排查设备周期性掉线，调试助手日志里只能看到“连接断开-重连成功”循环，完全看不出原因。我翻了 Wireshark 抓包才发现，断开前设备发了一个FIN包，但应用层数据并没有处理完，说明是设备端代码主动关闭了连接，而不是网络问题。这个结论如果没有抓包，单靠调试助手是永远得不出正确结论的。所以我的建议是：调试助手管应用层，Wireshark 管传输层，两个都是必备技能。

6.3 我踩过的几个坑，希望你绕开

总结一下我个人的血泪经验。第一，永远不要把“调试助手连上了”等同于“网络没有问题”。TCP 连接成功只代表握手完成，后面还有大量的丢包、乱序、半开连接等着你，连接成功只是起点。第二，下载工具尽量去官网或可信来源，网上很多“绿色版”调试助手捆绑了推广软件，我见过一台新电脑装完调试助手后多了三个弹窗广告的，非常影响效率。第三，做好现场记录，尤其是时间戳和收发方向，调试助手日志里如果连时间戳都没有，那这个工具不适合做问题排查，只能用来演示。

如果你也遇到过调 TCP 调到怀疑人生的时候，不妨重新审视一下手里的工具和排查方法。工具永远是辅助，真正靠谱的还是你对 TCP 协议的理解和对排查路径的直觉。希望这篇内容能让你少走几步弯路。