李紅衛(wèi) 蔣祖星

（廣東交通職業(yè)技術(shù)學院 廣州 510800）

1 引言

TCP協(xié)議（Transport Control Protocol）是一種端到端的、基于連接的、可靠的傳輸層控制協(xié)議。通過端到端的有序數(shù)據(jù)傳輸與反饋機制，為上層應(yīng)用提供了可靠的數(shù)據(jù)傳輸保障。

戰(zhàn)術(shù)互聯(lián)網(wǎng)絡(luò)的協(xié)議結(jié)構(gòu)比較復(fù)雜，它涉及到物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層以及應(yīng)用層所使用的網(wǎng)絡(luò)協(xié)議和接口［1］。TCP協(xié)議是保障可靠通信的關(guān)鍵部分，對于利用網(wǎng)絡(luò)進行通信的兩個終端來說，端到端通信的可靠性最終還是要由傳輸控制協(xié)議來解決。

圖1 TCP數(shù)據(jù)傳輸丟包與窗口變化示意圖

傳統(tǒng)的TCP協(xié)議是為有線網(wǎng)絡(luò)設(shè)計的，適用于差錯率低的有線網(wǎng)絡(luò)。與有線網(wǎng)絡(luò)相比，無線網(wǎng)絡(luò)通常表現(xiàn)出誤碼率高、多徑傳輸、移動終端的頻繁移動等特性，而戰(zhàn)術(shù)互聯(lián)網(wǎng)這些特性則體現(xiàn)的更為突出［2］，如圖1所示。這使得傳統(tǒng)的TCP協(xié)議直接用于戰(zhàn)術(shù)互聯(lián)網(wǎng)環(huán)境下時性能很差。所以如何提高TCP協(xié)議在戰(zhàn)術(shù)互聯(lián)網(wǎng)中的性能成為重要研究課題。

2 TCP協(xié)議傳輸速率影響因素

影響TCP傳輸速率的因素包括兩個方面：1）TCP協(xié)議所采用的算法、緩存大小等；2）網(wǎng)絡(luò)自身的狀況，包括最大傳輸速率、傳輸時延和丟包率等。

2.1 TCP協(xié)議影響

1）ACK機制

傳統(tǒng)的TCP協(xié)議采用的是積累ACK反饋機制，如果出現(xiàn)丟包，則持續(xù)反饋丟包前收到的數(shù)據(jù)的最后的序號（實際上也為丟失包的起始序號）。這導致在長時延的鏈路中，發(fā)送方在接收到丟包的ACK后的一個RTT的時間內(nèi)，都只能知道接收方已收到丟包前的數(shù)據(jù)。SACK（選擇確認）通過在TCP選項中告知發(fā)送端已經(jīng)收到的多個數(shù)據(jù)報區(qū)間，以此向發(fā)送端通告丟包、亂序等網(wǎng)絡(luò)狀況的出現(xiàn)。顯然相比采用積累ACK反饋機制，當出現(xiàn)丟包時，發(fā)送端能夠更及時地判斷網(wǎng)絡(luò)狀況以調(diào)整發(fā)送速率。

在許多針對衛(wèi)星鏈路的TCP傳輸優(yōu)化中，使用了SNACK技術(shù)。SNACK與SACK的作用是相似的，但是SNACK向發(fā)送端反饋傳輸序列中出現(xiàn)空洞，這與SACK正好相反。在Linux內(nèi)核中默認開啟SACK選項，但還沒有SNACK模塊可被使用。在SCPS_TP的實現(xiàn)中，使用了SNACK，其與SACK的性能比較還需要進一步探究［3］。

2）擁塞控制算法

