崔弘珂

(中國電子科技集團公司第五十四研究所,河北石家莊050081)

0 引言

在航天通信領(lǐng)域,采用IP協(xié)議傳輸測控業(yè)務(wù)和科學(xué)數(shù)據(jù)業(yè)務(wù)的研究早在20世紀(jì)90年代中期就開始了,Internet網(wǎng)絡(luò)技術(shù)的飛速發(fā)展推動著航天通信技術(shù)的革新,如何利用IP TCP協(xié)議可靠傳輸數(shù)據(jù)也成為測控通信研究的一個熱點。

1 空間信道特點

航天通信網(wǎng)的空間鏈路與地面鏈路相比,在帶寬、時延以及丟包率等許多方面存在差異。因此采用TCP傳輸技術(shù)用于航天通信網(wǎng)的空間數(shù)據(jù)傳輸協(xié)議,需要充分考慮空間信道特點的影響：

①高誤碼率：在高誤碼率的衛(wèi)星環(huán)境中,鏈路差錯帶來的丟包非常嚴(yán)重,如果不能區(qū)分是丟失還是擁塞,就會造成系統(tǒng)吞吐量下降,造成了網(wǎng)絡(luò)帶寬的浪費;

②長時延：空間信道傳播延時長,以地球靜止軌道(GEO)衛(wèi)星為例,往返時間(RTT)在550 ms左右,長延時特性進一步加重了空間信道高誤碼率對傳輸協(xié)議的影響;

③差異性：航天數(shù)據(jù)的各個接收者可能經(jīng)歷不同的信道條件(誤碼率和傳播時延),這導(dǎo)致了接收差異性問題,瓶頸接收者將嚴(yán)重制約著整個系統(tǒng)的性能;

④帶寬不對稱性：航天系統(tǒng)在前向和反向數(shù)據(jù)信道間往往有較大的帶寬不對稱性,反向信道一般帶寬比較低,會降低吞吐量,且吞吐量隨非對稱性呈指數(shù)減小。

2 TCP傳輸技術(shù)分析

TCP協(xié)議是在Internet環(huán)境下可靠、有序地傳送協(xié)議,當(dāng)TCP協(xié)議應(yīng)用于空間鏈路上時,空間鏈路的傳播時延和誤碼特性會對TCP性能產(chǎn)生負(fù)面影響,且降低了網(wǎng)絡(luò)資源的利用率。

2.1 長傳播時延

當(dāng)TCP協(xié)議用于長傳播時延衛(wèi)星信道時,將面臨3個主要的問題：擁塞窗口增長較慢、丟失數(shù)據(jù)包的恢復(fù)時間較長和接收窗口受限。

2.1.1 擁塞窗口增長較慢

往返時間是擁塞窗口增長的重要參數(shù),在擁塞避免期間,每個往返時間,擁塞窗口增加1。由于往返時間和擁塞窗口增長之間存在著一定的相關(guān)性,因此,往返時間越長,擁塞窗口增長得越慢。如果往返時間長,連接就要在慢啟動期間滯留很長一段時間,短連接將無法充分利用可用的信道帶寬。

2.1.2 檢測和恢復(fù)丟失的時間較長

由于丟失檢測是以確認(rèn)的交換為基礎(chǔ)的,因此,發(fā)送端總是至少花費一個往返時間去檢測數(shù)據(jù)包的丟失并進行重傳。重傳超時值也是以往返時間和往返時間采樣的偏量為基礎(chǔ)的,所以,這些值中的任何一個值較大的話,重傳超時都將很高。較高的重傳超時值意味著可能有較長的閑置時間,在這段時間內(nèi),連接等待重傳定時器超時,重新開始傳輸數(shù)據(jù)。

2.1.3 接收窗口受限

