氣象業(yè)務(wù)流可信交互架構(gòu)①

鮑磊磊, 吳銳濤, 胡 偉, 林 應(yīng)

1(南通市氣象局, 南通 226001)

2(北京網(wǎng)御星云信息科技有限公司, 北京 100089)

隨著氣象預(yù)報(bào)、預(yù)警和服務(wù)業(yè)務(wù)的拓展, 越來(lái)越多的信息系統(tǒng)需要在互聯(lián)網(wǎng)部署針對(duì)性的應(yīng)用, 例如突發(fā)事件預(yù)警、航空氣象服務(wù)系統(tǒng)等. 這些系統(tǒng)的數(shù)據(jù)庫(kù)大都在氣象內(nèi)網(wǎng), 但是同時(shí)又要和互聯(lián)網(wǎng)進(jìn)行業(yè)務(wù)流交互[1–3]. 如果在外網(wǎng)再開(kāi)發(fā)一套支撐互聯(lián)網(wǎng)應(yīng)用的系統(tǒng)不僅增加了開(kāi)發(fā)成本, 造成硬件資源的浪費(fèi), 同時(shí)將業(yè)務(wù)應(yīng)用部署在信息外網(wǎng)會(huì)帶來(lái)信息發(fā)布、網(wǎng)絡(luò)和數(shù)據(jù)等安全隱患[4–6]. 因此, 如何在保障系統(tǒng)安全的基礎(chǔ)上, 針對(duì)氣象業(yè)務(wù)應(yīng)用, 設(shè)計(jì)出一套可信交互架構(gòu),實(shí)現(xiàn)異構(gòu)網(wǎng)絡(luò)間的高效訪問(wèn)和數(shù)據(jù)同步, 優(yōu)化氣象業(yè)務(wù)流傳輸機(jī)制, 成為氣象信息化和網(wǎng)絡(luò)安全業(yè)務(wù)的重要研究難題.

1 體系架構(gòu)設(shè)計(jì)

1.1 硬件架構(gòu)

氣象業(yè)務(wù)流可信交互系統(tǒng)的硬件架構(gòu)如圖1所示.

圖1 可信交互系統(tǒng)硬件架構(gòu)

采用“2+1”模型結(jié)構(gòu)設(shè)計(jì), “2”是內(nèi)網(wǎng)和外網(wǎng)兩個(gè)主機(jī)系統(tǒng), “1”是指一個(gè)隔離交換矩陣模塊. 內(nèi)、外主機(jī)系統(tǒng)的作用是: 獲取數(shù)據(jù)包、拆解TCP/IP協(xié)議和安全檢測(cè). 隔離交換矩陣基于內(nèi)、外網(wǎng)雙通道設(shè)計(jì), 每個(gè)通道由專(zhuān)用ASIC芯片和交換芯片組成. 其中, 交換芯片由交換子系統(tǒng)和開(kāi)關(guān)控制子系統(tǒng)構(gòu)成, 實(shí)現(xiàn)對(duì)數(shù)據(jù)流的安全交換和臨時(shí)緩存. 隔離交換矩陣模塊通過(guò)開(kāi)關(guān)控制子系統(tǒng)控制開(kāi)關(guān)左右擺動(dòng), 實(shí)現(xiàn)內(nèi)、外網(wǎng)交換芯片完成兩次同步擺渡過(guò)程[7].

第1次擺渡是: 內(nèi)、外網(wǎng)交換芯片交換子系統(tǒng)彼此之間斷開(kāi)連接, 通過(guò)開(kāi)關(guān)控制子系統(tǒng)建立各自主機(jī)系統(tǒng)、專(zhuān)用ASIC芯片和交換子系統(tǒng)三者之間的連接,各自主機(jī)系統(tǒng)通過(guò)專(zhuān)用ASIC芯片將數(shù)據(jù)塊封裝成私有協(xié)議數(shù)據(jù)包寫(xiě)入交換子系統(tǒng)或反向讀取交換子系統(tǒng)緩存數(shù)據(jù).

