可靠的無反饋數(shù)據(jù)傳輸方案設(shè)計(jì)

王文波+唐成華

摘 要：涉密網(wǎng)絡(luò)與外界必須物理隔離，這使其成為名副其實(shí)的信息孤島，光閘等數(shù)據(jù)單向傳輸系統(tǒng)提供了一種有效的解決信息孤島的方案，這源于其采用了基于無反饋的數(shù)據(jù)傳輸協(xié)議。在無反饋傳輸協(xié)議中，如何確保文件被正確傳輸?shù)侥繕?biāo)網(wǎng)絡(luò)中，成為單向傳輸系統(tǒng)可靠性的一個(gè)重要評(píng)估標(biāo)準(zhǔn)。本文總結(jié)了目前主流的無反饋數(shù)據(jù)傳輸方案的利與弊，并在此基礎(chǔ)上提出一種新的可靠性解決方案，確保文件被完整、正確地傳輸?shù)侥繕?biāo)網(wǎng)絡(luò)。

關(guān)鍵詞：文件傳輸 單向傳輸 可靠性

中圖分類號(hào)：TP309 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1672-3791（2014）01（b）-0000-00

隨著計(jì)算機(jī)網(wǎng)絡(luò)技術(shù)的發(fā)展，網(wǎng)絡(luò)成為人們生活發(fā)展中必不可少的工具之一。但在一些涉密網(wǎng)絡(luò)中，由于密級(jí)要求的原因，往往需要隔離外界網(wǎng)絡(luò)，這逐漸形成涉密網(wǎng)絡(luò)的信息“孤島”效應(yīng)[1]。因此需要有一種手段，可以使人們可以將一些無安全風(fēng)險(xiǎn)的信息、文件等，安全、完整地從非涉密網(wǎng)絡(luò)傳輸?shù)缴婷芫W(wǎng)絡(luò)，同時(shí)保證涉密網(wǎng)絡(luò)的信息絕對(duì)不會(huì)流出到外界網(wǎng)絡(luò)。使用傳統(tǒng)協(xié)議的文件、信息傳輸系統(tǒng)并不能滿足這個(gè)需要。單向傳輸系統(tǒng)就是為解決這個(gè)問題而出現(xiàn)的。

單向傳輸系統(tǒng)主要由三個(gè)主要組成部分：外網(wǎng)服務(wù)器、單向傳輸模塊以及內(nèi)網(wǎng)服務(wù)器，如圖1所示。

單向傳輸模塊是單向傳輸系統(tǒng)能否達(dá)標(biāo)的重要環(huán)節(jié)。如何將文件完全、完整地傳輸至涉密內(nèi)部網(wǎng)絡(luò)，同時(shí)形成可追溯的歷史記錄，成為解決這個(gè)問題的一大關(guān)鍵技術(shù)。本文主要針對(duì)單向傳輸模塊的可靠性進(jìn)行探討。

1 單向傳輸協(xié)議的可靠性

單向傳輸協(xié)議的可靠性，在很早之前就已經(jīng)受到業(yè)界學(xué)者的廣泛關(guān)注。Saitoh提出了一種單向字節(jié)流的檢錯(cuò)與糾錯(cuò)編碼技術(shù)[2]，Vaidya在Fault-Tolerant Computing會(huì)議上也提出了類似錯(cuò)誤編碼的思路[3]，但這些僅僅局限于通用的單向協(xié)議本身的檢錯(cuò)與糾錯(cuò)技術(shù)，并不能完全適合于單向文件傳輸本身。2004年出現(xiàn)的FLUTE[4]提供了一種單向文件傳輸協(xié)議，成為單向傳輸系統(tǒng)使用最多的協(xié)議之一，但仍有局限性，其為文件單向傳輸提供了完整的解決方案，使用并向糾錯(cuò)碼解決了文件本身的完整性驗(yàn)證問題，但并不能完全發(fā)現(xiàn)信道上的問題，以及實(shí)際應(yīng)用中審計(jì)與可靠性需求。Jeffrey在其專利中介紹了一種類似同步信號(hào)的機(jī)制[5]，服務(wù)器定時(shí)發(fā)布同步信號(hào)，接收機(jī)器定時(shí)獲取服務(wù)器發(fā)布的同步信號(hào)，以確保傳輸信道的通信正常，但是這種機(jī)制的提出，并不是專門為單向傳輸系統(tǒng)所設(shè)計(jì)的，且僅提供了一種檢測(cè)信道正常的方案，也不能完全滿足需求。之后相繼出現(xiàn)了多種完整的解決方案，包括以下幾種：

1.1 日志比對(duì)方案

