一種實現在線視頻監控業務聯網共享的系統架構設計

鄧黃燕， 周 迪

（浙江宇視科技有限公司，浙江 杭州 310053）

0 引言

為有效維護社會穩定，構建和諧生活環境，平安城市建設一直是政府和公眾持續關注的熱門話題。 平安城市建設首先要滿足治安管理和社會安全防控的需求。 當前社會是一個人、財、物大流動的社會，社會面的信息千變萬化，極大地增加了公安機關管理社會的難度， 傳統治安管理和社會防控的方法和手段已很難滿足當前的工作要求。 而平安城市充分利用現代信息通信技術， 結合音視頻、智能、大數據的應用，達到了指揮統一、反應及時、作戰有效的目的。

然而，由于缺乏前期的統籌規劃，各單位根據自己的業務需求積極快速地部署了大量視頻監控系統。這些獨立運行的系統在有效發揮其最初規劃的功能的同時，也為聯網應用、數據共享造成了障礙。而聯網應用和數據共享是視頻監控系統及其數據價值獲得進一步質的提升的關鍵基礎。 為此，2015 年，國家發改委等九部委聯合發布了《關于加強公共安全視頻監控建設聯網應用工作的若干意見》，要求到2020 年基本實現“四個全”目標，分別為：全域覆蓋，即實現重點公共區域及重點行業、領域的重要部位100% 視頻監控覆蓋； 全網共享，即實現重點公共區域及重點行業、領域的涉及公共區域的視頻圖像資源100%聯網共享；全時可用，即實現重點公共區域安裝的視頻監控攝像機完好率達到98%，重點行業、領域的涉及公共區域的監控攝像機完好率達到95%；全程可控，即公共安全視頻監控系統聯網應用實現分層安全體系建設，保證重要視頻圖像信息不失控、敏感信息不泄露。

在視頻圖像信息聯網建設的過程中，如何實現數量巨大的、 存在IP 地址沖突的在線應用平臺無縫地互聯和共享，成為關乎視頻圖像信息整合與共享成敗的關鍵。

1 在線視頻監控業務聯網共享存在的問題

1.1 問題描述

1.1.1 平臺聯網擴展難

當前國內各級政府機關和事業單位的大型視頻監控系統建設大多遵從國家標準《GB/T 28181-2011 公共安全視頻監控聯網系統信息傳輸、交換、控制技術要求》，標準的最新版本為《GB/T 28181-2016 公共安全視頻監控聯網系統信息傳輸、交換、控制技術要求》，以下簡稱“GB/T 28181 標準”。

GB/T 28181 標準中平臺之間的對接需要進行域間互聯的注冊，從而形成鄰居關系。 但是鄰居關系的信令維護需要消耗平臺資源，通常一個平臺的鄰居數量規格在幾十到幾千。 顯然，巨量的平臺一旦實現兩兩互聯， 很多平臺將無法支撐鄰居關系，從而造成系統性能的障礙。

GB/T 28181 標準中平臺之間建立互聯， 需要管理員進行手動配置和維護。然而，大量的平臺進行兩兩互聯， 其配置和維護的工作量將非常巨大。 例如，1000 個平臺實現互聯， 管理員需要在每個平臺上進行關于其他999 個平臺的鄰居關系配置， 并將需要對499500 對鄰居關系進行維護。如此巨大的工作量是不可接受的，從而造成配置維護的障礙。

系統性能的障礙和配置維護的障礙屬于平臺聯網的擴展性困難。

1.1.2 在線業務無縫遷移難

目前公安視頻專網大量運行著基于GB/T 28181 標準的級聯模式的業務平臺。 這種模式下，上級域平臺可以調閱下級域平臺所管轄的視頻資源，但下級域無法調閱上級域和平級單位的視頻資源， 必須通過申請上級平臺的賬號權限以達到目的。 如此，業務執行的實時性和重要數據的對接融合便無法實現，從而造成業務融合對接的障礙。