連接的帶寬時延確定了連接在填滿整個網(wǎng)絡(luò)管道之前需要傳送數(shù)據(jù)包的數(shù)量,對于長傳播時延(或大帶寬)鏈路來說,這個值相當(dāng)大,TCP不可能充分利用可用的鏈路帶寬,這主要是由于接收窗口受限造成的。以GEO衛(wèi)星系統(tǒng)為例,即使衛(wèi)星信道的發(fā)送速率大于1.024 Mbps,它實際最大吞吐量也只能被限制在1.024Mbps,而不考慮實際可得到的帶寬有多大。

2.2 高誤碼率

當(dāng)TCP協(xié)議運行于高誤碼率(BER)的衛(wèi)星信道時,存在的問題有：

①無法區(qū)分擁塞丟失和受損丟失：TCP協(xié)議面向較低BER(大約為10-9)的可靠地面信道環(huán)境應(yīng)用,由于數(shù)據(jù)包受損的概率低,因此所有TCP擁塞控制策略都將丟失的數(shù)據(jù)包看作是擁塞的指示。對于每個丟失的數(shù)據(jù)包,TCP發(fā)送端至少將其傳輸速率減少一半。在丟失非常嚴(yán)重出現(xiàn)超時時,數(shù)據(jù)傳輸返回到每個RTT只傳送一個數(shù)據(jù)包。對于數(shù)據(jù)包因受損而丟失的情況,很顯然這是一個錯誤的響應(yīng),因為網(wǎng)絡(luò)并沒有真正的發(fā)生擁塞,根本不應(yīng)該減小發(fā)送端的傳送速率;

②不能很好地處理每個擁塞窗口中多個丟失的數(shù)據(jù)包：當(dāng)每個擁塞窗口有多個數(shù)據(jù)包丟失時,TCP協(xié)議(特別是TCP Reno)不能很好地處理這些丟失的數(shù)據(jù)包。連續(xù)丟失導(dǎo)致?lián)砣翱诘倪B續(xù)減半。

3 改善TCP性能的技術(shù)措施

TCP協(xié)議在衛(wèi)星環(huán)境中的傳輸性能問題已經(jīng)成為國內(nèi)外研究人員的研究熱點,這里的設(shè)計思想有2點：一是如何削弱衛(wèi)星鏈路對TCP協(xié)議不利的特點,或者使協(xié)議看不到空間信道的特點;二是如何修改TCP協(xié)議使其不容易被衛(wèi)星鏈路的特點所影響。本著這2項原則可將方案大致分為2種：鏈路層解決方案、端到端的解決方案。

3.1 鏈路層解決方案

3.1.1 可靠鏈路層協(xié)議

隱藏鏈路層損壞的方法是執(zhí)行可靠鏈路層協(xié)議,采用這種方法是必須對鏈路層協(xié)議進行非常精細(xì)的設(shè)計才能與TCP一起很好的工作。當(dāng)TCP的重復(fù)確認(rèn)傳送到TCP發(fā)送端時,錯誤很可能觸發(fā)鏈路層重傳,并使TCP將其擁塞窗口減為原來的一半,同時重傳同一個數(shù)據(jù)包。因此使用UDP不需要可靠的數(shù)據(jù)傳輸。

3.1.2 自適應(yīng)前向糾錯

自適應(yīng)前向糾錯(AFEC)的基本思想是找到一個(K,N)碼,使得有效吞吐量等于可獲得的吞吐量(實際上是TCP連接的最大吞吐量)。

3.2 端到端的解決方案

3.2.1 TCP協(xié)議增強方法

(1)增大初始窗口

采用一個較大的擁塞窗口(cwnd)初始值,在發(fā)生超時重傳時才將cwnd設(shè)置為一個數(shù)據(jù)包大小,這樣就能提高慢啟動開始時的網(wǎng)絡(luò)帶寬利用率。TCP協(xié)議允許cwnd的初始值可以從一個數(shù)據(jù)包大小增加到下式所給出的值：

