熊曉將

（中國空間技術(shù)研究院，北京 100094）

1 引言

傳輸控制協(xié)議（Transfer Control Protocol，TCP）是目前應(yīng)用廣泛的互連網(wǎng)傳輸協(xié)議。傳統(tǒng)的TCP協(xié)議包含4 個(gè)擁塞控制算法：慢啟動(dòng)（Slow Start）、擁塞避免（Congestion Avoidance）、快速重傳（Fast Retransmit）、快速恢復(fù)（Fast Recovery）。這4個(gè)擁塞控制算法相互關(guān)聯(lián)，合稱為TCP-Reno算法，在Allman等人所著的TCP 標(biāo)準(zhǔn)協(xié)議備忘錄RFC2581中有詳細(xì)的描述［1］。

在選擇衛(wèi)星鏈路的標(biāo)準(zhǔn)傳輸協(xié)議時(shí)，TCP是首選的傳輸層協(xié)議，但試驗(yàn)和理論研究表明，如果把有線環(huán)境的端到端數(shù)據(jù)傳輸TCP 協(xié)議直接用到衛(wèi)星鏈路中，則在長時(shí)延、高誤碼、間歇性中斷等因素的影響下，其擁塞控制機(jī)制將不能正常工作，使網(wǎng)絡(luò)的帶寬利用率低下，網(wǎng)絡(luò)的吞吐量下降，嚴(yán)重制約了數(shù)據(jù)傳輸?shù)男屎湍芰Α?/p>

國內(nèi)外在衛(wèi)星鏈路的擁塞控制機(jī)制和算法方面已做了很多研究，提出了很多改進(jìn)衛(wèi)星鏈路上TCP擁塞控制協(xié)議性能的方案。文獻(xiàn)［2-5］針對衛(wèi)星鏈路對TCP 性能的影響，提出了TCP 分片、快速啟動(dòng)、顯式擁塞通告、鏈路錯(cuò)誤通告、分離誤碼和擁塞等方法，提高衛(wèi)星鏈路上的TCP 性能。Internet工程任務(wù)組（IETF）在1997年成立了工作組，專門研究衛(wèi)星信道上的TCP／IP性能，如文獻(xiàn)［6］中建議增大TCP 初始窗口尺寸。NASA 的格林（Glenn）研究中心、路易斯（Lewis）研究中心、法國信息與自動(dòng)化研究所（INRIA）、俄亥俄州立大學(xué)（Ohio）等單位也在從事衛(wèi)星鏈路上TCP性能的研究，并通過實(shí)驗(yàn)提出了一些改進(jìn)衛(wèi)星鏈路上TCP 性能的技術(shù)措施［7-8］。國內(nèi)也有一些大學(xué)和研究機(jī)構(gòu)展開了提高衛(wèi)星網(wǎng)上TCP擁塞控制性能方面的研究［9-10］。

本文介紹了一種基于探測機(jī)制的擁塞控制算法，通過發(fā)送低優(yōu)先級且不攜帶有用信息的啞元來探測網(wǎng)絡(luò)資源的可用性，改進(jìn)了原有的慢啟動(dòng)及快速算法，并形成了新的突然啟動(dòng)和迅速恢復(fù)算法，經(jīng)仿真驗(yàn)證，能夠有效提高TCP連接的初始階段以及鏈路出錯(cuò)條件下的吞吐量?？蔀樘岣咝l(wèi)星鏈路TCP協(xié)議的性能提供參考。

2 基于探測機(jī)制的擁塞控制算法

2．1 算法的引入

基于探測機(jī)制［11］的擁塞控制算法，目的是保證與TCP協(xié)議兼容性良好的情況下，提高衛(wèi)星網(wǎng)絡(luò)TCP的吞吐量性能，特別是鏈路誤碼率高的情況下的吞吐量。該算法針對衛(wèi)星鏈路長時(shí)延、高誤碼的特點(diǎn)，設(shè)計(jì)了一種高效的TCP 擁塞控制機(jī)制，如圖1所示，4個(gè)核心算法分別為突然啟動(dòng)、擁塞避免、快速重傳和迅速恢復(fù)。其中，突然啟動(dòng)和迅速恢復(fù)算法就是在傳統(tǒng)的慢啟動(dòng)和快速恢復(fù)基礎(chǔ)上的改進(jìn)。

