衛(wèi)星通信中TCP協(xié)議分析改進方法研究

2019-11-03 09:04:57

字體：大中小

供稿：網(wǎng)友

電子工程學(xué)院網(wǎng)絡(luò)工程教研室　唐云　單洪

　　摘要：因特網(wǎng)的應(yīng)用中廣泛地使用著ＴＣＰ／ＩＰ協(xié)議，如簡單電子郵件協(xié)議（ＳＭＴＰ）、超文本傳輸協(xié)議（ＨＴＴＰ）、文件傳輸協(xié)議（ＦＴＰ）等。ＴＣＰ協(xié)議在有線網(wǎng)絡(luò)中工作得是很好的，但是在衛(wèi)星通信中卻不能很好的利用它的帶寬。傳輸?shù)拈L延時、接收窗口的大小、網(wǎng)絡(luò)中的擁塞等都成為衛(wèi)星通信中的突出問題，為此本文提出了衛(wèi)星通信中對ＴＣＰ協(xié)議進行改進的方法。

　　１引言

　　ＴＣＰＩＰ是目前進行網(wǎng)絡(luò)數(shù)據(jù)傳輸時使用的主要協(xié)議族。該協(xié)議族中，ＴＣＰ和ＩＰ是核心，同時還包括一些其它協(xié)議。ＴＣＰ和ＩＰ協(xié)議分別控制著數(shù)據(jù)在互聯(lián)網(wǎng)上的傳輸和路由選擇。ＩＰ是一個為廣域網(wǎng)設(shè)計的無連接網(wǎng)絡(luò)層協(xié)議，它被設(shè)計為網(wǎng)間互聯(lián)協(xié)議，ＩＰ數(shù)據(jù)報可在幾乎任何鏈路層協(xié)議上的網(wǎng)關(guān)（或路由器）間傳遞。從本質(zhì)上說，ＩＰ無非是指導(dǎo)網(wǎng)絡(luò)上的數(shù)據(jù)包從發(fā)方計算機送達(dá)收方計算機，而ＴＣＰ則負(fù)責(zé)確保數(shù)據(jù)在設(shè)備之間進行端到端的可靠交付。從這個意義上說，衛(wèi)星鏈路對ＴＣＰＩＰ數(shù)據(jù)傳輸?shù)挠绊懼饕w現(xiàn)在ＴＣＰ層。

　　２．ＴＣＰ協(xié)議概述

　　ＴＣＰ協(xié)議主要是通過積極的確認(rèn)機制來傳送數(shù)據(jù)。每一個數(shù)據(jù)段都包含了一個序號用來確定數(shù)據(jù)段在傳輸中的位置，這個序號由每個數(shù)據(jù)段的第一個字節(jié)在傳送中的相對位置決定。比如，假設(shè)一個ＴＣＰ發(fā)端將發(fā)送一批數(shù)據(jù)，每段大小為１００字節(jié)，若第一段的序號定為Ｘ，則第二段的序號將為Ｘ＋１００，以后各段依次類推（為了介紹方便，本文將不用標(biāo)準(zhǔn)的８比特數(shù)字來表示段的序號，而直接采用一般的數(shù)字）。接收端在收到數(shù)據(jù)后便可依據(jù)這些序號來重組數(shù)據(jù)，恢復(fù)成完整的信號。此外，收端在每收到一個數(shù)據(jù)段后便會向發(fā)端發(fā)一個確認(rèn)信號ＡＣＫ這個確認(rèn)信號包含了下一個需接收數(shù)據(jù)段的序號。

　　ＴＣＰ是一個滑動窗口協(xié)議。這種滑動窗口協(xié)議使發(fā)端可連續(xù)地發(fā)送一定數(shù)量的數(shù)據(jù)。發(fā)送數(shù)據(jù)時，當(dāng)發(fā)端收到了收端的確認(rèn)信號（ＡＣＫ）后，窗口便相應(yīng)地向后滑動，以便能傳送更多的數(shù)據(jù)段。每一個ＴＣＰ段（數(shù)據(jù)段或是ＡＣＫ）在其首部都許諾了一個窗口值，它的大小收到的數(shù)據(jù)段發(fā)送確認(rèn)應(yīng)答。

