Neko 路线图解析从 V3 服务器迁移、客户端重写到模块化架构【免费下载链接】nekoA self hosted virtual browser that runs in docker and uses WebRTC.项目地址: https://gitcode.com/GitHub_Trending/ne/nekoNeko 是一个运行在 Docker 中、基于 WebRTC 的自托管虚拟浏览器项目其官方路线图webpage/docs/roadmap.md将未来发展划分为三个阶段V3 服务器迁移、V3 客户端重写、整体模块化。本文以该路线图为骨架结合当前仓库中的服务端、客户端源码与配置实现逐阶段拆解每个规划的技术内涵、当前落地状态与后续演进方向帮助读者理解 Neko 的架构演进逻辑以及连接、媒体流、控制三大抽象层的设计思路。路线图总览三个阶段路线图将 Neko 的发展划分为三个彼此衔接的阶段每一阶段聚焦项目的一个侧面Phase 1 – Server migration to V3完成服务端向 V3 的迁移与整合已随 Neko V3.0.0 发布而完成Phase 2 – Client rewrite to V3将基于 Vue2 的客户端重写为基于 Vue3 的组件化客户端Phase 3 – Modularization将 V3 客户端与服务端模块化把连接、媒体流、控制抽取为可替换的接口层。从仓库结构看这三个阶段并非彼此割裂服务端server/internal/下的api/、capture/、http/legacy/、webrtc/、websocket/等模块以及客户端client/src/下的neko/、store/、components/共同构成了路线图所描述的现状基础。Phase 1V3 服务器迁移与 V2 兼容层服务器合并与 V3.0.0 发布Phase 1 的目标是完成服务端迁移其成果随 Neko V3.0.0 发布而落地。原 m1k1o/neko 服务器与已归档的 demodesk/neko 服务器被合并并在此基础上发布了新的 V3.0.0 版本。合并的目的在于统一两套代码遗产、收敛维护精力同时为后续的客户端重写与模块化提供稳定的服务端基础。V2 客户端兼容层legacy 模块路线图明确指出Phase 1 中添加了一个兼容层以支持 V2 客户端。在仓库中这一兼容层对应server/internal/http/legacy/目录handler.go 等。从源码看LegacyHandler采用协议翻译代理模式实现兼容对外暴露 V2 时代的 HTTP/WebSocket 端点例如/ws、/stats、/screenshot.jpg、/file支持 GET/POST/DELETE、/healthhandler.go收到 V2 客户端连接后通过wsDialer.Dial(ws://serverAddr/api/ws?token...)回连到 V3 后端handler.go通过两个 goroutine 双向复制 WebSocket 消息replicateWebsocketConn并在wsToClient/wsToBackend中对新旧消息格式做改写handler.go。这意味着 V2 老客户端无需改动即可继续访问 V3 服务端为 V3 上线提供了平滑过渡路径。配置层面的 V2 → V3 迁移与兼容层配套服务端保留了完整的 V2 配置兼容逻辑。以 WebRTC 配置为例server/internal/config/webrtc.go 中同时存在Init/SetV3 命名空间与InitV2/SetV2V2 旧命名空间V3 配置形如NEKO_WEBRTC_ICELITE、NEKO_WEBRTC_ICESERVERS_FRONTEND、NEKO_WEBRTC_EPR等V2 配置形如NEKO_ICELITE、NEKO_ICESERVERS、NEKO_EPR等一旦被检测到代码会打印弃用警告并自动启用legacy标志webrtc.go。视频捕获配置同样如此server/internal/config/capture.go 中 V2 的NEKO_VIDEO_CODEC、NEKO_HWENC、NEKO_VIDEO_BITRATE、NEKO_MAX_FPS会被转换为 V3 的NEKO_CAPTURE_VIDEO_*管线配置并通过NewVideoPipeline自动生成 GStreamer 管线capture.go。这种新旧并存、自动降级的设计保证了从 V2 到 V3 的配置迁移成本可控。Phase 2V3 客户端重写Vue2 → Vue3重写动机Vue2 生命周期结束路线图指出V2 客户端基于 Vue2 构建而 Vue2 早已到达生命周期终点EOL。当前仓库的 client/package.json 中依赖仍为vue: ^2.7.13、vue-class-component、vue-property-decorator、vuex等 Vue2 生态组件这正印证了路线图所述的现状——V2 客户端仍是当前实现。从界面导向到组件导向的设计转变路线图明确对比了两代客户端的设计哲学V2 客户端聚焦用户界面user interface当前client/src/components/下的connect.vue、video.vue、menu.vue、side.vue、controls.vue、members.vue、chat.vue、clipboard.vue等组件即为此类 UI 呈现V3 客户端聚焦可扩展性extensibility in the form of components客户端将被拆分为可无缝嵌入任意现有应用的组件这些组件可以在任何其他 Vue3 应用中被复用对传统用户而言客户端仍会以独立应用形式提供全部既有功能。仓库中已经能看到组件化方向的雏形client/src/lib.ts 通过build:lib脚本vue-cli-service build --target lib --name neko-lib src/lib.ts将客户端构建为库并导出了NekoConnect、NekoVideo、NekoMenu、NekoSide、NekoControls、NekoMembers、NekoChat、NekoClipboard等一系列可独立引用的组件package.jsonlib.ts。这就是组件可用于任何 Vue3 应用理念在当前代码中的最早落地。Phase 3模块化——连接、媒体流与控制三抽象Phase 3 是路线图中着墨最多的部分。其核心设想是V3 客户端将被拆分成一个不依赖 Vue.js甚至不依赖任何库的 TypeScript 组件库任何项目都可以像嵌入一个视频播放器那样轻松集成 Neko参考 demodesk/neko-client 的构建思路但去掉 Vue.js 依赖。同时连接connection、媒体流media streaming、控制control将被提取为接口使 Neko 从共享虚拟环境升级为内置反馈与带外通信工具的视频流服务器——例如原生绑定 RDP/VNC 协议、远程控制无人机/机器人/PTZ 摄像头/工业设备等。由于控制层可以是插件输入源也不再局限于键盘鼠标还可接入游戏手柄、摇杆甚至 VR 眼镜。Connection面向 API 用户的连接抽象路线图要求Neko 可以通过多种通道连接后端因此API 用户不应暴露于 WebSocket 内部细节只需要关心两类信息连接状态connection status状态含义connected用户已连接服务器connecting客户端正在尝试建立连接disconnected用户已断开且无重连尝试必须携带断开原因连接类型connection type类型机制none当前未使用任何连接short_polling每隔 X ms 客户端请求一次服务器获取更新long_pollingHTTP 请求保持打开直到服务器有更新下发随后客户端再发起新请求sse服务器通过 Server-Sent Events 向客户端推送更新websocket服务器通过 WebSockets 推送更新...其他例如 MQTT当前实现中连接状态机已存在于客户端基类 client/src/neko/base.tssocketOpen判断 WebSocket 是否打开peerConnected判断 WebRTC ICE 状态是否处于connected/checking/completed二者同时满足才认为整体connectedbase.ts事件处理中区分了EVENT.CONNECTING、EVENT.CONNECTED、EVENT.DISCONNECTED(reason)其中onDisconnected会接收reason?: Error参数base.ts与路线图断开必须携带原因的要求一致客户端状态在 Vuex store 中维护connecting/connected布尔状态client/src/store/index.ts。这也解释了路线图为何要求抽取连接接口当前BaseClient将 WebSocket信令、控制消息与 WebRTC媒体、数据通道深度耦合一旦接入 MQTT 或 SSE 通道就必须在接口层将这些细节隐藏起来。Media streaming单一接口下的多流后端路线图对媒体流提出了与连接层对称的抽象计划支持的流媒体后端包括流后端机制none当前无媒体流m3u8通过 HLS 传输媒体webrtc通过 WebRTC 传输媒体quic通过 QUIC 传输媒体...其他例如 RTSP、DASH不同的流媒体后端具备不同能力例如 WebRTC 支持向服务器发送媒体麦克风上行而 HTTP 系只能单向接收。流后端的选择可基于用户设备能力、网络条件、服务器能力综合决定。所有流后端必须满足同一个接口该接口是与系统其他部分通信的唯一通道。仓库当前的多流支持已经为这一抽象奠定了基础server/internal/config/capture.go 支持配置多个视频管线NEKO_CAPTURE_VIDEO_PIPELINESmap[string]VideoConfig与有序视频 ID 列表NEKO_CAPTURE_VIDEO_IDS也可用NEKO_CAPTURE_VIDEO_PIPELINE快捷配置单管线未配置时使用默认 VP8 管线capture.goserver/internal/capture/streamselector.go 实现了StreamSelectorManagerCtx流选择器支持按流 IDexact/lower/higher和按码率nearest/lower/higher/exact选择当前使用的流并带有nearestBitrate最近码率匹配逻辑streamselector.go服务端 WebRTC 带宽估计器webrtc.estimator.*系列配置见 server/internal/config/webrtc.go会根据估计带宽自动在高低码率流之间升级/降级其read_interval、stable_duration、unstable_duration、diff_threshold等参数正是基于网络条件选择流的工程实现。路线图中单一接口的设计目标与当前StreamSinkManager/StreamSelector的抽象方向是一致的——未来的 m3u8/quic 后端可以挂到同一接口之下。Control人机接口设备带内与带外反馈控制层是 Phase 3 中最具想象力的部分。路线图设想用户可使用键盘、鼠标、游戏手柄、触摸屏或任何其他可控制系统的设备也支持自定义或虚拟设备。控制数据的反馈分为两种模式带内反馈in-band正常情况下反馈直接在媒体流内呈现给用户例如画面本身带外反馈out-of-band在特定场景下必须走独立通道包括游戏手柄的振动反馈光标在屏幕上被隐藏或针对特定用户隐藏因此光标需要带外传输多用户场景下所有人可在屏幕上看到各自的自定义光标但只有一人能实际控制光标因此光标位置必须带外传输修改屏幕分辨率、方向或其他设置修改键盘布局或修饰键设置 host根据优先级与权限决定当前控制者。控制数据既可以通过底层连接传输也可以通过媒体流通道传输——例如WebRTC data channel 可用于实时传输控制数据。当前实现恰好展示了带外光标与数据通道控制的雏形server/internal/webrtc/handler.go 处理 WebRTC DataChannel 上到达的二进制控制协议OP_MOVE移动事件中host 用户移动真实光标manager.desktop.MovecurPosition.Set非 host 用户仅更新自己的会话光标位置session.SetCursor这与路线图只有一人控制光标、所有人光标位置带外传输完全吻合handler.go此外还处理OP_SCROLL、键盘按键KEY_DOWN/KEY_UP与OP_PING/OP_PONG心跳handler.go客户端侧 client/src/neko/base.ts 的sendData用二进制帧封装鼠标移动OPCODE.MOVE、滚轮OPCODE.SCROLL、按键按下/抬起通过this._channel.send(buffer)走 RTCDataChannel 发送服务端server/internal/webrtc/cursor/image.go、position.go独立维护光标图像与位置client/src/neko/index.ts 中EVENT.CONTROL.LOCKED/EVENT.CONTROL.RELEASE分别响应 host 的取得与释放配合键盘布局切换remote.changeKeyboard()正是设置 host与键盘布局带外同步的现有实现。路线图的演进价值综合来看Neko 的路线图描绘了一条清晰的架构演进路径兼容优先Phase 1 通过合并服务器 协议代理兼容层server/internal/http/legacy/ V2 配置自动迁移webrtc.go/capture.go的InitV2/SetV2在不中断老用户的前提下完成服务端换代体验升级Phase 2 借 Vue2 EOL 之机把以界面为中心的客户端重构为以组件为中心的可嵌入式客户端client/src/lib.ts已是第一步能力泛化Phase 3 将连接、媒体流、控制三者的接口彻底解耦使 Neko 从共享浏览器泛化为通用的低延迟远程控制与视频流基础设施输入设备与传输协议均可按插件化方式扩展。对开发者而言如果希望参与 Neko 的后续演进可以从三个切入点着手研究 server/internal/http/legacy/ 理解协议兼容层的实现模式阅读 client/src/neko/base.ts 与 client/src/lib.ts 评估 Vue3 客户端重写的工作量以及围绕 server/internal/webrtc/handler.go 与 server/internal/capture/streamselector.go 思考新流后端与控制设备插件应如何接入统一接口。【免费下载链接】nekoA self hosted virtual browser that runs in docker and uses WebRTC.项目地址: https://gitcode.com/GitHub_Trending/ne/neko创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考