國產平臺下可靠文件傳輸軟件的設計及實現

2023-08-03 00:31:54虞炳文龔建澤丁思煒袁化宇

計算機測量與控制 2023年7期

關鍵詞：設計

虞炳文，龔建澤，丁思煒，王益，袁化宇

(西昌衛星發射中心，四川西昌 615000)

0 引言

在測控數據傳輸網中，通常使用基于文件交換協議(file exchange protocol，FXP協議)開發的文件傳輸軟件來實現重要文件的傳輸。隨著國產自主可控平臺，以及通信網絡的快速發展，對文件傳輸軟件提出了更多新的要求，為保證測控數據在不同軟硬件平臺下的安全運行和在不同軟硬件平臺之間文件的快速收發，對所使用的文件傳輸軟件，提出了更高的功能完備及安全可靠運行方面的要求。通過對現實情況的分析，梳理出當前傳輸網中使用的文件傳輸軟件存在的如下幾個問題。

1)通常僅支持在windows平臺下使用，代碼不支持跨平臺編譯使用。此處平臺指不同型號CPU與不同操作系統的搭配。

2)通常以VC6++甚至更早的工具進行開發，不利于軟件代碼的維護。

3)不支持在不同平臺之間傳輸文件。

4)軟件界面的易用性和美觀性較差。

5)軟件運行的穩定性和可靠性較差，在軟件運行及操作過程中，可能會出現報錯而崩潰。

6)當網絡環境較差(如丟包率高，延時大)時，傳輸的文件可能出現不可用的情況。

7)當網絡環境較好時，傳輸速率受到明顯的限制的情況。

為解決以上問題，實現國產平臺下文件傳輸的可靠及高效傳輸，在以下幾個方面設計該軟件。

1)對FXP基于UDP及TCP協議進一步二次封裝，分別實現基于UDP協議的快速傳輸和基于TCP協議的可靠傳輸。

2)設計軟件具備自適應網絡狀態，自行決定基于UDP協議進行快速傳輸，還是基于TCP協議進行可靠傳輸的功能。

3)基于國產硬件和操作系統進行開發。例如龍芯CPU及銀河麒麟操作系統等。

4)利用Qt平臺開發一套可實現隨處編譯的文件傳輸工具。

5)將軟件設計區分為聚焦軟件界面操作的軟件功能架構設計和聚焦軟件后臺運行的軟件運行設計。

6)關注軟件安全編程，聚焦代碼的安全性、健壯性，確保軟件在運行和功能操作過程中的穩定性和可靠性。即重點闡述從軟件功能可靠實現和軟件穩定運行的兩個方面。

1 文件交換協議介紹

文件交換協議，即FXP協議，該協議支持對等的端到端文件交換，基于傳輸層TCP或UDP協議(基于UDP協議時，需與RECP協議配合使用，RECP即傳輸質量保障協議)，完成應用層數據的組包、解包以及應用層的協議控制[1]。

基于TCP協議時，適合在網絡環境較差時傳輸文件，確保文件的完整性，缺點是傳輸效率較低。基于UDP協議時，傳輸效率較高，適合在網絡環境較好時實現盡可能快速的傳輸文件，缺點是可靠性較低。

基于TCP協議的文件交換協議包含四種報文類型，分別為發送請求包、請求應答包、數據包和結束確認包。工作流程為：文件發送方發送發送請求包，接收方響應請求應答包，發送方發送數據包，接收方根據數據包的長度判斷發送是否結束，返回確認結束包，結束流程。見圖1。

圖1 基于TCP文件收發流程圖

基于UDP協議的文件交換協議包含四種報文類型，連接包、應答包、數據包和結束連接包。工作流程為：文件發送方發送連接包，接收方響應應答包，發送方發送數據包，接收方對每一幀進行響應，發送應答包，發送方發送完畢，發送結束連接包，接收方響應應答包，結束流程。見圖2。

圖2 基于UDP文件收發流程圖

2 軟件功能完備性設計

文件傳輸軟件主要需要實現以下五個部分功能。

1)是重新設計軟件界面，力求方便美觀；

2)是實現對同FXP協議軟件的無縫銜接；

3)實現基于UDP協議在暢通網絡環境中的快速盡力傳輸；

