氣象業務流可信交互架構①

鮑磊磊, 吳銳濤, 胡 偉, 林 應

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

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

隨著氣象預報、預警和服務業務的拓展, 越來越多的信息系統需要在互聯網部署針對性的應用, 例如突發事件預警、航空氣象服務系統等. 這些系統的數據庫大都在氣象內網, 但是同時又要和互聯網進行業務流交互[1–3]. 如果在外網再開發一套支撐互聯網應用的系統不僅增加了開發成本, 造成硬件資源的浪費, 同時將業務應用部署在信息外網會帶來信息發布、網絡和數據等安全隱患[4–6]. 因此, 如何在保障系統安全的基礎上, 針對氣象業務應用, 設計出一套可信交互架構,實現異構網絡間的高效訪問和數據同步, 優化氣象業務流傳輸機制, 成為氣象信息化和網絡安全業務的重要研究難題.

1 體系架構設計

1.1 硬件架構

氣象業務流可信交互系統的硬件架構如圖1所示.

圖1 可信交互系統硬件架構

采用“2+1”模型結構設計, “2”是內網和外網兩個主機系統, “1”是指一個隔離交換矩陣模塊. 內、外主機系統的作用是: 獲取數據包、拆解TCP/IP協議和安全檢測. 隔離交換矩陣基于內、外網雙通道設計, 每個通道由專用ASIC芯片和交換芯片組成. 其中, 交換芯片由交換子系統和開關控制子系統構成, 實現對數據流的安全交換和臨時緩存. 隔離交換矩陣模塊通過開關控制子系統控制開關左右擺動, 實現內、外網交換芯片完成兩次同步擺渡過程[7].

第1次擺渡是: 內、外網交換芯片交換子系統彼此之間斷開連接, 通過開關控制子系統建立各自主機系統、專用ASIC芯片和交換子系統三者之間的連接,各自主機系統通過專用ASIC芯片將數據塊封裝成私有協議數據包寫入交換子系統或反向讀取交換子系統緩存數據.

第2次擺渡是: 內、外網交換芯片通過開關控制子系統斷開各自交換子系統和ASIC芯片的連接, 交換子系統彼此之間建立連接, 實現數據交換.

兩次擺渡過程, 內、外網都不會直接物理連接, 另外專用ASIC芯片內部固化了多線程并行處理程序, 自動完成數據塊自有協議的封裝或拆裝, 因此, 內、外網主機系統之間沒有基于網絡協議的數據交換, 從而保證了內、外網之間的可信交互[8].

1.2 軟件架構

可信交互系統軟件架構如圖2所示, 數據包獲取后, 標準傳輸協議被阻斷并經網絡層和應用層安全檢測后, 進行協議重組. 通過系統內核驅動程序和隔離交換控制程序, 實現可信交互系統內部數據流高速全雙工交互的基本功能. 采用模塊化的設計, 將其封裝成系統基本功能模塊.

圖2 可信交互系統軟件架構

其他功能模塊主要分為: 系統模塊、訪問類和同步類模塊3類, 都基于系統基本功能模塊開發, 如圖3所示. 其中訪問類模塊在對TCP/IP協議還原的基礎上,對常用的應用層協議進行獨立開發, 供用戶根據不同的需求選用. 另外提供非常規端口的用戶定制訪問和安全通道服務.

圖3 軟件功能模塊

1.3 關鍵技術

為提升系統的性能, 實現多源異構網絡下的氣象業務流高速交互, 基于專業集成電路(ASIC)芯片進行編程開發, 實現了以下核心技術應用.

多網隔離技術: 為解決氣象內網需要同時與多個外網建立業務流可信交互的需求, 通過ASIC芯片的某一或多個固化通道建立內網主機系統的某一網口與外網主機系統的某一或多個網口的對應關系, 從而實現一對一或一對多的網絡隔離交換. 外網主機系統自身的多個網口禁止互訪[9].

協議處理技術: 為解決通用協議和私有協議之間線性轉換. 隔離交換矩陣模塊上的ASIC安全隔離芯片通過硬件固化處理程序實現通用協議數據塊和自有協議格式數據包之間的相互轉換.