式中,WI為初始窗口大小,MSS是網(wǎng)絡(luò)能夠傳輸?shù)淖畲髷?shù)據(jù)單元的字節(jié)數(shù)。通過增大cwnd的初始值,可以在數(shù)據(jù)傳輸?shù)牡?個RTT內(nèi)發(fā)送更多的數(shù)據(jù)包,觸發(fā)更多的ACK,使cwnd打開得更迅速一些,從而縮減了達到接收端通告窗口尺寸所需的時間。采用大的初始窗口后,慢啟動所需的時間將變?yōu)椋?/p>

(不采用時延確認(rèn),每個數(shù)據(jù)包給出一個確認(rèn))

(采用時延確認(rèn),每2個數(shù)據(jù)包給出一個確認(rèn))

由于增大初始窗口以后,慢啟動開始時至少要發(fā)送2個數(shù)據(jù)包,因此,接收端就不需要等待時延確認(rèn)超時以后才發(fā)送一個ACK,這樣就節(jié)省了3RTT和一個時延確認(rèn)時間。

(2)字節(jié)計數(shù)

在慢啟動階段,若使用標(biāo)準(zhǔn)的ACK計數(shù),對于每個接收到的ACK,cwnd都要增加一個數(shù)據(jù)包;若使用字節(jié)計數(shù),cwnd的增加數(shù)量則是由每個ACK所涵蓋的數(shù)據(jù)字節(jié)數(shù)來決定的,而不是由ACK的數(shù)量決定的,這樣就能加快cwnd增加的速度,減少慢啟動所需的時間。采用2種類型的字節(jié)計數(shù)算法：第1種是無限字節(jié)計數(shù)(Unlimited Byte Counting,UBC),該機制在每次ACK到達時,僅使用以前未確認(rèn)的字節(jié)來增大cwnd;第2種類型是受限字節(jié)計數(shù)(Limited Byte Counting,LBC),LBC把cwnd增加的數(shù)量限制在2個數(shù)據(jù)包,試驗證明LBC可以避免了較大的線速率突發(fā),提供了較好的性能,但也稍微增加了一些數(shù)據(jù)丟失率。

(3)慢啟動后時延確認(rèn)

在慢啟動階段后才使用慢啟動后時延確認(rèn)(Delayed Acknowledgement After Slow Start,DAASS),而在慢啟動過程中仍使用普通確認(rèn)方式,這樣加快了慢啟動過程。而在TCP連接穩(wěn)定后,減少確認(rèn)的數(shù)目,以節(jié)約網(wǎng)絡(luò)資源。使用DAASS比一直使用時延確認(rèn)在傳輸時間上有所改善,但是也稍微提高了一點丟失率,這是因為cwnd的快速增長造成的。

(4)選擇性確認(rèn)

使用選擇性確認(rèn)(Selective Acknowledgement,SACK)接收端可以通知發(fā)送端所有接收成功的數(shù)據(jù)包序列號,從而使發(fā)送端只重發(fā)那些確實丟失的數(shù)據(jù)包,并在一個RTT內(nèi)重發(fā)多個丟失的數(shù)據(jù)包,提高了TCP傳輸?shù)男阅堋?/p>

(5)前向確認(rèn)

前向確認(rèn)(Forward Acknowledgement,FACK)算法是一種更高效的算法,能夠獲得傳輸過程中“前進最多”的數(shù)據(jù)信息,所謂“前進最多”指的是接收端成功接收的序列號最大的數(shù)據(jù)包,FACK從TCP SACK選項中獲取有關(guān)鏈路擁塞情況的附加信息,對于差錯恢復(fù)期間輸入到網(wǎng)絡(luò)的數(shù)據(jù)進行更精確的控制。FACK削弱了標(biāo)準(zhǔn)差錯恢復(fù)算法中的擁塞控制算法,提供了一個簡單、直接地利用SACK來改善擁塞控制的方法。

3.2.2 TCP-Peach方案

TCP-Peach包括2種新算法：突然啟動和迅速恢復(fù),分別代替了TCP Reno中的慢啟動和快速恢復(fù)算法。