改進(jìn)算法的設(shè)計(jì)思想，在于它使用一種低優(yōu)先級且不包含任何有用數(shù)據(jù)的報(bào)文段（即啞元）來探測網(wǎng)絡(luò)的擁塞情況。使用啞元的目的主要是用于探測端到端連接網(wǎng)絡(luò)資源的可用性，啞元應(yīng)答的順利標(biāo)志著網(wǎng)絡(luò)情況良好，網(wǎng)絡(luò)正存在著未被使用的資源，發(fā)送方可以增大擁塞窗口；而一旦發(fā)生網(wǎng)絡(luò)擁塞，低優(yōu)先級IP 包攜帶的啞元將被首先丟棄。由于啞元不含任何有用的數(shù)據(jù)，其丟棄率不但可以反映網(wǎng)絡(luò)擁塞情況，而且丟棄的啞元不需要被重傳。

圖1 基于探測機(jī)制的擁塞控制流程Fig．1 Congestion control flow based on detection mechanism

2．2 突然啟動(dòng)算法

為了避免長時(shí)延衛(wèi)星鏈路慢啟動(dòng)造成的吞吐量低的問題，在一個(gè)新連接的開始采用了新的突然啟動(dòng)算法。突然啟動(dòng)算法將會(huì)持續(xù)一個(gè)往返時(shí)間（Rround-trip Time，RTT），隨即發(fā)送端將進(jìn)入擁塞避免階段，其基本思路如下。

在連接的開始階段，擁塞窗口（congestion window，cwnd）的大小Scwnd及變量w被分別初始化設(shè)置為1和0，并且在發(fā)送完第1個(gè)數(shù)據(jù)段后，它每隔時(shí)間α（α＝tRTT／Srwnd）就發(fā)送1個(gè)啞元（tRTT表示往返的時(shí)間，Srwnd代表接收窗口（receive window，rwnd）的大小，也是擁塞窗口的最大值）。這樣，在第一個(gè)RTT 內(nèi)發(fā)送了一個(gè)數(shù)據(jù)段和Srwnd-1個(gè)啞元。啞元到達(dá)接收端后，如果網(wǎng)絡(luò)中有未使用的資源，那么它們的確認(rèn)信號（acknowledgement，ACK）將會(huì)到達(dá)發(fā)送端。突然啟動(dòng)結(jié)束時(shí)，發(fā)送端會(huì)收到這些ACK 信號并開始執(zhí)行擁塞避免算法。因此，由于w＝0，一旦收到啞元的ACK，發(fā)送端將增加擁塞窗口。在一個(gè)RTT 之后，擁塞窗口會(huì)迅速增長，從連接建立的開始，突然啟動(dòng)比傳統(tǒng)的慢啟動(dòng)達(dá)到接收窗口大小的時(shí)間要快，僅需要2個(gè)RTT的時(shí)間。需要注意的是，發(fā)送端在連接建立的初始階段必須能夠估計(jì)RTT，即在3 次握手階段獲得RTT 的值。

2．3 迅速恢復(fù)算法

迅速恢復(fù)算法替代傳統(tǒng)快速恢復(fù)算法的目的，主要是解決由于鏈路錯(cuò)誤導(dǎo)致衛(wèi)星鏈路吞吐量性能下降的問題。

新的迅速恢復(fù)算法，將保留傳統(tǒng)快速恢復(fù)算法對所有丟包均是由于網(wǎng)絡(luò)擁塞引起的假設(shè)，因?yàn)門CP 層不知道引起網(wǎng)絡(luò)擁塞的確切原因，即到底是網(wǎng)絡(luò)擁塞還是鏈路錯(cuò)誤。

設(shè)置以下幾個(gè)變量：

（1）a表示允許發(fā)送端發(fā)送的啞元數(shù)量，a＞0時(shí)，允許發(fā)送啞元；

（2）Nseg表示未被確認(rèn)的數(shù)據(jù)報(bào)文，為能否發(fā)送新數(shù)據(jù)的判據(jù)，即Scwnd大于Nseg時(shí)，允許發(fā)送新的數(shù)據(jù)；

（3）w：作為Scwnd是否增長的判據(jù)，即若w＝0，則Scwnd增加一個(gè)報(bào)文大??；若w＞0，則w的值遞減1，而Scwnd的值保持不變。通過w的調(diào)節(jié)可以達(dá)到與傳統(tǒng)TCP的友好與兼容；

（4）tretr：為丟失的數(shù)據(jù)報(bào)文重傳的時(shí)刻，令其等于當(dāng)前的時(shí)刻t；

（5）tRTO：表示數(shù)據(jù)包從發(fā)送到失效的時(shí)間間隔。

迅速恢復(fù)階段的過程如下：

（1）發(fā)送端每收到一個(gè)數(shù)據(jù)報(bào)的ACK 信號，將Scwnd增加一個(gè)報(bào)文段大小，并檢測是否可以發(fā)送新的數(shù)據(jù)；

（2）若Scwnd大于未確認(rèn)數(shù)據(jù)報(bào)文Nseg，則發(fā)送新數(shù)據(jù)報(bào)文；

