一種戰術通信系統TCP協議雙端代理加速方法設計

李紅衛 蔣祖星

（廣東交通職業技術學院 廣州 510800）

1 引言

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

戰術互聯網絡的協議結構比較復雜，它涉及到物理層、數據鏈路層、網絡層、傳輸層以及應用層所使用的網絡協議和接口［1］。TCP協議是保障可靠通信的關鍵部分，對于利用網絡進行通信的兩個終端來說，端到端通信的可靠性最終還是要由傳輸控制協議來解決。

圖1 TCP數據傳輸丟包與窗口變化示意圖

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

2 TCP協議傳輸速率影響因素

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

2.1 TCP協議影響

1）ACK機制

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

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

2）擁塞控制算法

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

由于鏈路特性的不同，相適應的擁塞控制算法也不同，因此應當針對戰術通信網絡的特點來選擇合適的擁塞控制算法。

3）窗口緩存

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

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

圖2 TCP數據傳輸丟包與窗口變化示意圖

4）其他擴展選項

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

2.2 網絡狀況影響

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

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

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

3 民用TCP加速代理

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

3.1 單邊代理優化

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

圖3 PEPsal單邊加速部署圖

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

3.2 雙邊代理優化

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

圖4 SCPS_TP雙邊加速部署圖

3.3 SCPS_TP與PEPsal比較

SCPS_TP與PEPsal最大的區別在于，SCPS_TP所有的對數據報的操作均在用戶層實現，這使得SCPS_TP對TCP數據傳輸有更強的控制能力。可以針對兩側鏈路配置不同的窗口緩存、擁塞控制算法以及MTU等參數，也可以對在雙端SCPS_TP內傳輸的數據報進行壓縮、加密等操作。同時由于SCPS_TP在用戶層進行數據報獲取，SCPS_TP也可以對部分UDP數據報進行壓縮、聚合等優化操作。

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

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

表1 SCPS_TP雙端代理實驗測試

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

表2比較了SCPS_TP作為雙端代理且限速2Mbps情況下，不同擁塞算法、緩存和丟包率時的傳輸速率。可以看出，由于Vegas算法考慮了多競爭擁塞，因此在單一代理的情況下，速率調節不如pure算法激進；同時使用pure算法時，增大緩存能夠在丟包率提升時維持傳輸速率。

表3 PEPsal雙端代理實驗測試

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

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

4 雙端加速代理設計

4.1 應用模式設計

戰術網絡環境部署范圍廣，異構網絡種類繁多，為了獲得良好的端到端TCP傳輸效果，需要考慮充分屏蔽異構網絡之間的差異性，對數據傳輸過程進行逐段優化，最終實現端到端數據傳輸效率的優化與提升。

圖5 TCP加速模塊的組織應用模式

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

將TCP加速代理嵌入至戰術無線信道兩側的通信設備，可以對經過戰術無線信道的TCP數據流進行加速處理。如圖5所示，在基站節點及接入節點同時部署通用無線鏈路TCP加速模塊，可以對經過RAP接入網的從電臺網至骨干網的TCP數據流進行加速。

4.2 軟件架構設計

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

圖6 TCP加速代理軟件架構

1）數據收發與業務識別模塊：需要不同的產品平臺實現不同的網絡數據包收發接口，并識別接收數據包的協議及業務信息；對TCP協議的數據包轉發至TCP代理管理模塊進行處理；對非TCP協議的數據包直接在數據收發模塊進行轉發；

2）TCP代理管理模塊：通過對接收到的TCP數據包進行分析處理，對TCP數據流狀態進行維護；并依據TCP數據流狀態進行欺騙ACK反饋、數據重傳、保活檢測等操作；

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

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

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

6）公共適配模塊：通過對不同平臺系統調用API進行封裝，實現TCP加速模塊的通用跨平臺可移植性。

4.3 關鍵技術與突破

4.3.1 TCP協議分段代理技術

TCP協議通過端到端的可靠連接為端到端的數據傳輸提供保障。在戰術異構網絡環境中，由于端到端連接可能存在經過多種網絡傳輸信道，如在骨干網采用衛星、微波等信道，在接入網采用高速電臺等信道，在野戰指揮部采用以太網等信道，可能導致采用端到端的TCP協議無法針對多種網絡信道環境進行適配，傳輸效率較低。

圖7 TCP協議分段代理技術圖

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

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

TCP反饋欺騙，TCP代理接收到帶負載的數據報后，發送欺騙ACK給源節點，并負責成功傳輸這些帶負載的數據報；

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

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

4.3.2 基于TCP的雙端加速技術

傳統的TCP協議采用丟包信號作為擁塞控制窗口調整的信號，導致在較高丟包率的戰術無線通信網絡環境下擁塞窗口無法擴大，導致傳輸速率較低。TCP雙端加速修改了傳統TCP協議的擁塞控制算法及確認反饋機制，當出現丟包時，TCP雙端加速與傳統TCP的窗口變化差別如圖8所示。其原理是：1）利用已配置的信息獲知當前信道速率；2）由獲知的信道速率對TCP數據流發送速率進行控制；3）由于能夠對經過信道的所有TCP數據流進行感知，合理分配經過信道的各個TCP數據流的發送速率，以避免信道產生擁塞。

圖8 TCP的雙端加速技術圖

4.3.3 高效丟包感知與重傳技術

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

圖9 TCP的反饋ACK示意圖

4.3.4 多連接TCP動態分配技術

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

圖10 TCP帶寬分配技術效果圖

5 結語

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