简介：SocketTool是一款专业的TCP通信测试工具，面向网络工程师、系统管理员及软件开发者，用于网络编程调试、服务器连通性验证与协议兼容性测试。这套资源包压缩后仅1.55MB，共包含8个文件，其中可执行文件SocketTool V4.exe是主程序，两份PDF文档分别为《使用说明》和《二次开发说明》，另有TXT版本说明、JS脚本与安装教程截图，结构精简但覆盖了从基础操作到二次开发的核心资料。使用说明PDF和版本说明TXT指导用户完成TCP连接/断开、自定义数据包发送接收、流量控制及日志查看等常见调试任务；二次开发说明则为需要定制功能的开发者提供接口与实现原理参考；JS脚本和project.txt可辅助理解前端逻辑或进行脚本级扩展；安装教程PNG以图解方式扫清环境配置障碍。无论是排查本地网络故障、验证远程服务器端口连通性，还是测试应用在高并发下的表现，这份资料都能提供直接可用的工具与参考。目前该资源已有246人学习下载，适合希望在轻量级环境下快速搭建Socket调试场景的读者收藏使用。

1. SocketTool 到底是个什么工具：一次完整联调就明白了

在嵌入式、上位机和后端服务联调时，大量问题都出在 Socket 这一层：设备连接上了但不下发数据，服务端重启后客户端没有自动续上，报文来回对不上。SocketTool 这类工具，就是为这些场景准备的：它能在本机起一个 TCP/UDP 服务端，也能作为客户端去连远端地址，把收发报文以 ASCII 和 Hex 两种视图摊在你面前，顺手记录时间戳和连接状态。比如某设备模组上报告警时偶发字节错乱，用打印日志只能看到业务层结果，拿 SocketTool 在本机做端口转发，才能看清原始字节流的真实顺序。如果你也在做网络协议、设备联调或接口转发，这工具值得纳入日常工具箱。

2. 拆开 SocketTool 的底子：从连接模型到报文结构的三个关键选择

用 SocketTool 之前，最好先理解它到底在替你做哪几件事。它不是魔术，无非是在操作系统 Socket API 外面包了一层图形界面或命令行封装：能 bind 端口、能 accept 连接、能 recv/send，然后把最原始的字节流呈现出来。理解这层底子，后面调参数、查问题才不会靠玄学。

2.1 先分清 TCP 与 UDP：同一个工具为什么能调两种链路

SocketTool 的两种核心工作模式，对应的是内核里两种完全不同的 Socket 类型。TCP 模式要经历 listen、accept 三次握手，工具必须维护一个连接会话列表，每条连接是一个独立的数据流。UDP 模式只 bind 一个端口，然后 recvfrom 取出一个个数据报，工具界面里没有“会话”这个说法，只有来自不同地址的报文散列。

下面的表，是你在工具界面里最容易看到的差异：

很多工具同时支持这两种模式，是因为现实中的物联网项目往往一半设备走 TCP，一半走 UDP。电源控制、音视频传输这类行业协议，很多还是 UDP；而网关、模组、工业采集器，绝大多数走 TCP。只支持 TCP 的工具，遇到 UDP 项目就得换方案，所以我选型时首先确认它两种模式都带。

另外，TCP 模式里有一排状态要会看：LISTEN、ESTABLISHED、FIN_WAIT、CLOSE_WAIT、TIME_WAIT。工具把这些状态显示出来，不是为了好看。排查连接被断开时，主要靠它判断是主动关闭还是被动关闭。如果对端已经调用了 close，而工具界面里还停在 ESTABLISHED，那多半是应用层没收到关闭事件，数据还在内核缓冲区里等着被读走。

2.2 选型先看四个硬指标：字节视图、断线重连、并发连接与日志导出

市面上的 Socket 调试工具不少，但真正能撑起联调场景的，我认为要看四个硬指标。第一个是字节视图，必须同时有 ASCII 和 Hex 两种。很多二进制协议里控制字符在 ASCII 视图下是乱码甚至不可见，只有 Hex 视图能把 0x00、0x0A 这类字节原原本本露出来。第二个是断线重连与心跳模拟，联调时设备反复下线，工具如果能模拟自动重连，能帮助你判断是设备自己掉线还是网络层主动断开。第三个是并发连接数，一个网关同时接几十个设备是常态，工具只支持单连接的话，只能一条条测，效率很低。第四个是日志导出，最好带时间戳，联调过程要留证据、要回放问题，没有日志导出，出问题只能截图。