4)實現基于TCP協議在擁塞網絡環境中保證文件傳輸的完整；

5)基于模塊化實現上述功能，方便二次調用和擴展。

2.1 軟件界面及使用流程設計

設計軟件界面時，應當充分考慮用戶的操作便捷，盡量減少操作步驟及按鈕。

軟件使用流程設計[4]見圖3。

圖3 軟件使用流程

2.2 網絡編程分層結構

TCP/IP分層模型是最常見的網絡分層模型之一，該模型將網絡劃分為五個層次，由上到下依次為應用層、傳輸層、網絡層、數據鏈路層、物理層[2]。“由上到下”的描述，其含義可理解為數據的發送方向，從應用軟件至操作系統至網卡至物理鏈路(如網線、光纖等線纜)的一個數據傳輸方向。

TCP及UDP協議屬于五層結構中的傳輸層，而自定義的文件傳輸協議，便是基于TCP及UDP傳輸協議的應用層的網絡傳輸協議。換言之，從封裝網絡報文的角度分析，文件傳輸協議的報文，便是TCP或者UDP協議中的數據域內容。

2.3 軟件功能分析及設計

文件傳輸軟件應當具備以下特點。一是可靠傳輸，即便在較差網絡狀態下進行文件傳輸，也能保證文件接收完整；二是高效傳輸，盡可能多地設計并行傳輸機制，減少數據包排隊等待的時間；三是模塊化，封裝成函數庫，以便在其它軟件開發調用時盡量減少代碼的重寫，提高開發效率；四是部署簡單，盡量減少對運行環境的依賴，做到隨處部署；五是使用簡單，人機交互合理，實現同一功能，盡可能減少鼠標點擊次數，顯示盡可能多的提示信息，并且通過后臺托盤等設計，實現無感化運行；六是部分參數可預配置，避免每次啟動軟件需要重新設置參數值。

2.3.1 傳輸可靠性設計

為保證軟件可靠性，主要采用了四個方面的設計，一是基于TCP網絡協議傳輸機制，二是應答機制，三是隊列及超時重傳機制，四是自適應網絡狀態機制。

2.3.1.1 基于TCP網絡協議傳輸機制

軟件應當具備TCP網絡傳輸機制。TCP協議是面向連接的協議，在TCP網絡傳輸中，包含以下設計。

1)區分客戶端和服務器端設計。由服務器端啟動監聽，等待連接，由客戶端發起連接。

2)兩端等權設計。雖然在網絡傳輸層中區分服務器與客戶端，但在應用層文件傳輸中，無論是客戶端還是服務器，都可以發起文件傳輸和接收。

3)采用功能、角色、身份三層設計。身份包含客戶端、服務器兩種身份，角色包含文件的發送者和文件的接收者兩種，功能包括發送、處理、接收各類型報文等操作。一個身份可以包含有不同的角色，一個角色可以包含有不同的功能，最終一個身份根據其所含角色及角色所含功能，形成一個身份集合，以此實現客戶端和服務器的區分及等權。見圖4所示。

圖4 三層關系示意圖

2.3.1.2 應答機制

為保證在文件傳輸的過程中，不丟包、不重包，并且軟件發送或者接收過程中數據處理有序，設計收發流程。收發流程是指在發送者或者接受者角色中，在發送文件或者接收文件的過程中，對每一個步驟進行編號，逐步推進，如在某個步驟內收到非本步驟的報文，則不予處理。采用了以下設計。

1)基于TCP協議的發送流程設計值，0代表新建進程，1表示發送請求包階段，2表示收到請求應答包階段，3表示在數據發送階段，4表示收到結束確認包。見表1。

表1 基于TCP協議的發送流程設計

2)基于TCP協議的接收流程設計值，0為客戶端與服務器建立連接階段，1為接收到發送請求包階段，2為發送請求應答包階段，3為接收數據包階段，4為發送結束確認包階段。見表2。

表2 基于TCP協議的接收流程設計

3)基于UDP協議的發送流程設計值，0代表新建進程，1表示已發送請求包階段，2表示收到請求應答包階段，3表示發送數據包ASK數據階段，4表示收到數據包響應包階段，5為發送數據包DATA數據階段，6為已發送結束確認包階段，7為收到確認響應包階段。見表3。