　　由收端確定，是來自收端的流量控制，它限定了發(fā)端滑動窗口的最大值。標(biāo)準(zhǔn)的ＴＣＰ所能許諾的最大窗口是６５５３５字節(jié)，因為在它的ＴＣＰ頭中只有１６個比特用來定量窗口大小。

　　ＴＣＰ應(yīng)用了一系列的擁塞控制算法來解決擁塞問題。由于網(wǎng)絡(luò)的容量有限，如果ＴＣＰ發(fā)端傳輸數(shù)據(jù)速率過高，那么網(wǎng)絡(luò)中的路由器就會來不及處理這些數(shù)據(jù)段，數(shù)據(jù)段便擁塞在路由器處，若這些路由器又沒有緩沖能力或緩沖能力有限，便會造成擁塞在路由器處數(shù)據(jù)段的丟失。當(dāng)很多條通路都以高的速率向網(wǎng)絡(luò)中注入數(shù)據(jù)時，若沒有解決擁塞的辦法，大量注入網(wǎng)絡(luò)中的數(shù)據(jù)就會擁塞在路由器附近，導(dǎo)致數(shù)據(jù)丟失，不能到達(dá)目的地，從而引起發(fā)端不斷地重發(fā)，這樣就造成越來越多的數(shù)據(jù)注入到網(wǎng)絡(luò)，卻得不到正確的處理，網(wǎng)絡(luò)擁塞進一步惡化。ＴＣＰ的擁塞控制協(xié)議主要有四種，慢啟動、擁塞避免、快速重發(fā)和快速恢復(fù)。下面簡單地介紹一下這些算法。

　　２．１啟動和擁塞避免

　　通過運行慢速啟動和擁塞避免算法，ＴＣＰ能在不產(chǎn)生路由擁塞的前提下提高數(shù)據(jù)傳輸速率。ＴＣＰ發(fā)端采用一個可變的擁塞窗口（發(fā)端的滑動窗口），窗口大小不超過收端的通知窗口，ＴＣＰ不允許向網(wǎng)絡(luò)中注入多于窗口大小的未經(jīng)確認(rèn)的數(shù)據(jù)。

　　慢速啟動通過增加發(fā)端窗口大小逐漸地增加數(shù)據(jù)注入量，當(dāng)連接建立時或是網(wǎng)絡(luò)中檢測到擁塞時，此算法初始化擁塞窗口為一個數(shù)據(jù)段大小，每收到一個來自收端的確認(rèn)后，擁塞窗口大小便增加一個段值的大小，這樣傳輸速率便逐漸增加。當(dāng)窗口值達(dá)到慢速啟動門限或是擁塞再一次被檢測到時，慢速啟動便停止工作。在連接建立時慢速啟動門限被初始化為收端通知窗口值的大小。對于任何一個數(shù)據(jù)段，一旦超過了ＴＣＰ的重發(fā)時間（ＲＴＯ），ＴＣＰ便重發(fā)這個數(shù)據(jù)段，并認(rèn)為網(wǎng)絡(luò)發(fā)生了擁塞，這時慢速啟動的門限降為擁塞窗口值的一半，擁塞窗口值置為一個段值大小，慢速啟動算法開始工作，直到再次超過新的慢速門限或是再次檢測到擁塞為止。

　　擁塞避免在慢速啟動工作完后開始生效。在這個過程中，擁塞窗口（Ｃｗｉｎｄ）的大小以十分緩慢的速度增長，每收到一個確認(rèn)應(yīng)答（ＡＣＫ）窗口值便增加１Ｃｗｉｎｄ（除非它的大小已經(jīng)超過了收端通知窗口的大小），每一個往返時延（ＲＴＴ）大約增加一個段值大小。