这几个指标重要到什么程度，我遇到过实际例子。某次联调一个简单的 TCP 网关，问题只在第 20 路连接之后出现，单连接工具根本复现不了。换了一个支持 100 条会话的工具，直接在连接列表里看到第 20 路之后有 3 条处于 CLOSE_WAIT，顺着这个状态找应用代码里的资源没释放，问题就定位了。如果当时只有单连接工具，这个问题会被归因成“偶发网络故障”，实际上是工具能力不够。

2.3 没有现成工具时：四十行 Python 搭出最小 SocketTool

如果现场环境受限没法安装工具，常见做法是用 Python 标准库先写一个最小服务端，也够联调一轮。下面这个脚本是我会先跑起来的版本，它能接收连接，把收到的字节按 Hex 和可打印字符一起打印出来，再回一个带 ack 前缀的包：

import socket import select def hexdump(data: bytes) -> str: """把字节流转成 16 字节一行的 hex 视图""" lines = [] for i in range(0, len(data), 16): chunk = data[i:i+16] hex_part = ' '.join(f'{b:02x}' for b in chunk) ascii_part = ''.join(chr(b) if 32 <= b < 127 else '.' for b in chunk) lines.append(f'{i:04x} {hex_part:<47} {ascii_part}') return '\n'.join(lines) def tcp_echo_server(host: str, port: int) -> None: server = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind((host, port)) server.listen(32) print(f'listening on {host}:{port}') conns = [server] while True: readable, _, _ = select.select(conns, [], [], 0.5) for s in readable: if s is server: conn, addr = s.accept() conns.append(conn) print(f'[connect] {addr[0]}:{addr[1]}') else: data = s.recv(4096) if not data: print(f'[disconnect] {s.getpeername()}') conns.remove(s) s.close() continue print(f'[recv {len(data)}B]') print(hexdump(data)) s.send(b'ack:' + data)

这段代码里，SO_REUSEADDR让服务端在端口处于 TIME_WAIT 时也能重新绑定，这在反复重启调试时很重要。listen(32)是连接等待队列的长度，超过 32 条未 accept 的连接会被内核拒绝。select把 server socket 和已建立的连接放在一起轮询，这样就能同时处理多路收发，对应到工具里就是“会话列表”。recv(4096)一次最多读 4KB，如果一次到达的数据超过这个数，会被分多次读出，这就是后面会讲的半包现象来源。这个最小版已经具备 SocketTool 服务端模式的核心行为，后续加字节视图、时间戳、日志导出，都是在这上面叠功能。

3. 用 SocketTool 跑通一轮本地 TCP 联调：端口、报文与编码三件套

工具原理看明白了，接下来是实际操作。这一章以 TCP 联调为例，把起服务端、连客户端、调参数、看往返耗时这四个动作完整走一遍。你照着敲，就能把一台电脑上的两个角色打通。

3.1 起一个 TCP 服务端：三次握手状态在哪里看

常见做法是工具都带命令行入口，下面这条命令会在本机起一个 TCP 服务端，并把字节视图和时间戳全部打开：

sockettool --mode tcp-server --host 0.0.0.0 --port 19021 \ --hex-output on --timestamp on --log tcp_19021.log

--mode tcp-server指定当前作为服务端，和 tcp-client 相对。--host 0.0.0.0表示绑定本机所有网卡地址，这样局域网里的设备也能连进来；如果只想本机调试，建议改成127.0.0.1，可以减少外部干扰。--port 19021是调试端口，尽量选 1024 以上的高位端口，避免权限和系统服务冲突。--hex-output on让收到的字节以十六进制显示。--timestamp on给每条报文加上精确到毫秒的到达时间。--log会把报文原样写入文件，后面做回放和取证都会用到。

