运维123 - WebSocket
type: channel
link: https://www.sddts.cn/index.php/category/WebSocket/
items: 修复 mcporter 与 n9e-mcp-server SSE 连接挂起问题
items: OpenClaw Studio 入门指南
items: OpenClaw 安装配置指南
items: Netventory 网络扫描工具技术分析
items: Clawdbot 个人 AI 助手 Gateway 架构技术分析
items: Happy Server 零知识同步后端技术分析
items: Rustpad 开源协作代码编辑器技术分析
items: PushMe 消息通知平台技术分析
items: nasa42/Webterm 终端穿透访问技术分析
items: VibeTunnel 技术分析：浏览器终端代理平台

修复 mcporter 与 n9e-mcp-server SSE 连接挂起问题
type: item
date: 2026-03-02T06:29:19+00:00
description: 修复 mcporter 与 n9e-mcp-server SSE 连接挂起问题一、事件概述1. 事件背景用户在使用 mcporter 调用 Nightingale MCP 工具时，程序出现挂起现象。mcporter list 显示 nightingale 服务为 offline 状态，执行 mcporter call nightingale.list_active_alerts 命令时程序无响应。2. 影响范围A. 影响功能Nightingale MCP 工具调用全部失败无法通过 MCP 协议访问 Nightingale 监控数据影响 list_active_alerts、list_history_alerts 等所有监控工具B. 影响时长调试过程持续约 2 小时，涉及多次代码修改和验证3. 严重程度P2 级问题，影响特定 MCP 服务器的可用性二、事件时间线1. 问题发现（初始阶段）A. 现象描述执行 mcporter list 时，nightingale 显示为 "offline — unable to reach server"B. 初步判断根据计划文件，问题根源是配置不匹配：mcporter 配置使用 stdio 模式，但 n9e-mcp-server 已切换到 HTTP SSE 模式运行。2. 配置调整（第一阶段）A. 处理措施修改 /home/jacky/.claude/config/mcporter.json，将 nightingale 从 stdio 模式改为 HTTP SSE 模式B. 效果评估问题未解决，mcporter list 仍显示 nightingale 为 offline3. 用户关键反馈（第二阶段）A. 发现途径用户注意到服务器日志中 session_id 为空字符串：session_id=""B. 用户提问"from the log i see session_id is null, shall this is the problem?"4. SessionID 调查（第三阶段）A. 调研方法通过 zread 工具检查 go-sdk 源代码 mcp/sse.goB. 关键发现在 sseServerConn 和 sseClientConn 的 SessionID 方法中发现以下注释：// TODO(jba): get the session ID. (Not urgent because SSE transports have been removed from the spec.) func (s *sseServerConn) SessionID() string { return "" }C. 结论空的 session_id 是预期行为，SSE 传输已从 MCP 规范中移除，不是问题根源5. 真实问题定位（第四阶段）A. 处理措施使用 curl 直接测试 SSE 端点，验证服务器是否正常响应B. 关键发现curl 测试成功，SSE 流程正常工作。问题在于 mcporter 的传输模式回退逻辑：尝试 Streamable HTTP 模式：失败，提示 "sessionid must be provided"回退到 SSE 模式：挂起6. 配置文件定位（第五阶段）A. 处理措施搜索并确认 mcporter 的实际配置文件位置B. 关键发现mcporter 使用 /home/jacky/.mcporter/mcporter.json，而非 /home/jacky/.claude/config/mcporter.jsonC. 修复措施更新正确的配置文件，将 URL 从远程地址改为本地地址7. Token 认证逻辑修复（第六阶段）A. 问题分析检查 n9e-mcp-server 的 HTTP 处理代码，发现所有请求（包括 POST 到 session endpoint）都强制要求 token 认证B. 问题根因POST 请求到 /mcp?sessionid=XXX 时，这些请求应仅使用 sessionid 认证，不应再次验证 tokenC. 修复措施修改 /mydata/code/mcp/n9e-mcp-server/internal/http_server.go，添加条件判断：mainHandler.HandleFunc("/mcp", func(w http.ResponseWriter, r *http.Request) { // POST 请求带 sessionid 直接转发到 SSE handler if r.Method == http.MethodPost && r.URL.Query().Get("sessionid") != "" { sseHandler.ServeHTTP(w, …