TCP協(xié)議所采用的擁塞控制算法決定了當傳輸序列出錯（丟包、亂序）時，TCP的發(fā)送窗口的變化情況。傳統(tǒng)的TCP協(xié)議采用了Reno算法，該算法假設(shè)丟包皆由網(wǎng)絡(luò)擁塞導致，這在有線信道上是有效的，但是在無線信道上難以獲得良好的傳輸效率。當前的Linux內(nèi)核默認采用Cubic算法，該算法通過提高小窗口發(fā)送速率，盡早占用可用帶寬，同時減緩大窗口發(fā)送速率，延緩擁塞發(fā)生時間［4］。在PEPsal中推薦使用Vegas算法作為長時延鏈路的TCP擁塞控制算法，Vegas算法核心在于將傳輸速率獨立于時延差異，使長時延對鏈路的影響由響應(yīng)的擁塞控制參數(shù)補償。其他擁塞控制算法還包括Veno、Westwood、HSTCP等。

由于鏈路特性的不同，相適應(yīng)的擁塞控制算法也不同，因此應(yīng)當針對戰(zhàn)術(shù)通信網(wǎng)絡(luò)的特點來選擇合適的擁塞控制算法。

3）窗口緩存

TCP協(xié)議通過窗口緩存的大小來控制數(shù)據(jù)傳輸?shù)乃俾?。在?shù)據(jù)傳輸過程中，TCP協(xié)議通過擁塞控制算法來調(diào)整窗口的大小，同時系統(tǒng)也設(shè)置了對于窗口緩存的限制。可以通過簡單計算，得出在一定網(wǎng)絡(luò)條件下，達到一定發(fā)送速率所需的窗口緩存下限。在無差錯的鏈路中，無論采用哪種ACK機制，發(fā)送端只有收到接收端的ACK反饋才能進行窗口移動；假設(shè)網(wǎng)絡(luò)往返時延為RTT，若期望的發(fā)送速率為S，則發(fā)送窗口只有大于S*RTT才能持續(xù)保持S的發(fā)送速率。若在鏈路中出現(xiàn)一個丟包，發(fā)送端在1/2*RTT時間之后才能進行重傳，若采用積累ACK機制，發(fā)送端在丟包后的3/2*RTT時間才能夠獲知新的ACK反饋并進行窗口調(diào)整。如圖2所示，此時占用發(fā)送窗口的數(shù)據(jù)量為2*RTT，因此采用積累ACK機制，出現(xiàn)丟包時，發(fā)送窗口需要至少2*RTT*S才能維持S的發(fā)送速率。若在丟包后的RTT時間內(nèi)再次丟包，則發(fā)送窗口大于2*RTT*S才能維持S的發(fā)送速率。

若改用SACK或SNACK，由于在通告丟包的同時，也對后續(xù)的數(shù)據(jù)包進行了確認，發(fā)送端能夠更及時地調(diào)整發(fā)送窗口，因此，使用較小的發(fā)送窗口即可維持較高的發(fā)送速率［5］。

圖2 TCP數(shù)據(jù)傳輸丟包與窗口變化示意圖

4）其他擴展選項

TCP協(xié)議的一些擴展選項也有助于提高TCP傳輸效率。（1）窗口擴大選項：如果要使用大于2^16Bytes的窗口，需要在連接建立時通過窗口擴大選項來進行協(xié)商。（2）時間戳選項：時間戳選項使發(fā)送端在每個報文段中放置一個時間戳值，接收方在確認中返回這個數(shù)值，從而允許發(fā)送方為每一個收到的ACK計算RTT。對于部分擁塞控制算法，如果能夠獲得精確的RTT值，則能夠進行更有效的擁塞控制。

2.2 網(wǎng)絡(luò)狀況影響

網(wǎng)絡(luò)狀況在此主要考慮三方面的因素：1）鏈路最大速率；2）鏈路往返時延（RTT）；3）鏈路丟包率。這三方面會對TCP連接的傳輸速率產(chǎn)生綜合性的影響。