启动之后，可以用系统命令核对监听状态。Linux/macOS 上执行lsof -i :19021，Windows 上执行netstat -ano | findstr 19021，都能看到一条处于 LISTEN 状态的记录。客户端连入后，工具连接列表会出现新会话，状态为 ESTABLISHED。联调完关掉客户端时，如果是客户端主动断开，服务端这边会看到该连接进入 CLOSE_WAIT，然后消失。如果大量连接一直停在 CLOSE_WAIT 不消失，说明服务端应用没有正常回收资源，这个问题在工具界面里一眼就能看到。

3.2 发送报文：ASCII 与 Hex 两种模式的切换逻辑

服务端起来后，开第二个窗口用客户端模式连上去，发一条十六进制报文：

sockettool --mode tcp-client --host 127.0.0.1 --port 19021 \ --send-as hex --payload 01 03 00 00 00 0a 84 0a

--host 127.0.0.1指连本机，--send-as hex表示把 payload 里的空格去掉，每两个十六进制字符转成一个字节发送。上面这条01 03 00 00 00 0a 84 0a是常见的读寄存器请求，01是设备地址，03是功能码，00 0a是读取数量，最后两个字节是 CRC 校验。如果切换成--send-as ascii，工具会直接把字符串按字符字节发送，中文则按工具里设定的字符编码转字节。

这里有一个高频翻车点：很多工具在 ASCII 发送模式下默认会在末尾追加一个换行符。服务端收到的字节里多出 0x0A，协议解析立刻失败，新手往往以为是对方问题，折腾半天才发现是工具自作主张加的。建议在发送区找一下“追加换行”或“末尾 CR/LF”的开关，确认它是关闭状态。

3.3 必调参数表：连接超时、心跳间隔与接收缓冲区该设多大

工具默认参数能用，但不一定适合你的场景。我一般会在联调前把下面这组参数过一遍：

接收缓冲区设太小时，一次超过缓冲区大小的帧会被拆成多次 recv，工具界面上看起来像半包，容易误判协议问题。心跳间隔如果比设备侧的空闲超时还长，设备会先断开你，这时候联调看到的现象就是“隔一段时间连接自动掉线”，其实是保活节奏不对。TCP_NODELAY 选项在界面上通常是一个勾选框，叫“禁用 Nagle 算法”，勾上即可，它对小字节交互场景影响非常明显。

3.4 时间戳与往返耗时：验证请求响应闭环

报文能不能对上，最终要看一次请求响应闭环。带上往返耗时参数再看一遍：

sockettool --mode tcp-client --host 127.0.0.1 --port 19021 \ --send-as hex --payload 01 03 00 00 00 0a 84 0a \ --timestamp on --show-roundtrip

--show-roundtrip会从 send 发出后开始计时，到收到对端第一个响应字节为止，把耗时显示在发送记录旁边。这个值能帮你快速区分问题在哪一侧。如果耗时稳定在 1ms 以内，链路基本健康；如果经常超过 500ms，优先怀疑对端应用层处理慢，而不是网络。工具显示的时间戳是电脑本地时间，要和设备侧日志做对比时，记得先把两边时钟校准，否则时间线对不上又白忙一场。

4. UDP 与多连接场景：广播、组播和并发模拟的一次性配齐

TCP 联调跑通后，很多项目会遇到 UDP 场景。UDP 调试的思路和 TCP 完全不同：没有连接，没有重传，丢包和乱序只能靠应用层处理。这一章把 UDP 监听、组播发送、多连接模拟三个高频场景讲清楚。

4.1 从 TCP 切到 UDP：目标地址、端口与广播选项

先起一个 UDP 服务端，再开客户端向组播地址发数据：

# 服务端监听 UDP 端口 sockettool --mode udp-server --host 0.0.0.0 --port 19021 --hex-output on --timestamp on # 客户端向组播地址发送 sockettool --mode udp-client --host 239.255.25.100 --port 19021 \ --send-as hex --payload 01 02 03 --ttl 4

UDP 服务端不需要 accept，所以界面里没有会话列表，每收到一条报文，会直接显示来源 IP 和端口，这正好对应 UDP 无连接的特性。--host 239.255.25.100是组播地址，组播地址范围是 224.0.0.0 到 239.255.255.255，--ttl 4表示报文最多跨 4 跳，跨三层组播时 TTL 太小会导致对端收不到。如果只是想发广播，把--host改成255.255.255.255，并加上--broadcast on。