　　２．２快速重發(fā)和快速恢復(fù)

　　通過快速重發(fā)和快速恢復(fù)機制，ＴＣＰ能比依靠重發(fā)時間（ＲＴＯ）檢測方法更有效地檢測并恢復(fù)丟失的數(shù)據(jù)。ＲＴＯ等于（往返時延）ＲＴＴ加上一些變量，如果發(fā)端在重發(fā)時間內(nèi)未收到確認(rèn)應(yīng)答，便重發(fā)數(shù)據(jù)段，如果ＴＣＰ的計時器間隔不大于ＲＴＯ的話，這種體制運行得是很好的，若大于則難于引發(fā)這個重發(fā)機制（如在許多有線網(wǎng)絡(luò)中，ＲＴＴ小于５００ｍｓ，而ＢＳＤＵｎｉｘ操作系統(tǒng)計時器的時間間隔為５００ｍｓ）。

　　快速重發(fā)在重發(fā)時間前重發(fā)數(shù)據(jù)段。當(dāng)數(shù)據(jù)段沒有按順序到達(dá)收端時，ＴＣＰ便發(fā)送復(fù)制的ＡＣＫ，收端若收到３個這樣的復(fù)制ＡＣＫ，ＴＣＰ便認(rèn)為數(shù)據(jù)已經(jīng)丟失并重發(fā)相應(yīng)的數(shù)據(jù)段，并且，ＴＣＰ判定此時發(fā)生了網(wǎng)絡(luò)擁塞并且降低發(fā)送速率。當(dāng)運行快速重發(fā)機制重發(fā)數(shù)據(jù)段時，快速恢復(fù)算法也開始啟動。擁塞窗口值降為以前的一半大小，慢速啟動門限也被設(shè)置為此值。發(fā)端每收到一個確認(rèn)應(yīng)答便認(rèn)為對應(yīng)的數(shù)據(jù)段收端已收到，而不在網(wǎng)絡(luò)中，鑒于此，ＴＣＰ判定網(wǎng)絡(luò)還能容納更多的數(shù)據(jù)段，于是擁塞窗口增加一個數(shù)據(jù)段值大小，發(fā)送速率因此得到提高，如果收到了一個不是復(fù)制的ＡＣＫ，ＴＣＰ便減去這些因快速恢復(fù)增加的值（即回到慢速啟動門限值），隨后，開始提到的擁塞避免算法開始運行。

　　３．衛(wèi)星通信中使用ＴＣＰ存在的問題

　　ＴＣＰ是ＴＣＰＩＰ中的用于可靠數(shù)據(jù)傳輸?shù)膫鬏斂刂茀f(xié)議，ＴＣＰ要求反饋以確認(rèn)數(shù)據(jù)接收成功。衛(wèi)星信道的一些固有特性（如較大延遲、較高比特差錯率和帶寬不對稱等）對通過衛(wèi)星鏈路進行ＴＣＰＩＰ傳輸有一定的負(fù)面影響，如過長的ＴＣＰ超時和重傳引起較大的帶寬浪費，此外還要考慮衛(wèi)星環(huán)境下的一些ＴＣＰ特性，如窗口較小，往返定時器不精確，以及啟動窗口等問題。但其影響主要體現(xiàn)在通信流量（擁塞）控制和協(xié)議帶寬效率這兩方面，因此衛(wèi)星通信中的ＴＩＰＩＰ傳輸研究也應(yīng)主要集中在這兩方面。

　　３．１擁塞避免

　　假定一條信道的擁塞窗口為１２８個數(shù)據(jù)段大小，當(dāng)檢測到擁塞時降為６４個數(shù)據(jù)段大小，若用擁塞避免算法，每一往返時間（ＲＴＴ）大約增加一個數(shù)據(jù)段大小，將需要５．１２秒達(dá)到１２８個數(shù)據(jù)段大小，這對帶寬的利用是很低效的。

