首页 / 资讯中心 / 文章详情

sokit 1.3 win32中文版使用指南:TCP/UDP调试与HEX报文实战

sokit 1.3 win32中文版使用指南:TCP/UDP调试与HEX报文实战 ★ FEATURED ARTICLE
简介Sokit 1.3 是一款面向 Windows 32 位系统的轻量级端口管理工具压缩包自带简体中文支持适合网络管理员、开发者和运维人员在排查端口占用、验证服务连通性、监控网络连接等场景中使用。它无需复杂安装解压即可运行对熟悉命令行的用户也能提供直观的图形界面操作技能门槛较低。资源包共含6个文件以可执行程序、简体中文语言包、txt/htm 说明文档为主另有 GPL 许可协议与更新日志压缩后仅 3.91MB体积小巧便于随身携带或在多台机器间快速部署。说明文档内含使用方法和常见问题解答可帮助用户快速上手。目前已有 4221 人学习/下载。使用该工具可实时查看本机端口监听状态、定位占用端口的进程、测试指定端口连通性并能记录端口活动日志为网络故障排查、服务调试和基础安全审计提供有力支持。对于需要频繁管理 Windows 网络端口的用户来说这是一份实用且易上手的入门资源。1. sokit-1.3-win32-chs.zip 是什么一个网络调试工具的选择题sokit-1.3-win32-chs.zip 这个安装包是我这些年调试网络设备时用得最多的老工具sokit 1.3 的 Windows 32 位简体中文版。你只需要解压、双击就能把一个 TCP 客户端、TCP 服务端或 UDP 收发窗口拉到桌面上不用装 Python、不用记 netcat 参数。win32 是指它面向 32 位 Windows在 64 位系统上照样能跑chs 表示简体中文界面。它适合三类人写上位机和嵌入式固件的工程师、做设备联调的现场技术支持、需要快速验证端口通不通的运维。这篇笔记顺着这个包的解压、启动、参数设置到常见坑走一遍最后给你一个能直接复制的报文回放技巧。2. 把 sokit-1.3-win32-chs 跑起来解压、启动和 TCP/UDP 三种模式2.1 解压到纯英文路径先别急着双击拿到 zip 后不要直接双击进去看先把整个目录解压出来。我一般会放到D:\tools\sokit这种纯英文路径而不是放在桌面或者带中文的文件夹里。你可能会觉得这是玄学但这类老程序对 ANSI 路径的处理确实不完善放在中文路径下偶尔会出现配置文件写不进去、按钮点了没反应之类的怪问题。解压完毕后目录里通常有一个 exe 主程序可能是sokit.exe或类似名字。双击运行如果没有任何反应右键选择“以管理员身份运行”再试一次。win32 老程序在 Windows 10、Windows 11 上第一次启动时经常被 UAC 拦一下管理员权限能绕开一部分启动失败的问题。启动后的界面不算现代但布局很清晰左侧是一个会话树用来管理当前建立的连接右侧上半部分是发送区下半部分是接收区。底部或工具栏附近堆着连接模式、HEX 开关、编码选择、定时发送之类的控件。先不急着点把三种模式的差别搞清楚再动手。2.2 为什么还要选 sokit和 telnet、netcat、Python 的对比现在能调试 TCP 的工具太多了但实际现场里 sokit 仍然有它的不可替代性。telnet 能测端口通不通但没法方便地发 HEX 报文netcat 功能全但 Windows 默认不带还得去下载Python 足够灵活可工控机上往往没有 Python 环境现场也不可能等你现装。sokit 的优势是绿色、免安装、图形界面、自带 HEX 编辑几秒钟就能把调试环境拉起来。工具安装成本交互方式HEX 报文典型场景telnet系统自带命令行不方便只测端口通断netcat需下载命令行可用参数绕脚本化测试Python需安装脚本灵活自动化回归sokit解压即用GUI方便直观现场联调、快速验证这不是说 sokit 比它们都强而是说在“临时、快速、现场、没有环境依赖”这四个条件下它是性价比最高的选择。后面章节里我也会配合 Python 脚本补足 sokit 不具备的自动化能力两者并不冲突。2.3 TCP 客户端最小流程从输入 IP 到发出第一条报文最常见的使用方式是把 sokit 当作 TCP 客户端去连一个已知端口。操作步骤是这样在主界面的模式下拉框里选择 TCP Client。在目标地址栏填入对端 IP比如127.0.0.1端口填9000。点击“连接”按钮等待连接成功。连接成功后左侧会话树会出现一个条目选中它。在发送区输入hello点击“发送”。在接收区查看对端返回的数据。连接成功与否界面上通常会有状态提示如果失败先检查 IP 和端口有没有写错再检查对端服务是否真的在监听。为了验证这条链路我一般会在本地起一个最小的回显服务端用 Python 写很简单import socket srv socket.socket(socket.AF_INET, socket.SOCK_STREAM) srv.bind((127.0.0.1, 9000)) srv.listen(1) print(listening on 127.0.0.1:9000) conn, addr srv.accept() print(client:, addr) data conn.recv(1024) print(recv:, data) conn.send(bok) conn.close()这段代码先绑定本机 9000 端口然后等待一个客户端连接。收到数据后原样打印并回一个ok给 sokit。逻辑很简单sokit 发什么服务端就打印什么。参数说明里注意bind的地址写127.0.0.1表示只接受本机连接如果你想从局域网另一台机器测试就要改成0.0.0.0。跑通这个例子后你就能确认 sokit 的 TCP 客户端链路是好的。2.4 TCP 服务端和 UDP 模式监听端口与广播报文sokit 也能反过来当服务端这个场景在调试自己的上位机程序时非常有用。模式选择 TCP Server端口填一个未被占用的端口比如7000点击开始监听。当有客户端连进来时会话树会多出一个子节点代表这个新连接。这里有一个关键操作回复数据之前一定要先选中这个子节点而不是选中监听节点。如果选错数据发不出去或者被发给错误的连接这是很多人第一次用 sokit 时最容易踩的坑。UDP 模式则是另一套逻辑。UDP 没有连接概念sokit 只需要绑定一个本地端口比如6000就能接收发到该端口的数据报。发送时填写对端 IP 和端口直接点发送即可哪怕对端程序没启动数据也会从网卡发出去。这个特性在调试设备发现、心跳上报这类场景里很有用。模式是否需要连接典型场景关键注意点TCP Client是主动连设备服务端确认对端端口开放TCP Server是接收设备主动上报回复前选中具体连接UDP否设备发现、心跳、广播对端不在线也能发三种模式覆盖了绝大多数联调场景。TCP Client 测“我去连别人”TCP Server 测“别人来连我”UDP 测无连接通信。搞清这三种模式后sokit 的基本使用就掌握了七成剩下的是参数细节。3. sokit 必调的核心参数HEX 编辑、字符编码和定时发送3.1 HEX 模式与 ASCII 模式相同内容完全不同报文sokit 的发送区通常有一组显示模式开关最常见的是 ASCII 和 HEX 两种。这个开关决定了你敲进去的字符串最终以什么形式出现在网线上。举个例子你在发送区输入41如果当前是 ASCII 模式sokit 会把字符 4 和字符 1 分别按 ASCII 编码发送也就是发出去两个字节0x34 0x31。如果切到 HEX 模式sokit 会把41当作十六进制数发出去一个字节0x41。同一个界面文本两种模式发出去的内容完全不同协议调试时这决定了设备认不认你的报文。我日常的规则是凡是和设备约定好的二进制协议一律用 HEX 模式发送。输入时用大写字节之间用空格分隔比如01 03 00 00 00 01。注意不要混入逗号、分号sokit 不是必须解析分隔符但空格是最不容易出错的。有些协议文档会写成01,03,00,00你在 sokit 里发送前先统一替换成空格。3.2 字符编码chs 版在 GBK 与 UTF-8 之间的取舍文件名里的 chs 只代表界面是简体中文不代表 sokit 会自动帮你转换字符编码。发送区输入汉字、中文标点或者带中文的 JSON 字符串时字符编码选择直接决定字节流。常见做法是发送区旁边有一个编码下拉框提供 GBK、UTF-8、ANSI 之类的选项。如果对端是国产工控设备、DTU、串口服务器它们很多默认按 GBK 解释字节如果对端是 Python、Java 写的现代服务基本默认 UTF-8。选错编码最典型的表现是对端收到中文变成乱码或者你收到对端返回的中文乱码。对端类型建议编码说明国产串口设备、DTUGBK很多老设备固件写死 GBKPython/Java 服务UTF-8标准网络程序默认纯数字十六进制报文任意与编码无关不受影响调试时有一个土办法先用英文或拼音发一遍确认链路通再发中文如果乱码切换编码重发一次。不要一上来就纠结编码链路不通时编码问题没有意义。3.3 定时发送与重发次数周期、次数和停止定时发送是 sokit 这类图形工具比命令行方便的地方。很多协议需要周期性请求比如每隔一秒读一次设备状态或者持续发送心跳包。定时发送一般有两个参数周期和次数。周期单位是毫秒1000 表示一秒一次次数填 0 在不少工具里表示无限循环填具体数字表示发送几轮后自动停止。调参数时先设一个保守值验证逻辑再逐步调小。100ms通常足够模拟大多数工业轮询请求10ms已经接近极限再小就会出现界面卡顿、发送窗口刷新不过来的情况。定时发送一旦卡死点停止按钮往往也没反应这时候别反复点直接结束进程重新打开。后面第 4 章我会专门讲这个坑。3.4 接收区显示参数时间戳、自动换行与清屏策略接收区的显示参数容易被忽略但在排障时很关键。首先要确认接收区是 HEX 显示还是 ASCII 显示。二进制协议里如果按 ASCII 显示很多不可见字符会变成乱码方块看不出真实内容切到 HEX 显示后每个字节变成两个十六进制字符一眼就能对照协议文档。时间戳开关也值得打开。联调时经常需要判断两个事件之间的时间关系有毫秒级时间戳能快速定位“是不是超时了”。自动换行看个人习惯HEX 模式下每行字节变长不开自动换行就得横向拖滚动条建议打开。最后是清屏按钮的使用习惯。接收区的数据一旦清空就找不回来了重要报文在清屏之前先点“保存”或者手动复制出来。这不是 sokit 独有是所有网络调试工具的通病。后面第 6 章我会写一个配合脚本回放已保存报文的技巧前提就是你得先养成保存的习惯。4. sokit-1.3-win32 常见问题避坑指南起不来、连不上、发不对、乱码4.1 启动失败双击没反应或报缺 DLL现象在 Windows 10 或 Windows 11 上双击 sokit 可执行文件要么完全没反应要么弹窗提示“由于找不到 XXX.dll无法继续执行代码”。原因这是一款 32 位老程序依赖旧版 VC 运行库。新系统默认不预装这些运行库程序启动时找不到依赖项就会罢工。解决优先安装微软常用 VC 运行库合集装完后重启 sokit。如果公司电脑没有管理员权限把对应的 DLL 放到 sokit 所在的目录也能生效。建议再打开一个 cmd 窗口在命令提示符里直接输入 sokit 的完整路径运行让它把错误信息打印出来比双击后瞎猜高效得多。4.2 服务端收不到连接或者发送按钮无效现象sokit 作为 TCP Server 启动成功设备也显示连接上了但发送按钮是灰的或者点击发送没有任何效果。原因sokit 的会话树区分“监听节点”和“具体连接”。监听节点代表整个端口不是一条真实的连接要回复某个客户端必须选中那个客户端对应的子节点。没有选中具体连接时发送按钮自然不生效。解决展开会话树点击目标客户端对应的条目再点发送。反过来如果你是 TCP Client 连不上对端用netstat -ano | findstr 端口号查看对端端口是否处于 LISTENING 状态再检查防火墙是否放行了入站连接。4.3 HEX 报文发出去对方不回复现象按照协议文档在发送区填好了十六进制报文比如01 03 00 00 00 01 84 0A但设备就是没有反应。原因最常见的是当前处于 ASCII 模式发出去的是这些字符的 ASCII 码而不是十六进制字节其次是报文里的逗号、全角空格混了进去成了多余的符号有些带 CRC 校验的协议末尾校验字节算错也会导致设备直接丢弃。解决先确认发送区旁边的 HEX 开关已打开把逗号统一替换成空格对着协议文档逐字节数一遍确认长度和校验值。有人把报文在 ASCII 模式下发了一整夜设备纹丝不动最后发现只是模式选错这类事情在协议联调中真的常见。4.4 中文内容乱码现象发送中文后对端显示乱码或者 sokit 接收区里对端返回的中文变成难以辨认的符号。原因两端字符编码不一致。常见的组合是 sokit 按 GBK 发送对端按 UTF-8 解释或者反过来。还有一种情况是接收区切到了 HEX 显示把 UTF-8 字节直接当 ASCII 渲染看起来像乱码其实不是乱码。解决先区分是“显示乱码”还是“字节乱码”。切换接收区的显示模式试试如果切到 ASCII 后中文正常说明只是显示问题如果仍然乱码切换发送端的编码选项重新发送。先用纯英文报文验证链路再引入中文能减少排查维度。4.5 定时发送把窗口刷死现象把定时发送周期调到 1ms点下发送后窗口直接假死停止按钮也点不动整个 sokit 看起来像崩溃了。原因老工具多数把接收和发送刷新逻辑放在 UI 线程里发送频率过高时界面渲染跟不上窗口就卡住了。解决不要等它自己恢复直接打开任务管理器结束 sokit 进程再重启。之后把周期先设到 50ms 或 100ms 验证需要更小周期时优先用脚本而不是 sokit 的定时发送。接收区可以暂时勾选暂停刷新等数据收完再恢复显示这个功能能缓解高频数据下的卡顿。5. sokit 联调实战串口透传、Modbus 报文与临时服务端5.1 串口透传设备的联调流程把 COM 口搬到 TCP现场最典型的场景之一是调一台串口服务器。它把 RS485 总线上的设备数据封装成 TCP 服务PC 通过网络访问串口服务器就能和远端设备通信。sokit 在这里的角色就是 TCP 客户端。先确认串口服务器的 IP 和 TCP 端口比如192.168.1.200:8899打开 sokit选择 TCP Client填入地址和端口点连接。连接成功后在 HEX 模式下发送读取指令比如 Modbus RTU 的读寄存器报文串口服务器会把这条报文原样转到 RS485 总线上设备返回的数据再原路经 TCP 传回 sokit 接收区。这里要明确一个边界sokit 只负责 TCP/UDP 层面的字节收发它不会帮你计算 CRC不会解析 Modbus 协议更不会处理串口参数。串口服务器侧的波特率、数据位、校验位需要你在串口服务器的配置页面里设好sokit 拿到的是已经透明的字节流。5.2 拼一条 Modbus TCP 报文从协议文档到 sokit 输入框拿最常见的读保持寄存器举例。Modbus TCP 请求帧结构是事务处理标识符 2 字节、协议标识符 2 字节、长度 2 字节、单元标识符 1 字节、功能码 1 字节、起始地址 2 字节、寄存器数量 2 字节。假设事务 ID 是00 01协议 ID 固定00 00长度是后面 6 个字节单元标识符01功能码03起始地址00 00数量00 01拼出来就是00 01 00 00 00 06 01 03 00 00 00 01在 sokit 发送区输入这串十六进制确认 HEX 模式打开点发送。注意 Modbus TCP 帧末尾没有 CRCCRC 是 Modbus RTU 串口帧才需要的。很多第一次从串口转网络的人习惯性把 RTU 的 CRC 字节也拼上去反而画蛇添足。如果对端是 Modbus TCP 网关收到多余字节会解析失败。5.3 写一个临时服务端配合 sokit 验证链路现场不一定有现成的设备这时候我会写一个最简服务端程序让 sokit 和它先跑通逻辑。下面这段 Python 代码监听 5020 端口收到功能码03的请求后回一帧固定的 Modbus TCP 响应import socket srv socket.socket(socket.AF_INET, socket.SOCK_STREAM) srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) srv.bind((0.0.0.0, 5020)) srv.listen(1) print(server on 0.0.0.0:5020) conn, addr srv.accept() print(client:, addr) while True: data conn.recv(256) if not data: break print(recv:, data.hex( )) if data[7] 3: # 功能码 0x03 读保持寄存器 resp bytes.fromhex(00 01 00 00 00 05 01 03 02 00 01) conn.sendall(resp)这段代码里bind用0.0.0.0表示监听本机所有网卡这样你从局域网其他机器也能连上来SO_REUSEADDR允许程序停止后立即重启避免端口被 TIME_WAIT 状态占住。收到数据先打印十六进制方便你对照 sokit 发送框里的内容是否一致。第 7 个字节data[7]正好是功能码位置如果不是03就继续循环等待。还有一个要注意的边界sokit 本身不处理 TLS/SSL 加密。如果你用它去连 HTTPS 或者带 TLS 的服务接收区看到的是一堆无法解读的加密字节这不是程序坏了而是数据在传输层已经被加密。要调加密协议得先用openssl s_client或类似工具把 TLS 层剥掉再交给 sokit。6. 保存报文、脚本回放sokit 最后的进阶技巧联调尾声sokit 接收区已经积累了上百条报文。这时候不要急着清屏先把接收区内容点“保存”存成文本文件。大多数版本保存出来的是带时间戳、带[RECV]前缀的文本行不能直接回放需要先清洗一遍。我习惯用 Python 做这件事import re with open(recv.txt, encodingutf-8) as f: payloads [] for line in f: line line.strip() if not line: continue if line.startswith([RECV]): line line[len([RECV]):].strip() line re.sub(r^\d{2}:\d{2}:\d{2}, , line) payloads.append(bytes.fromhex(line))清洗逻辑就三步跳过空行、剥掉[RECV]前缀、去掉行首时间戳最后按十六进制还原成字节。保存文件的具体格式以你手头这个版本为准但核心思路是一样的把展示用的文本恢复成能直接用的字节流。清洗之后你可以用 Python 重新连接设备把这些报文按原顺序逐条发送做一次快速的回归验证看看设备是否还能复现当时的响应。这个技巧帮过我一次大忙。当时调一台网关它只在收到第三帧请求后才返回完整状态肉眼盯屏幕怎么都看不出来最后把保存的报文按时间戳顺序回放才发现前两帧的事务 ID 没有递增网关认为它们是重复请求直接丢掉了。从那以后我养成了一个习惯每次联调结束都把接收区的原始报文保存成带日期的文件文件名里写清设备型号和调试内容。这些文件就是你在这个项目上的黑匣子什么时候出了问题都能翻出来对照。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助?
咨询建站