將上下級域的級聯模式修改為平級域之間的互聯模式，確實可以在一定范圍內實現各平臺之間的聯網共享。 但是，基于GB/T 28181 標準平臺的重新配置改造，必定導致在線業務的中斷，影響該時間段內重要任務的執行。 這是在線系統平滑切換的障礙。

業務融合對接的障礙和在線系統平滑切換的障礙屬于無縫遷移的困難。

1.1.3 聯網的地址沖突解決難

由于歷史上各單位采取獨立的IT 設施規劃和建設的策略，IP 地址的沖突在所難免。如今若為了聯網而進行IP 地址的重新規劃和實施將是一項十分浩大的工程。 采用NAT （Network Address Translation，網絡地址轉換）設備進行隔離，并通過NAT 進行互聯，是一個常見的方案，但NAT 聯網也會遇到不少問題。

第一，IP 報文穿過NAT 設備后其源IP 地址或目的IP 地址會發生改變， 而其承載的消息體所包含的IP 信息不會發生改變， 這種不一致會導致某些業務無法交互。 例如，處于私網的服務器將私網服務地址包含在消息中告訴公網的訪問者，訪問者顯然無法訪問這個服務地址。 于是，相關的業務流程必須針對各種組網做出特殊而復雜的設計。

第二， 如果NAT 私網存在多個需要被公網設備訪問的服務器， 就必須在NAT 設備上為這些服務器分別配置公網IP，這會消耗很多公網IP 地址。雖然有時也可以通過配置“地址+端口” 映射來實現，但由于不同的業務使用不同的端口號，就需要管理員遍歷所有的業務類型， 配置大量的映射，維護工作量很大。

第三，中心控制服務器在某些情況下可以判斷出交互的雙方誰處于NAT 私網、誰處于公網，從而通知內網的設備主動向外網設備發起連接。這就要求每個會話都實現兩種以上的處理流程。對于一個包含了多個會話行為的業務流程來說，這種組合會非常復雜；況且某些標準業務也不允許交互的雙方顛倒C/S 的角色，例如HTTP 請求，不可能讓WEB服務器主動向WEB 客戶發起TCP 連接。

第四， 防火墻作為一個企業網絡的安全保障，其職責之重不言而喻，當存在多個被訪問的服務處于防火墻內側時， 就需要防火墻開放相當數量的UDP/TCP 端口，如此便會給內網帶來安全隱患。

1.1.4 異構系統共享對接難

GB/T 28181 標準發布之前， 視頻監控系統已經在各個單位獲得了大量的應用。這些系統遵從著不同的地方標準、 行業標準和企業標準， 很多與GB/T 28181 標準并不兼容。 現有視頻監控系統的標準不統一給聯網共享帶來了協議交互的障礙。

《關于加強公共安全視頻監控建設聯網應用工作的若干意見》同時要求：依托公安視頻圖像專網，以公安視頻圖像共享平臺為核心，分級有效整合各類視頻圖像資源，逐步對接社會面視頻資源，最大限度實現公共區域視頻圖像資源的全網聯網共享。社會面視頻資源采用的標準更是五花八門，不一而足，甚至根本沒有標準。

如何實現這些異構系統與GB/T 28181 標準平臺的便利靈活地對接， 是一個需要仔細研究的課題。

1.2 傳統的主要解決方法及不足之處

針對系統性能的障礙，一個常用的解決方案是集群或堆疊。 集群和堆疊可以節省前期投資，根據業務增長累加投資， 是一個總擁有成本TCO（Total Cost of Ownership）比較理想的方案。 針對配置維護的障礙， 或許可以單獨設計一種自動發現的機制，但目前GB/T 28181 標準中并沒有這方面的考慮。無論如何，這些方案均需要升級系統，對在線業務造成影響。

針對業務融合對接的障礙，一個解決方案是在上級域平臺分類分級開設賬號，并實施合適的權限管控。 不過，一個系統的在線用戶數量通常存在限制，受制于平臺的硬件性能。而在線系統平滑切換，依靠GB/T 28181 標準的平臺自身是無法實現的。

異構方案的對接，常用的方案是基于其中一方的業務SDK 調用， 或采用第三方網關進行業務轉換。 但若要同時解決前面的幾個問題， 單純采用SDK 和轉換網關顯然無能為力。

