简介SocketTool是一款面向网络工程师、系统管理员及后端开发者的TCP通信测试工具主要用于网络编程调试与服务器性能评估。它提供TCP连接与断开、自定义数据包收发、流量控制、通信日志记录以及多线程并发处理等能力可帮助使用者在本地或远程环境中排查网络故障、验证服务器配置并测试协议兼容性。资源包共8个文件以pdf使用说明与二次开发文档、txt版本说明与项目文档、js脚本、exe可执行程序及png安装教程图为主压缩包约1.55MB体积轻便解压后即可按文档指引完成安装与配置。其中使用说明与二次开发文档覆盖基础操作与高级用法安装教程图降低上手门槛脚本文件则便于理解界面交互逻辑。目前已有245人学习下载适合需要快速搭建TCP测试环境、验证数据传输稳定性或进行并发压力测试的开发者参考使用。1. SocketTool 到底解决什么问题从一次端口连不上说起上周三下午测试同事在群里甩了张截图设备管理页面一直转圈后台日志干干净净没有任何报错。我第一反应是服务挂了ps一看进程还在第二反应是防火墙查了规则也没拦。最后掏出 SocketTool建了个 TCP 客户端往目标端口一发连接直接被拒——问题根本不在应用层是服务压根没监听成功只是启动脚本把错误吞了。整个过程从怀疑到定位不到两分钟。SocketTool 这类工具本质就是一个图形化的 Socket 调试台能当 TCP/UDP 客户端发数据也能当服务端收数据还能做十六进制收发、定时发送、多连接管理。它解决的是「网络通不通、数据对不对」这个最底层的问题适合做嵌入式、物联网、工控上位机、后端联调的工程师。你不需要为了验证一个端口写二十行 Python也不用在命令行里跟nc的参数较劲。下面我按自己实际用的顺序把它拆成能直接抄的步骤。2. 建连接与发数据SocketTool 最小可用路径2.1 先分清 TCP 客户端、TCP 服务端、UDP 三种模式打开 SocketTool 第一件事不是急着点连接而是想清楚你在这条链路里扮演谁。这个判断错了后面所有操作都是白费。TCP 客户端模式是你主动去连别人的 IP 和端口比如连设备、连后端服务。TCP 服务端模式是你自己开一个端口等人来连比如模拟一个设备让上位机来采集。UDP 模式没有连接概念只管往目标地址发包适合广播、组播或者那些「发了就不管」的协议。我一般会先问自己一句数据是谁先发起的如果是我的工具先发那大概率是客户端如果是对方设备主动上报那我得开服务端等着。这个判断花十秒钟能省掉半小时的瞎试。2.2 用 TCP 客户端连一个端口并验证收发假设你要连一台设备的 502 端口Modbus TCP 常用端口验证它是否正常响应。操作路径是这样的第一步协议选 TCP Client。第二步远端 IP 填设备地址端口填 502。第三步点「连接」。如果连上了界面上的连接状态会变同时日志区会显示连接成功。连上之后发数据有两种输入方式ASCII 和 HEX。ASCII 就是你直接敲字符比如发helloHEX 就是你敲48 65 6C 6C 6F工具帮你转成字节。做工业协议的时候几乎全是 HEX因为报文里全是二进制字段。# 如果你手边没有 SocketTool用 nc 做同样的验证 # -v 显示详细过程-z 只扫描不发数据-w 2 超时 2 秒 nc -v -z -w 2 192.168.1.100 502 # 想真正发一段十六进制数据用 echo xxd 组合 echo -ne \x00\x01\x00\x00\x00\x06\x01\x03\x00\x00\x00\x01 | nc 192.168.1.100 502 | xxd上面这段命令的逻辑是nc -v -z只做连接探测确认端口开没开第二条命令把十六进制字节流通过管道喂给nc再把返回的数据用xxd转成十六进制显示。参数上-w 2是超时时间网络慢的环境可以调到 5xxd不加参数就是标准十六进制输出加-p是纯十六进制连续输出方便复制。SocketTool 里对应的操作就是HEX 模式下粘贴00 01 00 00 00 06 01 03 00 00 00 01点发送然后看接收区返回什么。如果返回00 01 00 00 00 05 01 03 02 00 01说明设备正常响应了。2.3 接收区的编码与显示设置接收区最容易翻车的地方是编码。设备返回的字节流里如果既有 ASCII 又有二进制你选错显示模式就会看到一堆乱码然后误判成「数据错了」。我的习惯是调试阶段一律先用 HEX 显示确认字节序列对了再切到 ASCII 看可读部分。SocketTool 一般会提供「HEX 显示」和「ASCII 显示」的切换有的版本还支持混合显示。如果接收区能设置「自动换行」和「显示时间戳」建议都打开排查时序问题的时候时间戳就是你的后悔药。还有一个细节接收缓冲区大小。如果对方一次发几 KB 的数据而你的接收区只显示最后 1KB你会以为数据丢了。遇到「发得多收得少」先去设置里把接收缓冲区调大再怀疑网络。3. 十六进制收发与定时发送协议联调的核心操作3.1 HEX 输入格式的四个边界坑十六进制输入看起来简单实际上我见过太多人栽在这上面。第一个坑空格分隔和连续输入混用。有的工具只认00 01 02你写000102它就不认有的反过来。第二个坑大小写。大部分工具不区分但个别老版本只认大写。第三个坑奇数个字符。0 1 0 2这种工具不知道你是想发01 02还是00 01 00 02。第四个坑注释。有些工具支持//注释有些不支持你写了注释它当成数据发出去。我的做法是统一用「两个字符一组、空格分隔、大写」的格式比如01 03 00 00 00 01。这个格式兼容性最好复制到哪个工具里都不会出问题。# 用 Python 生成一段 Modbus 读保持寄存器的请求报文 # 这样你就不用一个个手敲十六进制了 import struct def build_modbus_read(slave_id, start_addr, quantity): # 事务标识符随便填设备一般会原样返回 transaction_id 0x0001 # 协议标识符Modbus 固定为 0 protocol_id 0x0000 # 后面还有多少字节先占位 length 0x0006 # 功能码 03 表示读保持寄存器 function_code 0x03 # 起始地址和数量都是两个字节 payload struct.pack(HH, start_addr, quantity) # 拼接完整报文 frame struct.pack(HHHBB, transaction_id, protocol_id, length, slave_id, function_code) payload return frame # 生成从地址 0 开始读 1 个寄存器的报文 frame build_modbus_read(1, 0, 1) # 转成十六进制字符串方便粘贴到 SocketTool print( .join(f{b:02X} for b in frame)) # 输出00 01 00 00 00 06 01 03 00 00 00 01这段代码的价值在于当你需要频繁改起始地址和寄存器数量时手敲十六进制很容易错一位。用脚本生成改参数就行。struct.pack(HHHBB, ...)里的表示大端序Modbus TCP 默认就是大端H是两字节无符号整数B是一字节。如果你要读 10 个寄存器把quantity改成 10输出里的最后两个字节会自动变成00 0A。3.2 定时发送的参数怎么设才不翻车定时发送这个功能用好了是自动化测试利器用不好就是给自己挖坑。最常见的翻车场景是间隔设了 100ms结果设备处理不过来缓冲区堆积最后要么丢包要么设备死机。我一般会分三步定参数。第一步先手动发一包看设备多久返回这个时间记为 T。第二步定时间隔至少设成 3T 到 5T给设备留足处理时间。第三步如果要连续发几百包先设 1 秒间隔跑一轮确认稳定了再逐步缩短。SocketTool 里定时发送一般有两个参数间隔时间毫秒和发送次数0 表示无限。做压力测试的时候我会把发送次数设成有限值比如 1000然后盯着接收区的计数。如果发送计数到了 1000接收计数明显小于 1000说明中间有丢包这时候要么加大间隔要么去查网络质量。提示定时发送期间不要频繁切换 HEX/ASCII 显示模式有些工具在切换时会短暂停止接收导致你误以为丢包。3.3 多连接管理与会话隔离做网关类设备调试时经常需要同时连多个端口或者多个设备。SocketTool 的多连接能力就派上用场了。我一般会按「一个连接一个会话」的原则来管理连接 1 连设备 A 的 502 端口连接 2 连设备 B 的 502 端口每个连接的收发区独立。这里有个容易忽略的点发送区的数据是跟着连接走的。你在连接 1 里输入的数据切到连接 2 后不会自动带过去。所以我的习惯是每个连接建好后先把要用的报文粘贴到对应的发送区再统一点发送。这样不会出现「以为发给了 A实际发给了 B」的乌龙。如果工具支持「连接分组」或者「会话命名」一定要用起来。把「设备 A-502」这样的名字写上比默认的「连接 1」清楚一百倍。调试现场手忙脚乱的时候一个清晰的名字能救你一命。4. 避坑与排查SocketTool 联调中的五个血泪教训4.1 连上了但收不到数据现象客户端显示连接成功发送数据也显示已发送但接收区一直空白。原因这种情况八成不是 SocketTool 的问题而是对方服务端只收不发或者你的发送报文触发了它的静默逻辑。比如有些设备收到不合法的功能码直接丢弃不回错误帧。解决先用nc或者 Wireshark 确认数据到底有没有到对端。如果到了但没回去查对端的协议文档确认你发的报文格式、功能码、地址范围是否合法。别在 SocketTool 这边反复重连方向错了。4.2 中文乱码现象接收区显示的中文是乱码英文正常。原因编码不匹配。设备发的是 GBK你按 UTF-8 显示或者反过来。解决在 SocketTool 的显示设置里切换编码。如果工具不支持切换就用 HEX 模式看原始字节然后手动用 Python 解码验证bytes.fromhex(...).decode(gbk)。确认编码后再决定是改工具设置还是改设备固件。4.3 定时发送导致工具卡死现象设了 10ms 间隔的定时发送跑了几分钟之后 SocketTool 界面无响应。原因发送频率太高UI 线程被日志刷新拖死。很多工具把收发日志直接刷到界面上高频发送时日志量爆炸。解决把发送间隔调到 100ms 以上或者在设置里关闭「实时显示发送日志」只保留接收日志。如果工具支持「日志缓冲」把缓冲区调大减少 UI 刷新次数。实在不行换命令行工具做压力测试SocketTool 只用来做功能验证。4.4 服务端模式绑定端口失败现象想用 SocketTool 开一个 TCP 服务端点启动时提示绑定失败。原因端口被占用了。可能是之前的调试进程没退干净也可能是系统里别的服务占着。解决Windows 上用netstat -ano | findstr :端口号找到占用进程的 PID然后决定是杀掉还是换端口。Linux 上用ss -lntp | grep 端口号。换端口是最省事的做法但记得同步改对端的连接配置。4.5 发送成功但设备无响应现象SocketTool 显示发送成功字节数也对但设备就是不动。原因发送成功只代表数据写进了操作系统的 socket 缓冲区不代表对方收到了。中间可能被防火墙拦了、被交换机丢了、或者对方根本没在监听。解决按「本机→网络→对端」的顺序排查。本机先用telnet IP 端口或nc -vz确认端口可达网络层用 Wireshark 抓包看数据有没有发出去、有没有收到 ACK对端确认服务是否真的在监听。这个顺序能帮你快速缩小范围别一上来就怀疑工具。5. 把 SocketTool 用成协议验证器一个进阶习惯5.1 用「发送-接收-比对」闭环替代肉眼检查新手用 SocketTool往往是发一包、看一眼、再发一包。熟手会把它用成半自动的协议验证器。具体做法是把请求报文和期望的响应报文都准备好发送后不靠肉眼比对而是把接收到的 HEX 复制出来用脚本做字节级比对。# 验证设备返回的报文是否符合预期 expected 00 01 00 00 00 05 01 03 02 00 01 actual 00 01 00 00 00 05 01 03 02 00 01 # 从 SocketTool 接收区复制 # 去掉空格转成字节列表 exp_bytes bytes.fromhex(expected.replace( , )) act_bytes bytes.fromhex(actual.replace( , )) if exp_bytes act_bytes: print(PASS: 报文完全一致) else: print(FAIL: 报文不一致) # 逐字节找出差异位置 for i, (e, a) in enumerate(zip(exp_bytes, act_bytes)): if e ! a: print(f 第 {i} 字节: 期望 {e:02X}, 实际 {a:02X}) # 长度不一致也要报出来 if len(exp_bytes) ! len(act_bytes): print(f 长度不一致: 期望 {len(exp_bytes)}, 实际 {len(act_bytes)})这个脚本的核心是bytes.fromhex()它把十六进制字符串转成字节对象然后做逐字节比较。zip会按较短的序列截断所以长度不一致的情况要单独判断。输出里标出第几个字节不一致比肉眼扫一长串十六进制快得多。我一般会把这个脚本存成一个check_frame.py每次从 SocketTool 复制接收数据后改一下actual变量就能跑。做回归测试的时候把多组期望/实际数据写成一个列表循环比对几分钟就能覆盖几十个用例。5.2 参数速查表参数项常用值说明TCP 连接超时2~5 秒局域网 2 秒够用跨网段设 5 秒定时发送间隔100~1000ms功能验证用 1000ms压力测试逐步降到 100ms接收缓冲区4096~65536 字节大数据量场景调到 64KBHEX 显示默认开启调试阶段一律用 HEX确认后再切 ASCII发送次数有限值优先压测时设 1000 次避免无限发送失控编码HEX 优先中文场景确认 GBK/UTF-8 后再切换这张表是我自己调试时的默认起点具体值要根据设备响应速度和网络质量微调。比如设备响应要 500ms那定时间隔至少 1500ms 起步。5.3 我踩过的最深的一个坑早期做 Modbus 调试我一直以为「发送成功」就等于「设备收到了」。有一次现场设备不响应我在 SocketTool 这边反复重发了几十次最后抓包才发现数据包压根没出本机网卡——目标 IP 填错了填成了本机另一个网段的地址系统直接走了本地回环。从那以后我养成了一个习惯每次新建连接先ping一下目标 IP再用nc -vz探一下端口两个都通了才打开 SocketTool 发数据。这个习惯看起来多花三十秒但能挡掉八成「工具没问题、配置有问题」的无效调试。SocketTool 是个好工具但它只能告诉你「我发了」不能告诉你「对方收了」。把连通性验证前置比事后抓包省事得多。希望帮到你。本文还有配套的精品资源点击获取