鏈路速率和往返時延的增大都增加鏈路中數(shù)據(jù)的容量（更寬或更長的管道），如2.1節(jié)所述，發(fā)送端維持發(fā)送速率所需的發(fā)送窗口緩存大小與鏈路中容納的數(shù)據(jù)量直接相關(guān)。在丟包率一定的情況下，鏈路中容納的數(shù)據(jù)報越多，也意味著單位RTT時間內(nèi)丟失的包也越多，對于采用SACK或SNACK機制的TCP連接，SACK或SNACK能夠通告的丟包數(shù)量是有限的（因為TCP首部選項長度有限），如果RTT時間內(nèi)丟包數(shù)量超過限度，則不得不因為發(fā)送窗口緩存的耗盡而降低發(fā)送速率［6］。在TCP擁塞控制算法的研究中，給出了傳輸速率、傳輸時延、擁塞窗口與丟包率之間的關(guān)系。其中傳輸速率、傳輸時延、擁塞窗口之間的關(guān)系為。其中x(t)、w(t)及T(t)分別表示時間t時的傳輸速率，窗口大小和傳輸時延RTT。

由上述關(guān)系可知，在時延增大的情況下，維持相同的傳輸速率所需要擁塞窗口更大，所期望的丟包更低。

3 民用TCP加速代理

如第2節(jié)中所述，在異構(gòu)網(wǎng)絡(luò)中，需要依據(jù)不同的網(wǎng)絡(luò)環(huán)境設(shè)置合適的TCP配置，才能獲得良好的傳輸效率。由于TCP的連接和傳輸控制過程并不依賴于上層應(yīng)用，僅需要TCP首部中的信息，因此可以在異構(gòu)網(wǎng)絡(luò)中鏈路中插入代理節(jié)點，將TCP連接分為多段，在不同的網(wǎng)絡(luò)中針對網(wǎng)絡(luò)特性配置TCP參數(shù)，提高不同網(wǎng)絡(luò)中的傳輸效率［7］。使用TCP代理優(yōu)化的優(yōu)勢還包括：1）逐段可靠保障：由于需要在代理兩側(cè)的網(wǎng)段上分別建立了TCP連接，因此在代理節(jié)點實際對TCP數(shù)據(jù)報進行緩存，也即實現(xiàn)了TCP數(shù)據(jù)的逐段可靠保障；2）鏈路狀況隔離：一條連接所經(jīng)過的鏈路可能有不同的MTU，傳輸速率等，連接只能適配所有鏈路的最差情況，選擇最小的MTU和最低的傳輸速率；通過代理進行TCP分段，能夠屏蔽不同鏈路的差異，選擇適合當前鏈路配置進行傳輸。

3.1 單邊代理優(yōu)化

單邊代理優(yōu)化是僅在鏈路中靠近發(fā)送端一側(cè)加入TCP代理優(yōu)化節(jié)點（或模塊）。通常通過配置優(yōu)化的TCP擁塞控制算法來提高發(fā)送端的TCP傳輸效率，例如在長距廣域互聯(lián)網(wǎng)中使用FastTCP、ZetaTCP等模塊以提高TCP速率。PEPsal（PerformanceEnhancingProxyforSatelliteLink）是針對衛(wèi)星鏈路長時延特性進行TCP代理優(yōu)化的軟件，其設(shè)計作為可單邊插入發(fā)送側(cè)，為包含衛(wèi)星鏈路的長時延側(cè)進行TCP代理優(yōu)化的軟件。PEPsal本身僅包含建立和維系TCP連接的功能，TCP傳輸及擁塞控制依然交由Linux內(nèi)核中的TCP協(xié)議棧。通過實驗測試，配置TCP協(xié)議棧使用Vegas擁塞控制算法，在一定丟包率情況下能夠獲得比Cubic算法更好的TCP傳輸效率［8］。

圖3 PEPsal單邊加速部署圖

單邊代理優(yōu)化的優(yōu)勢在于，配置簡單，僅需要在發(fā)送端進行配置。其劣勢在于僅能對TCP協(xié)議中的擁塞控制算法進行修改，由于ACK機制和窗口緩存大小需要接收端配合，因此無法修改。對于廣泛使用的WindowsXP操作系統(tǒng)，其默認僅支持基礎(chǔ)的TCP協(xié)議，如積累的ACK機制和16位的擁塞窗口，這導致了單邊代理無法使用SACK/SNACK機制、更大的窗口緩存以及時間戳等配置來提高TCP的傳輸效率。

3.2 雙邊代理優(yōu)化