雙擺渡傳輸技術: 為解決內、外網交換子系統之間或交換子系統與主機系統之間的雙向數據高效交換.通過開關控制系統和ASIC芯片實現兩次擺渡傳輸過程.

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

鏈路聚合技術: 為解決外網與內網多對一訪問時,外網主機系統與內網數據傳輸過程中的帶寬瓶頸問題.通過主機系統的鏈路聚合技術將多個物理鏈路聚合成為一個邏輯鏈路進行數據交互[10].

2 可信交互結構的典型應用

2.1 氣象業務流交互需求

氣象信息網絡主要分為: 氣象業務內網、電子政務網、互聯網和物聯網4類. 各類氣象業務信息系統主要部署氣象業務內網(簡稱內網), 并通過可信交互框架與電子政務網、互聯網或物聯網(統稱外網)進行業務流交互. 在“云+端”的模式下, 采用智能手機、計算機等終端實現自動氣象站維修、數據采集、移動巡檢、計量檢定、預警信息發布等業務. 以市局為中心節點, 氣象業務流可信交互應用架構如圖4所示.

圖4 氣象業務流可信交互應用架構

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

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

表1 單向業務訪問需求表

雙向訪問即: 內網需要訪問外網的同時, 外網也要訪問內網的業務, 通過梳理, 具體應用需求如表2所示.

表2 雙向業務訪問需求表

(2)同步類應用: 分為氣象監測、預報、服務和預警類文件同步和氣象業務數據庫同步兩大類.

2.2 訪問類可信交互架構

以內網訪問外網的單向訪問為例, 發起訪問方為客戶端, 被訪問方為服務端, 整個氣象業務流傳輸路徑如圖5. 客戶端按照標準的網絡通信協議即TCP/IP協議7層體系通過內網發起訪問請求, 在可信交互架構的內網側經標準協議到私有協議轉換后通過隔離交互矩陣將發起的請求傳輸到外網側, 在外網側再經私有協議到標準協議轉換后將請求通過外網傳送給服務端,服務器收到客戶端的請求后響應并處理. 至此, 完成一次單向的訪問過程.

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

2.3 同步類可信交互架構

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

圖6 文件流同步類流程圖

圖7 數據庫同步流程圖

2.4 同步客戶端設計

(1)功能設計: 同步客戶端支持Windows和Linux多種系統版本, 在應用場景上支持單源多目的、多源單目的和多源多目的的實際應用環境, 支持單線程和多線程并發傳輸方式, 被傳輸的氣象業務數據需經過內置的安全策略進行格式檢查、內容過濾和病毒檢測, 確保數據在同步過程中的數據類型匹配、數據沖突檢測以及數據容錯控制. 提供斷點續傳功能, 避免系統在斷電斷網過程中數據丟失; 設計采用增量傳輸方式, 減輕因網絡帶寬原因造成的傳輸壓力. 客戶端的功能框圖如圖8.

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

圖8 同步客戶端功能框圖

(2)同步機制: 同步客戶端軟件部署在內、外網服務器上, 通過實時監控的機制監聽發送端產生的數據變化, 并通過證書認證機制與可信交互架構建立連接,將變化的氣象數據流寫到接收端. 如圖9所示.

圖9 同步客戶端同步機制

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

3 系統測試

3.1 功能測試

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

圖10 文件同步功能測試

圖11 數據庫同步功能測試

3.2 性能測試

(1)測試環境

基于可信交互架構的典型業務應用: 智慧航空氣象保障服務系統的網絡環境, 在氣象內網和電子政務網交互氣象數據的兩端分別新建文件同步任務以及數據庫同步任務, 在文件傳輸任務的兩端服務器創建對應的文件夾作為數據傳輸的源和目標路徑目錄, 在數據庫同步任務的兩端服務器創建相同的數據庫系統和測試表. 內、外網兩端的網絡環境帶寬均為1 Gb/s.

(2)測試方案

步驟1. 預先規劃好內網終端Server1和電子政務網終端Server2的真實IP; 終端對應在可信交互出、入口的虛擬IP和測試端口.