該方案是最簡(jiǎn)單最直接的方案，發(fā)送模塊與接收模塊分別在發(fā)送成功與接收成功時(shí)，各記錄一份日志，人為將兩份日志文件進(jìn)行人工比對(duì)或程序自動(dòng)化比對(duì)。該方案的主要缺點(diǎn)就是需要太多的人工干預(yù)，無論是進(jìn)行人工比對(duì)還是進(jìn)行程序自動(dòng)化比對(duì)，需要人工從外網(wǎng)服務(wù)器將日志帶入內(nèi)網(wǎng)服務(wù)器。

1.2 雙機(jī)冗余方案

該方案是采用兩個(gè)單向傳輸硬件冗余方式，采用兩套一模一樣的發(fā)送設(shè)備，發(fā)送模塊與接收模塊分別各自記錄一份發(fā)送日志與接收日志。通過定期的人為方式，將兩份發(fā)送日志與兩份接收日志進(jìn)行人工比對(duì)還是進(jìn)行程序自動(dòng)化比對(duì)，同時(shí)將發(fā)送日志與接收日志進(jìn)行比對(duì)，得到遺漏清單。

該方案解決了需要人工將日志帶入內(nèi)網(wǎng)進(jìn)行比對(duì)的缺點(diǎn)，但存在硬件資源嚴(yán)重浪費(fèi)的問題，也不是最佳的解決方案。

1.3 分流冗余方案

該方案采用單個(gè)單向傳輸硬件加分流方式，通過數(shù)據(jù)包分流方式，將傳輸?shù)臄?shù)據(jù)復(fù)制一份，同時(shí)發(fā)給本地，將已發(fā)送的日志與分流得到的日志進(jìn)行比對(duì)，得出遺漏信息，同時(shí)定時(shí)比對(duì)發(fā)送日志與接收日志，得到遺漏清單。

該方案是上一方案的一種變體，解決了硬件資源浪費(fèi)的問題，但是并沒有在根源上解決可靠性的問題，反而可能造成重要信息的遺漏。因?yàn)樵摲桨钢荒茉谕饩W(wǎng)服務(wù)器保證文件已傳出，但是并不能檢測(cè)到傳輸線路上、或者接收模塊上的錯(cuò)誤，造成不必要的損失。

1.4 定時(shí)同步信號(hào)方案

該方案包括兩部分內(nèi)容：首先，外網(wǎng)服務(wù)器會(huì)定時(shí)發(fā)送一個(gè)同步信號(hào)，使得內(nèi)網(wǎng)機(jī)器能夠判斷單向通信線路的連通性；同時(shí)，在文件傳輸時(shí)，會(huì)生成一個(gè)連續(xù)的流水號(hào)，內(nèi)網(wǎng)服務(wù)器能夠根據(jù)這個(gè)流水號(hào)的連續(xù)性，判斷文件傳輸過程中是否產(chǎn)生信息丟失，若發(fā)生丟失，則產(chǎn)生報(bào)警。

該方案解決基本上解決了需要人工參與的缺點(diǎn)，但是該方案有一個(gè)使用上的局限性：由于其依賴流水號(hào)的連續(xù)性來判斷文件傳輸?shù)恼_性，因此該方案只適用于使用單進(jìn)程、單根光纖的情況。

2 方案設(shè)計(jì)

本文在總結(jié)現(xiàn)有的幾種解決方案的基礎(chǔ)上，提出一種無需人工參與比對(duì)過程，且適用于多進(jìn)程、并發(fā)、多光纖傳輸線路的可靠性解決方案。

本方案主要包含四個(gè)模塊，分別為發(fā)送模塊、外網(wǎng)同步模塊、接收模塊、內(nèi)網(wǎng)同步模塊，如圖2所示。

2.1 發(fā)送模塊

外網(wǎng)發(fā)送模塊主要負(fù)責(zé)如下任務(wù)：

（1）接收新文件，獲取文件名、文件大小、文件哈希校驗(yàn)值（md5）等內(nèi)容；

（2）發(fā)送文件；

（3）若文件發(fā)送成功，則將步驟（1）的內(nèi)容添加到發(fā)送清單；

（4）否則，記錄發(fā)送失敗日志。

2.2 外網(wǎng)同步模塊

外網(wǎng)同步模塊除了具備上述1.4方案中的功能之外，還負(fù)責(zé)如下任務(wù)：

（1）新建同步文件；

（2）將上次同步時(shí)間與當(dāng)前時(shí)間分別寫入上一步的同步文件；

（3）從發(fā)送模塊中的發(fā)送清單中，獲取上次同步時(shí)間與當(dāng)前時(shí)間內(nèi)所有發(fā)送成功的文件信息，并寫入步驟（1）的同步文件內(nèi)；

（4）將同步文件交給發(fā)送模塊傳輸?shù)絻?nèi)部網(wǎng)絡(luò)。endprint