第2次擺渡是: 內(nèi)、外網(wǎng)交換芯片通過(guò)開(kāi)關(guān)控制子系統(tǒng)斷開(kāi)各自交換子系統(tǒng)和ASIC芯片的連接, 交換子系統(tǒng)彼此之間建立連接, 實(shí)現(xiàn)數(shù)據(jù)交換.

兩次擺渡過(guò)程, 內(nèi)、外網(wǎng)都不會(huì)直接物理連接, 另外專(zhuān)用ASIC芯片內(nèi)部固化了多線程并行處理程序, 自動(dòng)完成數(shù)據(jù)塊自有協(xié)議的封裝或拆裝, 因此, 內(nèi)、外網(wǎng)主機(jī)系統(tǒng)之間沒(méi)有基于網(wǎng)絡(luò)協(xié)議的數(shù)據(jù)交換, 從而保證了內(nèi)、外網(wǎng)之間的可信交互[8].

1.2 軟件架構(gòu)

可信交互系統(tǒng)軟件架構(gòu)如圖2所示, 數(shù)據(jù)包獲取后, 標(biāo)準(zhǔn)傳輸協(xié)議被阻斷并經(jīng)網(wǎng)絡(luò)層和應(yīng)用層安全檢測(cè)后, 進(jìn)行協(xié)議重組. 通過(guò)系統(tǒng)內(nèi)核驅(qū)動(dòng)程序和隔離交換控制程序, 實(shí)現(xiàn)可信交互系統(tǒng)內(nèi)部數(shù)據(jù)流高速全雙工交互的基本功能. 采用模塊化的設(shè)計(jì), 將其封裝成系統(tǒng)基本功能模塊.

圖2 可信交互系統(tǒng)軟件架構(gòu)

其他功能模塊主要分為: 系統(tǒng)模塊、訪問(wèn)類(lèi)和同步類(lèi)模塊3類(lèi), 都基于系統(tǒng)基本功能模塊開(kāi)發(fā), 如圖3所示. 其中訪問(wèn)類(lèi)模塊在對(duì)TCP/IP協(xié)議還原的基礎(chǔ)上,對(duì)常用的應(yīng)用層協(xié)議進(jìn)行獨(dú)立開(kāi)發(fā), 供用戶(hù)根據(jù)不同的需求選用. 另外提供非常規(guī)端口的用戶(hù)定制訪問(wèn)和安全通道服務(wù).

圖3 軟件功能模塊

1.3 關(guān)鍵技術(shù)

為提升系統(tǒng)的性能, 實(shí)現(xiàn)多源異構(gòu)網(wǎng)絡(luò)下的氣象業(yè)務(wù)流高速交互, 基于專(zhuān)業(yè)集成電路(ASIC)芯片進(jìn)行編程開(kāi)發(fā), 實(shí)現(xiàn)了以下核心技術(shù)應(yīng)用.

多網(wǎng)隔離技術(shù): 為解決氣象內(nèi)網(wǎng)需要同時(shí)與多個(gè)外網(wǎng)建立業(yè)務(wù)流可信交互的需求, 通過(guò)ASIC芯片的某一或多個(gè)固化通道建立內(nèi)網(wǎng)主機(jī)系統(tǒng)的某一網(wǎng)口與外網(wǎng)主機(jī)系統(tǒng)的某一或多個(gè)網(wǎng)口的對(duì)應(yīng)關(guān)系, 從而實(shí)現(xiàn)一對(duì)一或一對(duì)多的網(wǎng)絡(luò)隔離交換. 外網(wǎng)主機(jī)系統(tǒng)自身的多個(gè)網(wǎng)口禁止互訪[9].

協(xié)議處理技術(shù): 為解決通用協(xié)議和私有協(xié)議之間線性轉(zhuǎn)換. 隔離交換矩陣模塊上的ASIC安全隔離芯片通過(guò)硬件固化處理程序?qū)崿F(xiàn)通用協(xié)議數(shù)據(jù)塊和自有協(xié)議格式數(shù)據(jù)包之間的相互轉(zhuǎn)換.

