nakagami 在 GitHub 开源了 grdpwasm。它是一个基于 Go WebAssembly 和 grdp 的浏览器 RDP 客户端。用户在网页里填写 RDP 主机、端口、域、用户名、密码和分辨率，远程桌面显示在 canvas 上，键盘、鼠标、滚轮会转发到远端，RDPSND 音频通过 Web Audio API 播放。
这不是微软官方产品，也不是企业级远控平台。它更像一张工程样张：浏览器跑 WASM 客户端，Go 代理把 WebSocket 转成 TCP。真正的变量不在“浏览器能不能显示远程桌面”，而在代理怎么部署、谁来鉴权、凭据怎么过线、日志和责任谁来背。
发生了什么：RDP 进了浏览器，但不是直连 3389
项目 README 给出的链路很直白：Browser(WASM) -- WebSocket -- Go proxy -- TCP -- RDP Server。
这句话要拆开看。浏览器端跑的是 Go 编译出来的 WASM。它负责客户端逻辑、输入输出和画面呈现。Go proxy 负责把浏览器里的 WebSocket 流量接出来，再转成到 RDP Server 的 TCP 连接。
关键限制也在这里：浏览器不能直接打开 TCP 3389。grdpwasm 不是让浏览器获得了原生 TCP 能力，而是用代理绕过浏览器沙箱边界。
构建和运行门槛不复杂。项目要求 Go 1.24+，还需要一个可访问的 RDP 服务端。执行 make all 构建 WASM、Go runtime JS 和代理，再用 make serve 启动，本地访问 http://localhost:8080 测试。
| 问题 | 当前事实 | 对读者的含义 |
|---|---|---|
| 它是什么 | Go WebAssembly + grdp 的浏览器 RDP 客户端 | 更适合看作 PoC 或内网工具样张 |
| 怎么连 | Browser(WASM) -- WebSocket -- Go proxy -- TCP -- RDP Server | 代理是必需组件，不是可有可无 |
| 支持什么 | canvas 显示桌面，键鼠滚轮转发，RDPSND 音频走 Web Audio API | 功能比纯玩具 demo 更完整 |
| 怎么跑 | Go 1.24+，可访问 RDP 服务端，make all / make serve | 开发者试跑成本低，运维上线成本另算 |
| 项目状态 | GitHub 小型开源项目，约 15 stars、1 fork、无正式 release、GPLv3 | 不该按成熟商业产品解读 |
还有一个细节值得看。仓库带了 grdp 的本地 fork，给 RdpClient 增加了 Dialer 字段，让调用方能注入自定义 net.Conn 工厂。
这说明得很清楚：RDP 协议栈没有魔法穿墙。真正把浏览器世界和 TCP 世界接起来的，是 WebSocket-to-TCP 代理。
谁会受影响：内网工具开发者会心动，运维团队要多算一层账
最相关的人不是普通 Windows 用户，而是两类人。
一类是远程运维团队。他们可能想要一个轻量 Web 入口，用来访问内网里的 Windows 机器。少装客户端，少发安装包，少解释插件权限，这很有吸引力。
另一类是做内网工具、堡垒机原型、实验室控制台的开发者。grdpwasm 给了一个可读的路径：传统 TCP 协议可以通过 WASM 客户端加 WebSocket 代理搬进浏览器。
但动作要分清。
| 对象 | 可以做 | 不该做 |
|---|---|---|
| 远程运维团队 | 在可信内网试跑，评估是否能接入现有运维面板 | 把默认代理直接暴露到公网 |
| 内网工具开发者 | 阅读 Dialer 设计，借鉴 WebSocket-to-TCP 的拼接方式 | 把它包装成已有鉴权、审计、隔离能力的成品 |
| 技术采购或架构负责人 | 用它验证浏览器化远控的可行性 | 因为“能连上”就替代 Guacamole、堡垒机或成熟远控方案 |
这里必须和 Apache Guacamole 这类方案做个对照。Guacamole 已经在远程桌面 Web 网关这条路上走了很久，重点不只是协议转发，还包括认证、会话、管理和部署体系。grdpwasm 目前更轻，也更像工程实验。
两者不能简单说谁替代谁。grdpwasm 的好处是小、直接、适合读代码和做 PoC。成熟网关的价值在可管、可审、可交付。一个是样张，一个是系统。差别不在“能不能打开远程桌面”，而在出了事以后谁能查、谁能控、谁能止损。
这也是搜索读者最容易误读的地方。无插件远控听起来像省事，实际只是把客户端安装成本转移到了服务端治理成本。
真门槛在代理：默认能跑，不等于能裸奔
README 里的安全提示不应被轻描淡写。
代理默认接受任意来源。凭据会通过 WebSocket 从浏览器发送到代理。在非可信网络里，项目建议使用 HTTPS/WSS，把代理放在 nginx、Caddy 这类 TLS 终止反代后，并自行加入认证。
这不是漏洞利用结论。材料只支撑一个更朴素的判断：默认部署边界很窄。可信内网实验是一回事，公网入口是另一回事。
一旦放到公网，代理就不只是“转发器”。它会变成入口、凭据通道、访问控制点，也可能变成横向移动的跳板。远控系统最怕的不是连不上，而是连得太容易。
历史上这件事并不新。早年的 VNC Java applet、后来的 HTML5 远程网关，都在回答同一个问题：远程桌面能不能搬进浏览器？答案早就是能。难的是权限、隔离、证书、日志、审计、会话生命周期和故障处理。
“天下熙熙，皆为利来。”省掉客户端安装，是利。把代理、TLS、鉴权和运维责任补齐，是账。古话不负责替工程兜底，账单最终会落到部署的人头上。
接下来最该观察的不是 star 涨不涨，而是几个硬变量：
- 代理是否加入鉴权和 Origin 控制。
- WSS 是否成为默认推荐路径，而不是附加说明。
- 凭据处理、会话日志、断连清理有没有更清楚的设计。
- 兼容性、延迟、音频稳定性有没有公开测试。
- 是否出现正式 release，以及默认配置是否更适合安全部署。
目前材料看不到这些答案。那就不能替它吹成生产级方案。
我的判断很直接：grdpwasm 做对了技术演示，也暴露了浏览器远控的老问题。协议搬进网页只是上半场。安全边界、代理治理和运维责任，才是下半场。
对开发者，它值得读。对小团队，它可以内网试。对准备上线的运维团队，先把鉴权、WSS、访问边界和日志补完，再谈“好用”。