企业官网建设流程全解析

1. websocat 是什么，为什么你需要一个命令行 WebSocket 工具

1.1 一句话搞清楚 websocat 的定位

websocat 是一个用 Rust 编写的命令行 WebSocket 客户端和服务端工具，定位上非常类似 curl 之于 HTTP：你可以在终端里直接发起一个 WebSocket 连接，收发消息，甚至起一个本地 WebSocket 服务用来调试和测试。在 Ubuntu 22.04 上装 websocat，是很多做物联网设备调试、嵌入式通信、后端接口联调、甚至前端本地 mock 的同学迟早会遇到的需求。

我最早接触它，是因为要调试一个跑在 ARM 开发板上的 WebSocket 服务端。那会儿手里只有一个串口终端，没有图形界面，浏览器开发者工具根本用不上，Postman 的 WebSocket 客户端也不支持在那样的环境里跑。当时我就在想，要是能有一个像 curl 一样简单直接、能够在命令行里完成 WebSocket 连接和收发的工具就好了。后来一查，websocat 几乎就是为这个场景量身定做的。

它对标的是 Node.js 生态里的 wscat，但 websocat 最大的优势是静态编译、单文件、无运行时依赖，扔到任何 Linux 机器上都能跑，尤其适合服务器环境、Docker 容器、嵌入式系统，以及 Ubuntu 22.04 这种桌面和服务器并存的环境。

1.2 为什么不直接用浏览器开发者工具，非要折腾命令行工具

可能有人会说，Chrome 的开发者工具里不是自带 WebSocket 面板吗？F12 打开，切到 Network，过滤 WS，也能看到 WebSocket 帧。确实，浏览器能看，但它只能看，而且有几个硬伤。

第一，浏览器里的 WebSocket 面板只能配合页面本身的连接来用。如果你想主动连接一个任意地址、任意端口的 WebSocket 服务，比如 ws://192.168.1.100:8080，浏览器是没有一个类似 Postman 那样的“直接发起连接”入口的，除非你自己写个 HTML 页面。第二，浏览器工具没法做自动化。你写了一个 WebSocket 服务端，想压测它每分钟能处理多少条消息，用浏览器点？不现实。第三，在服务器上排查问题的时候，根本没有浏览器可用。

websocat 解决的正是这三个痛点：任意地址主动连接、管道友好可脚本化、纯命令行无图形依赖。它还支持把 stdin 的内容通过管道发给 WebSocket 服务端，加上-n模式可以逐行读取发送，这意味着你可以把日志文件、测试用例、甚至另一个程序的输出直接喂给一个 WebSocket 服务端，这在做协议调试和自动化测试的时候极其好用。

再说一个很多人不知道的隐藏功能：websocat 可以作为服务端运行，也就是-s模式，监听一个本地端口，充当一个简易的 WebSocket mock 服务。做前端开发的时候，后端接口还没好，你可以用 websocat 临时顶一下，模拟一个 WebSocket 推送服务，验证前端消息处理逻辑。这个功能我后面会详细演示。

2. 安装前的准备工作：先把环境和版本确认清楚

2.1 确认你的 Ubuntu 版本和系统架构

虽然标题写的是 Ubuntu 22.04，但实际操作前最好还是确认一下系统版本和 CPU 架构。22.04 的代号是 Jammy Jellyfish，不过你能拿到手的可能是22.04.1、22.04.2这些小版本，以及可能换过内核和桌面环境。这些对 websocat 的安装影响不大，但确认一遍总没坏处，特别是当你下载预编译二进制的时候，架构选错了，文件是跑不起来的。

查看系统版本用这个命令：

lsb_release -a

或者：

cat /etc/os-release

查看 CPU 架构用这个命令：

uname -m

常见的输出有x86_64、aarch64、armv7l等。如果你的机器是x86_64，那绝大多数情况下你下载x86_64-unknown-linux-musl或者x86_64-unknown-linux-gnu的预编译包就行。如果是苹果 M 系列芯片的 Asahi Linux、树莓派或者其他 ARM 设备，就需要下载aarch64-unknown-linux-musl版本。

这里有个小细节值得注意：Ubuntu 22.04 的官方 apt 源里其实是有 websocat 这个包的，版本是较旧的 1.11.0，而 GitHub Releases 上最新的版本已经到了 1.13.0（或者更新的版本）。功能上没有翻天覆地的变化，但 1.12.0 之后对--header参数的支持更好，对异步 I/O 的处理也更稳定。如果你只是想在本地简单调试，apt 装的老版本完全够用；如果你要用于生产环境或者自动化脚本里，建议优先考虑新版本。