步驟2. 在終端Server1和終端Server2都安裝同步客戶端軟件、時間測量軟件和時間同步軟件, 時間同步軟件連接到標準時間服務器, 確保兩端服務器的時間一致.

步驟3. 按照第2.3節圖6和圖7進行物理連接,并設置Server1為客戶端模式, Server2為服務端模式,在交互設備配置業務流傳輸通道, 在兩端的同步客戶端軟件上創建同步任務.

步驟4. 啟動氣象業務流同步任務, 傳輸任務可以根據測試需要適當增加, 選擇合適時間進行壓力測試.

實際業務中為了網絡安全, 端口默認關閉, 需在硬件防火墻上設置訪問控制策略, 系統防火墻上分別配置端口的入棧或出棧策略.

(3)測量結果及分析:

如表3所示. 并發數100和200是文件逐一傳輸,傳輸的文件數量越多, 傳輸的速率越慢, 而對于并發數300和400, 是將300和400個文件各自壓縮成1個數據包進行傳輸測試, 因此傳輸速率相對較快. 經過業務環境的真實測量, 可以得出結論: 傳輸文件的數量與系統的傳輸速率成反比, 傳輸文件的大小并不影響系統的傳輸速率.

表3 文件同步的測量結果

以上測量結論對于判斷可信交互架構的網絡瓶頸和估計帶寬利用率是非常有用的. 在實際應用中, 對于時效性要求不高的文件, 可以采用批處理程序將待傳輸的文件進行打包后傳輸, 傳輸采用增量傳輸的方式,可以有效提高氣象業務流的傳輸速率.

在異構網絡兩端的數據庫上分別創建數據表test1和test2, test1插入10 000條記錄, test2插入100 000條記錄. 并發數以數據表的記錄數為單位, 由于結構化數據庫本身的單個數據記錄的大小很小, 因此將每秒通過交互架構的記錄數作為測量指標更有意義. 經過10 000和100 000條記錄的傳輸測試, 得到如表4的測試結果.

表4 數據庫同步的測量結果

由第2.4節數據庫同步客戶端的設計機制: 同步任務啟動后, 數據庫中建立一個臨時data表, 用于保存待同步任務的數據, 為了保證數據傳輸的穩定性, data表每次最多只能完成5條數據插入, 即使傳輸速度很快,數據也會存在排隊等待時間, 此等待時間即為業務流傳輸的瓶頸. 通過3個月以上的實際業務運行得出結論: 正常情況下, 系統不會出現數據擁堵, 但受限于系統本身吞吐率和并發數等性能指標, 為追求傳輸的穩定性, data表的緩存設計是有上限的, 可以通過定期清理或定期重啟同步客戶端軟件釋放緩存. 另外經常關注data表的數據排隊情況, 對于業務流交互架構系統的運維有著重要的意義.

3.3 安全測試

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

表5 系統安全測試結果 (%)

基于測試統計, 下一代防火墻設備對于基于網絡層的攻擊絕大部分可以攔截, 對基于應用層的攻擊攔截需要匹配訪問控制策略、最新的特征庫基本才能實現100%的攔截; 可信交互架構對于各種基于網絡層和應用層的模擬攻擊實現了100%的攔截, 節省了下一代防火墻升級特征庫的費用, 采用可信交互架構與多種安全防護設備聯動可以達到更好的安全防護效果.

4 總結

氣象業務流可信交互架構采用“2+1”模型結構設計, 實現了氣象數據流在異構網絡下的安全傳輸, 為氣象信息系統提供便捷、安全的交互環境. 本文梳理了內、外網物理隔離后常見業務應用需求, 對訪問類和同步類交互架構、同步客戶端的功能和機制進行了詳細分析, 最后結合具體業務應用開展功能、性能和安全測試研究, 測試結果表明: 傳輸文件的大小不會影響系統的傳輸速率; 待同步文件的數量與系統的傳輸速率成反比, 待同步數據庫表的記錄數和系統傳輸速率成反比. 壓縮文件的傳輸結果表明: 可信交互架構的帶寬利用率達到80%以上.