OpenClaw Studio 入门指南
type: item
date: 2026-03-01T10:57:36+00:00
description: OpenClaw Studio 入门指南一、概述1. 简介A. 是什么OpenClaw Studio 是一个简洁的 Web 仪表板，用于管理和控制 OpenClaw Gateway。它提供统一的界面来连接 Gateway、查看和创建 agents、进行对话、管理审批任务以及配置定时作业。B. 为什么学提供可视化界面，简化 OpenClaw 的操作流程支持多种部署场景，满足本地和云端需求集中管理 agents、聊天、审批和作业配置C. 学完能做什么在本地或云端部署 OpenClaw Studio配置 Studio 与 Gateway 的连接使用 Studio 界面管理 agents 和执行任务二、环境准备1. 系统要求Node.js 18+（推荐使用 LTS 版本）OpenClaw Gateway URL 和访问 tokenTailscale（可选，推荐用于远程访问）2. 安装步骤推荐安装方式（npx）npx -y openclaw-studio@latest从源码安装（高级用户）git clone https://github.com/grp06/openclaw-studio.git cd openclaw-studio npm install npm run dev3. 验证安装安装完成后，在浏览器中打开 http://localhost:3000，确认 Studio 界面正常加载。三、核心概念1. 基本术语Gateway：OpenClaw 的核心服务，负责 agents 的执行和管理Studio：Web 仪表板，提供图形化界面与 Gateway 交互Upstream：Studio 连接到 Gateway 的上游服务Agent：可执行特定任务的智能代理Tailscale：虚拟网络服务，用于安全的远程访问2. 工作原理OpenClaw Studio 采用双路径网络架构，Studio 作为中间层连接浏览器和 Gateway。graph LR subgraph 用户终端 Browser[浏览器] end subgraph Studio主机 Studio[OpenClaw Studio Web服务] WS1[WebSocket 3000端口] end subgraph Gateway主机 Gateway[OpenClaw Gateway] WS2[WebSocket 18789端口] end Browser -->|HTTP/UI| Studio Browser <-->|WebSocket 实时更新| WS1 WS1 -->|WebSocket| WS2 WS2 <--> Gateway网络连接说明：浏览器到 Studio：HTTP 用于 UI 界面，WebSocket 用于实时更新Studio 到 Gateway：Studio 服务器通过 WebSocket 连接配置的上游 URL3. 部署模式Studio 支持三种常见的部署场景，根据 Gateway 和 Studio 的运行位置选择合适的方式。四、快速上手1. 场景选择根据你的网络环境选择部署场景：场景 A：Gateway 本地运行，Studio 本地运行（同一台计算机）场景 B：Gateway 云端运行，Studio 本地运行（你的笔记本电脑）场景 C：Studio 云端运行，Gateway 云端运行（始终在线）2. 场景 A：Gateway 本地，Studio 本地适用于开发和测试环境，两者在同一台计算机上运行。安装和启动npx -y openclaw-studio@latest cd openclaw-studio npm run dev配置连接打开 http://localhost:3000，在 Studio 中设置：Upstream URL: ws://localhost:18789Upstream Token: 你的 Gateway token（可通过 openclaw config get gateway.auth.token 获取）3. 场景 B：Gateway 云端，Studio 本地适用于 Gateway 部署在云服务器，而在本地进行管理的场景。运行 Studionpx -y openclaw-studio@latest cd openclaw-studio npm run dev配置网络连接方案一：Tailscale Serve（推荐）在 Gateway 主机上：tailscale serve --yes --bg --https 443 http://127.0.0.1:18789在 Studio（你的笔记本）中：Upstream URL: wss://.ts.netUpstream Token: 你的 Gateway token方案二：SSH 隧道…