　　３．２慢速啟動

　　ＴＣＰ為完成對數(shù)據(jù)的確認(rèn)使用了滑動窗口機制，為避免擁塞采用了稱為“慢啟動”的策略。發(fā)方對丟失或損壞數(shù)據(jù)的重發(fā)，要求保留數(shù)據(jù)副本直至收到數(shù)據(jù)確認(rèn)（ＡＣＫ）。為避免大量可能丟失的數(shù)據(jù)副本占用大量存儲器并浪費帶寬，ＴＣＰ采用了一個滑動窗口機制來限制傳輸中的數(shù)據(jù)數(shù)量。隨著確認(rèn)的返回，ＴＣＰ在前移窗口的同時，發(fā)送不斷增加的數(shù)據(jù)。一旦窗口被占滿，發(fā)方必須停止傳輸數(shù)據(jù)直至更多的確認(rèn)幀到達(dá)。

　　雖然ＴＣＰ能發(fā)現(xiàn)數(shù)據(jù)沒有送達(dá)，但重新發(fā)送會進一步加劇信道的擁塞，從而進一步導(dǎo)致數(shù)據(jù)丟失。為避免網(wǎng)絡(luò)因擁塞而癱瘓，ＴＣＰ只能降低傳輸速率以對數(shù)據(jù)丟失做出反應(yīng)。但是從算法上講，ＴＣＰ每次進行新的連接都必須從最低的傳輸速率啟動，ＴＣＰ用返回的ＡＣＫ來指示提高速率，這是一個較慢的線性增加的過程。這就是所說的“慢啟動”，即發(fā)送窗口依每次往返時間遞增，以提高傳輸速率和網(wǎng)絡(luò)吞吐量。

　　據(jù)測量，ＮＡＳＡ（美國國家宇航局）ＡＣＴＳ衛(wèi)星的往返時延（ＲＴＴ）是５６０ｍｓ，陸地網(wǎng)絡(luò)中，從俄亥俄大學(xué)到加利福尼亞大學(xué)的往返時延是８０ｍｓ，通過下面的公式：

　　慢速啟動時間＝（ＲＴＴ）×１ｏｇ２（Ｗ）Ｗ為最大窗口

　　假定窗口大小分別為５１２字節(jié)和１２８字節(jié)，我們可知在衛(wèi)星網(wǎng)絡(luò)中需要很長的時間（３．９２秒）來達(dá)到峰值傳輸速率，陸地網(wǎng)絡(luò)中需要５６０ｍｓ，顯然對于衛(wèi)星網(wǎng)絡(luò)來說帶寬利用率是很低的。

　　３．３信道吞吐量

　　對于衛(wèi)星ＴＣＰＩＰ數(shù)據(jù)傳輸，由于延遲時間過長，正常ＴＣＰ中滑動窗口的大小限制了衛(wèi)星鏈路的最高吞吐量；同樣，由于ＡＣＫ從衛(wèi)星網(wǎng)絡(luò)中返回得十分緩慢，ＴＣＰ達(dá)到全速時需要一個較長的提速時間，即使對于一個較小的數(shù)據(jù)連接也是如此。

　　許多可調(diào)整的參數(shù)可用于增強ＴＣＰ的性能，包括數(shù)據(jù)段、定時器和窗口的大小。ＴＣＰ實現(xiàn)中含有大量擁塞避免算法，如慢啟動、選擇重傳和選擇確認(rèn)，它通常能改進像Ｉｎｔｅｒｎｅｔ這樣的共享網(wǎng)絡(luò)的性能。但在許多擁塞控制算法，特別是慢啟動中，當(dāng)中等數(shù)量數(shù)據(jù)正在一個具有較大帶寬延遲特性的鏈路上傳輸時，會產(chǎn)生端到端通信的低效帶寬利用問題。對此需要有相應(yīng)的解決辦法。

