简介：Sokit 1.3 是一款面向 Windows 32 位系统的轻量级端口管理工具，集成简体中文界面，适合网络管理员、开发者在日常运维中检查开放端口、监听连接、测试端口连通性与定位占用端口的进程。与大型网络软件相比，它更强调便携与快速响应，解压后可直接运行主程序，配合自带的说明文档即可上手，无需额外配置环境。压缩包共 6 个文件，主要包含可执行程序、说明文档、开源许可、语言文件及日志等类型，整体仅 3.91MB，遵循 GPL-3.0 开源许可，适合作为绿色工具常备。该工具支持端口扫描、实时监听、连通性测试、端口开关控制、网络诊断及日志记录等常见功能，可用于服务器端口排查、Web 服务调试、远程连接诊断等实际场景；日志功能还可留存端口活动历史，便于安全审计与事后回溯。已有 4221 人学习下载，适合需要快速处理端口相关问题、优化系统网络性能的中级网络爱好者，无论是排查服务冲突、定位恶意连接，还是理解端口与进程的对应关系，都能在动手实践中获得直观认识。
1. sokit 是什么：一个让 TCP/UDP 联调不再黑匣子的 win32 小工具
sokit-1.3-win32-chs.zip 这个压缩包看起来不起眼，但它装的是我电脑里使用率最高的网络调试工具之一。做嵌入式、工控上位机或者设备联调的人，基本都遇到过这种场面：设备端说收不到数据，上位机说已经发出去了，两边对着协议文档反复查，最后还是不知道数据死在哪一步。sokit 就是用来打破这个僵局的，它是一个能在 Windows 32 位环境下直接充当 TCP 客户端、TCP 服务端、UDP 单播或广播端的图形化调试助手。压缩包解压即用，不需要安装，特别适合在工控机、旧笔记本或者虚拟机里快速搭联调环境。下面从它到底是什么讲起，一路落到参数配置、常见坑和具体项目里的使用习惯。
2. 先看懂 sokit 的原理：为什么联调要单独用一个调试助手
2.1 调试助手、抓包工具和 netcat：三者分工其实很明确
或许你觉得，Windows 自带 telnet，或者装个 Wireshark 不就够了？真正到现场的时候你会发现，这几个工具的定位差得很远。sokit 属于主动式 socket 调试助手，它会自己创建 socket、完成 connect、listen、bind 这些操作，然后让你手动输入任意字节流发给对端，当场观察回应。Wireshark 这类抓包工具是被动的，它挂在网卡上看经过的流量，能解析 TCP 重传、SYN 包、应用层负载，但它不会主动替你建一条连接去「问」对端一句。调试时经常是 sokit 把应用层逻辑跑通，Wireshark 再确认网络层是否干净。
那它和 netcat 有什么区别？netcat 功能其实很强，但要临时构造一段十六进制数据，命令参数的记忆成本很高。telnet 主要是面向字符交互，发几个可见字符行，遇到二进制协议就捉襟见肘。sokit 把 TCP Client、TCP Server、UDP 收发收到同一个界面里，文本和十六进制能即时切换，还支持文件发送和接收数据保存，这些恰是联调时最常用的操作。它不追求大而全，而是把「手动收发任意字节」这件事做到顺手。
| 工具类型 | 典型代表 | 是否主动建连 | 能否构造任意字节 | 主要用途 |
|---|---|---|---|---|
| 主动调试助手 | sokit | 能 | 能 | 应用层协议联调 |
| 被动抓包 | Wireshark / tcpdump | 不能 | 不能 | 网络层流量分析 |
| 命令行工具 | telnet / netcat | 能 | 勉强 | 应急检查与脚本化 |
我第一次调 Modbus TCP 温控模块时，模块文档只说支持标准 502 端口，设备固件里的多线程和超时重试逻辑全都不好使。当时就是拿 sokit 当第三方客户端去连模块，手动发 01 03 00 00 00 01 84 0A，看返回是不是预期的 01 03 02 02 8F。就那么一步步试，最终发现是上位机的超时设得太短，根本轮不到设备回包。所以我的建议是：协议联调先上 sokit，再决定要不要上 Wireshark，很多问题在应用层就能现出原形。
2.2 主界面拆解：连接区、发送区、接收区、状态栏分别管什么
sokit 的界面不是那种功能密密麻麻的工程软件，打开后你很快能找到四个关键区域。最上面是模式选择，TCP 和 UDP 两大类，每种下面再分客户端与服务端；很多第一次用的人忽略这个入口，直接在上方地址栏填内容，结果在 TCP Client 模式下找不到「监听」按钮。实际上模式选定以后，参数区才会变成对应的形态：TCP Client 要填目标 IP 和目标端口，TCP Server 要填本地监听端口，UDP 模式下还要区分本地端口和目标地址。
中间最显眼的是发送区和接收区，这俩是联调时盯得最多的地方。发送区支持多行文本编辑，也能切到 Hex 模式，按字节输入十六进制数据；接收区同样能在文本和 hex 之间切换，把对端发来的内容按你需要的形式展示。很多版本还在接收区附带清空、字节统计和编码选择，方便你把一次次测试的结果分开看。窗口底部是状态栏，连接成功、连接断开、错误信息都会在这里显示，它是判断当前连接状态的唯一权威来源。
在 TCP Client 模式下，填好地址和端口就直接点「发送」是很常见的误操作。你输入的字节其实进入了发送缓冲，但对端根本没建立连接，界面上看不出明显报错，状态栏可能只写着一个「未连接」。我自己已经养成习惯：发送之前先扫一眼状态栏，看到明确已连接再动手。如果状态栏没反应，不要反复点发送，那只会让问题更难定位。先解决问题，再考虑发数据。
2.3 chs 中文版到底改了什么：汉化边界和实际差异
sokit-1.3-win32-chs.zip 里的 chs，基本可以理解为简体中文语言资源。汉化的重点落在菜单、按钮、标签这类静态文字上，比如「连接」「断开」「发送」「清空」一眼就能认出。这带来了实际好处：新手不用抱着英文界面猜功能，工作效率会高不少。但汉化并不是把底层 socket 错误信息也翻译了，像 Connection refused、Address already in use 这类错误提示，在 win32 构建上仍然可能是英文风格。
这并不算缺陷。联调时看到英文错误码反而更好搜索，拿原样复制到搜索引擎，马上能定位到具体含义。需要留意的是，中文版只是换了显示文字，功能排列和原版没有区别，不存在「汉化版删减功能」的问题。若你在界面上找不到某个选项，对照原版的操作路径去找即可，别把时间浪费在怀疑版本上。另外，中文版的配置文件通常仍然以原版格式存在，复制迁移时改动不大，但我不建议随意修改配置里的字符集项，乱改会让界面和收发数据同时出问题。
3. 在 win32 环境跑通 sokit：解压、配置 TCP 客户端到发出第一包
3.1 运行环境自检：32 位构建的兼容性、运行库与路径
标题里的 win32 明确说明这是 32 位 Windows 构建。在 64 位 Windows 上它照样能跑，系统会通过 WoW64 兼容层去执行 32 位程序，这一点不用担心。拿到压缩包后先做三件事：第一，确认解压后目录里同时有可执行文件和它依赖的 dll，不要把 exe 单独拷到别的目录，很多 Qt 编写的工具都得依赖同目录下的运行库；第二，把整个解压目录放到纯英文路径下，比如 C:\tools\sokit，避免旧版 Qt 程序对中文路径处理不好；第三，如果双击没反应，先看杀毒软件是否把 exe 隔离了。
有些机器双击时报「找不到 Qt5Core.dll」或类似缺失，那是因为运行库没装全。常见做法是把压缩包里附带的 dll 和 exe 放在同一层目录，再启动；如果仍然缺，就补装 VC++ 运行库或对应的 Qt 运行库。不要为省事去系统目录里乱拷 dll，那样容易把别的软件带坏。管理员权限一般用不上，只有当你需要监听 1024 以下的特权端口时，才右键以管理员身份运行；联调阶段选 9000、9999 这类端口完全够用。
3.2 配置 TCP 客户端：从本机回环发出第一段数据
要验证 sokit 的客户端功能，最可靠的起点是连回环地址 127.0.0.1。但本机得先有一个服务端在听那个端口，否则 connect 会被拒绝。我习惯用 Python 起一个极简 TCP echo 服务端，先把它保存成 listen.py：
import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) s.bind(('127.0.0.1', 9999)) s.listen(1) print('listening on 9999', flush=True) c, addr = s.accept() print('connected from', addr, flush=True) data = c.recv(1024) print('recv:', data.hex(), flush=True) c.send(b'echo: ' + data) c.close() s.close()先把套接字绑定到回环地址和 9999 端口，setsockopt 那句是为了让端口在程序退出后能被立刻重新绑定，调试时避免地址复用问题。listen(1) 表示允许一个连接排队，对单连接联调已经足够。accept 会阻塞在这里，直到 sokit 连上来。收到数据后用 data.hex() 把字节以十六进制形式打印，你就能直观看到 sokit 到底发来的是什么。
然后在 sokit 里选 TCP Client，目标地址填 127.0.0.1，目标端口填 9999，点「连接」。状态栏显示已连接以后，回到发送区输入 hello，点「发送」。Python 窗口应该打印出 recv: 68656c6c6f，同时 sokit 接收区会显示 echo: hello，因为这段脚本把收到的内容原样拼了前缀又回给了 sokit。这一步跑通，说明 sokit 的客户端收发链路没有问题。如果 Python 窗口没反应，优先检查端口是否被占用，换一个端口再试。
3.3 文本模式与 Hex 模式：发送第一段二进制帧的参数选择
很多协议的字段不是人能直接读的字符，比如帧头 0xAA、长度 0x00 0x1C，这时文本模式就不好使了。sokit 的发送区通常有个模式切换，切到 Hex 后，你输入的 AA 55 01 00 会被程序解析成对应的字节发出。注意每个字节之间可以用空格分隔，也可以连续写，具体看版本，但为了自己核对，我习惯每两位一组加一个空格。
这里有一个很容易翻车的点：发送区输入框旁边如果带「自动追加换行」或类似选项，默认勾选状态下，你点发送时程序会在数据末尾追加 \r\n 这两个字节。对要求严格按帧校验的协议来说，多出的两个字节会直接导致校验失败。我以前调试一个私有点对点协议时，检查了好几轮才注意到追加换行选项，去掉后数据立刻正常。养成习惯：发送二进制定长帧之前，把输入框切到 Hex、清空内容、确认没有自动追加回车换行。接收区同样也要确认显示模式是 Hex 还是文本，否则一长串不可见字节可能被渲染成乱码或空白。
4. 用 sokit 模拟 TCP/UDP 服务端：本地联调协议的完整流程
4.1 TCP Server 模式：绑定本地端口、观察连接并手动回包
sokit 不只能当客户端去连别人，它也能冒充服务端，让被测设备主动来连你。切到 TCP Server 模式，填一个本地监听端口，点「监听」，它就变成了一个挂在那个端口上的服务端。做嵌入式联调时，这等于把你的电脑临时变成设备要连接的服务器，不需要先写一套完整的上位机代码就能验证设备的上报逻辑。
监听成功以后，被测设备或别的上位机来连接，你可以在接收区看到连接建立，也能看到它发来的数据。这一点在处理设备主动上报场景时特别有用：设备上电后会按协议向服务器地址发起连接并发送心跳包，你只要把服务器地址指到这台电脑的局域网 IP，端口指到 sokit 的监听端口，就能看到设备有没有按协议来。连接建立后，在发送区写好响应内容，点发送，数据会发给当前选中的连接；如果同时有多个连接，需要注意选择正确的那个，别把响应发到别的设备上。
模拟服务端时，一个典型场景是设备连接后立即发来数据，但用的是长连接应用层握手。这时候设备一般会不断重发，直到收到服务端确认帧。正确的做法是先用 sokit 手动回一帧协议里定义的确认包，再看设备后续是否按状态机继续。如果一上来就怀疑设备协议有错，容易被重发行为误导。先把确认帧回对，设备后续流程马上就会浮出水面。
到手一个协议验证任务时，我一般走这四步：
| 步骤 | 操作 | 留意点 |
|---|---|---|
| 1 | 模式选 TCP Server，本地端口填 9000，点监听 | 端口不能被占用 |
| 2 | 让被测设备连这台电脑的 IP:9000 | 确认 IP 和设备在同一网段 |
| 3 | 在接收区查看连接与数据 | 看清文本还是 Hex 显示 |
| 4 | 在发送区输入响应帧，点发送 | 确认选中的是对的那个连接 |
4.2 UDP 模式：本地端口、目标地址与局域网广播
UDP 和 TCP 最大的区别在于无连接，sokit 在 UDP 模式下一般有两个关键参数：本地端口和目标地址。本地端口填上以后，程序会 bind 这个端口，能收到发到这里来的 UDP 报文；目标地址则决定你要把数据发往哪个 IP。如果只填目标地址不填本地端口，也能发，但接收对方回包就没有固定端口可用，联调时不推荐这样做。
做局域网广播时，目标地址可以填 255.255.255.255 或子网广播地址，比如 192.168.1.255。前一个是全局广播，后一个是定向广播。调试时我遇到过一个很别扭的现象：同一台电脑上开两个 sokit，一个绑定端口发广播，另一个绑定同一端口想收，结果发送方显示数据已经发出，接收方却什么都收不到。原因不在 sokit，而是 Windows 对本机回环 UDP 广播的处理存在限制，再加上防火墙默认拦截，导致广播回环被吞。这个问题第五章会展开讲，这里先记住：UDP 联调优先用两台机器交叉收发，比在本机一边发一边收可靠。
UDP 模式下没有「已连接」的概念，状态栏通常不会显示连接成功。判断是否收到数据，只能看接收区字节数有没有增长。这让 UDP 联调比 TCP 更容易让人心里没底，所以更依赖留痕功能：把每个发送帧和接收到的回包都保存下来，对比时间就能判断是否出现丢包或乱序。
4.3 文件发送与接收保存：联调过程中的留痕习惯
sokit 一般支持选择文件作为发送数据源，这对发送较长报文或重复执行同一组测试极有帮助。你不用在输入框里手工复制上百个字节，直接把 .bin 文件的路径选好，点发送就会把整个文件内容作为一帧发出。接收区的内容一般也能保存成文件，方便做字节级比对。协议联调里，用文件的另一个好处是可控：同一个用例文件可以反复发，排错时不会因为手抖改变数据。
我在联调时坚持三个习惯：第一，把每个测试用例保存成独立 hex 文件，文件名带编号和功能名，比如 case01_heartbeat.bin；第二，每收到一包响应就另存一份接收记录，文件名带上时间戳；第三，配合 Wireshark 并行抓包时，把 sokit 的收发时刻和抓包文件记在同一个笔记里。大多数联调僵局都不是协议文档写错了，而是两边各说各话，没有留痕，导致谁也不知道某个时刻到底谁发了什么、谁回了什么。养成保存记录的习惯，能把「玄学问题」变成「可复盘的具体时间线」。
5. sokit win32 下常见问题避坑：乱码、广播收不到与端口残留
sokit 在 win32 下并不是一开箱就永远顺畅的软件，以下几条是我在多个项目里反复踩过的坑，按现象、原因、解决写清楚，方便你对照排查。每条都会给出实际处理的顺序，不保证覆盖所有版本，但大多数情况下照做就能脱困。
5.1 现象：启动后界面或接收区出现乱码
在 win32 环境下启动 sokit，有时候界面按钮是方框或问号，有时候接收区里显示中文字符变成乱码。这两类乱码的根源不一样。界面乱码多半是系统代码页或者字体渲染问题，常见解决方法是把 Windows 的区域设置里「使用 Unicode UTF-8 提供全球语言支持」选项打开并重启。这个方法能解决一批旧程序的界面乱码，但它是系统级修改，会影响这台机器上其他软件的编码行为，所以只建议在专用联调机上这么干。
接收区乱码则先要判断对端发来的到底是什么编码。把接收区切到 Hex 模式，看字节码再对照协议文档，比对着乱码猜要可靠得多。比如中文「温度」的 UTF-8 编码是 E6 B8 A9 E5 BA A6，如果你在 Hex 区看到的是这几个字节而文本区显示乱码，说明程序编码和字节流不一致，问题在显示层；如果 Hex 区看到的字节和文档预期不同，那就是对端真的发错了。显示乱码好解决，数据字节错就得回去查协议源。
5.2 现象：发送中文后对端收到一堆乱码或字节数不对
在文本模式下输入中文，点发送后对端收到乱码，这是编码不一致的典型结果。sokit 的文本模式会按系统当前代码页把输入转换成字节，而你的对端设备几乎都在按 UTF-8 或 GBK 的一个固定形式解析。两边默认编码对不上，中文这一换就乱。不要指望工具去猜你要发什么编码，联调环境下最可靠的做法是绕开文本模式，切到 Hex 模式，手动输入中文对应的 UTF-8 字节。
比如「状态」两个字，UTF-8 编码是 E7 8A B6 E6 80 81，你在 Hex 模式里输入这串字节，发送出去以后，对端拿到的就是明确的字节流，和编码设置彻底无关。等协议链路全部跑通，再返回去决定上位机正式发送时用 UTF-8 还是 GBK，那是工程决策问题，不该在联调阶段混进来。用字节说话，能砍掉一大批编码相关的干扰项。
5.3 现象：UDP 模式收不到发往本机广播的消息
在 UDP 模式下绑定了本地端口，往 255.255.255.255 发送广播，同一台机器上另一个 sokit 实例却收不到任何数据。这个现象在 Windows 上挺常见，原因有两个方向：一是 Windows 防火墙默认会拦截部分入站 UDP 流量，尤其是广播；二是当一个进程往全局广播地址发送数据时，系统选择的出接口可能不是你想的那个网卡，导致数据从另一个网卡出去，回环接收自然落空。
排查分三步走。第一步，打开 Windows 防火墙的入站规则，在「允许应用或功能通过 Windows 防火墙」里把 sokit 勾上，并允许专用网络。第二步，把全局广播地址 255.255.255.255 换成子网定向广播地址，比如你所在的局域网是 192.168.1.x，就填 192.168.1.255。第三步，如果还是收不到，换两台机器做交叉验证，一台只发、一台只收，排除本机回环的干扰。绝大多数 UDP 广播收不到的案例，走到第三步之前都能定位到原因。
5.4 现象：端口明明关了，其他程序再监听时报地址被占用
用 sokit 监听了一个端口，退出程序后，换另一个工具去监听同一个端口，却提示端口被占用。这多半是 sokit 还没完全退出，或者上一次的连接还在 TIME_WAIT 状态，系统没有立即释放端口。排查时打开任务管理器先确认有没有残留的 sokit 进程，有就结束它；如果没有进程残留，再用 netstat 查端口占用：
netstat -ano | findstr :9000这条命令会列出占用 9000 端口的连接和 PID，输出里最后一列就是进程 ID。拿到 PID 后在任务管理器里找到对应进程结束即可。TIME_WAIT 状态一般几十秒内会自动释放，不用急着处理。为了少遇到这种问题，我习惯在关闭 sokit 之前先点「断开」或「停止监听」，让 socket 正常关闭，再关窗口。
5.5 现象：连接对端反复失败，但 sokit 没有明显提示
TCP 客户端连接一个远程地址一直失败，状态栏却没给出明确的错误信息，看起来像什么都没发生。这种情况先别怀疑 sokit 有 bug，很多联调里真正的原因是网络层根本没通。打开命令提示符，ping 一下目标 IP，能通再确认端口：telnet 目标IP 端口。如果 telnet 提示无法连接，说明服务端没监听或者防火墙拦了入站；如果 ping 都不通，那就是网络链路、IP 地址或路由配置的问题。
这里有个心态问题：工具容易变成背锅侠。sokit 提供一个图形化窗口，但网络不通的黑锅不应该由它来背。先老老实实用系统自带的最基础命令做排除，等确认对端可达、端口确实开放，再回到 sokit 的界面参数里找问题。连接失败时多看状态栏、多记日志，比反复点连接按钮更有价值。
6. 拿 sokit 收尾：一个串口转 TCP 网关的联调套路
6.1 用 Hex 模式构造完整的指令帧
我在调一个串口转 TCP 网关时，设备文档给出一帧读取指令：AA 55 01 03 00 26。AA 55 是帧头，01 是功能码，03 是长度，00 26 是校验。我把 sokit 切到 Hex 模式，逐字节输入这帧数据点发送，再看网关是否按协议把数据转发到后端串口设备。这里最怕手滑输错一位，校验和会立刻让设备不回包，不过这也正好成为校验数据是否正确的天然裁判。
6.2 验证边界字节与响应时序
正常帧跑通之后，我又构造了两类边界情况：长度字段改成 00 00，校验字段改成 FF FF，观察网关是返回异常帧还是直接沉默。sokit 的接收区能直接显示返回的十六进制字节，我利用它记录从发送到收到响应之间的间隔，来判断网关和设备的超时参数是否合理。联调协议不能只测 happy path，边界帧和异常帧的响应行为同样需要留证。
6.3 我的使用习惯
我现在的习惯是每开始一轮联调，先清空接收区、保存一份初始日志，之后所有关键帧都从文件发送而不是手工粘贴。这看似多此一举，真到凌晨还在对线时会发现它救了大命。这台 win32 老机器上的 sokit 我留了很多年，它最大的价值不是功能多，而是随时打开就能把问题试一遍、把过程留下来。从第一次手忙脚乱到现在拿到包就能快速定位，它替我挡了不少最初的质疑。希望帮到你。
本文还有配套的精品资源，点击获取