雙擺渡傳輸技術(shù): 為解決內(nèi)、外網(wǎng)交換子系統(tǒng)之間或交換子系統(tǒng)與主機(jī)系統(tǒng)之間的雙向數(shù)據(jù)高效交換.通過(guò)開(kāi)關(guān)控制系統(tǒng)和ASIC芯片實(shí)現(xiàn)兩次擺渡傳輸過(guò)程.

并行處理技術(shù): 為解決多網(wǎng)絡(luò)接入時(shí), 氣象業(yè)務(wù)流擺渡過(guò)程中存在帶寬瓶頸問(wèn)題. 隔離交換矩陣模塊上的ASIC安全隔離芯片采用了多線程并行處理技術(shù), 提供了多個(gè)安全通道供內(nèi)、外網(wǎng)之間的數(shù)據(jù)流交互.

鏈路聚合技術(shù): 為解決外網(wǎng)與內(nèi)網(wǎng)多對(duì)一訪問(wèn)時(shí),外網(wǎng)主機(jī)系統(tǒng)與內(nèi)網(wǎng)數(shù)據(jù)傳輸過(guò)程中的帶寬瓶頸問(wèn)題.通過(guò)主機(jī)系統(tǒng)的鏈路聚合技術(shù)將多個(gè)物理鏈路聚合成為一個(gè)邏輯鏈路進(jìn)行數(shù)據(jù)交互[10].

2 可信交互結(jié)構(gòu)的典型應(yīng)用

2.1 氣象業(yè)務(wù)流交互需求

氣象信息網(wǎng)絡(luò)主要分為: 氣象業(yè)務(wù)內(nèi)網(wǎng)、電子政務(wù)網(wǎng)、互聯(lián)網(wǎng)和物聯(lián)網(wǎng)4類(lèi). 各類(lèi)氣象業(yè)務(wù)信息系統(tǒng)主要部署氣象業(yè)務(wù)內(nèi)網(wǎng)(簡(jiǎn)稱(chēng)內(nèi)網(wǎng)), 并通過(guò)可信交互框架與電子政務(wù)網(wǎng)、互聯(lián)網(wǎng)或物聯(lián)網(wǎng)(統(tǒng)稱(chēng)外網(wǎng))進(jìn)行業(yè)務(wù)流交互. 在“云+端”的模式下, 采用智能手機(jī)、計(jì)算機(jī)等終端實(shí)現(xiàn)自動(dòng)氣象站維修、數(shù)據(jù)采集、移動(dòng)巡檢、計(jì)量檢定、預(yù)警信息發(fā)布等業(yè)務(wù). 以市局為中心節(jié)點(diǎn), 氣象業(yè)務(wù)流可信交互應(yīng)用架構(gòu)如圖4所示.

圖4 氣象業(yè)務(wù)流可信交互應(yīng)用架構(gòu)

通過(guò)梳理, 主要的交互類(lèi)應(yīng)用可以分為以下兩類(lèi):

(1)訪問(wèn)類(lèi)應(yīng)用: 按照訪問(wèn)方向分為單向訪問(wèn)和雙向訪問(wèn)兩大類(lèi), 單向訪問(wèn)又分為內(nèi)網(wǎng)訪問(wèn)外網(wǎng)和外網(wǎng)訪問(wèn)內(nèi)網(wǎng)兩種, 具體的應(yīng)急需求如表1所示.

表1 單向業(yè)務(wù)訪問(wèn)需求表

雙向訪問(wèn)即: 內(nèi)網(wǎng)需要訪問(wèn)外網(wǎng)的同時(shí), 外網(wǎng)也要訪問(wèn)內(nèi)網(wǎng)的業(yè)務(wù), 通過(guò)梳理, 具體應(yīng)用需求如表2所示.

表2 雙向業(yè)務(wù)訪問(wèn)需求表

(2)同步類(lèi)應(yīng)用: 分為氣象監(jiān)測(cè)、預(yù)報(bào)、服務(wù)和預(yù)警類(lèi)文件同步和氣象業(yè)務(wù)數(shù)據(jù)庫(kù)同步兩大類(lèi).