表3 基于UDP協議的發送流程設計

4)UDP協議的接收流程設計值，0為無文件傳輸狀態，1為接收到SYN發送請求包階段，2為發送SYN應答包階段，3為接收DATA數據包中的發送請求包階段，4為響應階段，5為接收DATA數據包階段，6為接收到確認結束包階段，7為發送確認結束包階段。見表4。

表4 UDP協議的接收流程設計

5)發送者，根據接受者的響應報文，決定是否進入下一發送流程。

6)接受者收到報文后，根據對報文進行報文類型、包序號等內容進行判斷，決定是否進入下一流程。

2.3.1.3 隊列及超時重傳機制

文件發送者讀取并傳輸文件做如下設計。

1)將文件讀入緩存區，每次讀取指定報文長度，如4 096個字節長度的數據，讀取之后單獨開辟緩存區，在文件數據發送階段，寫入發送報文并發送。

2)在TCP協議文件傳輸階段中間過程中，無響應報文僅在發送請求和發送結束階段進行報文響應。但是在文件傳輸的過程中，每一個數據報文，都攜帶該部分數據內容在整個文件中所處的偏移位置。

3)在UDP協議中，接收者會對發送者的每一個報文進行響應，發送者會根據響應報文信息，決定是否改變所處發送流程的階段，在此做一些超時設計，如果在指定的時間內未收到響應報文，或者響應報文內容檢查(主要為包序號的檢查)不通過，則會將此報文掛起，啟動定時器，進行該報文的定時重傳，而流程也不會進入下一階段。直到收到指定包序號的響應報文，才會繼續發送下一報文。見圖5。

圖5 響應流程圖

4)在TCP協議中，如網絡傳輸中斷，導致客戶端與服務器重連，并重傳文件，發送者發起傳輸請求報文后，接受者回傳的響應會攜帶文件傳輸中斷位置信息，發送者根據此信息，從文件該位置開始重傳此文件。

2.3.1.4 自適應網絡狀態機制

自適應網絡狀態機制，主要針對當網絡狀態出現異常，報文傳輸在一定程度上受阻時軟件的應對機制，該部分內容設計專用于基于UDP進行文件傳輸的過程，做如下設計。

1)記錄網絡延時、丟包率兩個參數指標。基于UDP進行文件傳輸時，根據報文發送時間及接收到相應響應報文的時間差，作為網絡延時，根據發包數累計值與收包數累計值之差為丟包數，除以發包累計值，作為丟包率。每次接收報文時，將計算相應的網絡延時和丟包率并連同計算時間及接收方地址存入數據庫。

2)外推下一時刻的網絡延時和丟包率，作為網絡狀態的判別依據。在此提及的下一時刻，以設定的超時重傳界限值作為時間長度。選取最近的6次記錄數據，根據最小二乘法，進行曲線擬合，可選用二階、三階、四階等進行擬合。

3)計算時延抖動。選取最近的6次網絡延時值，計算方差，作為時延抖動。

4)根據網絡延時、丟包率、時延抖動三個指標綜合判斷[3]網絡狀態。將網絡狀態分為正常、干擾、阻塞、穩定四個狀態。正常狀態時，將超時重傳等待時間值減去10毫秒，但必須大于0值，干擾狀態時，將超時重傳等待時間值加上10毫秒，阻塞狀態時，將超時重傳等待時間增加一倍，穩定狀態時，不作操作。

2.3.2 效率設計

為保證軟件的文件傳輸效率，采用了三個方面的設計，一是自適應網絡狀態機制，二是數據處理多線程機制，三是數據驅動處理數據報文機制。

1)自適應網絡狀態機制。滑動窗口[5]設計，自適應網絡狀態機制在可靠性設計中已陳述主要內容，在效率設計方面的考慮，即當網絡狀態恢復時，會適當減少超時重傳時間，以加快網絡報文傳輸效率。

2)數據處理多線程機制。多線程機制主要針對兩種情況做處理，一是在TCP服務器端設計可同時接收多個客戶端的連接，接收處理不同數據發送者發來的數據，二是將數據處理線程獨立出來，加快效率。