（3）如果不能發(fā)送新數(shù)據(jù)，即Scwnd小于或等于未確認(rèn)數(shù)據(jù)報(bào)文Nseg，則發(fā)送端檢測a的值，若a＞0，發(fā)送端發(fā)送兩個(gè)啞元并將a的值減2；

（4）若收到了啞元的ACK，只有w＝0時(shí)Scwnd增加，否則Scwnd保持不變而將w的值減1；

（5）當(dāng)丟失的報(bào)文被確認(rèn)后，Scwnd減小到發(fā)現(xiàn)發(fā)現(xiàn)丟包之前的大小，a被置0，迅速恢復(fù)算法結(jié)束，開始執(zhí)行擁塞避免算法；

（6）如果在t≥（tretr＋tRTO）時(shí)刻，發(fā)送端仍處于迅速恢復(fù)階段，在tRTO時(shí)間之內(nèi)重傳數(shù)據(jù)報(bào)和啞元的ACK 都未曾收到，這表明網(wǎng)絡(luò)發(fā)生了嚴(yán)重的擁塞，應(yīng)立即終止迅速恢復(fù)，開始執(zhí)行突然啟動(dòng)。

如果網(wǎng)絡(luò)未發(fā)生擁塞，丟包只是由于發(fā)生了鏈路錯(cuò)誤，那么所有的啞元都會(huì)到達(dá)接收端，發(fā)送端會(huì)收到所有啞元的應(yīng)答ACK。先到的Scwnd／2個(gè)啞元的ACK 將使得變量w減小至0，且擁塞窗口并不增加，而隨后到達(dá)的其余Scwnd／2個(gè)啞元的ACK 會(huì)將擁塞窗口增加恢復(fù)到Scwnd。結(jié)果在很短的時(shí)間內(nèi)，Scwnd就恢復(fù)到檢測到丟包時(shí)的大小。

如果丟包真的是由于發(fā)生了擁塞，那么發(fā)生擁塞的路由器在每個(gè)RTT 時(shí)間內(nèi)能處理Scwnd個(gè)數(shù)據(jù)段。因而，網(wǎng)絡(luò)只能容納Scwnd／2個(gè)具有高優(yōu)先級的數(shù)據(jù)包，以及在迅速恢復(fù)階段中發(fā)送的啞元中一半，即Scwnd／2個(gè)啞元。收到啞元的ACK 后，變量w將會(huì)更新并減小至0，而擁塞窗口此時(shí)并不會(huì)增加，即在網(wǎng)絡(luò)發(fā)生擁塞時(shí)，迅速恢復(fù)算法與傳統(tǒng)的快速恢復(fù)算法的表現(xiàn)相同。

3 仿真驗(yàn)證

3．1 仿真模型的建立

仿真選用OPNET Technologies 公司的OPNET Modeler網(wǎng)絡(luò)仿真平臺軟件。

圖2為簡化的OPNET 仿真網(wǎng)絡(luò)模型，仿真環(huán)境為同步衛(wèi)星系統(tǒng)。在簡化的模擬場景中，用路由器代表地面站網(wǎng)關(guān)，通過對數(shù)據(jù)速率、傳輸延遲和誤碼率的設(shè)置模擬衛(wèi)星鏈路環(huán)境，以減小實(shí)現(xiàn)的復(fù)雜性。由于迅速恢復(fù)算法主要解決的是鏈路出錯(cuò)時(shí)吞吐量性能下降的問題，因而構(gòu)造了出現(xiàn)鏈路差錯(cuò)時(shí)的網(wǎng)絡(luò)模型。

圖2 出現(xiàn)鏈路差錯(cuò)時(shí)仿真的網(wǎng)絡(luò)模型Fig．2 Simulation network model in the condition of link errors

仿真使用的是文件傳輸協(xié)議（File Transfer Protocol，F(xiàn)TP）業(yè)務(wù)類型，參數(shù)設(shè)置見表1。

表1 仿真參數(shù)設(shè)置Table 1 Simulation parameter

3．2 仿真內(nèi)容及結(jié)果分析

對基于探測機(jī)制的擁塞控制算法的仿真驗(yàn)證分為以下兩種情形：

（1）網(wǎng)絡(luò)正常情況下對突然啟動(dòng)算法的性能驗(yàn)證；

（2）鏈路出現(xiàn)差錯(cuò)的情況下對迅速恢復(fù)算法的性能驗(yàn)證。

為了驗(yàn)證算法的性能，仿真的內(nèi)容包括接收確認(rèn)ACK 及吞吐量的比較。

圖3為網(wǎng)絡(luò)正常的情況下，對突然啟動(dòng)算法的性能驗(yàn)證。