2.2 訪問(wèn)類(lèi)可信交互架構(gòu)

以?xún)?nèi)網(wǎng)訪問(wèn)外網(wǎng)的單向訪問(wèn)為例, 發(fā)起訪問(wèn)方為客戶(hù)端, 被訪問(wèn)方為服務(wù)端, 整個(gè)氣象業(yè)務(wù)流傳輸路徑如圖5. 客戶(hù)端按照標(biāo)準(zhǔn)的網(wǎng)絡(luò)通信協(xié)議即TCP/IP協(xié)議7層體系通過(guò)內(nèi)網(wǎng)發(fā)起訪問(wèn)請(qǐng)求, 在可信交互架構(gòu)的內(nèi)網(wǎng)側(cè)經(jīng)標(biāo)準(zhǔn)協(xié)議到私有協(xié)議轉(zhuǎn)換后通過(guò)隔離交互矩陣將發(fā)起的請(qǐng)求傳輸?shù)酵饩W(wǎng)側(cè), 在外網(wǎng)側(cè)再經(jīng)私有協(xié)議到標(biāo)準(zhǔn)協(xié)議轉(zhuǎn)換后將請(qǐng)求通過(guò)外網(wǎng)傳送給服務(wù)端,服務(wù)器收到客戶(hù)端的請(qǐng)求后響應(yīng)并處理. 至此, 完成一次單向的訪問(wèn)過(guò)程.

圖5 單向訪問(wèn)類(lèi)功能示意圖

2.3 同步類(lèi)可信交互架構(gòu)

典型的氣象業(yè)務(wù)流同步有文件同步和數(shù)據(jù)庫(kù)同步兩種方式, 他們的同步原理類(lèi)似, 均通過(guò)在內(nèi)、外網(wǎng)服務(wù)器中部署同步客戶(hù)端軟件, 源服務(wù)器為同步發(fā)送端,目的服務(wù)器為同步接收端. 由客戶(hù)端軟件建立待同步的兩臺(tái)服務(wù)器之間的氣象業(yè)務(wù)流交互, 整個(gè)數(shù)據(jù)傳輸全程采取SSL加密, 以確保數(shù)據(jù)同步的高安全性. 業(yè)務(wù)文件同步的流程如圖6, 氣象數(shù)據(jù)庫(kù)同步的流程如圖7.

圖6 文件流同步類(lèi)流程圖

圖7 數(shù)據(jù)庫(kù)同步流程圖

2.4 同步客戶(hù)端設(shè)計(jì)

(1)功能設(shè)計(jì): 同步客戶(hù)端支持Windows和Linux多種系統(tǒng)版本, 在應(yīng)用場(chǎng)景上支持單源多目的、多源單目的和多源多目的的實(shí)際應(yīng)用環(huán)境, 支持單線程和多線程并發(fā)傳輸方式, 被傳輸?shù)臍庀髽I(yè)務(wù)數(shù)據(jù)需經(jīng)過(guò)內(nèi)置的安全策略進(jìn)行格式檢查、內(nèi)容過(guò)濾和病毒檢測(cè), 確保數(shù)據(jù)在同步過(guò)程中的數(shù)據(jù)類(lèi)型匹配、數(shù)據(jù)沖突檢測(cè)以及數(shù)據(jù)容錯(cuò)控制. 提供斷點(diǎn)續(xù)傳功能, 避免系統(tǒng)在斷電斷網(wǎng)過(guò)程中數(shù)據(jù)丟失; 設(shè)計(jì)采用增量傳輸方式, 減輕因網(wǎng)絡(luò)帶寬原因造成的傳輸壓力. 客戶(hù)端的功能框圖如圖8.

圖8中, 文件同步客戶(hù)端支持常規(guī)Office、可執(zhí)行、壓縮、圖片、視頻等多種文件傳輸, 同時(shí)能限制傳輸文件的格式, 有效放行或阻止特定格式的文件傳輸; 數(shù)據(jù)庫(kù)同步客戶(hù)端支持包括 SQL Server、Oracle、Sybase、DB2等主流數(shù)據(jù)庫(kù)中同種或異種數(shù)據(jù)庫(kù)增量或全表同步傳輸.

