國產(chǎn)平臺下可靠文件傳輸軟件的設(shè)計(jì)及實(shí)現(xiàn)

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

(西昌衛(wèi)星發(fā)射中心，四川 西昌 615000)

0 引言

在測控?cái)?shù)據(jù)傳輸網(wǎng)中，通常使用基于文件交換協(xié)議(file exchange protocol，F(xiàn)XP協(xié)議)開發(fā)的文件傳輸軟件來實(shí)現(xiàn)重要文件的傳輸。隨著國產(chǎn)自主可控平臺，以及通信網(wǎng)絡(luò)的快速發(fā)展，對文件傳輸軟件提出了更多新的要求，為保證測控?cái)?shù)據(jù)在不同軟硬件平臺下的安全運(yùn)行和在不同軟硬件平臺之間文件的快速收發(fā)，對所使用的文件傳輸軟件，提出了更高的功能完備及安全可靠運(yùn)行方面的要求。通過對現(xiàn)實(shí)情況的分析，梳理出當(dāng)前傳輸網(wǎng)中使用的文件傳輸軟件存在的如下幾個(gè)問題。

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

2)通常以VC6++甚至更早的工具進(jìn)行開發(fā)，不利于軟件代碼的維護(hù)。

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

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

5)軟件運(yùn)行的穩(wěn)定性和可靠性較差，在軟件運(yùn)行及操作過程中，可能會出現(xiàn)報(bào)錯(cuò)而崩潰。

6)當(dāng)網(wǎng)絡(luò)環(huán)境較差(如丟包率高，延時(shí)大)時(shí)，傳輸?shù)奈募赡艹霈F(xiàn)不可用的情況。

7)當(dāng)網(wǎng)絡(luò)環(huán)境較好時(shí)，傳輸速率受到明顯的限制的情況。

為解決以上問題，實(shí)現(xiàn)國產(chǎn)平臺下文件傳輸?shù)目煽考案咝鬏敚谝韵聨讉€(gè)方面設(shè)計(jì)該軟件。

1)對FXP基于UDP及TCP協(xié)議進(jìn)一步二次封裝，分別實(shí)現(xiàn)基于UDP協(xié)議的快速傳輸和基于TCP協(xié)議的可靠傳輸。

2)設(shè)計(jì)軟件具備自適應(yīng)網(wǎng)絡(luò)狀態(tài)，自行決定基于UDP協(xié)議進(jìn)行快速傳輸，還是基于TCP協(xié)議進(jìn)行可靠傳輸?shù)墓δ堋?/p>

3)基于國產(chǎn)硬件和操作系統(tǒng)進(jìn)行開發(fā)。例如龍芯CPU及銀河麒麟操作系統(tǒng)等。

4)利用Qt平臺開發(fā)一套可實(shí)現(xiàn)隨處編譯的文件傳輸工具。

5)將軟件設(shè)計(jì)區(qū)分為聚焦軟件界面操作的軟件功能架構(gòu)設(shè)計(jì)和聚焦軟件后臺運(yùn)行的軟件運(yùn)行設(shè)計(jì)。

6)關(guān)注軟件安全編程，聚焦代碼的安全性、健壯性，確保軟件在運(yùn)行和功能操作過程中的穩(wěn)定性和可靠性。即重點(diǎn)闡述從軟件功能可靠實(shí)現(xiàn)和軟件穩(wěn)定運(yùn)行的兩個(gè)方面。

1 文件交換協(xié)議介紹

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

基于TCP協(xié)議時(shí)，適合在網(wǎng)絡(luò)環(huán)境較差時(shí)傳輸文件，確保文件的完整性，缺點(diǎn)是傳輸效率較低?；赨DP協(xié)議時(shí)，傳輸效率較高，適合在網(wǎng)絡(luò)環(huán)境較好時(shí)實(shí)現(xiàn)盡可能快速的傳輸文件，缺點(diǎn)是可靠性較低。