為了克服單邊代理優(yōu)化的劣勢，在特殊鏈路的兩端，均配置TCP優(yōu)化代理，將TCP連接分為三段。在包含特殊鏈路的TCP連接段，由于兩端均使用優(yōu)化代理，因此能夠針對特殊鏈路的特性配置TCP協(xié)議，使該段的TCP傳輸效率最大化。SCPS_TP（SPACECOMMUNICATIONSPROTOCOL SPECIFICATION——TRANSPORTPROTOCOL）是針對衛(wèi)星鏈路傳輸設(shè)計的TCP代理，通過對代理兩側(cè)設(shè)置不同的TCP協(xié)議選項對長時延的衛(wèi)星鏈路進行TCP傳輸優(yōu)化［9］。SCPS_TP與PEPsal在實現(xiàn)上的差異在于，SCPS_TP不依賴Linux內(nèi)核的協(xié)議棧進行傳輸和擁塞控制，由程序本身進行控制。SCPS_TP默認使用SNACK作為可選的ACK機制，同時可對TCP協(xié)議的其他多種參數(shù)進行配置。PEPsal設(shè)計作為單側(cè)優(yōu)化代理，但其也可作為雙端優(yōu)化代理，經(jīng)實驗驗證，對PEPsal所運行的Linux內(nèi)核進行優(yōu)化配置，其作為雙端代理也能獲得相比單側(cè)優(yōu)化更好的傳輸性能。

圖4 SCPS_TP雙邊加速部署圖

3.3 SCPS_TP與PEPsal比較

SCPS_TP與PEPsal最大的區(qū)別在于，SCPS_TP所有的對數(shù)據(jù)報的操作均在用戶層實現(xiàn)，這使得SCPS_TP對TCP數(shù)據(jù)傳輸有更強的控制能力?？梢葬槍蓚?cè)鏈路配置不同的窗口緩存、擁塞控制算法以及MTU等參數(shù)，也可以對在雙端SCPS_TP內(nèi)傳輸?shù)臄?shù)據(jù)報進行壓縮、加密等操作。同時由于SCPS_TP在用戶層進行數(shù)據(jù)報獲取，SCPS_TP也可以對部分UDP數(shù)據(jù)報進行壓縮、聚合等優(yōu)化操作。

PEPsal依賴于Linux內(nèi)核的Netfilter模塊獲取數(shù)據(jù)報，同時依賴于Linux內(nèi)核的TCP協(xié)議棧進行TCP連接的傳輸和擁塞控制。PEPsal的優(yōu)勢在于，能夠靈活運用Linux內(nèi)核中的特性對數(shù)據(jù)傳輸過程進行處理［10］。例如利用Netfilter進行數(shù)據(jù)過濾，可以僅對特定源IP的TCP傳輸進行優(yōu)化；可以在Linux內(nèi)核中加載更多種的TCP擁塞控制算法，以針對不同的鏈路特性使用最合適的算法。

SCPS_TP雙端代理實驗結(jié)果與理論預(yù)期相符合。由表1中結(jié)果項1、2、3比較可知，RTT增大時，需要增加窗口緩存才能維持較高的傳輸速率。由結(jié)果項4、5、6比較可知，在出現(xiàn)丟包時，窗口緩存需要大于2*RTT*S，才能維持較高的傳輸速率。由結(jié)果項4、5、7比較可知，采用SNACK能夠在每個RTT時間內(nèi)丟包2個以上也能夠維持較好的傳輸速率。

表1 SCPS_TP雙端代理實驗測試

表2 SCPS_TP雙端代理限速2M測試

表2比較了SCPS_TP作為雙端代理且限速2Mbps情況下，不同擁塞算法、緩存和丟包率時的傳輸速率?？梢钥闯觯捎赩egas算法考慮了多競爭擁塞，因此在單一代理的情況下，速率調(diào)節(jié)不如pure算法激進；同時使用pure算法時，增大緩存能夠在丟包率提升時維持傳輸速率。

表3 PEPsal雙端代理實驗測試

