之前的公检法项目中遇到要在网闸隔离的内外网之间实现文档的在线协同编辑。需求场景是内网有一篇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
技术交流：183026419（https://qm.qq.com/q/uMwFyL5Wn0）