OpenClaw 安装配置指南
type: item
date: 2026-02-28T03:49:29+00:00
description: OpenClaw 安装配置指南一、概述1. 简介A. 是什么OpenClaw 是一个开源的个人 AI 助手平台，支持多平台集成（WhatsApp、Telegram、Discord 等）和任务自动化。B. 为什么使用支持多聊天平台统一管理提供 WebSocket Gateway 实现实时通信支持代理管理和会话持久化开源免费，可自主部署C. 学完能做什么在 Linux 环境中安装 OpenClaw配置和管理聊天频道运行和监控 Gateway 服务使用控制面板管理 AI 代理2. 前置知识A. 必备技能基本 Linux 命令操作了解 Node.js 和 npm 基本概念B. 推荐知识了解 WebSocket 基本原理熟悉 JSON 配置文件二、环境准备1. 系统要求操作系统：Linux（Kali、Ubuntu、Debian 等）Node.js：v22.12.0 或更高版本构建工具：gcc、make、g++、python3内存：至少 2GB 可用磁盘：至少 500MB 可用空间2. 安装步骤检查 Node.js 版本node --version检查构建工具make --version gcc --version检查 npm（通过 corepack）node /usr/share/nodejs/corepack/dist/npm.js --version3. 验证安装确保所有前置条件满足后再继续。三、核心概念1. 基本术语Gateway（网关）：WebSocket 服务器，处理通道和代理之间的通信Agent（代理）：AI 智能体，处理用户消息和任务Channel（通道）：连接的聊天平台（Telegram、Discord 等）Session（会话）：用户与代理之间的对话历史Credentials（凭证）：第三方服务的认证信息2. 工作原理graph TB Client[用户客户端 Telegram/Discord] --> Channel[通道模块] Channel --> Gateway[WebSocket 网关] Gateway --> Agent[AI 代理] Agent --> Gateway Gateway --> Channel Channel --> Client Gateway --> Control[控制面板 http://127.0.0.1:18789] Agent --> Session[(会话存储)] Channel --> Cred[(凭证存储)]四、快速上手1. 安装 OpenClaw官方安装脚本（推荐）curl -fsSL --proto '=https' --tlsv1.2 https://openclaw.ai/install.sh | bash替代方案：用户级安装当 npm 通过 corepack 提供且没有系统级权限时使用：# 创建用户级 npm 目录 mkdir -p ~/.npm-global # 设置环境变量 export npm_config_prefix="$HOME/.npm-global" export PATH="$npm_config_prefix/bin:$PATH" # 使用 corepack npm 安装 npm_config_prefix="$HOME/.npm-global" PATH="$npm_config_prefix/bin:$PATH" \ node /usr/share/nodejs/corepack/dist/npm.js install -g openclaw@latest2. 验证安装# 检查可执行文件 ls -la ~/.npm-global/bin/openclaw # 查看版本 ~/.npm-global/bin/openclaw --version # 检查已安装包 ~/.npm-global/bin/node /usr/share/nodejs/corepack/dist/npm.js list -g openclaw预期输出：可执行文件：~/.npm-global/bin/openclaw版本：2026.2.26（或更新版本）3. 初始化配置首次使用前需要运行配置向导：~/.npm-global/bin/openclaw onboard或使用交互式设置向导：~/.npm-global/bin/openclaw configure配置完成后，配置文件位于：主配置：~/.openclaw/openclaw.json工作空间：~/.openclaw/workspace凭证：~/.openclaw/credentials日志：~/.openclaw/logs/五、启动服务1. 启动 Gateway~/.npm-global/bin/openclaw g…

Netventory 网络扫描工具技术分析
type: item
date: 2026-01-25T10:38:11+00:00
description: Netventory 网络扫描工具技术分析一、新闻概述1. 标题Netventory：快速单二进制网络扫描工具，支持 TUI 和 WebUI 双界面2. 发布时间2025 年 1 月（当前版本 v0.3.0n）3. 来源GitHub 开源项目4. 作者RamboRogers二、核心内容1. 事件摘要A. 主要内容Netventory 是一个用 Go 语言编写的快速网络发现工具，提供终端 TUI 和 Web 两种用户界面，无需 root 权限即可运行。B. 核心亮点单二进制可执行文件，无需额外依赖跨平台支持 Linux、macOS 和 Windows双界面设计：终端 TUI 和 WebUI高并发扫描架构，性能优异多协议主机名解析MAC 地址厂商识别2. 关键信息A. 版本号当前版本：v0.3.0nB. 技术栈语言：Go 1.21+（GPLv3 开源许可）架构：并发扫描 + Worker PoolC. 涉及技术网络扫描、端口检测NetBIOS、SMB、RDP、mDNS 协议解析WebSocket 实时通信Token 认证机制3. 背景介绍A. 项目定位网络发现和网络审计工具，替代传统的 nmap 等复杂工具，提供更友好的用户界面。B. 相关上下文网络扫描工具通常分为命令行工具（如 nmap）和图形化工具（如 Angry IP Scanner），Netventory 结合了两者的优势。三、详细报道1. 主要功能A. 网络发现快速网络扫描，可配置 Worker 数量自动检测网络接口和计算 CIDR 范围MAC 地址解析和厂商查找端口扫描（22、80、443、445、139、135、8080、3389、5900、8006）无需 root 权限B. 高级主机名解析Netventory v0.3.0n 引入了多层主机名解析策略：graph TD A[目标设备] --> B{DNS 解析} B -->|成功| F[主机名] B -->|失败| C{NetBIOS} C -->|成功| F C -->|失败| D{SMB 主机名} D -->|成功| F D -->|失败| E{RDP 证书} E -->|成功| F E -->|失败| G{mDNS/Bonjour} G -->|成功| F G -->|失败| H[使用 IP 地址]C. 设备类型检测Apple 设备：通过厂商 OUI、端口开放情况和 mDNS 发现Windows 设备：通过 SMB 和 NetBIOS 检测Proxmox 虚拟化平台：检测 8006 端口D. 协议增强SMB：支持来宾账户、匿名访问回退、共享枚举RDP：TLS 证书解析，提取 CN 和 SANmDNS：服务类型发现、Apple 专用服务检测2. 技术架构A. 系统组成graph TB subgraph 用户界面层 TUI[终端 TUI] WEB[Web UI] end subgraph 业务逻辑层 SCAN[扫描引擎] RESOLVE[主机名解析器] DETECT[设备检测器] end subgraph 协议层 DNS[DNS 客户端] NETBIOS[NetBIOS] SMB[SMB 客户端] RDP[RDP 证书解析] MDNS[mDNS 客户端] end subgraph 网络层 WORKER[Worker Pool] ICMP[ICMP Ping] TCP[TCP 端口扫描] end TUI --> SCAN WEB -->|WebSocket| SCAN SCAN --> WORKER WORKER --> ICMP WORKER --> TCP RESOLVE --> DNS RESOLVE --> NETBIOS RESOLVE --> SMB RESOLVE --> RDP RESOLVE --> MDNS SCAN --> RESOLVE SCAN --> DETECT DETECT --> SMB DETECT --> MDNSB. 并发扫描模型sequenceDiagram participant M as 主控制器 participant W as Worker Pool participant T as 目标设备 M->>W: 分配 IP 段 par 并发扫描 W->>T: ICMP Ping W->>T: TCP 端口检测 end T-->>W: 返回在线状态 W->>W: 端口扫描 W->>W: MAC 地址解析 W-->>M: 设备信息 M->>M: 主机名解析 M->>M: 设备类型判断C. Web 架构graph LR C[客户端浏览器] -->|HTTP + WebSocket| S[Web 服务器] S -->|Token 验证| A[认证中间件] A -->|通过| S…

Clawdbot 个人 AI 助手 Gateway 架构技术分析
type: item
date: 2026-01-25T02:22:07+00:00
description: Clawdbot 个人 AI 助手 Gateway 架构技术分析一、概述1. 项目简介Clawdbot 是一个开源的个人 AI 助手平台，采用本地优先的架构设计，允许用户在自己的设备上运行完全可控的 AI 助手。项目由 Peter Steinberger 发起，采用 MIT 许可证发布。2. 核心特性本地优先的 Gateway 控制平面多通道消息支持（WhatsApp、Telegram、Slack、Discord、Signal、iMessage、Microsoft Teams、Matrix、Zalo、WebChat 等）多 Agent 路由与会话隔离语音唤醒和对话模式（支持 macOS/iOS/Android）实时 Canvas 可视化工作区浏览器自动化控制Docker 沙箱安全隔离跨平台支持（macOS、Linux、Windows WSL2、iOS、Android）二、系统架构1. 整体设计Clawdbot 采用中心化的 Gateway 控制平面架构，所有组件通过 WebSocket 连接到 Gateway 进行通信。graph TB subgraph 通信层 WA[WhatsApp] TG[Telegram] SL[Slack] DS[Discord] SI[Signal] IM[iMessage] MT[Teams] MX[Matrix] WC[WebChat] end subgraph 控制平面 GW[Gateway WebSocket ws://127.0.0.1:18789] end subgraph 执行层 AG[Pi Agent Runtime] CLI[CLI Interface] UI[WebChat UI] end subgraph 设备节点 MAC[macOS App] IOS[iOS Node] AND[Android Node] end subgraph 工具层 BR[Browser Control] CV[Canvas] CR[Cron] WH[Webhooks] end WA --> GW TG --> GW SL --> GW DS --> GW SI --> GW IM --> GW MT --> GW MX --> GW WC --> GW GW --> AG GW --> CLI GW --> UI GW --> MAC GW --> IOS GW --> AND AG --> BR AG --> CV AG --> CR GW --> WH2. 核心组件A. Gateway（控制平面）Gateway 是 Clawdbot 的核心组件，提供统一的 WebSocket 控制平面，负责：会话管理（sessions）通道路由（channel routing）工具调度（tool orchestration）事件分发（event dispatch）配置管理（configuration）定时任务（cron scheduling）Webhook 处理B. Pi Agent Runtime采用 RPC 模式运行的 AI Agent 运行时，支持：工具流式传输（tool streaming）块流式传输（block streaming）会话隔离（session isolation）思考级别控制（thinking levels）C. 通道适配器支持多种消息平台的适配器，每个适配器负责：平台特定的消息协议处理媒体文件处理（图片、音频、视频）群组路由规则私聊策略（pairing/open）三、会话模型1. 会话类型Clawdbot 采用灵活的会话模型：main 会话：直接对话，拥有完整工具访问权限群组会话：隔离的会话环境，可配置沙箱模式工作区会话：支持多 Agent 并行工作2. 激活模式stateDiagram-v2 [*] --> Inactive Inactive --> Mention: 群组中被提及 Inactive --> Always: 始终激活模式 Mention --> Processing: 处理消息 Always --> Processing: 接收消息 Processing --> Idle: 处理完成 Idle --> Inactive: 超时 Idle --> Processing: 新消息3. Agent-to-Agent 协调Clawdbot 提供独特的会话间通信机制：sessions_list：发现活跃的 Agent 会话sessions_history：获取会话历史记录sessions_send：向其他会话发送消息这种设计允许多个 Agent 协同工作，无需在聊天界面之间切换。四、安全模型1. 默认安全策略Clawdbot 对入站 DM 采用默认拒绝策略：dmPolicy=pa…

Happy Server 零知识同步后端技术分析
type: item
date: 2026-01-19T02:14:58+00:00
description: Happy Server 零知识同步后端技术分析一、技术概述1. 项目简介Happy Server 是一个专为开源 Claude Code 客户端设计的最小化后端服务，提供端到端加密的对话同步功能。A. 核心定位Happy Server 作为安全同步的骨干网络，使多设备能够共享加密对话，同时保持完全隐私。服务器存储加密数据但无法解密，仅作为加密数据的中继存储点。B. 设计哲学零知识架构：服务器无能力查看用户消息内容最小化攻击面：仅包含安全同步必需的功能隐私优先：无分析、无追踪、无数据挖掘2. 核心特性A. 安全特性零知识证明：服务器存储加密数据但无法解密密码学认证：不存储密码，仅使用公钥签名端到端加密：消息在离开发备前已加密B. 功能特性实时同步：基于 WebSocket 的跨设备实时同步多设备支持：手机、平板、电脑无缝会话管理推送通知：任务完成或需要权限时加密推送通知分布式就绪：设计支持水平扩展C. 开源特性完全开源：透明的实现可审计和自托管MIT 许可：自由使用、修改、部署二、技术架构1. 架构设计graph TB subgraph 客户端设备 C1[设备 A 手机] C2[设备 B 电脑] C3[设备 C 平板] end subgraph 本地加密层 E1[密钥生成] E2[端到端加密] E3[签名验证] end subgraph Happy Server S1[WebSocket 同步] S2[加密数据存储] S3[推送通知服务] end C1 -->|本地加密| E1 C2 -->|本地加密| E1 C3 -->|本地加密| E1 E1 --> E2 E2 -->|加密数据流| S1 S1 --> S2 S2 -->|同步| S1 S1 -->|加密推送| S3 S3 -->|加密通知| C1 S3 -->|加密通知| C2 S3 -->|加密通知| C32. 工作流程A. 消息同步流程sequenceDiagram participant D1 as 设备 A participant E as 本地加密层 participant H as Happy Server participant D2 as 设备 B D1->>E: 1. 生成密钥对 D1->>E: 2. 加密消息 D1->>E: 3. 签名验证 E->>H: 4. 上传加密数据 H-->>D1: 5. 确认存储 H->>D2: 6. WebSocket 推送 D2->>E: 7. 下载加密数据 D2->>E: 8. 本地解密 E-->>D2: 9. 显示消息B. 安全模型分析层级安全措施说明客户端本地密钥生成密钥永不离开设备传输层端到端加密服务器仅中继加密数据存储层加密数据存储服务器存储无法解密的数据认证层公钥签名无密码存储风险3. 技术栈分析根据 GitHub 仓库信息：主语言：TypeScript（99.4%）部署方式：Docker 容器化数据库：Prisma ORM实时通信：WebSocket 协议三、安全分析1. 零知识架构A. 核心原理服务器仅存储加密数据块（encrypted blobs），完全没有解密能力。加密在客户端本地完成，只有用户持有密钥。B. 安全优势服务器被入侵无风险：攻击者仅能获取无法解密的加密数据无需信任服务器提供商：即使云服务商也无法访问消息内容符合隐私法规：数据始终处于加密状态C. 密码学认证不存储用户密码使用公钥签名进行身份验证防止密码泄露风险2. 隐私保护A. 无数据收集无分析追踪无行为记录无数据挖掘B. 推送通知加密通知内容同样经过加密，服务器仅能转发但无法查看通知内容。四、部署方案1. 云服务托管A. 官方云服务地址：happy-api.slopus.comB. 安全性说明由于采用端到端加密，使用官方云服务的安全性与自托管完全相同。所有数据在离开发备前已加密，服务器即使想查看也做不到。C. 优势无需维护基础设施自动更新和扩展与自托管相同的安全模型2. 自托管部署A. 开源特性MIT 许可，可自由修改和部署完全透明的实现可审计的代码B. 部署建议使用 Docker 容器化部署配置反向代理（Nginx）启用 HTTPS 加密传输配置防火墙规则五、应用场景1. Claude Code 客户端Happy Server 专为开源 Claude Code 客户端设计，实现：多设备对话同步任务状态共享加密推送通知2. 扩展应用场景基于其架构设计，Happy Server 可应用于：需要高隐私保护的即时通讯多设备协作工具加密笔记同步六、技术影响1. 隐私保护范式Happy Server 展示了一种新的隐私保护范式：通过端到端加密实现零信任架构服务器提供商无法访问用户数据开源透明增加可信度2. 同步架构设计最小化服务器功能客户端承担…

Rustpad 开源协作代码编辑器技术分析
type: item
date: 2026-01-17T02:17:49+00:00
description: Rustpad 开源协作代码编辑器技术分析一、项目概述1. 项目背景Rustpad 是一个高效且极简的开源协作文本编辑器，基于 Operational Transformation（OT）算法实现。该项目由 ekzhang 开发，采用 Rust + React 技术栈，提供实时协作代码编辑功能。2. 核心特性A. 技术亮点无需数据库：使用内存存储，支持可选的 SQLite 持久化极小体积：Docker 镜像仅 6 MB自托管：完全独立部署，不依赖外部服务WebAssembly：OT 逻辑编译为 WASM 在浏览器中运行B. 应用场景团队协作代码编辑实时文档协作技术面试编程环境临时代码分享和协作3. 项目状态开源协议：MIT LicenseDocker 拉取量：活跃使用中GitHub 状态：CI workflow 通过公网实例：rustpad.io二、系统架构1. 整体架构Rustpad 采用典型的三层架构：graph TB subgraph 客户端 A[Monaco Editor] --> B[React UI] B --> C[WASM OT 模块] end subgraph 传输层 C --> D[WebSocket] D --> E[Warp HTTP 服务器] end subgraph 服务端 E --> F[OT 算法库] F --> G[内存数据结构] G --> H[可选 SQLite 持久化] end2. 组件说明A. 前端组件Monaco Editor：VS Code 同款编辑器，提供代码编辑功能React UI：用户界面框架WASM OT 模块：WebAssembly 编译的操作转换逻辑B. 后端组件Warp：高性能 Rust Web 框架operational-transform：OT 算法实现库内存存储：文档内容的内存数据结构C. 通信层WebSocket：客户端与服务器的实时双向通信三、核心技术1. Operational Transformation 算法OT 算法是实现实时协作编辑的关键技术。其核心思想是将用户的编辑操作转换为可交换、可合并的变换操作。A. 基本原理graph LR A[用户 A 操作] --> C[OT 引擎] B[用户 B 操作] --> C C --> D[操作转换] D --> E[合并后的文档状态] E --> F[同步到所有客户端]B. WebAssembly 优化Rustpad 使用 wasm-bindgen 将 Rust 编写的 OT 逻辑编译为 WebAssembly，实现浏览器端的高性能执行。优势：接近原生的执行速度减少服务器负载更快的响应时间2. 数据存储策略A. 内存优先模式默认情况下，Rustpad 将文档存储在内存中：优点：极快的读写速度无需数据库配置简化部署缺点：文档在服务器重启后丢失24 小时无活动后自动清除B. SQLite 持久化模式通过设置 SQLITE_URI 环境变量启用持久化：SQLITE_URI=/data/rustpad.db优点：文档在重启后保留支持长期存储注意事项：需要挂载 Docker 卷性能略有下降四、技术栈详解1. 后端技术栈A. Rust + Warp选择理由：Warp 基于 Tokio 异步运行时，性能优异类型安全的路由系统内置 WebSocket 支持零成本抽象代码示例（路由定义）：let routes = warp::path("editor") .and(warp::ws()) .map(|ws: warp::ws::Ws| { ws.on_upgrade(|socket| handle_connection(socket)) });B. operational-transform 库功能：实现文本操作的转换和合并处理并发编辑冲突保持文档一致性2. 前端技术栈A. React + TypeScript选择理由：组件化开发强类型检查丰富的生态系统B. Monaco Editor特性：VS Code 同款编辑器支持多种编程语言语法高亮代码补全和智能提示主题和快捷键自定义3. 构建工具链A. wasm-pack用于构建和打包 WebAssembly 模块：wasm-pack build rustpad-wasmB. Vite前端开发和构建工具，提供热重载功能。五、部署方案1. Docker 部署A. 快速启动docker pull ekzhang/rustpad docker run --rm -dp 3030:3030 ekzhang/rustpadB. 持久化部署docker run -d \ -p 3030:3030 \ -v /path/to/data:/data \ -e SQLITE_URI=/data/ru…

PushMe 消息通知平台技术分析
type: item
date: 2026-01-15T10:45:48+00:00
description: PushMe 消息通知平台技术分析项目概述PushMe 是一个开源的轻量级消息通知解决方案，由 Android 客户端、自建服务器端和多种接收端组成。该项目旨在为个人开发者和小型团队提供简单、可靠的消息推送能力，无需复杂的注册登录流程，通过 push_key 即可实现消息推送。核心特点：简单：无需登录注册，安装后获取 push_key 即可使用轻量：Android 原生开发，安装包不到 3M可靠：支持离线消息存储与转发兼容：接口兼容企业微信/钉钉/飞书群机器人可扩展：支持插件开发和消息转发系统架构graph TD subgraph "发送端" A1[API调用] A2[curl命令] A3[第三方服务] A4[群机器人兼容] end subgraph "PushMe服务器" B1[HTTP API 端口3010] B2[WebSocket服务] B3[消息队列] B4[push_key管理] end subgraph "接收端" C1[Android客户端] C2[Windows客户端] C3[Telegram机器人] end A1 -->|HTTP POST| B1 A2 -->|HTTP POST| B1 A3 -->|HTTP POST| B1 A4 -->|HTTP POST| B1 B1 --> B3 B3 --> B2 B2 -->|WebSocket| C2 B2 -->|原生推送| C1 B2 -->|Bot API| C3 C1 -->|确认回执| B4 C2 -->|确认回执| B4架构说明：发送端：支持多种消息来源API 调用：任何支持 HTTP 的编程语言curl 命令：命令行直接发送第三方服务： webhook 集成群机器人兼容：可直接替换企业微信/钉钉/飞书群机器人地址PushMe服务器：核心消息中继HTTP API（端口3010）：接收消息推送请求WebSocket服务：实时推送给桌面客户端消息队列：处理离线消息push_key管理：用户身份验证接收端：多终端消息同步Android客户端：原生推送接收Windows客户端：WebSocket 实时接收Telegram机器人：跨平台消息转发技术栈分析服务器端（PushMeServer）组件技术选型运行时Node.js >= 16进程管理PM2部署方式Docker / 源码安装通信协议HTTP + WebSocket消息格式JSON端口分配：3010：Web管理界面、消息发送 API、WebSocket 服务（管理员和 Windows 客户端）3100：消息服务端口（Android 客户端连接）Android 客户端特性说明系统要求Android 7+开发方式原生 Android 开发安装包大小< 3M后台保活支持多种 ROM 的后台保活设置后台保活策略：权限管理：允许自启动、后台运行电池管理：允许后台高耗电（实测耗电低）通知管理：允许消息通知Android 12+：需开启 alarm 闹钟权限部分手机：关闭后台网络优化消息类型支持type 参数类型说明text通知消息普通文本消息markdown通知消息Markdown 格式文本消息html通知消息HTML 格式消息data数据消息数据可视化（支持 data/markdata/chart/echarts 格式）核心功能分析1. push_key 认证机制push_key 是 PushMe 的核心认证机制，用户在 Android 客户端生成后，即可用于 API 调用。这种设计避免了传统账号体系的复杂性：获取流程：安装APP → 生成push_key → 复制使用 → 发送消息优势：无需注册登录密钥即身份支持多设备独立密钥2. 消息通道机制PushMe 支持自定义消息通道，用户可以为不同来源的消息设置：不同的通知声音不同的震动模式不同的通知样式应用场景：监控告警：使用紧急提醒消息通知：使用普通提示定时任务：使用静默通知3. 插件系统PushMe 支持插件开发，允许用户对收到的消息进行加工处理：// 插件开发示例（概念） function processMessage(message) { // 自定义处理逻辑 return modifiedMessage; }4. 消息转发支持将手机端收到的消息转发到电脑端：Android 客户端接收消息通过 WebSocket 转发到 Windows 客户端实现跨设备消息同步API 接口发送消息接口请求地址：POST https://push.i-i.me/请求参数：参数描述必填push_key接口密钥是title消息标题与 content 至少填一项content消息内容与 title 至少填一项type消息类型（text/markdown/html/data）否to…

nasa42/Webterm 终端穿透访问技术分析
type: item
date: 2026-01-15T09:23:51+00:00
description: nasa42/Webterm 终端穿透访问技术分析项目概述Webterm 是一个用 Rust 编写的轻量级工具，旨在提供安全的、基于浏览器的远程终端访问能力。该项目主要解决防火墙后、私有网络或动态 IP 环境下的服务器访问问题。项目地址：https://github.com/nasa42/webterm官方状态：早期开发阶段，不建议生产环境使用。核心问题分析问题定义传统 SSH 访问在以下场景存在限制：防火墙限制：入站连接被阻止私有网络：设备仅拥有私有 IP（如负载均衡器或 NAT 后）端口限制：无法开放或转发额外端口动态 IP：家庭服务器 IP 频繁变化客户端限制：受限环境无 SSH 客户端解决方案核心Webterm 通过三层架构解决上述问题：Agent：运行在目标设备上的轻量级二进制程序Relay：无状态中继服务器，仅转发加密数据Frontend：静态前端网站，通过浏览器访问系统架构架构图组件说明组件技术实现作用AgentRust 二进制在设备上运行，保持与 Relay 的持久 WebSocket 连接Relay无状态服务器路由 Agent 与 Frontend 之间的通信Frontend静态网站浏览器端终端界面数据流向用户浏览器 --[WebSocket]--> Relay --[WebSocket]--> Agent --> PTY 会话认证与加密机制认证流程零知识证明认证Agent 使用 Device Name 和 Secret Key 向 Relay 注册Frontend 请求连接时，Relay 向 Agent 转发请求Agent 使用零知识证明验证 Frontend 身份密钥不传输：原始 Secret Key 永不通过网络传输加密方案机制实现方式密钥派生PBKDF2传输加密AES256-GCM中继安全零信任（仅转发加密数据）技术特性性能特点内存占用：空闲时低于 10 MB通信协议：FlatBuffers 高效序列化持久会话：支持数天/数周后重连安全特性端到端加密：所有通信使用 AES256-GCM零信任中继：Relay 无法读取消息内容静态前端：未压缩代码便于审计自托管支持：可自行部署 Relay 和 Frontend功能特性多终端支持：单设备多会话设备子名称：多设备共享同一 Device NameIP 变更容忍：设备 IP 变化不影响连接部署与使用快速安装# 安装 Agent curl -sSfL https://webterm.run/install.sh | bash # 启动 Agent webterm-agent --device-name <DEVICE_NAME> --secret-key <SECRET_KEY>访问终端访问 https://webterm.run 并使用相同凭据连接。与 SSH 对比维度SSHWebterm网络要求需开放端口仅需出站连接客户端SSH 客户端浏览器会话持久否是动态 IP不友好支持审计能力依赖日志流计划支持应用场景远程访问：浏览器安全连接服务器容器管理：无需开放网络端口管理 Docker嵌入式/IoT：树莓派等低功耗 Linux 系统个人设备：家庭服务器或笔记本远程访问发展路线[ ] SSO 单点登录集成[ ] 文件浏览器功能[ ] 审计日志记录[ ] 实时服务器指标[ ] 自定义插件支持[ ] Relay 故障转移与负载均衡技术分析总结优势网络穿透能力强：解决传统 NAT 穿透问题安全性设计完善：零知识证明 + 端到端加密资源占用极低：适合资源受限环境跨平台访问：仅需现代浏览器风险与限制项目早期阶段：功能不完整，API 可能变化依赖中继服务：默认使用 webterm.run 公共中继仅支持 Linux：当前仅支持基于 Linux 的系统架构启示Webterm 的三层架构设计体现了现代 Web 应用在受限网络环境下的创新解决方案：反向连接模式：Agent 主动连接 Relay，避免入站端口需求加密数据平面：中继仅转发，无法窃听状态最小化：Relay 无状态设计便于横向扩展参考资料项目仓库：https://github.com/nasa42/webterm官方网站：https://webterm.run

VibeTunnel 技术分析：浏览器终端代理平台
type: item
date: 2026-01-15T04:09:40+00:00
description: VibeTunnel 技术分析：浏览器终端代理平台一、核心问题定义在现代 AI 开发工作流中，开发者面临三个关键痛点：远程监控需求：AI agent 执行长时间任务时，开发者需要离开开发环境但仍需监控进度跨设备访问障碍：从移动设备或不同终端访问本地开发环境需要复杂的 SSH 配置Agent 协作复杂性：多个 AI agent 同时工作时，缺乏统一的会话管理和监控界面VibeTunnel 通过"将浏览器转换为终端"的核心理念，为这些问题提供了零配置的解决方案。二、系统架构分析2.1 三层架构设计graph TD subgraph 客户端层 A[浏览器 Web UI] B[iOS App] C[移动浏览器] end subgraph 传输层 D[WebSocket 连接] E[Tailscale VPN] F[ngrok 隧道] end subgraph 服务端层 G[Node.js 服务器] H[PTY 分配器] I[会话管理器] end subgraph 系统集成层 J[macOS 菜单栏 App] K[Git Hooks] L[终端会话] end A --> D B --> D C --> D D --> E D --> F E --> G F --> G G --> H G --> I I --> K H --> L J --> G2.2 核心组件分解组件技术栈职责macOS AppSwift服务器生命周期管理、菜单栏集成Web ServerTypeScript/Node.js终端会话处理、WebSocket 通信Web FrontendLit + ghostty-web终端渲染、会话 UIPTY Controllernode-pty伪终端分配、I/O 转发2.3 vt 命令转发机制sequenceDiagram participant User as 用户终端 participant VT as vt wrapper participant Server as VibeTunnel Server participant Browser as 浏览器界面 User->>VT: vt npm run dev VT->>VT: 解析别名/函数 VT->>Server: 创建会话请求 Server->>Server: 分配 PTY Server-->>Browser: WebSocket 推送 Browser->>Browser: 渲染终端输出 User->>VT: 输入命令 VT->>Server: 转发输入 Server-->>Browser: 实时更新vt 命令的智能特性：别名解析：自动展开 shell 别名（如 vt gs → git status）Shell 检测：智能路由到最佳实现（Mac App 优先于 npm 版本）标题管理：三种模式（static/filter/none）控制终端标题行为三、关键功能实现3.1 Git Follow Mode这是 VibeTunnel 最具创新性的功能，解决了 AI agent 使用 Git worktree 时的同步问题。工作原理：在 worktree 中执行 vt follow 安装 Git hooks（post-commit、post-checkout）主仓库通过 Git config 存储被跟踪的 worktree 路径当 worktree 切换分支时，hooks 触发主仓库自动 checkout实际价值：传统工作流： Agent 在 worktree 工作 → 切换分支 → 主仓库 IDE 失效 → 需要重启服务器 VibeTunnel 工作流： Agent 在 worktree 工作 → 切换分支 → 主仓库自动跟随 → IDE 继续运行3.2 多重远程访问方案方案安全性配置复杂度适用场景Tailscale Private最高（端到端加密）低个人设备间访问Tailscale Public高（HTTPS）中临时分享会话ngrok高（HTTPS）低快速公网暴露Cloudflare Tunnel高中企业级部署3.3 认证系统架构graph LR A[客户端请求] --> B{认证模式检查} B --> C[系统认证] B --> D[环境变量] B --> E[SSH 密钥] B --> F[无认证] B --> G[本地绕过] C --> H[PAM/macOS 本地用户] D --> I[VIBETUNNEL_USERNAME/PASSWORD] E --> J[~/.ssh/authorized_keys] F --> K[仅受信任网络] G --> L[localhost + token 可选] H --> M[会话创建] I --> M J --> M K -->…