PEPsal雙端代理試驗中主要比較了不同擁塞控制算法對傳輸速率的影響。由實驗結(jié)果可知，在無丟包的情況下，采用兩種不同的擁塞控制算法均可以獲得非常高傳輸速率，但當出現(xiàn)丟包時，Vegas算法能夠獲得相比Cubic算法更好的傳輸速率。

表4 PEPsal雙端代理限速2M測試

4 雙端加速代理設(shè)計

4.1 應(yīng)用模式設(shè)計

戰(zhàn)術(shù)網(wǎng)絡(luò)環(huán)境部署范圍廣，異構(gòu)網(wǎng)絡(luò)種類繁多，為了獲得良好的端到端TCP傳輸效果，需要考慮充分屏蔽異構(gòu)網(wǎng)絡(luò)之間的差異性，對數(shù)據(jù)傳輸過程進行逐段優(yōu)化，最終實現(xiàn)端到端數(shù)據(jù)傳輸效率的優(yōu)化與提升。

圖5 TCP加速模塊的組織應(yīng)用模式

戰(zhàn)術(shù)無線網(wǎng)絡(luò)環(huán)境兩方面的特性使得使用單邊代理加速優(yōu)化難以獲得良好的效果：1）網(wǎng)絡(luò)終端難以統(tǒng)一：戰(zhàn)術(shù)無線互聯(lián)網(wǎng)絡(luò)中所使用的網(wǎng)絡(luò)終端種類繁多，每種終端的TCP協(xié)議配置可能存在差異；包括WindowsXP系統(tǒng)在內(nèi)的終端操作系統(tǒng)默認僅對TCP的非擴展協(xié)議提供支持，導致單邊代理無法使用TCP的協(xié)議擴展來提高TCP傳輸效率。2）網(wǎng)絡(luò)異構(gòu)性導致一條連接通過不同類型的鏈路：由于戰(zhàn)術(shù)無線互聯(lián)網(wǎng)絡(luò)采用異構(gòu)組網(wǎng)的方式，一條TCP連接可能經(jīng)過多種不同類型的鏈路，單邊代理難以對多種不同類型的鏈路匹配最優(yōu)的擁塞控制算法，導致單邊代理無法獲得良好的加速效果。因此在戰(zhàn)術(shù)無線互連網(wǎng)絡(luò)中，對于不同類型鏈路采用雙端代理優(yōu)化才能獲得良好的鏈路適應(yīng)性，提高TCP傳輸效率。

將TCP加速代理嵌入至戰(zhàn)術(shù)無線信道兩側(cè)的通信設(shè)備，可以對經(jīng)過戰(zhàn)術(shù)無線信道的TCP數(shù)據(jù)流進行加速處理。如圖5所示，在基站節(jié)點及接入節(jié)點同時部署通用無線鏈路TCP加速模塊，可以對經(jīng)過RAP接入網(wǎng)的從電臺網(wǎng)至骨干網(wǎng)的TCP數(shù)據(jù)流進行加速。

4.2 軟件架構(gòu)設(shè)計

TCP加速模塊的軟件設(shè)計架構(gòu)如圖6所示。主要包含的子模塊及其功能有：

圖6 TCP加速代理軟件架構(gòu)

1）數(shù)據(jù)收發(fā)與業(yè)務(wù)識別模塊：需要不同的產(chǎn)品平臺實現(xiàn)不同的網(wǎng)絡(luò)數(shù)據(jù)包收發(fā)接口，并識別接收數(shù)據(jù)包的協(xié)議及業(yè)務(wù)信息；對TCP協(xié)議的數(shù)據(jù)包轉(zhuǎn)發(fā)至TCP代理管理模塊進行處理；對非TCP協(xié)議的數(shù)據(jù)包直接在數(shù)據(jù)收發(fā)模塊進行轉(zhuǎn)發(fā)；

2）TCP代理管理模塊：通過對接收到的TCP數(shù)據(jù)包進行分析處理，對TCP數(shù)據(jù)流狀態(tài)進行維護；并依據(jù)TCP數(shù)據(jù)流狀態(tài)進行欺騙ACK反饋、數(shù)據(jù)重傳、?；顧z測等操作；