解決NAT 穿越的問題，當前的主要方法[8]包括應用層網關ALG （Application Layer Gateways）、隧道技術、Hole Punching 方案、STUN 協議、TURN 協議、Full Proxy 方 法、Middlebox Communications（MidCom）協議等。 ALG 方案[9]組網部署最簡單，但對NAT/Firewall 有特殊要求，要求其識別應用層信息，并修改內部字段，每增加一種應用都需對NAT/Firewall 做版本升級。 隧道技術[10]簡潔方便，但隧道兩端的網絡很可能存在地址規劃沖突，需要對兩端網絡做IP 地址規劃更改。Hole Punching[11]、STUN[12]、TURN[13]、Full Proxy 等協議各有特點，但均要求在外網部署一臺服務器。 MidCom[14]協議要求可信的第三方組件對應用信息進行識別并對NAT/Firewall 進行控制。

上述傳統的解決方案各有特點，但均無法完成現存的大量視頻監控系統的無縫平滑地聯網共享。因此，我們期望從第三方網關入手，設計一套能靈活適應各種NAT 網絡環境、允許IP 地址存在規劃沖突、實現異構業務無縫對接，并具有良好擴展性的架構。

2 基于虛擬地址空間的共享架構設計

為統一解決上述難題，本文設計并實踐了一種基于虛擬地址空間的共享架構。在每個平臺旁邊部署一個共享網關（后文簡稱“網關”）；網關之間建立一個虛擬的、不與外部路由的地址空間，并由業務觸發， 按需在網關之間建立GB/T 28181 標準的平級域互聯；網關與平臺之間采用平臺所支持的協議進行平級域互聯， 例如GB/T 28181 標準或其他地方標準、行業標準、企業標準等。最終實現各視頻監控系統之間的無縫共享聯網。

2.1 基本原理

為便于描述虛擬地址空間共享架構的基本原理，我們將聯網模型簡化為兩個域間的廣域互聯。

如圖1 所示是一個比較常見的城市監控系統互聯模型。 監控中心網絡（這里稱為“總部”）處于NAT/Firewall 的內網，分支網絡（這里稱為“分部”）處于另一個NAT/Firewall 的內網，分別租用運營商的網絡接入公網。 公網不允許部署任何監控設備。

圖1 城市監控系統互聯模型架構原理圖Figure 1 Schematic diagram of the interconnection model architecture of the city monitoring system

總部和分部分別擁有自己完整的監控系統，總部與分部之間建立平級域互聯。我們讓總部的數據轉發服務器（MS）兼任中繼（Relay），總部的防火墻為Relay 配置一個IP/端口映射，以便讓分部的VM（視頻監控系統管理平臺）和MS 能向Relay 建立虛通道；總部的VM 也向Relay 建立虛通道。 這些虛通道形成了虛擬地址空間。 Relay 為總部的VM、分部的VM 和MS 分別分配不同的虛地址，于是兩臺VM 和兩臺MS 分別各自擁有了兩個IP 地址，一個為本身真實的IP 地址， 另一個為分配的虛IP 地址。 每個域內的終端或客戶端與它們的VM 和MS交互時采用真實的IP 地址；總部的VM 和MS 與分部的VM 和MS 交互時采用虛地址，通過虛通道進行報文的傳輸。

我們以視頻實況點播業務為例描述整個流程。假設總部的客戶端（Client）要點播分部的終端：總部Client 向本域VM 發起申請；總部VM 通過虛通道向分部VM 發起指令；分部VM 指示前端發送視頻流， 目的地址為分部MS 的真實IP 地址； 分部MS 將視頻流封裝進虛擬地址空間轉發給總部MS；總部MS 將視頻流解封裝后轉發給本地的Client。

為提高可靠性和系統整體的業務性能，可以設計多中繼以實現中繼的主備機制或負載分擔機制。

監控業務使用虛擬地址空間中的虛擬IP 地址進行封裝， 并作為虛通道承載報文的應用層信息進行傳送。如此，承載報文在穿越NAT、防火墻、網閘時所發生的任何IP 頭部的改變都不會影響監控業務。

