企业官网建设流程全解析

简介：《云视通网络视频监控解决方案.doc》是一份面向安防监控与网络工程领域的技术方案文档，针对复杂网络环境下远程监控连接困难、公网IP不固定或无公网IP等常见问题，提供了一种只需申请云视通号码即可完成远程连接的方案。资源为单个Word文档，仅238KB，便于快速查阅与分发。文档重点阐述了云视通融合P2P与CDN的传输机制，在P2P无法接通时自动转为CDN全网转发，并结合部署于运营商关键节点的CDN服务器、BGP协议和底层UDP穿透技术，保障跨运营商传输及“大局域网”访问的稳定高效；同时介绍了监控主机上的云视通号码申请、通道分配、启用步骤，以及客户端通过局域网或广域网进行远程监控的设置方法，还给出了修改默认用户名、密码等网络安全建议。对于安防监控项目的方案设计、设备选型和技术答疑具有实用参考价值，目前已有109人学习浏览。

1. 云视通网络视频监控方案的定位：不固定公网 IP 也能远程看图

干过安防工程的人应该都有这种经历：现场网络是 ADSL 拨号，或者整栋楼共用一条企业专线，公网 IP 要么不固定、要么压根没有，可甲方偏偏要求门店视频在办公室和手机上随时能调看。传统做法是动态域名加端口映射，碰上运营商级别的 NAT 直接失效，光调路由器就能耗掉大半天，换个网络环境又得从头再来。云视通这类网络视频监控方案解决的核心问题就在这里：它把远程连接涉及的 IP 地址、端口映射、域名解析全部封装掉，主机端申请一个云视通号码，分控端填同一个号码，链路就建立起来了。下面按这份《云视通网络视频监控解决方案》文档，拆一下传输机制、主机端配置、分控端连接方式，以及交付时容易踩的坑。

2. 传输机制拆解：P2P 优先、CDN 兜底、UDP 打洞，三级链路怎么配合

远程监控这类应用，判断方案好不好用，第一看连通率，第二看传输速度。云视通在这两项上做了双链路设计：优先走 P2P 直连，直连失败自动切 CDN 转发，底层用自研的 UDP 打洞模块做 NAT 穿越。这一章把这三层机制讲清楚，后面调故障才知道问题出在哪一段。

2.1 从安防全球通到云视通：升级到底改了什么

云视通是安防全球通的升级版，文档里有一句话值得注意：「虽说是升级，但软件上的传输机制，以及服务器的部署都采用了完全不一样的技术」。意思是，这不是在旧架构上打补丁，而是把底层连接逻辑换掉了。老产品主要依赖服务器做信令交换后建立 P2P 直连，一旦两端 NAT 环境不友好，连通率就上不去；云视通则在保留 P2P 的同时，加入了一整套 CDN 转发节点作为备用通道。

文档给了两个指标：连通率和传输速度「整体提升一倍」。这个数字在实际工程里不能当绝对值去验收，但方向上是对的——连通率提升来自双链路兜底，速度提升来自就近取流，而不是网速真能翻倍。理解这一点，后面调画面卡顿的时候，就知道该往哪一段链路去查。

P2P 和 CDN 的关系在监控行业里经常被误解。做网站的人提到 CDN 想到的是缓存静态资源、加速网页打开；监控里的 CDN 转发不是缓存视频内容，实时视频没法等它缓存完再播。CDN 在这里做的是把视频流从主控端转发到离分控端最近的节点，再由节点把流推给分控端。这个区别在第 2.3 节展开。

2.2 P2P 直连与 CDN 转发的切换逻辑：什么时候走哪条路

连接建立时，系统优先尝试 P2P。原理不复杂：主控端和分控端都在私网里时，两端先向云视通服务器上报自己公网侧的映射地址和端口，服务器把两端的映射信息互换，两端再直接互发 UDP 包尝试打通。云视通说的「底层 UDP 打洞技术」，就是把打洞动作放在传输层模块里静默完成，应用程序不需要干预，用户也感知不到这个过程。

打洞能不能成功，很大程度取决于两端的 NAT 类型。全锥形 NAT 对打洞最友好，两端只要有一方是全锥形，基本能通；对称型 NAT 每次对外映射的端口都不同，打洞难度最大。工程里没有工具直接看 NAT 类型时，观察行为就够了：本地能上外网、能看视频网站，但云视通 P2P 就是不通，大概率是对称 NAT，这种情况直接指望 CDN 转发兜底，不用纠结为什么打洞失败。

打洞失败后，软件会在几秒内自动切换成 CDN 转发，不需要人工干预。两种模式的差异可以用一张表对比：