　　這里我們假定信道最大吞吐量為１．５３６ＭｂｉｔＳ，使用最大的接收窗口６５５３５字節(jié)，ＲＴＴ為５６０ｍｓ，它的最大吞吐量＝６４Ｋ×８５６０＝０．９４ＭｂｉｔＳ，可知沒有完全應(yīng)用衛(wèi)星的信道帶寬。

　　４．衛(wèi)星網(wǎng)絡(luò)中ＴＣＰ效率的改善

　　１．基于衛(wèi)星信關(guān)站采用特殊的方法來提高ＴＣＰ效率

ＴＣＰ協(xié)議采用的是端到端控制方式。將擁塞控制放在擁塞發(fā)生的衛(wèi)星信關(guān)站會取得更好的效果。嚴(yán)格說，在信關(guān)站采取的策略不屬于ＴＣＰ協(xié)議。由于信關(guān)站對擁塞控制具有直接性，因此對網(wǎng)絡(luò)傳輸具有比較好的改進效果，主要的方法包括：

　　（１）隨機及早監(jiān)測

　　當(dāng)信關(guān)站緩存區(qū)長度超過門限時，數(shù)據(jù)就會按照一定的概率丟失，這是信關(guān)站及早地通知發(fā)端降低發(fā)送速率，以免過多地向網(wǎng)絡(luò)中注入數(shù)據(jù)。

　　（２）明確擁塞指示

　　信關(guān)站向源端發(fā)出明確的擁塞指示，源端據(jù)此指示減少擁塞窗口和慢啟動門限。

　　（３）ＴＣＰ欺騙法

　　在確認(rèn)信息尚未到達(dá)時，信關(guān)站作為虛擬的目的節(jié)點向源端發(fā)送確認(rèn)信息使得源端可以繼續(xù)發(fā)送下一數(shù)據(jù)包，同時信關(guān)站又作為虛擬的源端向真正的目的端發(fā)送數(shù)據(jù)，這樣對源端可以減少確認(rèn)信息的往返時延，從而提高源端的發(fā)送速率。這種方法僅適用于鏈路質(zhì)量非常好的網(wǎng)絡(luò)，對鏈路質(zhì)量差、網(wǎng)絡(luò)和安全性要求高的業(yè)務(wù)都不適用。

　　（４）延時確認(rèn)

　　延時確認(rèn)是當(dāng)網(wǎng)絡(luò)擁塞時信關(guān)站通過對返回的確認(rèn)信號進行延時，源端在收不到確認(rèn)信號時就會減小發(fā)送速率，以此減緩擁塞的發(fā)生。此方法在擁塞不嚴(yán)重時效果明顯，但在擁塞嚴(yán)重時效果不很明顯。

　　２．我們可以采用多條ＴＣＰ連接，從而更加充分地利用信道帶寬。慢啟動時每次發(fā)送Ｎ個數(shù)據(jù)段，其效率大于僅發(fā)送一個數(shù)據(jù)段，同樣在擁塞避免時也能更快地實現(xiàn)。

　　３．加大初始化窗口

　　針對初始化窗口為１，在信道連接時信道利用太低的緣故可適量的加大初始化窗口。

　　初始窗口＝ｍｉｎ４×ＭＳＳ，ｍａｘ（２×ＭＳＳ，４３８０）

　　其中：ＭＳＳ代表收發(fā)雙方允許的最大數(shù)據(jù)包長。按照這種方法，在慢啟動算法中所需要的最大接收窗口恢復(fù)時間可以縮短為：

　　慢速啟動時間＝ＲＴＴｌｏｇ２Ｗａ－Ｒｌｏｇ２Ｗｉ

　　其中：Ｗａ為最大允許接收窗口，Ｗｉ為初始窗口。

　　４．選擇性確認(rèn)

　　在數(shù)據(jù)傳送過程中接收方不需要對發(fā)送方的每個數(shù)據(jù)段都進行確認(rèn)，在確認(rèn)信息中告知發(fā)送方已經(jīng)正確接收到的數(shù)據(jù)包，發(fā)送方只需重發(fā)出錯包，這就避免了不必要的數(shù)據(jù)重傳。