3）TCP雙端加速模塊：對需要發(fā)送的TCP數(shù)據(jù)進行緩存、發(fā)送窗口限制及發(fā)送速率控制；改變傳統(tǒng)TCP依據(jù)擁塞窗口進行發(fā)送速率控制導致對丟包敏感，無法高效利用無線信道帶寬的問題；

4）TCP斷鏈續(xù)傳模塊：檢測當前TCP數(shù)據(jù)流的連接狀態(tài)，在電臺通信較長時間不通暢時暫停數(shù)據(jù)傳輸；在電臺數(shù)據(jù)通信恢復(fù)時更好的進行數(shù)據(jù)重傳；

5）多連接TCP動態(tài)分配模塊：依據(jù)預(yù)配置信息或電臺上報帶寬信息，為經(jīng)過無線鏈路的TCP數(shù)據(jù)流進行動態(tài)帶寬分配；同時對TCP的帶寬需求進行感知，避免分配時浪費帶寬；

6）公共適配模塊：通過對不同平臺系統(tǒng)調(diào)用API進行封裝，實現(xiàn)TCP加速模塊的通用跨平臺可移植性。

4.3 關(guān)鍵技術(shù)與突破

4.3.1 TCP協(xié)議分段代理技術(shù)

TCP協(xié)議通過端到端的可靠連接為端到端的數(shù)據(jù)傳輸提供保障。在戰(zhàn)術(shù)異構(gòu)網(wǎng)絡(luò)環(huán)境中，由于端到端連接可能存在經(jīng)過多種網(wǎng)絡(luò)傳輸信道，如在骨干網(wǎng)采用衛(wèi)星、微波等信道，在接入網(wǎng)采用高速電臺等信道，在野戰(zhàn)指揮部采用以太網(wǎng)等信道，可能導致采用端到端的TCP協(xié)議無法針對多種網(wǎng)絡(luò)信道環(huán)境進行適配，傳輸效率較低。

圖7 TCP協(xié)議分段代理技術(shù)圖

TCP協(xié)議分段代理技術(shù)，打破了TCP的端到端連接，將不同的網(wǎng)絡(luò)信道分割開來，使得在不同異構(gòu)網(wǎng)絡(luò)能夠有針對性地對TCP協(xié)議進行傳輸優(yōu)化，提高端到端的整體傳輸效率。TCP協(xié)議分段代理技術(shù)原理圖如圖7所示，其原理是：

TCP連接管理，檢測從鏈路上接收到的TCP數(shù)據(jù)報，分析其所屬的TCP連接會話，并依據(jù)會話狀態(tài)對TCP數(shù)據(jù)報進行管理；

TCP反饋欺騙，TCP代理接收到帶負載的數(shù)據(jù)報后，發(fā)送欺騙ACK給源節(jié)點，并負責成功傳輸這些帶負載的數(shù)據(jù)報；

TCP代理刪除了從對端接收到的真實的ACK，防止源節(jié)點混淆。

使用TCP代理優(yōu)化的優(yōu)勢還包括：1）逐段可靠保障：由于需要在代理兩側(cè)的網(wǎng)段上分別建立了TCP連接，因此在代理節(jié)點實際對TCP數(shù)據(jù)報進行緩存，也即實現(xiàn)了TCP數(shù)據(jù)的逐段可靠保障；2）鏈路狀況隔離：一條連接所經(jīng)過的鏈路可能有不同的MTU，傳輸速率等，連接只能適配所有鏈路的最差情況，選擇最小的MTU和最低的傳輸速率；通過代理進行TCP分段，能夠屏蔽不同鏈路的差異，選擇適合當前鏈路配置進行傳輸［11］。

4.3.2 基于TCP的雙端加速技術(shù)