实际工程里不用记触发条件，记住结论：P2P 通了画质最好，P2P 不通系统自动降级到转发。但有个前提——主机端和分控端的云视通功能都得是启用状态，任一端关掉，这套双链路逻辑就不成立。

2.3 服务器部署与 BGP 路由表：为什么说就近取流是关键

云视通的服务器部署在各大运营商的关键节点托管机房，多用多线服务器，通过路由器用 BGP 协议和运营商的路由设备共享路由表。这堆概念翻译成一句大白话：节点机房同时接了电信、联通、移动的带宽，并且对外宣告「我这里有这段路由」，各运营商过来的访问都能就近落在这个机房，不需要绕到别的运营商网内去。

BGP 在安防方案里出现频率不高，很多人听到就觉得是高端路由协议，实际作用很朴素。多线机房如果不做 BGP，就得靠技术员手工配策略路由：电信的流量走电信线、联通的走联通线，配置量随线路数量指数上升。用 BGP 共享路由表之后，系统自动根据前缀来源选择出口线路，跨运营商访问的延迟会明显降下来。

这里要澄清一个容易混淆的点：网站 CDN 缓存的是静态文件，云视通的 CDN 节点转发的是实时码流，节点只中转不落盘。所以不存在「视频要等节点缓存完才能播」的说法，切到 CDN 转发后画面是连续出来的，只是延迟比 P2P 略高一点点。

云视通解决大规模内网环境远程访问，靠的就是这套节点部署。公网路由不可达的区域，运营商内部的节点是可达的，云视通把视频流推送到内网用户就近可达的节点，分控端从节点取流，绕开了「公网不可达」的死结。文档里承诺「不会出现由于一台机器 DOWN 掉而造成的全网瘫痪」，单节点故障时取流请求会被调度到同区域其他节点，这就是服务器集群冗余的实际意义。工程上不必纠结承诺的绝对性，但节点冗余设计确实让远程连接的可靠性比单点服务器方案高一个量级。

一套链路要跑得稳，实际上是「UDP 打洞 + CDN 转发 + 服务器调度」三个环节同时工作。打洞负责快，CDN 负责兜底，服务器负责分配合适的就近节点。判断云视通好不好用，就看这三个环节是否都正常，第 5 章会给出一个不依赖客户端日志的验证方法。

3. 监控主机端配置：申请云视通号码、绑定通道与网络权限加固

主机端是整个方案的源头，所有远程连接都从这台机器发起。配置集中在「网络服务」功能页里，整个操作链路不长，但号码申请、通道绑定、权限修改的顺序不能乱。下面按文档给的操作路径走一遍，每个步骤说明为什么这么做。

3.1 主机端开启云视通的完整步骤：从登录到号码绑定

配置前先确认三件事：监控主机已接入互联网并能正常出图、系统时间与实际时间一致、网络服务功能可用。第三点容易被忽略，有些项目现场防火墙只放行了 80 和 443 端口，云视通握手端口没放行，后续申请号码会一直失败。

第一步，在监控主机上运行中维数字监控系统，用默认用户名 abc、密码 123 登录主界面。注意，abc/123 只是首次登录的默认凭据，后面必须改，原因在 3.3 讲。

第二步，在主界面下部功能区点击「网络服务」，打开云视通设置对话框。所有和远程连接相关的选项都在这个界面里，号码申请、通道勾选、启用状态都在这里管理。

第三步，点击「申请号码」按钮，软件自动向云视通服务器申请一个号码，并自动分配到当前主机的通道上。这个号码是后台分配的，不是你手动起的，所以别想着填一个好记的号码，也不需要记 IP。

第四步，号码绑定通道后，勾选对应的通道；通道多的时候用右下角的「全选择」按钮，一次勾选全部，省得一个一个点。

第五步，确定设置。到这一步，主机端云视通功能就启用了。

提示：申请号码时主机必须能正常访问云视通服务器。如果点击申请后长时间无响应，先检查主机能否访问外网、DNS 是否配置正确，再检查防火墙是否放行云视通通信端口。很多申请失败的案例，最后都查出来是网络层被拦了。

3.2 云视通号码的唯一性与通道分配规则：8 路卡为什么只生成一个号

云视通号码的分配规则和很多人想的不一样。文档里写得很明确：一张板卡对应一个云视通号码，号码一旦申请成功就不能修改，唯一性和终身性都是相对这张板卡而言。

以 8 路卡为例：主机上插一张 8 路卡，打开云视通功能界面后会看到 8 个有效通道。点一次申请，软件只生成一个号码，这 8 路通道共用这一个号码。分控端填这个号码，看到的是这一台主机的全部 8 路画面，不是单路。这一点经常造成误会，有人以为每路通道各要一个号码，结果发现申请一次只出一个号，以为软件坏了，其实设计就是如此。