2.2 三条安装路线：最容易、最推荐、最灵活

websocat 在 Ubuntu 22.04 上的安装方式，我整理下来主要有三条路，每条都有各自的适用场景，我先把它们列出来对比一下：

绝大多数情况下，我建议你选第二条路——下载预编译二进制。原因很简单：websocat 的 GitHub Releases 页面会同时提供.deb包、.tar.bz2压缩包和.zip包，其中.deb包可以直接用dpkg -i安装，装完即用，非常干净，卸载也方便。依赖上，websocat 使用 musl 静态编译，几乎不依赖系统库，所以不用担心缺依赖的问题。

还有一种情况，如果你的 Ubuntu 22.04 上已经装了 Rust 工具链，比如你平时写 Rust 或者用 cargo 管理项目，那cargo install websocat也是很自然的选法。它会把 websocat 编译进~/.cargo/bin/目录，只要这个目录在 PATH 里，就能直接用。

2.3 安装前的一个建议：先装好 wget 和 curl

虽然这不属于 websocat 安装本身的硬性要求，但我在实际下载过程中发现，很多 Ubuntu 22.04 最小化安装环境里，wget 和 curl 不一定都装了。你至少要有一个能下载文件的工具，才能把 websocat 的二进制包拉下来。如果你发现自己wget命令提示找不到，先执行：

sudo apt update sudo apt install -y wget curl

把基础工具补齐再继续。这个步骤很多人会跳过，等到下载的时候才发现问题，然后倒回来折腾，不如一开始就装好。

3. 三种安装方式逐一实测：从二进制到源码编译

3.1 最推荐：下载 GitHub Releases 预编译二进制

这是我在服务器和本地环境里最常用的一种方式，因为它可控性最强。你需要做的第一件事是去 websocat 的 GitHub Releases 页面找到对应你系统架构的包。在浏览器里打开 GitHub，找到vi/websocat仓库的 Releases 页面，往下拉到 Assets 区域，会看到很多文件。

对 Ubuntu 22.04 的 x86_64 机器，有两个选择：一个是websocat_1.13.0_amd64.deb，另一个是websocat.x86_64-unknown-linux-musl.tar.bz2。前者可以直接安装成系统软件包，后者解压出来是单个二进制文件。我个人的建议是下载.deb包，因为它会被 dpkg 完整管理，以后想卸载直接sudo apt remove websocat即可，非常干净。

具体命令如下：

cd /tmp wget https://github.com/vi/websocat/releases/download/v1.13.0/websocat_1.13.0_amd64.deb sudo dpkg -i websocat_1.13.0_amd64.deb

执行完dpkg -i之后，正常情况下会看到输出提示安装成功。这时候你可以先验证一下版本：

websocat --version

如果输出类似websocat 1.13.0这样的信息，说明安装成功。

如果你下载的是.tar.bz2压缩包，那么安装步骤就变成了：

cd /tmp wget https://github.com/vi/websocat/releases/download/v1.13.0/websocat.x86_64-unknown-linux-musl.tar.bz2 tar -xf websocat.x86_64-unknown-linux-musl.tar.bz2 sudo mv websocat /usr/local/bin/

解压出来通常只有一个websocat文件，把它放到/usr/local/bin/目录，这个目录一般在 PATH 环境变量里，所以你可以在任意路径下直接执行websocat。用这种方式安装的好处是完全脱离系统包管理，适合那种不想让软件包污染系统数据库的极简场景，也适合拷到 Docker 镜像里使用。

这里有个坑必须提醒一下：GitHub 的 Releases 下载地址需要你的网络能正常访问 GitHub。如果你在服务器上下载很慢或者直接失败，可以考虑用代理或者换一个网络环境。另外，下载前一定要确认你下载的版本号和文件路径是对应的，复制链接的时候不要手滑。

3.2 最简单：apt 直接安装

如果你觉得去 GitHub 找文件比较麻烦，或者网络条件不支持，那么 apt 是一条完全没有门槛的路。Ubuntu 22.04 的官方源里已经收录了 websocat，直接执行：

sudo apt update sudo apt install -y websocat

apt 会自动把所有依赖处理好，装完之后同样可以用websocat --version验证。装完之后，你可以用apt show websocat查看具体的包信息，里面会有维护者、版本号、描述等。

不过需要留意，官方源里的 websocat 版本很可能停留在 1.11.0，这倒不是 Ubuntu 22.04 特有的问题，而是软件源同步总是会滞后于上游。对大多数调试场景来说，1.11.0 和 1.13.0 用起来差别不大。但如果你需要用--http-headers或者某些新参数，建议确认一下版本支持情况。在 1.11.0 里--header功能需要开启相应 feature 才能用，而在新版本里默认就支持了，这算是比较明显的体验差异。