虛通道提供的這個虛擬地址空間純粹是一個應用層信息， 僅為虛擬地址空間兩端的設備所理解，不與網絡設備進行路由交互，也就規避了兩邊私網地址規劃沖突的問題。 即使沒有NAT 設備進行隔離， 只要保證兩邊的VM 和MS 服務器可與Relay 進行正常互通，這個模型同樣適用。

2.2 系統設計

借助上述簡化模型的原理，我們可以利用下述模型解決共享聯網遇到的所有問題。

我們以常見的多級聯網模型為例，如圖2 所示為系統設計圖。 每個聯網單元（即實際的視頻監控平臺）配置一個共享網關，網關利用聯網單元支持的互聯協議與聯網單元進行對接，建立平級域的互聯。

圖2 基于虛擬地址空間的共享架構系統設計圖Figure 2 Design of shared Architecture system based on Virtual address space

第一，網關之間建立虛擬地址空間。 除了最下面一級聯網單元的網關，其他級的網關兼任其下級網關的Relay。 每個下級網關均向自己的上級網關建立虛通道，每個上級網關均向自己的下級網關分配虛擬地址塊，同時自己保留一個虛擬地址。如此，網關之間形成了一個虛擬地址空間，而網關與聯網單元之間則采用實際地址進行對接。聯網單元除了新增與網關的平級域互聯之外，沒有做任何的改動。

第二，單位和網關地址對應關系的傳播。 網關一旦獲得虛擬地址，即定期向外廣播自己所屬單位和虛擬地址的綁定關系，以便于虛擬地址空間內的網關都可以獲知各單位及其網關地址的綁定關系。

第三，人機界面設計。 資源請求方式雖然可以多樣，但基于地圖的可視化交互更為直觀。 若某個用戶需要其他單位一定地理范圍內的攝像機資源，他只需在地圖界面上畫個范圍即可，Client 主機便知道用戶想要的攝像機資源的集合。

第四， 業務交互。 當某個聯網單元所屬的Client 想要獲取其他單位的攝像機資源信息并進行點播，Client 可以在地圖界面上畫個范圍；Client所屬的VM 平臺即向自己的共享網關發起請求，內含地理范圍包含的單位信息和攝像機信息；該網關根據單位信息找到對應的網關，向該網關申請建立平級域互聯，并申請相關攝像機資源；對方單位的網關向它的VM 轉發請求。 當回復層層回遞后，Client 即可點播相關攝像機的視頻。

第五，權限管理。為了安全起見，視頻監控系統的共享資源可以進行分類： 不受限資源和受限資源。 前者經過上級審批即可在全網傳播，后者必須由上級指定特定的接收者。每個上級只能審批自己權限內的下屬和自己的資源，審批后的資源也只能在自己轄區內共享傳播。 當某個網關收到請求，在回復資源之前，必須將該請求的摘要上送上級平臺審批。 審批通過之后，才可以進行回復。

第六，異構處理。共享網關負責實現與各現有平臺的互聯對接， 所以各個平臺無需關心其他平臺的標準執行狀況。 共享網關負責采用異構平臺的協議實現與異構平臺的對接，從而實現異構特征的屏蔽。

3 試驗驗證分析

考慮到多級和兩級的運行原理相同，本文以兩級聯網單元和對應的兩級共享網關進行試驗。兩個共享網關需要其中一方作為服務端（試驗環境中稱為UAG），另一方作為客戶端，本試驗選擇上級共享網關為服務端UAG，本級共享網關為客戶端。

如圖3 所示是服務端UAG 的配置界面。 啟動UAG 服務器， 設定虛擬地址空間的網絡地址段為10.110.0.0/16；啟動DHCP 服務，動態分配的地址段為10.110.0.1～10.110.236.114。 其中UAG 服務器在虛擬地址空間中的IP 地址為10.110.255.251，分配給本級聯網單元VM 服務器的虛擬地址為192.168.104.100。

