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

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

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

隨著氣象預(yù)報、預(yù)警和服務(wù)業(yè)務(wù)的拓展, 越來越多的信息系統(tǒng)需要在互聯(lián)網(wǎng)部署針對性的應(yīng)用, 例如突發(fā)事件預(yù)警、航空氣象服務(wù)系統(tǒng)等. 這些系統(tǒng)的數(shù)據(jù)庫大都在氣象內(nèi)網(wǎng), 但是同時又要和互聯(lián)網(wǎng)進(jìn)行業(yè)務(wù)流交互[1–3]. 如果在外網(wǎng)再開發(fā)一套支撐互聯(lián)網(wǎng)應(yīng)用的系統(tǒng)不僅增加了開發(fā)成本, 造成硬件資源的浪費(fèi), 同時將業(yè)務(wù)應(yīng)用部署在信息外網(wǎng)會帶來信息發(fā)布、網(wǎng)絡(luò)和數(shù)據(jù)等安全隱患[4–6]. 因此, 如何在保障系統(tǒng)安全的基礎(chǔ)上, 針對氣象業(yè)務(wù)應(yīng)用, 設(shè)計(jì)出一套可信交互架構(gòu),實(shí)現(xiàn)異構(gòu)網(wǎng)絡(luò)間的高效訪問和數(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)兩個主機(jī)系統(tǒng), “1”是指一個隔離交換矩陣模塊. 內(nèi)、外主機(jī)系統(tǒng)的作用是: 獲取數(shù)據(jù)包、拆解TCP/IP協(xié)議和安全檢測. 隔離交換矩陣基于內(nèi)、外網(wǎng)雙通道設(shè)計(jì), 每個通道由專用ASIC芯片和交換芯片組成. 其中, 交換芯片由交換子系統(tǒng)和開關(guān)控制子系統(tǒng)構(gòu)成, 實(shí)現(xiàn)對數(shù)據(jù)流的安全交換和臨時緩存. 隔離交換矩陣模塊通過開關(guān)控制子系統(tǒng)控制開關(guān)左右擺動, 實(shí)現(xiàn)內(nèi)、外網(wǎng)交換芯片完成兩次同步擺渡過程[7].

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

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

兩次擺渡過程, 內(nèi)、外網(wǎng)都不會直接物理連接, 另外專用ASIC芯片內(nèi)部固化了多線程并行處理程序, 自動完成數(shù)據(jù)塊自有協(xié)議的封裝或拆裝, 因此, 內(nèi)、外網(wǎng)主機(jī)系統(tǒng)之間沒有基于網(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)用層安全檢測后, 進(jìn)行協(xié)議重組. 通過系統(tǒng)內(nèi)核驅(qū)動程序和隔離交換控制程序, 實(shí)現(xiàn)可信交互系統(tǒng)內(nèi)部數(shù)據(jù)流高速全雙工交互的基本功能. 采用模塊化的設(shè)計(jì), 將其封裝成系統(tǒng)基本功能模塊.

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

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

圖3 軟件功能模塊

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

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

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

協(xié)議處理技術(shù): 為解決通用協(xié)議和私有協(xié)議之間線性轉(zhuǎn)換. 隔離交換矩陣模塊上的ASIC安全隔離芯片通過硬件固化處理程序?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ān)控制系統(tǒng)和ASIC芯片實(shí)現(xiàn)兩次擺渡傳輸過程.

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

鏈路聚合技術(shù): 為解決外網(wǎng)與內(nèi)網(wǎng)多對一訪問時,外網(wǎng)主機(jī)系統(tǒng)與內(nèi)網(wǎng)數(shù)據(jù)傳輸過程中的帶寬瓶頸問題.通過主機(jī)系統(tǒng)的鏈路聚合技術(shù)將多個物理鏈路聚合成為一個邏輯鏈路進(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類. 各類氣象業(yè)務(wù)信息系統(tǒng)主要部署氣象業(yè)務(wù)內(nèi)網(wǎng)(簡稱內(nèi)網(wǎng)), 并通過可信交互框架與電子政務(wù)網(wǎng)、互聯(lián)網(wǎng)或物聯(lián)網(wǎng)(統(tǒng)稱外網(wǎng))進(jìn)行業(yè)務(wù)流交互. 在“云+端”的模式下, 采用智能手機(jī)、計(jì)算機(jī)等終端實(shí)現(xiàn)自動氣象站維修、數(shù)據(jù)采集、移動巡檢、計(jì)量檢定、預(yù)警信息發(fā)布等業(yè)務(wù). 以市局為中心節(jié)點(diǎn), 氣象業(yè)務(wù)流可信交互應(yīng)用架構(gòu)如圖4所示.

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

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

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

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

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

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

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

2.2 訪問類可信交互架構(gòu)

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

圖5 單向訪問類功能示意圖

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

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

圖6 文件流同步類流程圖

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

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

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

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

圖8 同步客戶端功能框圖

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

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

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

3 系統(tǒng)測試

3.1 功能測試

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

圖10 文件同步功能測試

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

3.2 性能測試

(1)測試環(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ù)庫同步任務(wù), 在文件傳輸任務(wù)的兩端服務(wù)器創(chuàng)建對應(yīng)的文件夾作為數(shù)據(jù)傳輸?shù)脑春湍繕?biāo)路徑目錄, 在數(shù)據(jù)庫同步任務(wù)的兩端服務(wù)器創(chuàng)建相同的數(shù)據(jù)庫系統(tǒng)和測試表. 內(nèi)、外網(wǎng)兩端的網(wǎng)絡(luò)環(huán)境帶寬均為1 Gb/s.

(2)測試方案

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

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

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

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

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

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

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

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

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

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

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

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

3.3 安全測試

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

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

基于測試統(tǒng)計(jì), 下一代防火墻設(shè)備對于基于網(wǎng)絡(luò)層的攻擊絕大部分可以攔截, 對基于應(yīng)用層的攻擊攔截需要匹配訪問控制策略、最新的特征庫基本才能實(shí)現(xiàn)100%的攔截; 可信交互架構(gòu)對于各種基于網(wǎng)絡(luò)層和應(yīng)用層的模擬攻擊實(shí)現(xiàn)了100%的攔截, 節(jié)省了下一代防火墻升級特征庫的費(fèi)用, 采用可信交互架構(gòu)與多種安全防護(hù)設(shè)備聯(lián)動可以達(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)物理隔離后常見業(yè)務(wù)應(yīng)用需求, 對訪問類和同步類交互架構(gòu)、同步客戶端的功能和機(jī)制進(jìn)行了詳細(xì)分析, 最后結(jié)合具體業(yè)務(wù)應(yīng)用開展功能、性能和安全測試研究, 測試結(jié)果表明: 傳輸文件的大小不會影響系統(tǒng)的傳輸速率; 待同步文件的數(shù)量與系統(tǒng)的傳輸速率成反比, 待同步數(shù)據(jù)庫表的記錄數(shù)和系統(tǒng)傳輸速率成反比. 壓縮文件的傳輸結(jié)果表明: 可信交互架構(gòu)的帶寬利用率達(dá)到80%以上.