3.3 最灵活：用 cargo 编译安装

第三种方式适合本机已经装了 Rust 工具链的情况。官方推荐的方式是：

cargo install websocat

但这里我想多说一句，cargo install websocat编译的是默认特性版本，对于一些丰富的功能，比如 SSL、异步 I/O 优化等，你可能需要指定 features。常见的编译命令是：

cargo install websocat --features=ssl

或者为了获得完整的体验，用官方推荐的完整 feature 组合：

cargo install websocat --features=pin,ssl,upnp,async-std

编译过程中，cargo 会下载很多依赖源码，然后逐一编译，耗时根据机器性能不同，通常在 3 到 10 分钟不等。我第一次编译的时候，感觉比预想中要久，后来发现是因为依赖了 tokio、rustls 这一大堆异步库，源码量很大，耐心等就行。

编译完成之后，websocat 会被安装到~/.cargo/bin/websocat。如果你的系统提示websocat 命令找不到，先检查一下 PATH 里是否包含~/.cargo/bin：

export PATH="$HOME/.cargo/bin:$PATH"

如果不想每次都写这个命令，可以把它加到~/.bashrc里。实际上，如果你是通过 rustup 安装的 Rust，这行配置通常已经自动写好了，不需要额外处理。

我用 cargo 方式主要看中的是它不受系统发行版和 GitHub 网络环境影响，只要网络能拉到 crates.io 的依赖包，就能编译成功。而且编译出来的二进制放在~/.cargo/bin/下，对用户来说是本地安装，不需要 sudo 权限，很适合那种你没有管理员权限的共享服务器场景。

3.4 三种方式选哪个：我给一个决策建议

说了这么多，可能你会纠结到底选哪种。我直接给出一个简单粗暴的决策逻辑：

• 如果你的机器内存小于 1GB、CPU 很弱，比如老款的树莓派，或者你是安装在虚拟机上跑，那就不要选 cargo 编译，编译过程会非常痛苦，直接走 apt 或者预编译二进制。
• 如果你对 WebSocket 调试有高频需求，以后还会用到 websocat 的--header、-s服务模式、-b广播模式这些高级功能，建议用 GitHub Releases 的.deb包，版本新，功能全。
• 如果你是 Rust 开发者，日常离不开 cargo，那cargo install websocat就是顺手的事，也可以保持你的工具链统一。

4. 验证安装并跑通第一个 WebSocket 连接

4.1 用一个公共 echo 服务做冒烟测试

装好之后，第一件事当然是验证它能不能正常连接外部 WebSocket 服务。我常用的测试服务是wss://echo.websocket.org，这个服务会把收到的消息原样返回，非常适合冒烟测试。虽然它偶尔不稳定，但大多数时候是开放的。如果它连不上，可以换wss://ws.postman-echo.com/raw，Postman 提供的也是类似的 echo 服务。

最简单的测试命令是：

echo "hello websocat" | websocat wss://echo.websocket.org

这条命令的意思是：把字符串“hello websocat”作为一条消息，通过 WebSocket 发出去，然后立即断开连接。由于 echo 服务会把消息原样返回，正常情况下你会在终端里看到输出：

hello websocat

如果你看到这个输出，说明 websocat 安装成功，而且能正常和 wss 协议的 WebSocket 服务建立 TLS 加密连接。

这里有个小细节值得解释一下：echo "hello websocat" | websocat wss://...这种管道用法，本质上是因为 websocat 默认会打开 stdin 读取输入。你通过管道传入的字符串会被当成一条完整的 WebSocket 消息发送，服务端返回后，websocat 会把收到的消息打印到 stdout。这个“管道进，管道出”的交互模式，是 websocat 最核心的设计理念之一，你完全可以把它嵌入到 shell 脚本里，实现 WebSocket 读写的自动化。

如果你想测试更长的连接保持场景，也就是连接后不立即断开，而是持续收发消息，可以用这个命令：

websocat wss://echo.websocket.org

不带任何管道输入，直接执行，你会发现终端进入了类似交互模式的状态。此时你每输入一行文字，回车后，echo 服务会返回同样的文字。这个模式用来调试协议，非常直观。

4.2 理解 websocat 最基本的收发模型