基于TCP協(xié)議的文件交換協(xié)議包含四種報(bào)文類型，分別為發(fā)送請求包、請求應(yīng)答包、數(shù)據(jù)包和結(jié)束確認(rèn)包。工作流程為：文件發(fā)送方發(fā)送發(fā)送請求包，接收方響應(yīng)請求應(yīng)答包，發(fā)送方發(fā)送數(shù)據(jù)包，接收方根據(jù)數(shù)據(jù)包的長度判斷發(fā)送是否結(jié)束，返回確認(rèn)結(jié)束包，結(jié)束流程。見圖1。

圖1 基于TCP文件收發(fā)流程圖

基于UDP協(xié)議的文件交換協(xié)議包含四種報(bào)文類型，連接包、應(yīng)答包、數(shù)據(jù)包和結(jié)束連接包。工作流程為：文件發(fā)送方發(fā)送連接包，接收方響應(yīng)應(yīng)答包，發(fā)送方發(fā)送數(shù)據(jù)包，接收方對每一幀進(jìn)行響應(yīng)，發(fā)送應(yīng)答包，發(fā)送方發(fā)送完畢，發(fā)送結(jié)束連接包，接收方響應(yīng)應(yīng)答包，結(jié)束流程。見圖2。

圖2 基于UDP文件收發(fā)流程圖

2 軟件功能完備性設(shè)計(jì)

文件傳輸軟件主要需要實(shí)現(xiàn)以下五個(gè)部分功能。

1)是重新設(shè)計(jì)軟件界面，力求方便美觀；

2)是實(shí)現(xiàn)對同F(xiàn)XP協(xié)議軟件的無縫銜接；

3)實(shí)現(xiàn)基于UDP協(xié)議在暢通網(wǎng)絡(luò)環(huán)境中的快速盡力傳輸；

4)實(shí)現(xiàn)基于TCP協(xié)議在擁塞網(wǎng)絡(luò)環(huán)境中保證文件傳輸?shù)耐暾?/p>

5)基于模塊化實(shí)現(xiàn)上述功能，方便二次調(diào)用和擴(kuò)展。

2.1 軟件界面及使用流程設(shè)計(jì)

設(shè)計(jì)軟件界面時(shí)，應(yīng)當(dāng)充分考慮用戶的操作便捷，盡量減少操作步驟及按鈕。

軟件使用流程設(shè)計(jì)[4]見圖3。

圖3 軟件使用流程

2.2 網(wǎng)絡(luò)編程分層結(jié)構(gòu)

TCP/IP分層模型是最常見的網(wǎng)絡(luò)分層模型之一，該模型將網(wǎng)絡(luò)劃分為五個(gè)層次，由上到下依次為應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層、物理層[2]?！坝缮系较隆钡拿枋?，其含義可理解為數(shù)據(jù)的發(fā)送方向，從應(yīng)用軟件至操作系統(tǒng)至網(wǎng)卡至物理鏈路(如網(wǎng)線、光纖等線纜)的一個(gè)數(shù)據(jù)傳輸方向。

TCP及UDP協(xié)議屬于五層結(jié)構(gòu)中的傳輸層，而自定義的文件傳輸協(xié)議，便是基于TCP及UDP傳輸協(xié)議的應(yīng)用層的網(wǎng)絡(luò)傳輸協(xié)議。換言之，從封裝網(wǎng)絡(luò)報(bào)文的角度分析，文件傳輸協(xié)議的報(bào)文，便是TCP或者UDP協(xié)議中的數(shù)據(jù)域內(nèi)容。

2.3 軟件功能分析及設(shè)計(jì)

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

2.3.1 傳輸可靠性設(shè)計(jì)

為保證軟件可靠性，主要采用了四個(gè)方面的設(shè)計(jì)，一是基于TCP網(wǎng)絡(luò)協(xié)議傳輸機(jī)制，二是應(yīng)答機(jī)制，三是隊(duì)列及超時(shí)重傳機(jī)制，四是自適應(yīng)網(wǎng)絡(luò)狀態(tài)機(jī)制。

