坑边闲话：最近飞牛发布了一款名为 FnTermX 的应用，允许用户在 web 桌面里使用 ssh，这想法真是棒极了！同样是 SSH, TrueNAS 的模型就比较粗糙，由于不能以独立窗口形式存在，切换到别的菜单再切回来，刚才的会话就没了。飞牛的设计基于窗口，因此可以长期保活。然而，在反向代理情况下，FnTermX 打开就是一片空白，这到底是为什么？本文尝试简单分析问题的原因，以及分享笔者关于未来的一些构想。

1. 问题归因·

目前在飞牛 web 桌面里，有两套开发桌面 app 的方案：

基于 absolute flex 飞牛自研框架，典型 App 包括「文件管理」、「日志」、「系统设置」等原生应用。
基于 iframe 的嵌入型窗口 App，如「百度网盘飞牛版」、「Docker容器管理」。

前者就是最原生的应用，体验最好，兼容性无敌。

后者就是把一个独立的应用加载成飞牛桌面里的小窗口。下面简单展示一下：

图 1. 飞牛的 Docker 管理器就是一个 iframe 嵌入。这个应用可能是由其他小组的人开发，所以形式是 iframe 嵌入，而非飞牛 flex 本地开发。

通过你的飞牛地址（域名、IP均可）加上路径 /apps/docker 就能直接打开容器管理界面。同样，这也适合飞牛版百度网盘（地址是 IP_ADDR/app-baidu-netdisk/）。

作为一个原教旨主义者，我不是很赞同这种集成模式，因为这会让飞牛开发变得比较复杂。当然，百度网盘由于前端比较复杂，从头到尾用飞牛 Trim 架构 SDK 做一个发行版比较费时费力，最好的方法就是找百度要一下网页前端代码然后稍微去掉广告和乱七八糟的东西，弄一个干净版嵌入进来。

那么 FnTermX 问题在哪里呢？原来 FnTermX 默认以 HTTP 方式打开位于 5122 端口的服务。然而，反向代理为 HTTPS 之后，浏览器默认禁止从 HTTPS 跳转到 HTTP iframe，然后你的 FnTermX 打开就是空白。

2. 解决方案·

如果非得使用 FnTermX，可以使用 IP 加端口是 5122 进行访问。

图 2. 可以直接使用 IP:port 的方式使用 FnTermX.

至于这个网页版 terminal 有什么用，我想最大的用途就是在不方便接触 KVM 而且 sshd 拒绝的情况下使用命令行。

3. 头脑风暴·

今天在飞牛共建团的直播间和主播们交流时，讨论到了我最近的一个想法。由于我不是前端大师，所以有些问题、想法可能只是自己对原理不理解、误解导致的。这很有可能，因为作为一个存储和安全研究者，我经常面对一些行外人提出的「并不存在的问题」。因此我也很有可能犯同样的错误。

目前，

SaaS 基本上以单体应用为开发模型，前后端分离；
前端以 JavaScript/CSS/HTML 构建，基于 HTTP 与后端交互，完全依赖浏览器。而且前端完全无状态，会话保持着浏览器 cookie 或 localStorage 里。
后端以存储（数据库和文件系统）和 App web 服务器为主体，
- 存储解决状态问题，
- App 后端以无状态模式支持 K8S 横向扩展；
以 nginx 作为负载均衡器 LB，用户在单一界面可以请求多个后端服务。

然而，在前端设计里，由于技术的限制，很少有厂商能以用户最为熟悉的类 Windows 桌面的形式提供交互式服务。群晖作为 web 桌面的发明者，也仅仅是提供了「文件浏览器」、「系统设置」、「纯文本编辑器」（注意不是富文本）、「ABB 控制台」等几个应用而已。复杂的 Synology Office 只能依赖独立的网页做单独开发。

那么问题来了，群晖为什么不把 Office iframe 化？可能问题还是在于安全性。Office 最大的问题在于它能对 NAS 里的文件直接编辑，所以它基本上不允许其他任何应用 iframe 自己，以防 clickjacking 点击劫持攻击。

简单总结一下：

