之前的公检法项目中遇到要在网闸隔离的内外网之间实现文档的在线协同编辑。需求场景是内网有一篇Office文档需要在内网和外网进行多次编辑和修改在此过程中需要保证内外网编辑的是同一份文件而且任何一侧的修改要即时的同步给另一侧保证文档内容准实时一致性。这就需要有协同编辑能力的在线Office(WebOffice)来解决但在此之前客户选型了国内前三家的WebOffice产品限于其产品设计和通信机制都无法不大改的情况满足这类场景。最终选择我们团队提供的方案既可以满足内外网协同编辑的需要又可以防止外网编辑过程中内容被拷贝出去的风险见 构建安全内部剪切板内容复制管控与OnlyOffice优化实践确保了信息安全。以下结合实际项目的经验简单介绍在公检法、政府、军工、医疗、能源等关键行业和领域对隔离强要求的情况针对类似需求场景为大家提供一种解决思路。网闸是什么国内网闸市场的兴起可追溯至2000年。彼时随着政府信息化与电子政务系统建设进程加速在电子政务的内网、外网及专网之间实现信息交换成为一项基本需求。然而政府内网对安全性的要求远高于对外提供服务的电子政务外网如何在保障内网与专网资源安全的前提下构建便于公众使用的信息资源共享服务平台成为电子政务系统建设中的关键挑战。根据当时的相关规定“涉及国家秘密的计算机信息系统不得直接或间接与国际互联网或其他公共信息网络连接必须实行物理隔离”进一步明确了隔离要求的强制性。工作原理网闸根据工作方式分为两种1.数据单向传输模式单向传输模式只允许数据从一个方向传输到另一个方向阻止反向的数据流动。这种模式通常用于非常高安全级别的场景如从内网向外网发布数据但不允许外网对内网进行数据请求。2.数据双向传输模式双向传输模式允许数据在两个网络之间进行控制下的双向传输。在这种模式下网闸通常通过过滤、协议转换等方式确保传输的内容符合安全策略。主要类型根据不同的应用层次和数据处理方式网闸可分为以下几类1.应用层网闸应用层网闸工作在OSI模型的应用层它根据特定的应用协议如HTTP、FTP、SMTP等来解析、过滤和控制数据传输。应用层网闸能够识别应用协议中的安全威胁防止非法访问和攻击。适用场景企业邮件网关、应用系统之间的数据交互等。2.数据层网闸数据层网闸工作在较低的网络层次如传输层、网络层它对数据包的内容进行检查和过滤确保网络中的数据流量符合安全策略要求。适用场景如数据库同步、文件传输等场景保证数据的安全传输。3.安全隔离网闸安全隔离网闸是专门用于严格隔离不同安全级别网络的设备通常用于内网和外网之间的信息隔离。它不仅能控制数据流向还能防止恶意代码或攻击通过网络渗透。适用场景政府、军事机构等安全敏感领域防止数据泄露和网络入侵。对WebOffice的挑战这里说的WebOffice是通过Web技术实现的在线Office产品可以满足文档的在线编辑和多人协同编辑而且能够保证各方编辑过程中冲突的解决和最终结果的一致性。除此之外的伪WebOffice产品不在此列。目前主流的WebOffice类产品需要满足多人协同编辑这个场景实时、冲突解决、结果一致等。为保证实时性一般采用的是WebSocket通信有些做的比较好的考虑在弱网环境下的数据传输加入了WebRTC。降级的就是采用HTTP 长轮询或长连接这类方案来实现。一般产品从设计实现成本考虑只会支持一种模式要么WebSocket(外加WebRTC)要么HTTP很少有兼顾这两种模式。在网闸的数据双向传输模式下特别是应用层网闸对通信协议有特定要求如HTTP、FTP、SMTP等只采用WebSocket通信的WebOffice产品无法穿透网闸实现内外网通信解决方案文曲Office是前后端分离且重前端的产品形态主要采用WebSocket实现协同数据的实时传输同时保留HTTP长轮询方式以满足对协同实时性要求不高可以容忍几百毫秒延迟的需求场景。该项目中需要内外网协同编辑的文件和用户数相较于内网协同编辑要少为此要首先保证内网用户的使用体验同时兼顾纯外网用户之间、内外网两侧用户这两类协同编辑下数据的准实时性。文曲Office的两种通信协议刚好可以满足这类要求。具体方案是1.内网部署完整的文曲Office包括前端和服务端采用WebSocket协议2.外网仅部署文曲Office的前端并将协议设置为HTTP长轮询editorConfig: { customization: { // 将Websocket强制降级为长轮询true 开启 false 关闭 polling: true, }, }以上仅是部署方式和配置调整不涉及业务代码层面的改动上层应用对此无感知。世上没有完美的方案只有权衡利弊后能够解决当前问题的才是合适的方案 本方案也是。因为采用了长轮询会有以下问题但可以通过监控资源消耗及动态扩容等措施来做预防或应急服务器资源消耗大每个连接必须保持较长时间服务器需要维护大量的连接增加了资源消耗。高并发下可能导致性能瓶颈如果有大量客户端连接并保持长时间连接服务器可能会因为资源不足而产生性能瓶颈。当然也有其他的方案如通过文件同步的方式异步在内外网编辑但会涉及到文档内容一致性性问题可能需要做好版本管理用户体验不佳等问题。相关资源OnlyOffice最新版本镜像https://onlyoffice.moqisoft.com/docs/install/docker中国版本介绍https://onlyoffice.moqisoft.com/docs/product/summary技术交流183026419https://qm.qq.com/q/uMwFyL5Wn0
攻克网闸难题：我们如何实现内外网文档准实时协同编辑
发布时间：2026/7/15 15:21:22
之前的公检法项目中遇到要在网闸隔离的内外网之间实现文档的在线协同编辑。需求场景是内网有一篇Office文档需要在内网和外网进行多次编辑和修改在此过程中需要保证内外网编辑的是同一份文件而且任何一侧的修改要即时的同步给另一侧保证文档内容准实时一致性。这就需要有协同编辑能力的在线Office(WebOffice)来解决但在此之前客户选型了国内前三家的WebOffice产品限于其产品设计和通信机制都无法不大改的情况满足这类场景。最终选择我们团队提供的方案既可以满足内外网协同编辑的需要又可以防止外网编辑过程中内容被拷贝出去的风险见 构建安全内部剪切板内容复制管控与OnlyOffice优化实践确保了信息安全。以下结合实际项目的经验简单介绍在公检法、政府、军工、医疗、能源等关键行业和领域对隔离强要求的情况针对类似需求场景为大家提供一种解决思路。网闸是什么国内网闸市场的兴起可追溯至2000年。彼时随着政府信息化与电子政务系统建设进程加速在电子政务的内网、外网及专网之间实现信息交换成为一项基本需求。然而政府内网对安全性的要求远高于对外提供服务的电子政务外网如何在保障内网与专网资源安全的前提下构建便于公众使用的信息资源共享服务平台成为电子政务系统建设中的关键挑战。根据当时的相关规定“涉及国家秘密的计算机信息系统不得直接或间接与国际互联网或其他公共信息网络连接必须实行物理隔离”进一步明确了隔离要求的强制性。工作原理网闸根据工作方式分为两种1.数据单向传输模式单向传输模式只允许数据从一个方向传输到另一个方向阻止反向的数据流动。这种模式通常用于非常高安全级别的场景如从内网向外网发布数据但不允许外网对内网进行数据请求。2.数据双向传输模式双向传输模式允许数据在两个网络之间进行控制下的双向传输。在这种模式下网闸通常通过过滤、协议转换等方式确保传输的内容符合安全策略。主要类型根据不同的应用层次和数据处理方式网闸可分为以下几类1.应用层网闸应用层网闸工作在OSI模型的应用层它根据特定的应用协议如HTTP、FTP、SMTP等来解析、过滤和控制数据传输。应用层网闸能够识别应用协议中的安全威胁防止非法访问和攻击。适用场景企业邮件网关、应用系统之间的数据交互等。2.数据层网闸数据层网闸工作在较低的网络层次如传输层、网络层它对数据包的内容进行检查和过滤确保网络中的数据流量符合安全策略要求。适用场景如数据库同步、文件传输等场景保证数据的安全传输。3.安全隔离网闸安全隔离网闸是专门用于严格隔离不同安全级别网络的设备通常用于内网和外网之间的信息隔离。它不仅能控制数据流向还能防止恶意代码或攻击通过网络渗透。适用场景政府、军事机构等安全敏感领域防止数据泄露和网络入侵。对WebOffice的挑战这里说的WebOffice是通过Web技术实现的在线Office产品可以满足文档的在线编辑和多人协同编辑而且能够保证各方编辑过程中冲突的解决和最终结果的一致性。除此之外的伪WebOffice产品不在此列。目前主流的WebOffice类产品需要满足多人协同编辑这个场景实时、冲突解决、结果一致等。为保证实时性一般采用的是WebSocket通信有些做的比较好的考虑在弱网环境下的数据传输加入了WebRTC。降级的就是采用HTTP 长轮询或长连接这类方案来实现。一般产品从设计实现成本考虑只会支持一种模式要么WebSocket(外加WebRTC)要么HTTP很少有兼顾这两种模式。在网闸的数据双向传输模式下特别是应用层网闸对通信协议有特定要求如HTTP、FTP、SMTP等只采用WebSocket通信的WebOffice产品无法穿透网闸实现内外网通信解决方案文曲Office是前后端分离且重前端的产品形态主要采用WebSocket实现协同数据的实时传输同时保留HTTP长轮询方式以满足对协同实时性要求不高可以容忍几百毫秒延迟的需求场景。该项目中需要内外网协同编辑的文件和用户数相较于内网协同编辑要少为此要首先保证内网用户的使用体验同时兼顾纯外网用户之间、内外网两侧用户这两类协同编辑下数据的准实时性。文曲Office的两种通信协议刚好可以满足这类要求。具体方案是1.内网部署完整的文曲Office包括前端和服务端采用WebSocket协议2.外网仅部署文曲Office的前端并将协议设置为HTTP长轮询editorConfig: { customization: { // 将Websocket强制降级为长轮询true 开启 false 关闭 polling: true, }, }以上仅是部署方式和配置调整不涉及业务代码层面的改动上层应用对此无感知。世上没有完美的方案只有权衡利弊后能够解决当前问题的才是合适的方案 本方案也是。因为采用了长轮询会有以下问题但可以通过监控资源消耗及动态扩容等措施来做预防或应急服务器资源消耗大每个连接必须保持较长时间服务器需要维护大量的连接增加了资源消耗。高并发下可能导致性能瓶颈如果有大量客户端连接并保持长时间连接服务器可能会因为资源不足而产生性能瓶颈。当然也有其他的方案如通过文件同步的方式异步在内外网编辑但会涉及到文档内容一致性性问题可能需要做好版本管理用户体验不佳等问题。相关资源OnlyOffice最新版本镜像https://onlyoffice.moqisoft.com/docs/install/docker中国版本介绍https://onlyoffice.moqisoft.com/docs/product/summary技术交流183026419https://qm.qq.com/q/uMwFyL5Wn0