2.3.1.1 基于TCP網(wǎng)絡(luò)協(xié)議傳輸機(jī)制

軟件應(yīng)當(dāng)具備TCP網(wǎng)絡(luò)傳輸機(jī)制。TCP協(xié)議是面向連接的協(xié)議，在TCP網(wǎng)絡(luò)傳輸中，包含以下設(shè)計(jì)。

1)區(qū)分客戶端和服務(wù)器端設(shè)計(jì)。由服務(wù)器端啟動監(jiān)聽，等待連接，由客戶端發(fā)起連接。

2)兩端等權(quán)設(shè)計(jì)。雖然在網(wǎng)絡(luò)傳輸層中區(qū)分服務(wù)器與客戶端，但在應(yīng)用層文件傳輸中，無論是客戶端還是服務(wù)器，都可以發(fā)起文件傳輸和接收。

3)采用功能、角色、身份三層設(shè)計(jì)。身份包含客戶端、服務(wù)器兩種身份，角色包含文件的發(fā)送者和文件的接收者兩種，功能包括發(fā)送、處理、接收各類型報(bào)文等操作。一個(gè)身份可以包含有不同的角色，一個(gè)角色可以包含有不同的功能，最終一個(gè)身份根據(jù)其所含角色及角色所含功能，形成一個(gè)身份集合，以此實(shí)現(xiàn)客戶端和服務(wù)器的區(qū)分及等權(quán)。 見圖4所示。

圖4 三層關(guān)系示意圖

2.3.1.2 應(yīng)答機(jī)制

為保證在文件傳輸?shù)倪^程中，不丟包、不重包，并且軟件發(fā)送或者接收過程中數(shù)據(jù)處理有序，設(shè)計(jì)收發(fā)流程。收發(fā)流程是指在發(fā)送者或者接受者角色中，在發(fā)送文件或者接收文件的過程中，對每一個(gè)步驟進(jìn)行編號，逐步推進(jìn)，如在某個(gè)步驟內(nèi)收到非本步驟的報(bào)文，則不予處理。采用了以下設(shè)計(jì)。

1)基于TCP協(xié)議的發(fā)送流程設(shè)計(jì)值，0代表新建進(jìn)程，1表示發(fā)送請求包階段，2表示收到請求應(yīng)答包階段，3表示在數(shù)據(jù)發(fā)送階段，4表示收到結(jié)束確認(rèn)包。見表1。

表1 基于TCP協(xié)議的發(fā)送流程設(shè)計(jì)

2)基于TCP協(xié)議的接收流程設(shè)計(jì)值，0為客戶端與服務(wù)器建立連接階段，1為接收到發(fā)送請求包階段，2為發(fā)送請求應(yīng)答包階段，3為接收數(shù)據(jù)包階段，4為發(fā)送結(jié)束確認(rèn)包階段。見表2。

表2 基于TCP協(xié)議的接收流程設(shè)計(jì)

3)基于UDP協(xié)議的發(fā)送流程設(shè)計(jì)值，0代表新建進(jìn)程，1表示已發(fā)送請求包階段，2表示收到請求應(yīng)答包階段，3表示發(fā)送數(shù)據(jù)包ASK數(shù)據(jù)階段，4表示收到數(shù)據(jù)包響應(yīng)包階段，5為發(fā)送數(shù)據(jù)包DATA數(shù)據(jù)階段，6為已發(fā)送結(jié)束確認(rèn)包階段，7為收到確認(rèn)響應(yīng)包階段。見表3。

表3 基于UDP協(xié)議的發(fā)送流程設(shè)計(jì)

4)UDP協(xié)議的接收流程設(shè)計(jì)值，0為無文件傳輸狀態(tài)，1為接收到SYN發(fā)送請求包階段，2為發(fā)送SYN應(yīng)答包階段，3為接收DATA數(shù)據(jù)包中的發(fā)送請求包階段，4為響應(yīng)階段，5為接收DATA數(shù)據(jù)包階段，6為接收到確認(rèn)結(jié)束包階段，7為發(fā)送確認(rèn)結(jié)束包階段。見表4。