群晖 DSM 桌面看起来像 Windows，本质是 Single Page Application (SPA)；
Office 不是 DSM UI 的子应用，而是 另一个独立 Web 应用；
由于安全因素，Office 不接受作为 DSM 桌面的的 iframe.

此外，不仅 Office，Drive、Chat、ABB 备份查看与回滚、MailPlus 全部都是独立 Web App。

DSM 是管理系统
Office/Drive 等属于独立产品

3.1 我梦想做一个大一统的 SPA 桌面·

群晖发迹比较早了，当时的桌面开发框架选择有限，而且没有 wasm 技术，然而今时不同往日。如果继续沿着群晖的思路做 DSM + 独立产品，效果可能不太好。当时我在直播间说，这样做的天花板就是另一个 DSM 而已。

Desktop (SPA)
 ├─ AppManager
 │   ├─ OfficeEditor (WebAssembly + Canvas/WebGPU)
 │   ├─ PhotoEditor (WebGL/WebGPU)
 │   ├─ CADEngine (WebAssembly)
 │   └─ FileExplorer (IndexedDB/OPFS)
 └─ WindowManager（Zindex + focus + drag + resize）

可以给 App 进行归类：

完全云端运行的应用，如 ABB, 日志记录，快照等。
完全在浏览器本地运行的应用，如画图、文档，类似 Draw.io，此时 NAS 只负责做 CDN 下发 app 程序；
可以浏览器本地运行但是可以选择和 NAS 交互的应用，NAS 只提供中心化存储能力，如
- 文档编辑：从 NAS 读取文件编辑后再保存回 NAS, 文件实时同步或异步地 flush 到 NAS 里；
- 只读的流媒体服务：从 NAS 读取文件进行本地读取，如看视频、听音乐、浏览图片等；
需要 NAS 深度参与计算并提供交互的服务，如 AI 推理、edge-cloud 联合计算等。
- AI 推理自然不必多说；
- edge-cloud 联合计算可以参考微软的 Fluid Framework，用户在本地浏览器里进行部分计算，复杂计算交给 NAS 或云端服务器处理。
- 串流游戏：游戏安装在 NAS 上，用户在浏览器里进行交互，NAS 负责游戏画面渲染并以视频流形式传输到浏览器。

我觉得飞牛如果要实现革命，应该彻底跳出 DSM UI、iframe、独立应用这种过时的路径，而是直接做一个大一统的 SPA 桌面应用，把所有的功能模块都集成在一个单一的前端应用里。这样用户体验会好很多，而且开发和维护也会简单很多。

当然，这只是一个梦想罢了。我也不确定未来会不会有这样的桌面出现。但是如果出现了，我觉得这个应用可能会彻底改写目前计算机的使用方式：

学校、企业购买强大的服务器；
用户使用廉价的终端设备（Chromebook、平板、轻薄本等）接入服务器；
所有的计算和存储都在服务器端完成，用户只负责交互。

3.2 与 ChromeOS、RDP 的区别·

ChromeOS 和 DSM 这种传统系统主要是多个独立产品同时存在，比如 Google Docs、Google Sheets、Google Slides 等等。每个产品都是一个独立的 Web App，用户需要在浏览器里打开不同的标签页进行使用。

这好吗？使用起来确实好像没什么大问题，但是浏览器的问题就是标签页容易爆炸，用户很容易迷失在各种标签页里。比如我经常使用的 Google Sheets, 一旦打开四五个表，来回切换的体验就比较糟糕了，此时无比渴望有三四个大屏幕同时使用。而在 Windows 桌面的情况下，窗口切换就方便很多。可能也是笔者的心理作用，总感觉在浏览器里打开十几个网页办公，效率会比在桌面环境里低一些。

RDP （远程桌面协议）则是把整个桌面环境都搬到了远程服务器上，用户通过 RDP 客户端进行交互。这样用户的本地设备就像一个终端，所有的计算和存储都在服务器端完成。这可能是最务实的选择，因为除了 RDP，我们不需要开发任何前端应用，所有的应用都在服务器端运行。VDI 市场也是基于这个思路。而且 RDP 的性能也不错，尤其是在局域网内使用时，用户体验接近本地桌面。然而，