圖8 同步客戶(hù)端功能框圖

(2)同步機(jī)制: 同步客戶(hù)端軟件部署在內(nèi)、外網(wǎng)服務(wù)器上, 通過(guò)實(shí)時(shí)監(jiān)控的機(jī)制監(jiān)聽(tīng)發(fā)送端產(chǎn)生的數(shù)據(jù)變化, 并通過(guò)證書(shū)認(rèn)證機(jī)制與可信交互架構(gòu)建立連接,將變化的氣象數(shù)據(jù)流寫(xiě)到接收端. 如圖9所示.

圖9 同步客戶(hù)端同步機(jī)制

文件同步客戶(hù)端, 采用實(shí)時(shí)監(jiān)控文件的open、close狀態(tài), 第一時(shí)間捕獲變化的文件. 數(shù)據(jù)庫(kù)同步客戶(hù)端的具體實(shí)現(xiàn)是由同步客戶(hù)端在數(shù)據(jù)庫(kù)中建立一個(gè)臨時(shí)data表, 用于保存待同步任務(wù)的數(shù)據(jù), 當(dāng)所有任務(wù)的數(shù)據(jù)同步完成時(shí), data表中的臨時(shí)數(shù)據(jù)就會(huì)自動(dòng)清除, 等待下一個(gè)時(shí)刻查詢(xún)待同步數(shù)據(jù), 如此反復(fù)循環(huán). 同步客戶(hù)端展示實(shí)時(shí)同步的日志, 自動(dòng)查詢(xún)每個(gè)任務(wù)在臨時(shí)數(shù)據(jù)表中的數(shù)據(jù), 避免數(shù)據(jù)積壓.

3 系統(tǒng)測(cè)試

3.1 功能測(cè)試

為驗(yàn)證該可信交互架構(gòu)的訪問(wèn)類(lèi)和同步類(lèi)應(yīng)用的有效性和實(shí)用性. 依據(jù)氣象業(yè)務(wù)流可信交互需求, 通過(guò)配置可信交互架構(gòu)的軟件功能模塊實(shí)現(xiàn)氣象業(yè)務(wù)流交互, 常用的配置包括源IP地址、目的IP地址、可信交互入口、出口地址和服務(wù)端口, 常用的訪問(wèn)類(lèi)模塊有FTP、郵件、數(shù)據(jù)庫(kù)訪問(wèn)模塊, 用戶(hù)可以選擇定制訪問(wèn)或安全通道模塊自定義服務(wù)端口. 本測(cè)試以文件同步和數(shù)據(jù)庫(kù)同步應(yīng)用為例, 選擇安全通道模塊下普通模式的配置方式, 在同步客戶(hù)端下配置待同步的任務(wù)進(jìn)行測(cè)試, 文件同步功能測(cè)試結(jié)果如圖10所示, 數(shù)據(jù)庫(kù)同步功能測(cè)試結(jié)果如圖11所示.

圖10 文件同步功能測(cè)試

圖11 數(shù)據(jù)庫(kù)同步功能測(cè)試

3.2 性能測(cè)試

(1)測(cè)試環(huán)境

基于可信交互架構(gòu)的典型業(yè)務(wù)應(yīng)用: 智慧航空氣象保障服務(wù)系統(tǒng)的網(wǎng)絡(luò)環(huán)境, 在氣象內(nèi)網(wǎng)和電子政務(wù)網(wǎng)交互氣象數(shù)據(jù)的兩端分別新建文件同步任務(wù)以及數(shù)據(jù)庫(kù)同步任務(wù), 在文件傳輸任務(wù)的兩端服務(wù)器創(chuàng)建對(duì)應(yīng)的文件夾作為數(shù)據(jù)傳輸?shù)脑春湍繕?biāo)路徑目錄, 在數(shù)據(jù)庫(kù)同步任務(wù)的兩端服務(wù)器創(chuàng)建相同的數(shù)據(jù)庫(kù)系統(tǒng)和測(cè)試表. 內(nèi)、外網(wǎng)兩端的網(wǎng)絡(luò)環(huán)境帶寬均為1 Gb/s.