圖3 上級共享網關的服務端UAG 配置界面Figure 3 The server UAG configuration interface of the upper-level shared gateway

撥號成功后，開始逐項檢查撥號連通性：

第一，打開cmd 使用route print 確認路由已經正常下發， 如192.168.104.0 255.255.255.0 下一跳為10.110.255.251。

第二， 檢查確定能夠ping 通網關IP∶10.110.255.251。

第三，檢查確定能夠ping 通UAG 服務器虛擬地址∶10.110.255.251。

第四， 檢查確定能夠ping 通VM 服務器IP 地址：192.168.104.100。

然后，兩級聯網單元均以平級域的方式連接各自的網關。至此，雙方均可以看到對方共享的資源，可根據需要點播預覽和回放對方的視頻資源。

如圖4 所示，本級共享網關作為客戶端向服務端撥號連接。其中，202.8.101.101 為服務端UAG 的實際IP 地址；5555 為服務端UAG 的協議連接的端口號。

圖4 本級共享網關的客戶端撥號界面Figure 4 Client dial interface of shared gateway

經過試驗系統的測試驗證， 基于虛擬地址空間的架構可以有效地解決共享聯網所遇到的所有問題。

3.1 消除了擴展性難題

試驗系統里的共享網關相互之間默認不建立平級域的互聯，只在業務需要時才自動地建立臨時互聯，業務結束則斷開互聯。 從而規避了n*n 的兩兩互聯所帶來的巨大壓力，消除了系統性能的障礙。

試驗系統采用了基于單位和地址綁定關系的廣播機制， 各單位管理員無需手動建立己方單位平臺與其他各個單位平臺的平級域互聯， 只需維護己方共享網關與己方單位平臺之間的一個平級域互聯，總體工作量從n*n 降低至n； 而且只是一次性的投入， 任何單位無需因為其他單位新增聯網單元而增加本單位的維護投入，從而消除了維護配置的障礙。

3.2 實現了無縫融合

在共享網關與業務平臺建立平級域互聯的過程中，以及在共享網關之間建立動態的平級域互聯過程中，各業務平臺原先的在線業務未出現中斷，視頻流暢無卡頓，實現了業務系統的平滑無縫聯網。

當業務平臺的客戶需要調閱其他平級單位的資源，通過地圖界面圈定地理范圍，對應的攝像機點位便出現在界面上， 通過點擊可以實現實況視頻的調閱，而無需登錄上級平臺，實現了業務的平滑融合。

3.3 消除了NAT 和異構帶來的問題

試驗系統中，三個待聯網的平臺及其共享網關分別處于三個不同的私網，其中一個平臺為非GB/T 28181 的異構平臺。它們通過各自的NAT 防火墻聯入互聯網。

由于虛擬地址空間在監控業務與承載網絡之間實現了通用的適配層， 對上屏蔽網絡的特征，使得監控業務不受網絡拓撲的干擾；對下屏蔽業務特征， 使網絡傳輸不必針對監控業務進行定制化部署，所以很順利地實現了聯網互通，不用修改業務流程，公網也無需增加任何設備，無需新購公網IP。

雖然兩個私網的地址規劃存在沖突，但虛擬地址空間隔離了各個私網的地址空間，所以無需做任何地址的調整。

中繼所在的防火墻僅開啟了一個 “地址/端口映射”，且這個“地址/端口映射”指向Relay 非數據管理服務器。其他私網的防火墻均無需開啟任何映射，從而將整體安全風險降至了最低。

異構平臺采用異構協議與共享網關實現平級域互聯， 共享網關將其轉換為GB/T 28181 協議與其他共享網關交互，實現了異構屏蔽。 無論哪一個平臺均可以進行順利的資源調閱。

4 結語

基于虛擬地址空間的共享聯網架構便利地解決了《關于加強公共安全視頻監控建設聯網應用工作的若干意見》 大聯網任務所遇到的主要障礙，消除了聯網的擴展性難題， 實現了業務的無縫融合，消除了NAT 帶來的一系列問題， 屏蔽了系統的異構性，具有很高的靈活性、安全性和便利性。