随着机器人系统、智能设备以及分布式软件架构的发展，跨网络环境的通信能力逐渐成为系统基础设施的重要组成部分。在实际部署中，系统往往分布于不同局域网、企业内网或家庭网络之中，彼此之间缺乏直接连通路径，受限于网络安全策略及拓扑结构。大量设备运行在 NAT（网络地址转换）之后，外部系统难以主动建立连接，这一问题在机器人及边缘设备场景中尤为普遍。
挑战：跨网络接口调用的困境与现有方案局限
**在软件工程领域，远程过程调用（RPC）是构建分布式系统的经典技术方式。RPC 允许调用方与执行方运行在不同主机上，通过网络完成通信，同时在程序层面保持类似本地函数调用的开发体验。但这一模型依赖一个关键前提：客户端能够直接访问服务端地址，当服务器部署在 NAT 网络之后时，传统 RPC 架构往往会遇到连接问题，稳定性难以保障。
近年来，也有几种现有解决方案如端口映射、VPN 或基于 WebSocket/MQTT 的中心化中转：
01 端口映射
首先，端口映射是最直接的方式，但其前提是具备网络设备配置权限。在实际环境中，设备通常部署于多级 NAT 或受限网络之中，端口映射不仅配置复杂，而且在设备迁移或网络变化时需要反复调整，难以规模化运维。
02 VPN
其次，VPN 通过构建虚拟局域网，在逻辑上打通网络边界，使 RPC 调用能够恢复"直连"模式。然而 VPN 本质上引入了一层额外网络基础设施，不仅需要专门部署与维护，还对网络环境稳定性提出更高要求。在机器人设备频繁上下线、跨网络切换的场景下，其连接可靠性与运维成本往往成为瓶颈。
03 构建中心化中转服务
另一类方案基于 WebSocket 或 MQTT 构建中心化中转服务，通过公网服务器转发请求与数据。这种方式虽然规避了网络连通问题，但本质上改变了原有通信模型：调用过程不再是标准的 RPC 或 TCP 连接，而需要重新设计数据格式与交互协议。同时，中心化服务承担全部转发压力，也带来了带宽成本与单点故障风险。
综合来看，传统方案的核心问题在于：要么依赖网络配置，要么侵入业务协议和引入中心化负担，难以同时兼顾简洁化与稳定性。
基于上述问题，我们提出了loong_remote_communication 方案：不改变现有客户端与服务端通信模型，而是在两者之间引入一层透明的网络适配层，将跨网络连接问题从业务层剥离。
设计： loong_remote_communication 透明隧道架构
loong_remote_communication 基于 WebRTC DataChannel 构建透明 TCP 隧道，采用 Portal + Proxy + MQTT 信令通道的组合模式，实现跨局域网设备的零侵入通信。
从结构上看，loong_remote_communication通过 Portal（控制侧）与 Proxy（设备侧）协同工作：
01
Portal 在本地模拟服务端行为，对外暴露本地端口或 Unix Socket，接收客户端连接
02
Proxy 在设备侧模拟客户端行为，主动连接服务端
03
**WebRTC 信令服务：**负责交换 SDP（Session Description Protocol）和 ICE 候选，协助建立 P2P 连接，该通道替代了传统的 WebRTC 信令服务器，利用 MQTT 协议实现信令数据的可靠传输
04
STUN/TURN服务：辅助NAT穿透，必要时进行中继转发（如使用coturn）
每个 Portal 对象内部会生成一个 Agent 子对象，而每个 Proxy 对象会为每个连接的 Agent 生成一个 Broker 子对象。Agent 与 Broker 之间建立一条 WebRTC PeerConnection，并在其上创建一条 DataChannel（单通道策略）或多条DataChannel（多通道变种），通信双方以标识字符串在信令服务中注册，从而支持任意局域网间的多客户端跟多服务端访问。
核心设计
1.透明 TCP 隧道：协议无感的数据映射
通过 WebRTC DataChannel，将远端 TCP 流量直接映射到本地端口，实现远程服务在逻辑上的本地化访问。现有 RPC（如 gRPC）、HTTP 或任意基于 TCP 的应用协议无需修改即可接入。
2.MQTT 信令通道：轻量可靠的连接协商
连接握手
Portal 订阅 Proxy 的状态话题以检测设备在线状态，并向 Proxy 的信令话题发布 SDP Offer，并在自身的信令话题等待 Answer；Proxy 订阅信令话题接收 Offer，生成 Answer 并回传至 Portal 的信令话题。双方同时通过 MQTT 交换 ICE Candidate，完成 WebRTC 连接建立，设备上线或下线时同步发布状态话题。
权限管理
所有鉴权操作在 MQTT Broker（如 EMQX）端执行，并结合 Authing 进行统一身份认证。复杂的机器人控制权限被抽象为标准 MQTT Topic 的读写权限，实现可扩展、细粒度的访问控制，且无需改动客户端或设备端应用逻辑。
3.协议无关与 P2P 优先：高效稳定的传输策略
数据通道完全透明，支持任意基于 TCP 的应用协议；WebRTC 优先建立 P2P 直连，必要时通过 TURN 中继，降低延迟与带宽成本，保证复杂网络环境下的稳定性。
特性：高性能、零侵入与协议无关
loong_remote_communication在设计上突出高性能、零侵入与易用性，具体体现为以下几个方面：
- RaaS（Remote as a Service）架构
通过将远端 TCP 服务（如 gRPC、REST）代理到本地，远程服务在逻辑上被完全映射为本地服务，无论客户端在公网还是局域网，调用方式和接口语义均保持一致，实现真正的"远程即本地"体验。
- 高性能
采用 Rust 语言和 Tokio 异步运行时，实现高并发协程处理，最大限度降低 TCP 数据转发开销，确保大规模设备部署下的低延迟通信。
- 内存安全
借助 Rust 的所有权与生命周期机制，在编译期即保证并发访问的内存安全，避免常见的缓冲区溢出、数据竞争等问题。
- 极简部署
信令通道基于 MQTT，无需额外 WebSocket 服务器支持，并可结合 EMQX 实现统一鉴权和安全管理，使部署与运维更加简便。
- 跨平台兼容
支持 Linux（x86_64 / aarch64）及 Windows 系统，覆盖常见服务器与边缘设备运行环境，保证系统灵活性与可扩展性。
- 协议无关
透明转发 TCP 流量，无需修改原有应用协议，支持任意基于 TCP 的自定义或标准协议，涵盖 RPC、HTTP、WebSocket 等多种业务场景。
本质上，loong_remote_communication并非替代 RPC 或其他通信协议，而是构建了一层面向复杂网络环境的"透明通信基础设施"，使分布式系统在跨网络场景下仍能够保持与局域网一致的开发与运行体验，为跨局域网的机器人、智能设备及分布式系统提供稳定、高效且可扩展的通信基础设施。
规划：未来演进方向
loong_remote_communication 目前已在机器人遥操控、云平台后端接入等场景中得到验证，我们仍在持续演进，下一步将重点推进以下方向：
集群控制：支持单 Portal 连接多个 Proxy，实现请求广播（例如机器人编队控制、批量指令下发）。
连接复用：优化 DataChannel 与底层 Socket 的复用机制，减少频繁握手的开销，提升大规模连接场景下的吞吐能力。
HTTPS 支持：为 Web 客户端提供安全的 HTTP 代理能力，扩展至浏览器直接访问内网服务。
统一鉴权体系：基于 EMQX + Authing 构建可扩展的权限模型，将设备、用户、Topic 的访问控制统一集成，实现细粒度安全管理。
此外，此方案还将融合跨局域网数据透传与音视频互通，使同一套基础设施既能承载 TCP 数据流，也能支持 WebRTC 音视频通道，打造更加完整的远程通信解决方案。
生态：社区开源
目前，loong_remote_communication已在 OpenLoong 开源社区正式开源。项目代码仓库包含完整的 Rust 实现、MQTT 信令集成示例以及多平台部署指南，欢迎体验跨局域网透明隧道带来的便捷。
深入解读文章
同时，为了帮助开发者深入理解方案背后的设计思想与实现细节，技术团队已撰写深入解读文章，涵盖 WebRTC DataChannel 隧道原理、MQTT 信令集成实践、Rust 异步编程在通信中间件中的应用等，欢迎前往阅读。
OpenLoong 开源社区致力于为人形机器人与具身智能领域提供高水平的开源基础设施，我们欢迎每一位对实时通信、网络穿透、Rust 开发感兴趣的开发者加入社区，无论是提交代码、撰写文档、报告问题，还是参与讨论，都将为社区带来宝贵价值，让我们一起构建开放、高效、的具身智能开源生态吧！