UDP 调试还要记住两条数：单包最大 65507 字节，这是 IP 报文 65535 减去 UDP 头部的余量；跨越三层网络时建议单包不超过 1472 字节，否则 IP 分片后，任何一个分片丢失都会导致整包丢弃，表现出来就是有规律的丢包。联调时发现 UDP 大报文总丢，先查单包大小，别一上来就怀疑网络质量。

4.2 模拟 50 个设备并发连接：复制连接与发送间隔

有些网关类项目，需要同时观察几十个设备的行为。SocketTool 类工具通常提供连接复制功能，把一条客户端连接复制成多份：

sockettool --mode tcp-client --host 127.0.0.1 --port 19021 \ --preset-client-count 50 --interval 20 \ --send-as hex --payload 01 03 00 00 00 0a 84 0a

--preset-client-count 50让工具同时建立 50 条 TCP 连接，--interval 20表示每条连接启动后间隔 20ms 再发请求。这个功能适合验证网关的会话管理上限和连接回收逻辑，但要说清楚，它模拟不了真实设备的协议栈特征，比如 TCP 窗口、重传策略都和真设备不同，所以它只能说明网关在网络层能不能扛住，不能作为正式压力测试的依据。真做压测，还是要用专门的压测工具。

4.3 粘包、半包与乱序：报文视图里的三种怪象

联调中看到最多的三类问题，我把它们的表现、原因和常规对策整理成一张表：

粘包和半包是 TCP 模式里最磨人的问题。处理思路是维护一个接收缓冲区，把每次 recv 到的数据先塞进去，再从缓冲区里按协议规则拆出完整帧。假定协议是 2 字节长度加正文，拆包逻辑可以写成这样：

def try_decode(buf: bytes): # 缓冲区不到 2 字节，说明连长度字段都不完整 if len(buf) < 2: return None, buf body_len = int.from_bytes(buf[:2], 'big') # 长度字段说 200 字节，实际只到了 80 字节，继续等 if len(buf) < 2 + body_len: return None, buf return buf[2:2 + body_len], buf[2 + body_len:]

这个函数每次调用，返回None表示数据还没凑齐，需要继续等；返回具体的 bytes 和剩余部分，说明已经拆出一条完整报文。SocketTool 类工具如果自带“按长度字段拆包”的选项，原理就是这个。

5. SocketTool 避坑与排查手册：四个高频事故的现场还原

用了这么多年，真正让我觉得“幸好有这个工具”的时刻，都是卡在诡异现象里的时候。这一章不聊概念，直接排队盘四个高频事故，每条按现象、原因、解决三步来。

5.1 监听失败，报 Address already in use：端口其实还在 TIME_WAIT

现象：设好端口 19021，启动服务端立刻报绑定失败，换一个端口又正常。原因：上一次联调的进程没有完全退出，端口还处于 TIME_WAIT 状态；或者有别的调试工具默默占用了同一个端口。TIME_WAIT 是主动关闭方要停留约 2 个报文最大生存时间的状态，正常要几十秒甚至更久才能释放。解决：先用系统命令查占用，Windows 执行netstat -ano | findstr 19021，Linux/macOS 执行lsof -i :19021；看到残留进程后等它超时或直接结束进程。如果工具提供SO_REUSEADDR开关，打开它也能绑定 TIME_WAIT 中的端口。需要注意的是，别为了绕过报错随手换一个端口，那样可能掩盖另一个工具占端口的问题。

5.2 连接秒断，对端发来 RST

现象：TCP 客户端显示连接已建立，一两秒后连接状态直接变成关闭，接收区出现对端重置的错误码。原因：大概率两种。一种是对端应用层已经 close，但发送缓冲区里还有没发完的数据，内核只能用 RST 强制结束；另一种是连接建立后长时间没有业务数据，被中间设备或对端的空闲超时策略踢掉。解决：抓包工具看时序。如果抓包里 FIN 和 RST 紧挨着出现，说明对端应用层收到数据后立刻关闭；如果只有 ACK，隔一段时间才有 RST，多半是空闲超时。确认是超时后，把工具心跳间隔调整到设备保护时长的三分之一，比如设备 60 秒没数据就断开，心跳设 20 到 30 秒。