TCP-Peach有2個信道,一個用于數(shù)據(jù)傳輸,另一個用于網(wǎng)絡(luò)帶寬探測。TCP-Peach使用低優(yōu)先級的偽段來探測網(wǎng)絡(luò)的帶寬,偽段是最后被傳送的數(shù)據(jù)段,而且不傳送任何新信息,沿路徑的所有路由器都應(yīng)該執(zhí)行某種優(yōu)先級機制。在連接建立時的突然啟動期間,發(fā)送端發(fā)送一個數(shù)據(jù)包和(rwnd-1)個偽段,發(fā)送這些段的時間安排被均勻地分布在一個RTT內(nèi)。如果沿路徑?jīng)]有擁塞,偽段的確認(rèn)將返回到發(fā)送端,用來增加cwnd,這樣cwnd能在一個RTT以后達到cwnd。如果發(fā)生擁塞,那么就丟棄低優(yōu)先級的偽段,這樣就不會影響數(shù)據(jù)信道的帶寬。迅速恢復(fù)采用同樣的思想能夠把鏈路錯誤損壞從擁塞丟失中區(qū)分開來。在快速重傳之后,發(fā)送端發(fā)送偽段去探測信道帶寬。如果丟失是由鏈路層造成的,那么大部分偽段都應(yīng)該到達目的地,并且使用它們的ACKs來增加cwnd。如果丟失是由擁塞造成的,那么將丟棄所有偽段,同時迅速恢復(fù)像快速恢復(fù)一樣運行。

4 仿真實驗

仿真場景是模擬一種航天通信網(wǎng)絡(luò),目的是驗證采用的改進TCP協(xié)議后的傳輸性能評估,衛(wèi)星軌道高度為343 km的衛(wèi)星子網(wǎng)通過具有非對稱性的衛(wèi)星中繼轉(zhuǎn)發(fā)連接到地面網(wǎng)關(guān),為了協(xié)議性能,仿真時僅考慮衛(wèi)星與地面局域網(wǎng)BeijingLAN 的服務(wù)器之間建立的多次FTP業(yè)務(wù)傳輸情況。

仿真結(jié)果如圖1、圖2和圖3所示,證明采用改進TCP協(xié)議網(wǎng)絡(luò)性能是原來的8～25倍,能夠明顯提高空間鏈路條件下的TCP傳輸性能,保證整個網(wǎng)絡(luò)通信質(zhì)量。

圖1 窗口尺寸與吞吐量的關(guān)系

圖2 鏈路往返時間與吞吐量的關(guān)系(ber=0,BW=10 Mbps)

圖3 誤碼率與吞吐量的關(guān)系(DBW =10Mbps,ntt=560 ms)

5 結(jié)束語

該文研究了空間鏈路條件下的TCP傳輸控制協(xié)議,顯著提高了數(shù)據(jù)鏈路傳輸協(xié)議的吞吐率,提高了衛(wèi)星網(wǎng)絡(luò)鏈路帶寬利用率,預(yù)計隨著航天工程的大力推進,這一研究成果也會得以廣泛應(yīng)用。

[1]郝巖.航天測控網(wǎng)[M].北京：國防工業(yè)出版社,2004.

[2]趙軍,術(shù)雷鳴.中國航天測控網(wǎng)的發(fā)展[J].現(xiàn)代軍事,2003,23(2)：24-25.

[3]XA Hui-zhong.Discussion on the Networking Technology for TT&C Information Networks[J].Telecommunication Engineering,2007,47(3)：4-9.

[4]吳祖民,胡卓宇.衛(wèi)星通信中Internet業(yè)務(wù)接入[J].通信與廣播電視,2005(4)：21-27.

[5]盧潔,張淑清,應(yīng)啟戛.幾種網(wǎng)絡(luò)擁塞控制算法比較分析[J].自動化儀表,2006(27)：23-26.