如果项目里有多个前端主机，比如一个仓库装了两台主机，那就每台主机各申请一个号码，分控端在云视通号码列表里分别添加这两个号码，按主机维度去连接。

再补充一个工程经验：文档提到「如果网络状况不理想，可能出现某一路或多路通道无法分配到云视通号，可以重新点击『申请号码』按钮重新申请」。我遇到这类情况，一般是主机刚上电、网络模块还没完全就绪，等两分钟再点申请基本能成。另外申请号码前先确认主机时间准确，云视通握手有有效期校验，时间偏差超过几分钟，号码可能申请成功，但后续连接会频繁掉线，看起来像网络问题，实际是时间戳对不上。

3.3 网络用户名与密码加固：默认 abc/123 必须改的三个原因

云视通号码一旦申请就不能改，等于这台主机的远程入口是公开可见的。所以云视通的认证设计是用户名、密码、云视通号三者同时验证，号码固定不变，密码就成了最后一道门。默认 abc/123 不改，至少有三个实际风险。

第一，这个默认凭据是公开的。做过中维设备的同行都知道初始账号密码是什么，号码如果被扫到，画面等于直接暴露。第二，文档里明确写了「此默认用户与分控登录用户名及密码相同，容易泄漏」——默认的 abc/123 既用于本地操作，也用于远程登录，不改的话，拿到号码的人就能用同一套账号直接看你的监控。第三，监控主机是 7×24 小时在线设备，弱密码被扫描的时间窗口比普通软件长得多，不是用完就关的应用。

操作路径是：主控界面 [系统设置] → [用户管理] 功能页，修改默认用户或新建用户，并勾选相应的网络权限。这里建议按角色拆账号：

这套做法在交付时特别好用：给甲方的账号只留远程预览权限，没有录像回放和系统设置权限，即使账号密码被转给别人，也动不了主机配置。我自己做交付时，本地维护账号和远程分控账号一定分开，后面第 4 章有个故障案例就和这个操作直接相关。

4. 分控客户端连接与排查：局域网、广域网两种模式的配置差异与常见故障

主机端配置完成后，真正的坑大都出现在分控端。分控软件是中维云视通数字分控系统，连接方式分局域网和广域网两种，先分清这两条路，故障排查就完成了一半。

4.1 局域网连接与广域网连接：两种填法不能混

局域网连接的操作是：分控端打开系统设置，勾选「使用域名或 IP 连接」，填入主控端机器的局域网 IP 地址，在对应窗口上点击右键「连接本窗口」，画面就开始传输。这个模式适用于监控中心和前端在同一局域网，比如门店和办公室在同一栋楼，走内网直连，延迟最低。

广域网连接的操作是：分控端在系统设置里选择「云视通号码」方式，填入主控端申请的云视通号码，保存后连接。这个模式适用于跨公网场景，不管主控端是 ADSL 拨号、专线上网还是没有公网 IP，只要号码有效就能连。

最容易翻车的情况有两类：一类是分控端和主机明明在同一个局域网，却用云视通号码连接。不是不能通，而是多绕了一次云视通服务器，延迟和带宽占用都划不来。另一类是跨公网时填了主控端的内网 IP，比如 192.168 开头的地址，公网路由根本到不了那个私有地址，结果就是一直连接失败。

提示：两种连接方式切换后，要重新点击「连接本窗口」触发重连。只改设置不重连，界面会一直保持旧连接状态，看起来像没生效。

4.2 故障一：号码申请了但某一路通道一直分配不到

现象：主机上申请号码成功，但「网络服务」界面里 8 路通道中某一路或某几路没有绑定到云视通号，勾选框灰色不可选。

原因：文档里的说法是网络状况不理想时，通道与服务器之间的握手不完整；我实际遇到的情况还包括主机刚开机、网络模块还没就绪就急着点申请，通道还没来得及注册上去。

解决：等网络完全稳定后，重新点击「申请号码」，软件会为缺失的通道补偿申请并绑定。重复申请不会产生多个号码——号码与板卡绑定，重复申请只是补齐缺漏的通道。如果重试三次仍然缺通道，重点检查主机 DNS 和外网连通性，再不行就重启监控软件后重新申请。

4.3 故障二：分控端填入号码后长时间卡在「连接中」

现象：广域网模式下填入云视通号码，界面长时间显示「连接中」，最后提示连接失败。

原因：连接建立时先尝试 P2P 打洞，这个过程本身要几秒；打洞失败后切换到 CDN 转发，切换还要再握手一次。如果两端网络都比较复杂，整个流程可能持续十几秒。用户误以为卡死，反复点连接，反而打断了正在进行的切换流程。