2.3 接收模塊

接收模塊主要負(fù)責(zé)如下任務(wù)：

（1）接收文件；

（2）檢驗(yàn)文件完整性；

（3）若文件正確，則獲取文件名，計(jì)算文件大小、文件哈希校驗(yàn)值（md5）等內(nèi)容，并將這些內(nèi)容添加到接收清單中；

（4）否則，記錄接收失敗日志。

2.4 內(nèi)網(wǎng)同步模塊

內(nèi)網(wǎng)同步模塊負(fù)責(zé)如下任務(wù)：

（1）接收同步文件；

（2）解析接收到的同步文件，獲取該文件指定的時(shí)間范圍與對(duì)應(yīng)的時(shí)間范圍內(nèi)成功發(fā)送的文件清單；

（3）從接收模塊獲取步驟（2）的時(shí)間范圍內(nèi)成功接收的文件清單；

（4）將步驟（2）與步驟（3）獲得的兩份清單進(jìn)行比對(duì)，獲得遺漏的文件清單與文件校驗(yàn)值不匹配的文件清單；

（5）若步驟（4）中發(fā)現(xiàn)錯(cuò)誤，則向管理員發(fā)出報(bào)警信息（如短信、郵件通知等）。

同時(shí)，該模塊還負(fù)責(zé)啟動(dòng)一個(gè)定時(shí)器，當(dāng)超過指定時(shí)間還未接收到新的同步文件，則可認(rèn)為當(dāng)前傳輸線路存在問題，則會(huì)向管理員發(fā)出報(bào)警信息。

3 總結(jié)

表1列出了本方案與當(dāng)前主流方案之間在是否需要人工比對(duì)、是否滿足低成本以及是否支持并發(fā)傳輸三方面的對(duì)比：

本文雖然提出一個(gè)新的可靠性設(shè)計(jì)思想，但是并未涉及到傳輸本身數(shù)據(jù)包完整性的問題。今后工作可以將本方案與現(xiàn)有的數(shù)據(jù)包檢驗(yàn)技術(shù)結(jié)合，并可結(jié)合方案1.3中的設(shè)計(jì)思想，進(jìn)一步實(shí)現(xiàn)單向傳輸系統(tǒng)的可靠性保證。

參考文獻(xiàn)

[1] 孔斌，杜虹，馬朝斌.安全隔離與信息交換技術(shù)發(fā)展及應(yīng)用.計(jì)算機(jī)安全： 2003，7：39-42.

[2] Saitoh Y， Imai H. Some codes for correcting and detecting unidirectional byte errors， IEEE Transactions on Computers， 1993， Vol 42， Issue 5.

[3] Vaidya N F. Unidirectional error control codes， The Twenty-Third International Symposium on Digest of Papers， 22-24 June 1993， pp.120-129.

[4] T Paila， M Luby， R Lehtonen， V Roca， et al. FLUTE - File Delivery over Unidirectional Transport， Internet Engineering Task Force， RFC 3926， Oct. 2004.

[5] Jeffrey C Smith， J C Bandini. Electronic document delivery system in which notification of said electronic document is sent a recipient thereof， US6487599 B1. Nov 26， 2002.endprint

2.3 接收模塊

接收模塊主要負(fù)責(zé)如下任務(wù)：

（1）接收文件；

（2）檢驗(yàn)文件完整性；

（3）若文件正確，則獲取文件名，計(jì)算文件大小、文件哈希校驗(yàn)值（md5）等內(nèi)容，并將這些內(nèi)容添加到接收清單中；

（4）否則，記錄接收失敗日志。

2.4 內(nèi)網(wǎng)同步模塊

內(nèi)網(wǎng)同步模塊負(fù)責(zé)如下任務(wù)：

（1）接收同步文件；

（2）解析接收到的同步文件，獲取該文件指定的時(shí)間范圍與對(duì)應(yīng)的時(shí)間范圍內(nèi)成功發(fā)送的文件清單；

（3）從接收模塊獲取步驟（2）的時(shí)間范圍內(nèi)成功接收的文件清單；

（4）將步驟（2）與步驟（3）獲得的兩份清單進(jìn)行比對(duì)，獲得遺漏的文件清單與文件校驗(yàn)值不匹配的文件清單；

（5）若步驟（4）中發(fā)現(xiàn)錯(cuò)誤，則向管理員發(fā)出報(bào)警信息（如短信、郵件通知等）。

同時(shí)，該模塊還負(fù)責(zé)啟動(dòng)一個(gè)定時(shí)器，當(dāng)超過指定時(shí)間還未接收到新的同步文件，則可認(rèn)為當(dāng)前傳輸線路存在問題，則會(huì)向管理員發(fā)出報(bào)警信息。

3 總結(jié)