(2)測(cè)試方案

步驟1. 預(yù)先規(guī)劃好內(nèi)網(wǎng)終端Server1和電子政務(wù)網(wǎng)終端Server2的真實(shí)IP; 終端對(duì)應(yīng)在可信交互出、入口的虛擬IP和測(cè)試端口.

步驟2. 在終端Server1和終端Server2都安裝同步客戶(hù)端軟件、時(shí)間測(cè)量軟件和時(shí)間同步軟件, 時(shí)間同步軟件連接到標(biāo)準(zhǔn)時(shí)間服務(wù)器, 確保兩端服務(wù)器的時(shí)間一致.

步驟3. 按照第2.3節(jié)圖6和圖7進(jìn)行物理連接,并設(shè)置Server1為客戶(hù)端模式, Server2為服務(wù)端模式,在交互設(shè)備配置業(yè)務(wù)流傳輸通道, 在兩端的同步客戶(hù)端軟件上創(chuàng)建同步任務(wù).

步驟4. 啟動(dòng)氣象業(yè)務(wù)流同步任務(wù), 傳輸任務(wù)可以根據(jù)測(cè)試需要適當(dāng)增加, 選擇合適時(shí)間進(jìn)行壓力測(cè)試.

實(shí)際業(yè)務(wù)中為了網(wǎng)絡(luò)安全, 端口默認(rèn)關(guān)閉, 需在硬件防火墻上設(shè)置訪問(wèn)控制策略, 系統(tǒng)防火墻上分別配置端口的入?；虺鰲２呗?

(3)測(cè)量結(jié)果及分析:

如表3所示. 并發(fā)數(shù)100和200是文件逐一傳輸,傳輸?shù)奈募?shù)量越多, 傳輸?shù)乃俾试铰? 而對(duì)于并發(fā)數(shù)300和400, 是將300和400個(gè)文件各自壓縮成1個(gè)數(shù)據(jù)包進(jìn)行傳輸測(cè)試, 因此傳輸速率相對(duì)較快. 經(jīng)過(guò)業(yè)務(wù)環(huán)境的真實(shí)測(cè)量, 可以得出結(jié)論: 傳輸文件的數(shù)量與系統(tǒng)的傳輸速率成反比, 傳輸文件的大小并不影響系統(tǒng)的傳輸速率.

表3 文件同步的測(cè)量結(jié)果

以上測(cè)量結(jié)論對(duì)于判斷可信交互架構(gòu)的網(wǎng)絡(luò)瓶頸和估計(jì)帶寬利用率是非常有用的. 在實(shí)際應(yīng)用中, 對(duì)于時(shí)效性要求不高的文件, 可以采用批處理程序?qū)⒋齻鬏數(shù)奈募M(jìn)行打包后傳輸, 傳輸采用增量傳輸?shù)姆绞?可以有效提高氣象業(yè)務(wù)流的傳輸速率.

在異構(gòu)網(wǎng)絡(luò)兩端的數(shù)據(jù)庫(kù)上分別創(chuàng)建數(shù)據(jù)表test1和test2, test1插入10 000條記錄, test2插入100 000條記錄. 并發(fā)數(shù)以數(shù)據(jù)表的記錄數(shù)為單位, 由于結(jié)構(gòu)化數(shù)據(jù)庫(kù)本身的單個(gè)數(shù)據(jù)記錄的大小很小, 因此將每秒通過(guò)交互架構(gòu)的記錄數(shù)作為測(cè)量指標(biāo)更有意義. 經(jīng)過(guò)10 000和100 000條記錄的傳輸測(cè)試, 得到如表4的測(cè)試結(jié)果.

表4 數(shù)據(jù)庫(kù)同步的測(cè)量結(jié)果