　　ＴＣＰ接下來的一個主要缺點是它易受多個丟失的影響，造成失去其″自計數(shù)″屬性和超時。在長延遲網(wǎng)絡(luò)中，阻止不必要的窗口減小并僅重發(fā)受損丟失分組，有助于提高帶寬利用率，如ＩＴＵ－Ｔ為衛(wèi)星制定的ＳＳＣＯＰ協(xié)議。這類協(xié)議稱為選擇性確認(rèn)（ＴＣＰＳＡＣＫ），對ＴＣＰ協(xié)議提出了明顯的改進。ＴＣＰＳＡＣＫ是一個數(shù)據(jù)發(fā)現(xiàn)算法，其中接收方能夠有選擇地示意哪個數(shù)據(jù)塊（數(shù)據(jù)段）沒有收到。這允許接收方僅精確地重傳這些遺漏的分組，從而有效地減少了不必要的重傳。

　　研究表明ＴＣＰＳＡＣＫ適合于具有中等丟失率（低于窗口大小的５０％）的長延遲網(wǎng)絡(luò)環(huán)境以及對于線路丟失率較嚴(yán)重的網(wǎng)絡(luò)，在ＳＡＣＫ基礎(chǔ)上改進的前向ＡＣＫ建議比較適合。前向ＡＣＫ進一步地結(jié)合了擁塞控制以及數(shù)據(jù)發(fā)現(xiàn)算法，盡管對于高噪聲衛(wèi)星環(huán)境還有待進一步研究，但前向ＡＣＫ有望提供較高的性能增益。

　　５．慢速啟動門限評估

　　當(dāng)ＴＣＰ運用多條連接進行數(shù)據(jù)傳送時便容易引起數(shù)據(jù)的丟失，如果我們能在數(shù)據(jù)丟失前終止慢速啟動就可以避免這種數(shù)據(jù)丟失了。根據(jù)公式：

　　窗口大小＝（ｂａｎｄｗｉｄｔｈ）×（ＲＴＴ）

　　在知道了往返時間（ＲＴＴ）后，只要能評估出可使用的帶寬，窗口大小便可確定了，這時就可以決定慢速啟動算法在什么時候?qū)⑼Ｖ埂?br>
　　６．快速重傳和快速恢復(fù)

　　增大初始窗口雖然使得窗口恢復(fù)時間縮短了，但是并沒有改變慢啟動算法和擁塞避免算法結(jié)合的擁塞控制機制。將快速重傳和快速恢復(fù)配合使用，就是為改進擁塞避免和慢速啟動算法而提出的。當(dāng)源端收到３個相同的確認(rèn)信息時就判定發(fā)生擁塞，立即進行重發(fā)，同時將窗口減半，慢啟動門限設(shè)置為減小后的窗口大小，擁塞控制窗口比慢啟動門限大３。當(dāng)源端收到一個新的確認(rèn)信息后，將擁塞窗口的大小設(shè)置為慢啟動門限，同時轉(zhuǎn)入擁塞避免。快速重傳和快速恢復(fù)可以避免單純利用超時重發(fā)引起的系統(tǒng)性能下降。

　　５．結(jié)論

　　本文對衛(wèi)星通信的ＴＣＰ協(xié)議進行了詳細(xì)的討論，并對ＴＣＰ體制中存在的問題和一些解決方法進行了分析。這些應(yīng)用型的結(jié)論將能更加好的利用衛(wèi)星通信的信道帶寬，高效地提供網(wǎng)絡(luò)服務(wù)，但這些結(jié)論只是在原有的基礎(chǔ)上的改進，并不是十分完美，如快速重傳和快速恢復(fù)協(xié)議在擁塞恢復(fù)后發(fā)送速率的增長呈線性增加，還有些算法只是針對特定的情況有效，這些都需要進一步地研究與改進。

----《通信世界報》