3)數據驅動處理數據報文機制。在多線程的基礎上，定義一個全局的數據容器。當數據接受者從主線程接收到數據后，將數據放入數據容器，在數據處理線程利用while函數無限循環，不斷判斷數據容器是否為空，非空則處理數據，處理完則將該部分數據扔出容器。

2.3.3 模塊化設計

在軟件中，根據功能，角色，身份三層管理的設計，將三個方面的內容逐層實現模塊化，在別處可根據需求通過接口調用即可方便使用。

2.3.3.1 發送者和接受者角色模塊化

根據發送者和接受者的角色區分，以及TCP和UDP的功能區分，可以設計為TCP發送者類、TCP接受者類、UDP發送者類、UDP接受者類四個模塊，實現數據報文的發送、處理、接收功能。

2.3.3.2 客戶端和服務器的身份模塊化

根據客戶端和服務器的身份區分，并根據發送者和接受者角色區分，可以分為客戶端類、服務器類、UDP收發類三個模塊，分別實現客戶端、服務器及UDP收發的功能。

2.3.3.3 重寫界面顯示類

為實時顯示文件發送和接收進度，實現文件拖曳上傳等輔助性功能，重寫一個繼承自QTableWidget的類，作為顯示模塊，在調用時，只需要將控件提升為自定義類即可。

2.3.3.4 集成工具類

為方便調用，設計一系列自定義工具類，實現數據庫相關操作的數據庫類、實現自適應網絡狀態的網絡質量保障控制類以及實現讀取XML預配置參數的讀取類。

2.3.4 兼容性設計

為實現軟件部署方便，提高可移植性，需要盡量減少對環境因素的依賴，做以下三方面設計。

1)部署簡單。最后發布的軟件版本應該將其依賴庫統一發布。

2)輕量級數據庫。為避免對環境數據庫的依賴，不采用mysql等需要安裝部署的數據庫，采用Qsqlite數據庫。

3)區分系統加入不同的庫。在調用系統自帶的庫實現一些功能時，可能會出現適配的問題，因此需要采用#if defined(Q_OS_WIN32)，#else，#endif語句，對庫的調用加上限制條件。

2.3.5 易用性設計

為實現交互界面的優化，有以下三方面設計。

1)精簡界面按鈕。盡量減少界面中的點擊按鈕，僅保留選擇文件、發送、啟動監聽、連接服務器四種類型按鈕。

2)設置預配置項。將部分不常修改的配置內容，作為預配置項，通過修改xml文件進行修改，如本地監聽端口，報文長度等配置。

3)無感化運行。可將軟件最小化至托盤，并在后臺運行，接收文件。

3 軟件運行安全穩定性設計

為保證軟件穩定可靠運行，避免因代碼編寫或邏輯上錯誤導致軟件崩潰，對軟件安全編程內容做一些設計，以進一步提升軟件運行可靠。

3.1 安全編程概念

應用軟件安全編程，是從提升軟件安全性的角度，依照《GB-T 38674-2020 信息安全技術應用軟件安全編程指南》等應用軟件安全編程規范性引用文件，針對應用軟件編程過程進行規范，實現軟件開發全過程的指導，以達到有效降低軟件安全風險的目的。

3.2 安全編程設計

3.2.1 報文組幀拆幀設計

在軟件中，涉及到大量的報文的組幀和拆幀，在此類操作中，應當先將所有報文根據其報文類型及報文中不同字段的數據類型和含義，先設計成一個結構體，當處理到報文的組幀或者拆幀時，只需將指定長度的數據賦值給同樣長度的結構體即可。結構體主要可分為兩種類型，一是定長結構體，二是不定長結構體。在軟件中，傳輸文件數據的報文設計為不定長結構體，因其最后一幀不一定為完整的一幀，除此之外的報文，都是定長結構體。

3.2.2 報文賦值操作設計

在軟件中，涉及到大量的數據內容賦值，主要涉及到將接收到的數據賦值給相應結構體，將結構體中的數據賦值給報文以發送兩個操作，在此過程中，如涉及到指針的賦值，避免使用strcpy()等不能指定賦值長度的函數，因為此類函數通常認為“