5.3 显示发送成功，但对端就是没收到

现象：工具状态栏显示“已发送 n 字节”，对端日志里却一条请求都没有。原因：三种情况最常见。第一，Nagle 算法把多个小包合并，对端应用在等完整帧，超时后才处理，看起来像没收到。第二，send成功只表示数据进入了内核发送队列，不代表网卡已经发出。第三，中间防火墙或安全软件把特征明显的调试报文直接丢弃。解决：在工具里打开 TCP_NODELAY，先把 Nagle 关掉；然后用抓包工具确认报文是否真的出现在链路上。抓包能看到而对端没有，问题就在对端应用层，检查它的接收线程是否阻塞或者缓冲区有没有及时读走。抓包也看不到，重点查本机防火墙出方向规则。

5.4 中文报文转 Hex 后对不上：UTF-8 和 GBK 必须二选一

现象：协议文档里写的中文字段是B2 E2 CA D4，工具里把同样的字符串转 Hex 得到E6 B5 8B E8 AF 95，两边对不上。原因：设备固件用 GBK 编码，工具默认按 UTF-8 转字节；同一个词“测试”，UTF-8 每个汉字占 3 字节，GBK 占 2 字节，结果当然不同。解决：联调第一天就在协议文档里写死编码格式，工具侧把字符编码切到 GBK 或 GB18030 再转 Hex。如果文档已经给了 GBK 的 Hex，工具又只支持 UTF-8，先用本地脚本把文本转码后再填进 payload。这里还要多提醒一句：编码一变，CRC 校验字节也要跟着重新计算，联调时经常出现“改对了编码、忘了重算 CRC”的情况。

6. 把 SocketTool 从手工点击变成自动化联调：脚本回放与断言检查

手工点界面适合刚开始摸底，做长跑联调和回归验证时，建议把 SocketTool 导出的日志交给脚本回放。下面这个脚本读一个 hex 日志文件，逐条发送，并检查响应里是否包含特征字节：

import socket def replay(server: str, port: int, log_path: str, expect: bytes): s = socket.create_connection((server, port), timeout=5) for raw in open(log_path, encoding='utf-8'): line = raw.strip() if not line or line.startswith('#'): continue # 如果这一行全是 hex 字符，就按 hex 解析 if set(line) <= set('0123456789abcdefABCDEF '): payload = bytes.fromhex(line.replace(' ', '')) else: payload = line.encode('utf-8') s.sendall(payload) try: resp = s.recv(1024) except socket.timeout: print('timeout:', payload.hex()) continue if expect and expect not in resp: print('mismatch, expect', expect.hex(), 'got', resp.hex()) s.close()

这个脚本的参数分别是服务端地址、端口、日志文件和期望响应特征。字符集过滤的作用是自动区分日志行是 hex 还是普通文本，省去手工转换。expect参数传一个字节串，比如b'\x01\x03'，脚本会在每个响应里做包含匹配，不通过就把报文 hex 打出来。跑完一轮，把输出重定向到文件，就是一份现成的回归报告。

长时间联调时，光回放还不够，要看工具能不能顶住一整晚。自动重连和心跳保活的常见做法是外面套一层重试循环：

import socket import time host, port = '127.0.0.1', 19021 while True: try: s = socket.create_connection((host, port), timeout=5) print('connected') while True: s.sendall(b'\x01\x00\x00\x01') # 应用层心跳 time.sleep(30) except Exception as e: print('connection lost:', e) time.sleep(5)

心跳设 30 秒，重连间隔设 5 秒。这个节奏适合大多数网关设备，既能占住连接不被踢掉，又不会因为频繁重连把对端日志刷爆。代码里的心跳报文要根据实际协议改写，不要照抄。我现在的习惯是，每做一个新协议联调，第一件事就是用 SocketTool 录制一轮正常交互，导出成日志，再写一个像上面这样的回放脚本存进项目里。这样后续每次改动，回归只需要跑一遍脚本，不用再坐在电脑前一边点击一边盯报文。希望你也能把这个习惯用起来，联调路上一路顺畅。

本文还有配套的精品资源，点击获取