傳統(tǒng)的TCP協(xié)議采用丟包信號作為擁塞控制窗口調(diào)整的信號，導致在較高丟包率的戰(zhàn)術(shù)無線通信網(wǎng)絡(luò)環(huán)境下?lián)砣翱跓o法擴大，導致傳輸速率較低。TCP雙端加速修改了傳統(tǒng)TCP協(xié)議的擁塞控制算法及確認反饋機制，當出現(xiàn)丟包時，TCP雙端加速與傳統(tǒng)TCP的窗口變化差別如圖8所示。其原理是：1）利用已配置的信息獲知當前信道速率；2）由獲知的信道速率對TCP數(shù)據(jù)流發(fā)送速率進行控制；3）由于能夠?qū)?jīng)過信道的所有TCP數(shù)據(jù)流進行感知，合理分配經(jīng)過信道的各個TCP數(shù)據(jù)流的發(fā)送速率，以避免信道產(chǎn)生擁塞。

圖8 TCP的雙端加速技術(shù)圖

4.3.3 高效丟包感知與重傳技術(shù)

如圖9所示，TCP連接通過反饋ACK信息來保障傳輸?shù)睦鄯e可靠性。由于反饋的ACK只能表示已經(jīng)累積收到的TCP數(shù)據(jù)報，發(fā)送端無法從反饋的ACK中獲得足夠的丟包信息；因此在TCP的相關(guān)擴展中增加了SACK及SNACK以在ACK反饋中包含丟包信息，以提高發(fā)送端對丟包的感知能力。但是SACK及SNACK對丟包的感知也具有一定的局限性，無法對重傳數(shù)據(jù)報的丟失進行感知；由于在信道中所有數(shù)據(jù)報的丟失概率一致，因此在遭遇重傳數(shù)據(jù)報丟失時，采用SACK或SNACK進行丟包反饋的TCP協(xié)議只能通過超時機制重傳丟失的數(shù)據(jù)報，導致傳輸速率降低。在本項目中，實現(xiàn)了高效丟包感知與重傳技術(shù)，能夠有效提高高丟包信道環(huán)境中的TCP傳輸速率。其原理如下：1）SNACK反饋，在反饋ACK中包含SNACK信息，向發(fā)送端反饋丟包信息；2）丟包空洞的掃描及定時觸發(fā)，在SNACK的基礎(chǔ)上增強了對重傳數(shù)據(jù)報丟失的感知能力，使得發(fā)送端能夠更加及時地進行數(shù)據(jù)報重傳，避免進入超時重傳階段導致傳輸速率降低［12］。

圖9 TCP的反饋ACK示意圖

4.3.4 多連接TCP動態(tài)分配技術(shù)

在當前方案中，所有經(jīng)過無線鏈路的TCP數(shù)據(jù)流均會先由TCP代理加速模塊進行處理，因此可以在TCP代理加速模塊中為TCP數(shù)據(jù)流分配可用的無線鏈路帶寬，避免出現(xiàn)競爭擁塞。該技術(shù)效果如圖10所示。其原理是：1）全局帶寬分配：設(shè)置全局定時器定期生成可用帶寬令牌，為經(jīng)過無線鏈路的TCP數(shù)據(jù)流分配可用帶寬；2）TCP數(shù)據(jù)流優(yōu)先級管控：依據(jù)可配置的優(yōu)先級信息為不同優(yōu)先級的TCP數(shù)據(jù)流分配不同的帶寬；3）TCP帶寬需求感知：對TCP數(shù)據(jù)流的帶寬需求進行感知，為帶寬需求低的TCP數(shù)據(jù)流少分配或不分配帶寬，避免帶寬浪費［13］。

圖10 TCP帶寬分配技術(shù)效果圖

5 結(jié)語

本文針對戰(zhàn)術(shù)無線網(wǎng)絡(luò)的具體特性，從TCP協(xié)議和網(wǎng)絡(luò)自身狀況等影響傳輸速率的因素分析，屏蔽異構(gòu)網(wǎng)絡(luò)之間的差異性，對數(shù)據(jù)傳輸過程進行逐段優(yōu)化。通過將該設(shè)計以軟件模塊形式嵌入至產(chǎn)品運行經(jīng)長時間使用驗證，使用效果良好，數(shù)據(jù)傳輸性能得到有效提升。