表4 UDP協(xié)議的接收流程設(shè)計(jì)

5)發(fā)送者，根據(jù)接受者的響應(yīng)報(bào)文，決定是否進(jìn)入下一發(fā)送流程。

6)接受者收到報(bào)文后，根據(jù)對報(bào)文進(jìn)行報(bào)文類型、包序號等內(nèi)容進(jìn)行判斷，決定是否進(jìn)入下一流程。

2.3.1.3 隊(duì)列及超時(shí)重傳機(jī)制

文件發(fā)送者讀取并傳輸文件做如下設(shè)計(jì)。

1)將文件讀入緩存區(qū)，每次讀取指定報(bào)文長度，如4 096個(gè)字節(jié)長度的數(shù)據(jù)，讀取之后單獨(dú)開辟緩存區(qū)，在文件數(shù)據(jù)發(fā)送階段，寫入發(fā)送報(bào)文并發(fā)送。

2)在TCP協(xié)議文件傳輸階段中間過程中，無響應(yīng)報(bào)文僅在發(fā)送請求和發(fā)送結(jié)束階段進(jìn)行報(bào)文響應(yīng)。但是在文件傳輸?shù)倪^程中，每一個(gè)數(shù)據(jù)報(bào)文，都攜帶該部分?jǐn)?shù)據(jù)內(nèi)容在整個(gè)文件中所處的偏移位置。

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

圖5 響應(yīng)流程圖

4)在TCP協(xié)議中，如網(wǎng)絡(luò)傳輸中斷，導(dǎo)致客戶端與服務(wù)器重連，并重傳文件，發(fā)送者發(fā)起傳輸請求報(bào)文后，接受者回傳的響應(yīng)會攜帶文件傳輸中斷位置信息，發(fā)送者根據(jù)此信息，從文件該位置開始重傳此文件。

2.3.1.4 自適應(yīng)網(wǎng)絡(luò)狀態(tài)機(jī)制

自適應(yīng)網(wǎng)絡(luò)狀態(tài)機(jī)制，主要針對當(dāng)網(wǎng)絡(luò)狀態(tài)出現(xiàn)異常，報(bào)文傳輸在一定程度上受阻時(shí)軟件的應(yīng)對機(jī)制，該部分內(nèi)容設(shè)計(jì)專用于基于UDP進(jìn)行文件傳輸?shù)倪^程，做如下設(shè)計(jì)。

1)記錄網(wǎng)絡(luò)延時(shí)、丟包率兩個(gè)參數(shù)指標(biāo)?；赨DP進(jìn)行文件傳輸時(shí)，根據(jù)報(bào)文發(fā)送時(shí)間及接收到相應(yīng)響應(yīng)報(bào)文的時(shí)間差，作為網(wǎng)絡(luò)延時(shí)，根據(jù)發(fā)包數(shù)累計(jì)值與收包數(shù)累計(jì)值之差為丟包數(shù)，除以發(fā)包累計(jì)值，作為丟包率。每次接收報(bào)文時(shí)，將計(jì)算相應(yīng)的網(wǎng)絡(luò)延時(shí)和丟包率并連同計(jì)算時(shí)間及接收方地址存入數(shù)據(jù)庫。

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

3)計(jì)算時(shí)延抖動。選取最近的6次網(wǎng)絡(luò)延時(shí)值，計(jì)算方差，作為時(shí)延抖動。

4)根據(jù)網(wǎng)絡(luò)延時(shí)、丟包率、時(shí)延抖動三個(gè)指標(biāo)綜合判斷[3]網(wǎng)絡(luò)狀態(tài)。將網(wǎng)絡(luò)狀態(tài)分為正常、干擾、阻塞、穩(wěn)定四個(gè)狀態(tài)。正常狀態(tài)時(shí)，將超時(shí)重傳等待時(shí)間值減去10毫秒，但必須大于0值，干擾狀態(tài)時(shí)，將超時(shí)重傳等待時(shí)間值加上10毫秒，阻塞狀態(tài)時(shí)，將超時(shí)重傳等待時(shí)間增加一倍，穩(wěn)定狀態(tài)時(shí)，不作操作。