由第2.4節(jié)數(shù)據(jù)庫(kù)同步客戶(hù)端的設(shè)計(jì)機(jī)制: 同步任務(wù)啟動(dòng)后, 數(shù)據(jù)庫(kù)中建立一個(gè)臨時(shí)data表, 用于保存待同步任務(wù)的數(shù)據(jù), 為了保證數(shù)據(jù)傳輸?shù)姆€(wěn)定性, data表每次最多只能完成5條數(shù)據(jù)插入, 即使傳輸速度很快,數(shù)據(jù)也會(huì)存在排隊(duì)等待時(shí)間, 此等待時(shí)間即為業(yè)務(wù)流傳輸?shù)钠款i. 通過(guò)3個(gè)月以上的實(shí)際業(yè)務(wù)運(yùn)行得出結(jié)論: 正常情況下, 系統(tǒng)不會(huì)出現(xiàn)數(shù)據(jù)擁堵, 但受限于系統(tǒng)本身吞吐率和并發(fā)數(shù)等性能指標(biāo), 為追求傳輸?shù)姆€(wěn)定性, data表的緩存設(shè)計(jì)是有上限的, 可以通過(guò)定期清理或定期重啟同步客戶(hù)端軟件釋放緩存. 另外經(jīng)常關(guān)注data表的數(shù)據(jù)排隊(duì)情況, 對(duì)于業(yè)務(wù)流交互架構(gòu)系統(tǒng)的運(yùn)維有著重要的意義.

3.3 安全測(cè)試

采用網(wǎng)絡(luò)安全攻防演練的模式, 基于網(wǎng)絡(luò)層和應(yīng)用層選取幾種常用的網(wǎng)絡(luò)攻擊進(jìn)行模擬攻擊, 統(tǒng)計(jì)該可信交互架構(gòu)的攔截率, 并與下一代防火墻的攔截率進(jìn)行對(duì)比統(tǒng)計(jì), 防火墻匹配訪問(wèn)控制策略、病毒和IPS特征庫(kù), 并升級(jí)特征庫(kù)到最新版本. 測(cè)試結(jié)果如表5.

表5 系統(tǒng)安全測(cè)試結(jié)果 (%)

基于測(cè)試統(tǒng)計(jì), 下一代防火墻設(shè)備對(duì)于基于網(wǎng)絡(luò)層的攻擊絕大部分可以攔截, 對(duì)基于應(yīng)用層的攻擊攔截需要匹配訪問(wèn)控制策略、最新的特征庫(kù)基本才能實(shí)現(xiàn)100%的攔截; 可信交互架構(gòu)對(duì)于各種基于網(wǎng)絡(luò)層和應(yīng)用層的模擬攻擊實(shí)現(xiàn)了100%的攔截, 節(jié)省了下一代防火墻升級(jí)特征庫(kù)的費(fèi)用, 采用可信交互架構(gòu)與多種安全防護(hù)設(shè)備聯(lián)動(dòng)可以達(dá)到更好的安全防護(hù)效果.

4 總結(jié)

氣象業(yè)務(wù)流可信交互架構(gòu)采用“2+1”模型結(jié)構(gòu)設(shè)計(jì), 實(shí)現(xiàn)了氣象數(shù)據(jù)流在異構(gòu)網(wǎng)絡(luò)下的安全傳輸, 為氣象信息系統(tǒng)提供便捷、安全的交互環(huán)境. 本文梳理了內(nèi)、外網(wǎng)物理隔離后常見(jiàn)業(yè)務(wù)應(yīng)用需求, 對(duì)訪問(wèn)類(lèi)和同步類(lèi)交互架構(gòu)、同步客戶(hù)端的功能和機(jī)制進(jìn)行了詳細(xì)分析, 最后結(jié)合具體業(yè)務(wù)應(yīng)用開(kāi)展功能、性能和安全測(cè)試研究, 測(cè)試結(jié)果表明: 傳輸文件的大小不會(huì)影響系統(tǒng)的傳輸速率; 待同步文件的數(shù)量與系統(tǒng)的傳輸速率成反比, 待同步數(shù)據(jù)庫(kù)表的記錄數(shù)和系統(tǒng)傳輸速率成反比. 壓縮文件的傳輸結(jié)果表明: 可信交互架構(gòu)的帶寬利用率達(dá)到80%以上.