很多新手第一次用 websocat 会懵，特别是它和 curl 的行为差异。curl 是发送一个 HTTP 请求，服务器返回一个响应，请求-响应是一对一的，完成即结束。而 WebSocket 是一个全双工长连接，连接建立之后，双方可以随时发消息。websocat 的默认行为是：从 stdin 读取数据，作为消息发送；同时从 WebSocket 接收数据，写到 stdout。

这个模型的含义是，只要你不在终端里主动按 Ctrl+C，或者服务端断开，连接会一直保持。所以在脚本里使用 websocat 时，如果你只想发送一条消息就退出，一定要记得用管道或者重定向的方式，比如echo "something" | websocat ...。管道在数据读完之后就会关闭 stdin，websocat 检测到 stdin 关闭，就会主动断开连接。

如果你需要发送多条消息，有两种思路：一种是用一个文件，把每一行作为一条消息：

websocat ws://localhost:8080 < messages.txt

这种方式 websocat 会逐行读取文件内容，每一行发一条消息。另一种是用-n参数（或--no-close）来告诉 websocat，读完 stdin 不要立即断开连接，保持会话继续。具体用哪种，视你的需求而定。

4.3 连接本地 WebSocket 服务端：开发联调最常用

如果你本地正在开发一个 WebSocket 服务端程序，比如 Node.js 的ws库、Python 的websockets库，或者 Go 的gorilla/websocket，那么你可以在另一个终端里用 websocat 来模拟客户端。假设你的服务端监听在ws://localhost:3000，那么：

websocat ws://localhost:3000

输入任意文本，回车，你就会看到服务端返回的数据（如果有的话）。终端里没有图形界面，你依然能完成和浏览器开发者工具一样的调试。

我多次用这种方式排查过一个问题：服务端在特定业务逻辑下会往 WebSocket 连接推数据，但是浏览器页面里没显示。我直接在终端里用 websocat 连上去看，发现服务端确实推送了数据，问题出在前端渲染逻辑上。这个定位方式，比浏览器里反复刷新页面高效得多。

4.4 作为服务端运行：用 -s 起一个本地 mock

再说一个很多人没注意到的功能：websocat 可以反向操作，作为 WebSocket 服务端运行。命令很简单：

websocat -s 8080

-s是--server的缩写，监听在本机的 8080 端口，接受来自任意客户端的 WebSocket 连接。默认情况下，它会回显收到的消息，也就是一个 echo 服务。这用来测试前端的 WebSocket 客户端非常方便。

更进一步的场景是，当你想模拟一个推送服务时，可以配合管道把服务端要推送的内容喂进去。比如：

while true; do echo "tick $(date)"; sleep 1; done | websocat -s 8080

这样每秒钟都会向所有连接的客户端推送一条带时间戳的消息。我在做前端实时图表联动的时候，就是用这种方式临时充当数据推送服务，效果非常不错，省得一开始就上真正的后端。

4.5 带上自定义 Header 连接：带鉴权的 WebSocket

很多线上 WebSocket 服务需要通过 Header 传递 token 鉴权。websocat 从 1.12.0 版本开始，对自定义 Header 的支持已经非常成熟，用法是：

websocat --header "Authorization: Bearer your-token-here" wss://api.example.com/ws

这里有个坑：如果你是使用 apt 装的旧版（1.11.0），默认特性里可能不包含--header的支持。你会遇到“unrecognized option”的报错。解决方案有两个：一是升级到新版，二是用--http-header配合编译时开启相应的 feature。但说实话，没必要在旧版本上纠结，直接上最新版最简单。

5. 日常使用中我踩过的坑和排查套路

5.1 命令找不到，或者版本不对

安装完之后，最常遇到的问题就是输入websocat提示找不到命令。原因大概率是两个：一是 PATH 环境变量里没有对应的安装目录，二是安装过程实际上失败了，只是你没注意看输出信息。

排查步骤：

type websocat which websocat ls -l /usr/local/bin/websocat

如果which websocat没有输出，说明websocat不在 PATH 里。这时候你需要自己找一下它被装到哪里了。dpkg -L websocat可以查看 deb 包安装的文件列表；如果是 cargo 方式，检查~/.cargo/bin/websocat是否存在。确定路径后，把对应目录加入 PATH，或者用绝对路径调用。

另外，有同学遇到过这种情况：之前装过 websocat，后来系统升级，apt 自动把 websocat 卸载了，或者从旧版本仓库安装后版本号一直是老的。遇到版本不对，先用apt-cache policy websocat看一下可安装的版本来源，再从上游下载新版本替换即可。

5.2 SSL 证书校验失败和 TLS 报错