2.3.2 效率設(shè)計(jì)

為保證軟件的文件傳輸效率，采用了三個(gè)方面的設(shè)計(jì)，一是自適應(yīng)網(wǎng)絡(luò)狀態(tài)機(jī)制，二是數(shù)據(jù)處理多線程機(jī)制，三是數(shù)據(jù)驅(qū)動處理數(shù)據(jù)報(bào)文機(jī)制。

1)自適應(yīng)網(wǎng)絡(luò)狀態(tài)機(jī)制。滑動窗口[5]設(shè)計(jì)，自適應(yīng)網(wǎng)絡(luò)狀態(tài)機(jī)制在可靠性設(shè)計(jì)中已陳述主要內(nèi)容，在效率設(shè)計(jì)方面的考慮，即當(dāng)網(wǎng)絡(luò)狀態(tài)恢復(fù)時(shí)，會適當(dāng)減少超時(shí)重傳時(shí)間，以加快網(wǎng)絡(luò)報(bào)文傳輸效率。

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

3)數(shù)據(jù)驅(qū)動處理數(shù)據(jù)報(bào)文機(jī)制。在多線程的基礎(chǔ)上，定義一個(gè)全局的數(shù)據(jù)容器。當(dāng)數(shù)據(jù)接受者從主線程接收到數(shù)據(jù)后，將數(shù)據(jù)放入數(shù)據(jù)容器，在數(shù)據(jù)處理線程利用while函數(shù)無限循環(huán)，不斷判斷數(shù)據(jù)容器是否為空，非空則處理數(shù)據(jù)，處理完則將該部分?jǐn)?shù)據(jù)扔出容器。

2.3.3 模塊化設(shè)計(jì)

在軟件中，根據(jù)功能，角色，身份三層管理的設(shè)計(jì)，將三個(gè)方面的內(nèi)容逐層實(shí)現(xiàn)模塊化，在別處可根據(jù)需求通過接口調(diào)用即可方便使用。

2.3.3.1 發(fā)送者和接受者角色模塊化

根據(jù)發(fā)送者和接受者的角色區(qū)分，以及TCP和UDP的功能區(qū)分，可以設(shè)計(jì)為TCP發(fā)送者類、TCP接受者類、UDP發(fā)送者類、UDP接受者類四個(gè)模塊，實(shí)現(xiàn)數(shù)據(jù)報(bào)文的發(fā)送、處理、接收功能。

2.3.3.2 客戶端和服務(wù)器的身份模塊化

根據(jù)客戶端和服務(wù)器的身份區(qū)分，并根據(jù)發(fā)送者和接受者角色區(qū)分，可以分為客戶端類、服務(wù)器類、UDP收發(fā)類三個(gè)模塊，分別實(shí)現(xiàn)客戶端、服務(wù)器及UDP收發(fā)的功能。

2.3.3.3 重寫界面顯示類

為實(shí)時(shí)顯示文件發(fā)送和接收進(jìn)度，實(shí)現(xiàn)文件拖曳上傳等輔助性功能，重寫一個(gè)繼承自QTableWidget的類，作為顯示模塊，在調(diào)用時(shí)，只需要將控件提升為自定義類即可。

2.3.3.4 集成工具類

為方便調(diào)用，設(shè)計(jì)一系列自定義工具類，實(shí)現(xiàn)數(shù)據(jù)庫相關(guān)操作的數(shù)據(jù)庫類、實(shí)現(xiàn)自適應(yīng)網(wǎng)絡(luò)狀態(tài)的網(wǎng)絡(luò)質(zhì)量保障控制類以及實(shí)現(xiàn)讀取XML預(yù)配置參數(shù)的讀取類。

2.3.4 兼容性設(shè)計(jì)