解决：第一次连接时耐心等 30 秒以上，让系统完成打洞失败判定并走转发链路。仍然失败就去主机端确认云视通是否处于启用状态、主机外网是否可达。常见做法是在主机端 ping 云视通服务器域名，能 ping 通但连接失败，多数是防火墙策略挡住了云视通端口，放行后重新连接一般就好。

这个故障在设计上有个不透明的地方：客户端在「连接中」状态时，不会显示当前是正在打洞还是正在切换转发，用户只能靠等待来判断。理解了这一点，就不会去反复点连接了。

4.4 故障三：多路同时查看时画面卡顿、延迟增大

现象：单路画面流畅，分控端同时打开 4 路以上时，画面延迟明显增大，马赛克和花屏变多。

原因：P2P 直连模式占用主控端上行带宽，转发模式路径更长且共享节点带宽。前端主机的上行带宽是有限的，多路取流一旦超出上行承载能力，画面就会卡。另一种常见情况是码流参数没调，默认画质偏高，远程预览根本不需要那么大的码流。

解决：远程预览降低码流标准。在主机端按通道调整子码流或降低分辨率，常见做法是远程预览用 720P 或 D1 分辨率、帧率 15 以下。画面会稍微糊一点，但流畅度优先，本地录像保持原画质，用双码流设置可以同时满足两端需求。多路同时查看时，还要看主机端上行带宽的支撑能力：

判断瓶颈在哪一段有个土办法：在主机端打开任务管理器看网络占用。如果远程预览时上行几乎跑满，就是上行带宽不够，降低子码流即可；如果主机上行没满但分控端还是卡，瓶颈可能出在节点转发或者分控端下行，这时候换一条网络再试就能区分开来。

4.5 故障四：改了密码后分控端忘了同步，反复提示认证失败

现象：主机端改了网络用户名或密码，分控端连接几秒后提示认证失败，或者弹密码框一直过不去。

原因：云视通采用用户名、密码、云视通号三重验证，任何一项对不上都失败。多数情况是改密码后分控端还保存着旧凭据。少数情况是现场有多个分控端，办公室一台、手机一台、甲方电脑一台，只改了一个，其他没同步。

解决：到每个分控端的系统设置里重新填写用户名和对应密码，保存后重连。然后把「修改密码后同步所有分控端」写进变更流程，尤其交接给甲方之后，改密码要提前通知到每一个使用端。

如果忘记密码，主机端画面还在但远程进不去，恢复办法是接本地显示器，用 admin 权限在用户管理里重置。所以前面强调本地维护账号不要给网络权限——就是给这种场景留后悔药，即使远程账号出问题，本地维护通道始终是干净的。

5. 交付前的验证方法：五分钟确认云视通链路正常

5.1 判断链路走的是 P2P 还是 CDN 转发

云视通客户端不显示当前走的是哪条链路，但可以靠网络连接状态判断。在分控端电脑上打开命令提示符，用一条命令就能看出端倪：

:: Windows 下查看与视频传输相关的活动连接 netstat -ano | findstr ESTABLISHED :: 如果连接很多，按端口过滤视频传输连接（常见视频端口范围） netstat -ano | findstr :8000

逻辑说明：ESTABLISHED 状态的连接里，远端地址如果是主控端所在的公网 IP，说明走的是 P2P 直连；如果远端是一堆不认识的陌生 IP，多半走了 CDN 转发节点。要确认主控端的公网出口 IP，在主机端打开网页搜索「本机 IP」，显示的地址和 netstat 里的远端地址对得上，就是直连。

参数说明：findstr 是 Windows 下的文本过滤命令，作用类似 Linux 的 grep。不记得视频端口就只跑第一句，把连接数多的远端 IP 挑出来对照就行。这条验证不依赖云视通客户端日志，对任何远程监控方案都适用。

5.2 交付前检查清单

做完配置别急着走，按这套清单过一遍：默认密码是否已修改、远程账号是否只给了最小权限；云视通号码对应的通道是否全部勾选启用；分控端每个使用点是否已添加号码并实际连接成功；用不同运营商网络各测一次，电信、移动、联通各找一台机器试连；多路画面同时预览是否有卡顿，卡就按 4.4 的方式降码流。

从那次远程账号密码没同步、半夜接到甲方电话之后，我每次做远程监控交付，都强制把上面这套流程完整走一遍，再叫甲方验收。密码同步、码流参数、两种连接方式的分工，这三件事宁可提前查三遍，也不要等上线了再补救。希望帮到你。

本文还有配套的精品资源，点击获取