表1列出了本方案與當(dāng)前主流方案之間在是否需要人工比對(duì)、是否滿足低成本以及是否支持并發(fā)傳輸三方面的對(duì)比：

本文雖然提出一個(gè)新的可靠性設(shè)計(jì)思想，但是并未涉及到傳輸本身數(shù)據(jù)包完整性的問題。今后工作可以將本方案與現(xiàn)有的數(shù)據(jù)包檢驗(yàn)技術(shù)結(jié)合，并可結(jié)合方案1.3中的設(shè)計(jì)思想，進(jìn)一步實(shí)現(xiàn)單向傳輸系統(tǒng)的可靠性保證。

參考文獻(xiàn)

[1] 孔斌，杜虹，馬朝斌.安全隔離與信息交換技術(shù)發(fā)展及應(yīng)用.計(jì)算機(jī)安全： 2003，7：39-42.

[2] Saitoh Y， Imai H. Some codes for correcting and detecting unidirectional byte errors， IEEE Transactions on Computers， 1993， Vol 42， Issue 5.

[3] Vaidya N F. Unidirectional error control codes， The Twenty-Third International Symposium on Digest of Papers， 22-24 June 1993， pp.120-129.

[4] T Paila， M Luby， R Lehtonen， V Roca， et al. FLUTE - File Delivery over Unidirectional Transport， Internet Engineering Task Force， RFC 3926， Oct. 2004.

[5] Jeffrey C Smith， J C Bandini. Electronic document delivery system in which notification of said electronic document is sent a recipient thereof， US6487599 B1. Nov 26， 2002.endprint

2.3 接收模塊

接收模塊主要負(fù)責(zé)如下任務(wù)：

（1）接收文件；

（2）檢驗(yàn)文件完整性；

（3）若文件正確，則獲取文件名，計(jì)算文件大小、文件哈希校驗(yàn)值（md5）等內(nèi)容，并將這些內(nèi)容添加到接收清單中；

（4）否則，記錄接收失敗日志。

2.4 內(nèi)網(wǎng)同步模塊

內(nèi)網(wǎng)同步模塊負(fù)責(zé)如下任務(wù)：

（1）接收同步文件；

（2）解析接收到的同步文件，獲取該文件指定的時(shí)間范圍與對(duì)應(yīng)的時(shí)間范圍內(nèi)成功發(fā)送的文件清單；

（3）從接收模塊獲取步驟（2）的時(shí)間范圍內(nèi)成功接收的文件清單；

（4）將步驟（2）與步驟（3）獲得的兩份清單進(jìn)行比對(duì)，獲得遺漏的文件清單與文件校驗(yàn)值不匹配的文件清單；

（5）若步驟（4）中發(fā)現(xiàn)錯(cuò)誤，則向管理員發(fā)出報(bào)警信息（如短信、郵件通知等）。

同時(shí)，該模塊還負(fù)責(zé)啟動(dòng)一個(gè)定時(shí)器，當(dāng)超過指定時(shí)間還未接收到新的同步文件，則可認(rèn)為當(dāng)前傳輸線路存在問題，則會(huì)向管理員發(fā)出報(bào)警信息。

3 總結(jié)

表1列出了本方案與當(dāng)前主流方案之間在是否需要人工比對(duì)、是否滿足低成本以及是否支持并發(fā)傳輸三方面的對(duì)比：

本文雖然提出一個(gè)新的可靠性設(shè)計(jì)思想，但是并未涉及到傳輸本身數(shù)據(jù)包完整性的問題。今后工作可以將本方案與現(xiàn)有的數(shù)據(jù)包檢驗(yàn)技術(shù)結(jié)合，并可結(jié)合方案1.3中的設(shè)計(jì)思想，進(jìn)一步實(shí)現(xiàn)單向傳輸系統(tǒng)的可靠性保證。

參考文獻(xiàn)

[1] 孔斌，杜虹，馬朝斌.安全隔離與信息交換技術(shù)發(fā)展及應(yīng)用.計(jì)算機(jī)安全： 2003，7：39-42.

[2] Saitoh Y， Imai H. Some codes for correcting and detecting unidirectional byte errors， IEEE Transactions on Computers， 1993， Vol 42， Issue 5.

[3] Vaidya N F. Unidirectional error control codes， The Twenty-Third International Symposium on Digest of Papers， 22-24 June 1993， pp.120-129.

[4] T Paila， M Luby， R Lehtonen， V Roca， et al. FLUTE - File Delivery over Unidirectional Transport， Internet Engineering Task Force， RFC 3926， Oct. 2004.

[5] Jeffrey C Smith， J C Bandini. Electronic document delivery system in which notification of said electronic document is sent a recipient thereof， US6487599 B1. Nov 26， 2002.endprint