為實(shí)現(xiàn)軟件部署方便，提高可移植性，需要盡量減少對環(huán)境因素的依賴，做以下三方面設(shè)計(jì)。

1)部署簡單。最后發(fā)布的軟件版本應(yīng)該將其依賴庫統(tǒng)一發(fā)布。

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

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

2.3.5 易用性設(shè)計(jì)

為實(shí)現(xiàn)交互界面的優(yōu)化，有以下三方面設(shè)計(jì)。

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

2)設(shè)置預(yù)配置項(xiàng)。將部分不常修改的配置內(nèi)容，作為預(yù)配置項(xiàng)，通過修改xml文件進(jìn)行修改，如本地監(jiān)聽端口，報(bào)文長度等配置。

3)無感化運(yùn)行?？蓪④浖钚』镣斜P，并在后臺運(yùn)行，接收文件。

3 軟件運(yùn)行安全穩(wěn)定性設(shè)計(jì)

為保證軟件穩(wěn)定可靠運(yùn)行，避免因代碼編寫或邏輯上錯(cuò)誤導(dǎo)致軟件崩潰，對軟件安全編程內(nèi)容做一些設(shè)計(jì)，以進(jìn)一步提升軟件運(yùn)行可靠。

3.1 安全編程概念

應(yīng)用軟件安全編程，是從提升軟件安全性的角度，依照《GB-T 38674-2020 信息安全技術(shù) 應(yīng)用軟件安全編程指南》等應(yīng)用軟件安全編程規(guī)范性引用文件，針對應(yīng)用軟件編程過程進(jìn)行規(guī)范，實(shí)現(xiàn)軟件開發(fā)全過程的指導(dǎo)，以達(dá)到有效降低軟件安全風(fēng)險(xiǎn)的目的。

3.2 安全編程設(shè)計(jì)

3.2.1 報(bào)文組幀拆幀設(shè)計(jì)

在軟件中，涉及到大量的報(bào)文的組幀和拆幀，在此類操作中，應(yīng)當(dāng)先將所有報(bào)文根據(jù)其報(bào)文類型及報(bào)文中不同字段的數(shù)據(jù)類型和含義，先設(shè)計(jì)成一個(gè)結(jié)構(gòu)體，當(dāng)處理到報(bào)文的組幀或者拆幀時(shí)，只需將指定長度的數(shù)據(jù)賦值給同樣長度的結(jié)構(gòu)體即可。結(jié)構(gòu)體主要可分為兩種類型，一是定長結(jié)構(gòu)體，二是不定長結(jié)構(gòu)體。在軟件中，傳輸文件數(shù)據(jù)的報(bào)文設(shè)計(jì)為不定長結(jié)構(gòu)體，因其最后一幀不一定為完整的一幀，除此之外的報(bào)文，都是定長結(jié)構(gòu)體。

3.2.2 報(bào)文賦值操作設(shè)計(jì)

在軟件中，涉及到大量的數(shù)據(jù)內(nèi)容賦值，主要涉及到將接收到的數(shù)據(jù)賦值給相應(yīng)結(jié)構(gòu)體，將結(jié)構(gòu)體中的數(shù)據(jù)賦值給報(bào)文以發(fā)送兩個(gè)操作，在此過程中，如涉及到指針的賦值，避免使用strcpy()等不能指定賦值長度的函數(shù)，因?yàn)榇祟惡瘮?shù)通常認(rèn)為“

鄂托克旗| 缙云县| 泗阳县| 桦甸市| 高碑店市| 德令哈市| 民县| 临沭县| 通山县| 襄垣县| 伊吾县| 阿荣旗| 虹口区| 达拉特旗| 崇阳县| 杭锦旗| 外汇| 微山县| 沛县| 临汾市| 安丘市| 那曲县| 密云县| 会理县| 社旗县| 仙游县| 本溪市| 漳浦县| 大邑县| 玉林市| 灌云县| 孝感市| 乐至县| 石棉县| 剑川县| 大荔县| 澄迈县| 平度市| 新化县| 牡丹江市| 曲周县|