圖3 網(wǎng)絡(luò)正常時(shí)啟動(dòng)算法的ACK 比較Fig．3 ACK Comparison of start algorithm when network in order

由圖3仿真結(jié)果可知：在網(wǎng)絡(luò)正常的情況下，在新連接建立的起始階段，由于衛(wèi)星鏈路長時(shí)延的影響，傳統(tǒng)TCP-Reno慢啟動(dòng)算法直接應(yīng)用于衛(wèi)星鏈路，性能要比在地面網(wǎng)絡(luò)應(yīng)用的效果差；若在衛(wèi)星鏈路中采用突然啟動(dòng)算法，由于采用了探測機(jī)制，突然啟動(dòng)比慢啟動(dòng)達(dá)到rwnd窗口大小的時(shí)間要快，這也表明了在衛(wèi)星鏈路連接建立的起始階段，突然啟動(dòng)又比慢啟動(dòng)傳送數(shù)據(jù)的速度要快得多。

圖4為鏈路出現(xiàn)差錯(cuò)的情況下對迅速恢復(fù)算法的性能驗(yàn)證，仿真時(shí)假設(shè)在107s出現(xiàn)一個(gè)報(bào)文丟棄。

圖4 鏈路出錯(cuò)時(shí)恢復(fù)算法的吞吐量比較Fig．4 Throughput comparison of recovery algorithm in the condition of link errors

由圖4 可知：在鏈路出現(xiàn)差錯(cuò)的情況下，傳統(tǒng)TCP-Reno快速恢復(fù)算法直接應(yīng)用于衛(wèi)星鏈路，性能比在地面網(wǎng)絡(luò)應(yīng)用的效果差；通過啞元的發(fā)送與確認(rèn)，對網(wǎng)絡(luò)容量進(jìn)行了有效探測，迅速恢復(fù)算法在擁塞避免階段的窗口明顯增加，因而迅速恢復(fù)算法的吞吐量在衛(wèi)星鏈路中應(yīng)用的性能又要優(yōu)于傳統(tǒng)的TCP-Reno快速恢復(fù)算法。

4 結(jié)束語

衛(wèi)星鏈路長時(shí)延、高誤碼的特點(diǎn)使得TCP的數(shù)據(jù)傳輸性能下降，本文基于探測機(jī)制的擁塞控制改進(jìn)算法，采用對網(wǎng)絡(luò)資源的探測機(jī)制，可以有效解決衛(wèi)星鏈路慢啟動(dòng)以及鏈路錯(cuò)誤造成的吞吐量低的問題。仿真結(jié)果表明，該算法可提高和改善衛(wèi)星鏈路中TCP 的吞吐量，不涉及中間節(jié)點(diǎn)的改造，并與傳統(tǒng)的TCP協(xié)議兼容。

（References）

［1］Allman M．TCP congestion control［S／OL］．［2012-02-21］．http：／／datatracker．ietf．org／doc／rfc2581

［2］Balakrishnan H．A comparison of mechanisms for improving TCP performance over wireless links［R］．New York：IEEE，1997

［3］Pamanabhan V N，Katz R．TCP fast start：a technique for speeding up web transfer［R］．New York：IEEE，1998

［4］Floyd S．TCP and explicit congestion notification［R／OL］．［2012-03-11］．http：／／citeseerx．ist．psu．edu

［5］Durst R C，Miller G J，Travis E J．TCP extensions for space communications［R／OL］．［2010-04-11］．http：／／citeseerx．ist．psu．edu

［6］Allman M，F(xiàn)loyd S，Partridge C．Increasing TCP’s initial window［S／OL］．［2009-11-12］．http：／／datatracker．ietf．org／doc／rfc2414

［7］Lakshman T V，Madhow U．The performance of TCP／IP for networks with high bandwidth delay products and random loss［R］．New Yok：IEEE，1997：336-350

［8］Alman M．Improving TCP performance over satellite channels［D］．Ohio：Ohio University，1997：27-35

［9］劉春霞．衛(wèi)星網(wǎng)傳輸層擁塞控制協(xié)議研究［D］．哈爾濱：哈爾濱工程大學(xué)，2001

Liu Chunxia．Research on congestion control protocol of transmission layer in satellite network［D］．Harbin：Harbin Engineering University，2001（in Chinese）

［10］羅萬明，林闖，閻保平．TCP／IP 擁塞控制研究［J］．計(jì)算機(jī)學(xué)報(bào)，2001，24（1）：1-18

Luo Wanming，Lin Ge，Yan Baoping．Research on TCP／IP congestion control［J］．Computer Transaction，2001，24（1）：1-18（in Chinese）

［11］Akyildiz I F，Morabito G，Palazzo S．Research issues for transport protocols in satellite IP networks［R］．New York：IEEE，2001：44-48