连接 wss 地址的时候，有时候会报 SSL 相关的错误，比如 "certificate verify failed" 或者 "invalid peer certificate"。这可能是两种情况：一是你连的服务器用了自签名证书，或者证书链不完整；二是系统的 CA 证书过期了。

对于自签名证书的调试场景，websocat 提供了一个临时跳过的参数：

websocat -k wss://192.168.1.10:443

-k等价于 curl 里的-k参数，会跳过证书校验。注意你可以在连实时服务时用，但生产环境排查时最好不要习惯性加-k，因为你可能会掩盖掉证书配置的真实问题。

如果是系统 CA 证书过期的问题，更新一下：

sudo apt update sudo apt install --reinstall ca-certificates

这个命令在 Ubuntu 22.04 上很管用，尤其当你发现浏览器能正常访问某个网站，但 websocat 连不上同一个域名的时候。

5.3 某些服务器上 websocat 连接后立刻退出

我在一台低配的云服务器上遇到过一个问题：websocat 连接 ws:// 地址成功后，马上退出，没有任何输出。排查了半天，发现是服务器内存太紧张，导致异步 I/O 线程创建失败，进程直接退出但没报错。这个情况比较特殊，最终是通过给服务器增加 swap 解决的。

如果你也遇到类似问题，先别慌，按这个顺序检查：先确认你连接的 WebSocket 服务端是否正常；用curl http://...测试一下同主机的 HTTP 端口是否可达；用dmesg | tail查看系统日志里是否有 Out of Memory 相关的记录。如果确实是内存不够，最简单的解决方案是创建 swap 分区，或者用更简化的客户端工具交叉验证是不是 websocat 自身的问题。

5.4 在脚本里用 websocat 的几个小技巧

实际写脚本的时候，有几个细节如果不注意，会导致莫名其妙的问题。

第一个是超时问题。websocat 默认没有超时限制，如果你在 CI 或者 crontab 里跑，连接一直挂起会导致脚本卡死。解决办法是配合其他命令使用，比如用timeout命令包一层：

timeout 10 websocat wss://api.example.com < input.txt

10 秒后如果还没结束，就强制终止。

第二个是-n参数的使用。默认情况下 websocat 读完 stdin 后立即关闭连接，如果你希望它读完 stdin 之后保持连接等待后续数据，就需要加-n参数。这个参数在 1.11.0 和 1.13.0 里的行为略有差别，老版本对标准输入读完后立即关闭，新版本提供了更精细的控制，用之前先websocat --help看一下当前版本的行为。

第三个是输出缓冲问题。当你把 websocat 的输出重定向到文件时：

websocat wss://api.example.com > output.log

它默认是行缓冲，但在某些版本里，如果输出内容没有换行符，可能不会实时写入文件。加上-n或者使用--no-buffer可以缓解这个情况。我在用脚本持续采集 WebSocket 推送数据时，试过加--no-buffer后日志实时性明显提升。

最后分享一个我常用的组合拳：用 websocat 配合 jq 解析 JSON 消息，实现命令行版的 WebSocket 数据流分析：

websocat wss://stream.example.com/ws | jq '.price'

这条命令会把从 WebSocket 收到的每一条 JSON 消息管道给 jq 提取字段，直接可以在终端看到实时价格变化，非常适合做行情监控、实时日志分析这类轻量场景。

5.5 新旧版本共存时的 PATH 冲突

最后提醒一个比较隐蔽的问题：如果你既用 apt 装了 websocat，又用 cargo 装了 websocat，那么系统里会存在两个版本。当你输入websocat时，具体用哪个取决于 PATH 的搜索顺序。echo $PATH看一下，如果~/.cargo/bin排在/usr/bin前面，你会用到 cargo 版本；反过来则会用到 apt 版本。

这个问题在我身上真实发生过，apt 装的是 1.11.0，cargo 装的是 1.13.0，我测试--header参数时一直报错，还以为是 bug，后来才发现是因为 PATH 里旧版本优先。解决方法是把不要的那个版本删掉，或者调整 PATH 顺序。卸载 apt 版本用sudo apt remove websocat，卸载 cargo 版本直接删掉~/.cargo/bin/websocat文件即可，非常干净。

以上就是我在 Ubuntu 22.04 上安装和使用 websocat 的完整过程，每条路都实际跑过，每个坑也都踩过。如果你只记住了三件事，我希望是这三点：优先用 GitHub Releases 的.deb包装最新版；用-k参数跳 SSL 校验只用于调试自签名证书；在脚本里记得用timeout包裹避免长时间挂起。按照这份流程走，你在 Ubuntu 22.04 上搞定 websocat 应该不会超过十分钟。