NS-2實踐分析TCP的擁塞控制原理

1、NS-2 實踐：分析 TCP 的擁塞控制原理作者：何堅(來源：賽迪網(wǎng))http:/2005 年 07 月 05 日之前我曾經(jīng)給大家介紹了如何安裝網(wǎng)絡(luò)模擬器 NS-2,如何安裝移動 IPv6 快速切換協(xié)議的擴(kuò)展，以及如何使用NAM 和 XGRAPH 對試驗結(jié)果進(jìn)行分析(請參見NS-2 實踐：在 NS-2 環(huán)境下模擬移動 IPv6 的快速切換)。這篇文章中，我將在上篇文章的基礎(chǔ)上，給大家詳細(xì)介紹如何利用 XGRAPH 來分析 TCP 的擁塞控制原理。TCP 是 TransmissionControlProtocol 的縮寫，即傳輸控制協(xié)議，它對應(yīng)于 OSI 七層模型中的傳輸層，建立于網(wǎng)絡(luò)層之上。T

2、CP 旨在給互聯(lián)網(wǎng)提供一種可靠的端到端的字節(jié)傳輸流。自從 1988 年問世以來，TCP 在研究者的努力下先后得到了許多新的發(fā)展，目前主要的模型包括四個，即 TCPTAHOE,TCPRENO,TCPNEWRENO 和 TCPSACK。TCPTAHOE 模型是最早的 TCP 協(xié)議之一，它由 Jacobson 提出。Jacobson觀察到，TCP 報文段(TCPSegment)丟失有兩種原因，其一是報文段損壞，其二是網(wǎng)絡(luò)阻塞，而當(dāng)時的網(wǎng)絡(luò)主要是有線網(wǎng)絡(luò)，不易出現(xiàn)報文段損壞的情況，網(wǎng)絡(luò)阻塞為報文段丟失的主要原因。針對這種情況，TCPTAHOE 對原有協(xié)議進(jìn)行了性能優(yōu)化，其特點是，在正常情況下，通過重傳

3、計時器是否超時和是否收到重復(fù)確認(rèn)信息(dupack)這兩種丟包監(jiān)測機(jī)制來判斷是否發(fā)生丟包，以啟動擁塞控制策略；在擁塞控制的情況下，采用慢速啟動(SlowStart)算法和快速重傳(FastRetransmit)算法來控制傳輸速率。在試驗中，我們以 TCPTAHOE 模型為例，對 TCP 的擁塞控制原理進(jìn)行分析，包括兩種丟包監(jiān)測機(jī)制和擁塞控制中的慢速啟動算法和快速重傳算法。1.1. TCPTCP 擁塞控制相關(guān)技術(shù)簡介1.11.1 慢速啟動算法在 TCPTAHOE 模型中，擁塞控制主要是通過調(diào)整發(fā)送端的發(fā)送速率，而這又主要是通過三個變量實現(xiàn)的：擁塞窗口(CongestionWindow),接收端窗

4、口(ReceiverssWindow,慢速啟動閾值(SlowStartThreshold,SSTHRESH)。發(fā)送端一旦監(jiān)測到數(shù)據(jù)包丟失(其原因可能是重傳計時器超時，亦可能是收到重復(fù)的 ACK 信令)，它就會開始調(diào)整發(fā)送速率。這包括，ssthresh 調(diào)整為當(dāng)前擁塞窗口的一半，同時擁塞窗口將降低到 1 個報文段。然后，隨著通信過程的恢復(fù)，擁塞窗口持續(xù)增長。在擁塞窗口大小未達(dá)到 ssthresh 之前，它以指數(shù)速度增長；到達(dá)之后則開始線性增長。有趣的是，雖然這種算法稱為慢速啟動算法，但實際上一點兒也不慢，它是指數(shù)增長的。1.21.2 快速重傳算法當(dāng)發(fā)送端連續(xù)收到 3 個對應(yīng)于同一個序列號的 AC

5、K 信令時，就觸發(fā)了其快速重傳算法，即發(fā)送端不等重傳計時器超時，立即向接收端發(fā)送指定的報文段。1.31.3 丟包檢測機(jī)制有如下兩種.重復(fù) ACK 信令重復(fù) ACK 有兩個作用，其一，發(fā)送端可以確信該 ACK 序列號之前的 TCP 報文段都已經(jīng)被接收端成功接收；其二，發(fā)送端可以據(jù)此判斷出接收端接收到的 TCP 報文段發(fā)生了亂序的情況和接收端當(dāng)前期待的 TCP 報文段序列號，從而觸發(fā)其擁塞控制策略。.超時重傳發(fā)送端發(fā)出報文段后，在規(guī)定的時間內(nèi)沒有能夠收到接收端返回的 ACK 信令，從而使得發(fā)送端認(rèn)為該報文段丟失，觸發(fā)其擁塞控制策略。在這里面主要涉及到重傳計時器(retransmissiontime

6、r),它是 TCP 協(xié)議中最重要的計時器。根據(jù)ComputerNetworks,FourthEdition,當(dāng)報文段發(fā)出后，重傳計時器立即啟動，如果發(fā)送端在計時器超時之前得到 ACK,則計時器停止； 如果計時器超時后仍然沒有收到新啟動。 計算超時的主要公式有：Timeout=RTT+4DD=aD+(-Pa)|RTTM|RTT=aRTT+(1-a)M其中 M、RTT、D 均為可變值，M 是當(dāng)次的 RTT 值。. .試驗網(wǎng)絡(luò)拓?fù)鋱D與參數(shù)該試驗基于 NS-2 網(wǎng)絡(luò)模擬器，并在我們之前搭建好的無線環(huán)境中進(jìn)行，試驗?zāi)康氖欠治?TCP 擁塞控制原理。圖 1 是試驗網(wǎng)絡(luò)拓?fù)鋱D。由于網(wǎng)絡(luò)層協(xié)議是移動 IPv6

7、,因此有名稱為通信節(jié)點(CorrespondingNode,CN)、家鄉(xiāng)代理(HomeAgent,HA)、接入路由器(AccessRouter,AR)、移動節(jié)點(MobileNode,MN)的網(wǎng)絡(luò)實體,其中 CN 為數(shù)據(jù)發(fā)送端，MN 為數(shù)據(jù)接收端，AR 是接入路由器，HA 則對于我們這次的試驗沒有影響，因此不予介紹。NodeX 為普通網(wǎng)絡(luò)節(jié)點。網(wǎng)絡(luò)鏈路的典型參數(shù)，即帶寬和延遲，標(biāo)于每條鏈路之上。一般情況下，由于 Internet 上傳送的數(shù)據(jù)量大，相應(yīng)的延遲比較大，因此 Internet 的延遲設(shè)為了 50ms;無線網(wǎng)絡(luò)的帶寬比較小，因此我們設(shè)為了 1M。整個試驗過程持續(xù) 80 秒。CN 為

8、FTP 型的數(shù)據(jù)源，TCP 報文段大小為 256bytes,擁塞控制窗口(CongestionWindow)為 32。CN 從第 6 秒開始向 MN1 發(fā)送 TCP 報文段，一直到整個試驗結(jié)束。該 TCP 協(xié)議采用 NS-2中的 Tahoe 模型。兩個接入路由器(AccessRouter,AR)分別接入兩個局域網(wǎng)，它們的位置分別為(85.0,135.0),(155.0,135.0),相隔70 米，AR 的有效覆蓋范圍是以 AR 自身為中心，半徑 40 米的圓，又因為 PAR 和 NAR 在縱坐標(biāo)相同，因此在他們兩者的中心連線上，有 10 米重復(fù)的覆蓋范圍。MN從第5秒開始接收CN發(fā)送過來的FT

9、P數(shù)據(jù)， 經(jīng)過5秒鐘的穩(wěn)定時間后， 于第10秒以1m/s的恒定速度由位置(85.0,135.1)走到(155.0,135.1)處，相當(dāng)于沿著 PAR 與 NAR 的中心連線，由 PAR 走向 NAR 處。試驗進(jìn)行到第 80 秒的時候，MN 剛好走到目的地。對于網(wǎng)絡(luò)節(jié)點而言，沒有配置好網(wǎng)絡(luò)層就不能夠正常的進(jìn)行傳輸層通信。在該試驗中，MN 在移動過程中會發(fā)生切換，其間由于 MN 需要進(jìn)行網(wǎng)絡(luò)層的配置將不能夠進(jìn)行正常的傳輸層通信，因此 CN 會監(jiān)測到報文段丟失的情況，并且會啟動其擁塞控制策略，這就是我們觀察的重點。. .試驗與分析我們的測試分為兩部分。第一部分試驗以重復(fù) ACK 信令彳為 TCP 擁

10、塞控制策略的觸發(fā)事件，第二部分試驗以超時重傳作為 TCP 擁塞控制策略的觸發(fā)事件。每部分都做 10 次模擬試驗以求試驗數(shù)據(jù)的客觀性。ACK,那么報文段就重傳，并且計時器重當(dāng)試驗結(jié)束后，我們用 XGRAPH 制圖，有兩種類型。第一種為 TCP 序列號圖，它們基于通信節(jié)點（發(fā)送報文段的節(jié)點）和移動節(jié)點（接收報文段的節(jié)點）的發(fā)送和接收緩存中的 TCP 序列號制成，能反映 TCP 報文段的傳輸情況，這類圖的橫坐標(biāo)為時間，縱坐標(biāo)為 TCP 序列號。第二類圖為擁塞窗口變化圖，能反映數(shù)據(jù)包的傳輸速率，這類圖的橫坐標(biāo)為時間，縱坐標(biāo)為擁塞窗口大小。首先我們根據(jù)圖 2 至圖 7 來分析通過重復(fù) ACK 信令觸發(fā)

11、CN（發(fā)送節(jié)點）啟用 TCP 擁塞控制策略的情況。圖 4 通信節(jié)點和移動節(jié)點發(fā)送端 TCP 序列號詳圖圖 6 通信節(jié)點擁塞控制窗口變化4142圖 7 通信節(jié)點擁塞控制窗口變化詳圖其中，圖 2 至圖 5 是試驗期間 CN(通信節(jié)點，在試驗中又是發(fā)送節(jié)點)和 MN(移動節(jié)點，在試驗中又是接收節(jié)點)的接收緩存和發(fā)送緩存中的 TCP 序列號圖。圖 6 和圖 7 則是試驗期間 CN 的擁塞窗口變化圖。圖 4、圖 5分別為為圖 2、圖 3 紅色矩形區(qū)域的放大圖；圖 7 為圖 6 藍(lán)色矩形區(qū)域的放大圖。具體分析如下：.MN 進(jìn)行切換的過程中，短時間內(nèi)將不能夠接收 TCP 報文段，這在圖 5 中，表現(xiàn)為 MN

12、 的接收端 TCP 序列號在 40.4 至40.6 秒期間，有一個缺口；.由于 CN 并不了解 MN 已經(jīng)不能夠接收 TCP 報文段，所以它繼續(xù)發(fā)送數(shù)據(jù)?？梢詮膱D 4 中看到 CN 發(fā)送的 TCP 報文段序列號比 MN 的長了一段，而正常通信情況下，應(yīng)該是 CN 發(fā)出的每一個報文段，MN 都會回應(yīng)一個 ACK 信令，在圖中表現(xiàn)為縱坐標(biāo)相同；.由于 MN 接收的報文段序列號有缺口，意味著它收到了亂序的報文段，因此 MN 發(fā)送了一連串的重復(fù) ACK信令，對應(yīng)于圖 4 中一段平行于時間軸的直線；.40.6 秒左右，CN 收到一連串的來自 MN 的重復(fù) ACK 信息，即圖 5 中一段平行于時間軸的直線

13、，這就觸發(fā)了 CN 的擁塞控制策略及快速重傳算法；.根據(jù)快速重傳算法，CN 在收到第 3 個重復(fù)確認(rèn)信令后，不等重傳計時器超時，立即發(fā)送 MN 在 ACK 信令中所指定的報文段，因此在圖 4 中，在 40.6 秒時間軸的右方，有個紅色的三角形，即代表 CN 發(fā)出的 TCP 報文段?？焖僦貍魉惴ㄔ诖颂幖铀倭送ㄐ潘俣?，因為，CN 與 MN 間的 RTT(RoundTripTime)至少為它們之間網(wǎng)絡(luò)延遲之和的兩倍，即 112 毫秒，RTO(RetransmissionTimeOut)還要更長，如果等到 RTO 超時再重發(fā)數(shù)據(jù)包，則需要花至少 112 毫秒；但實際上，從圖 4 中可以看出，CN 重發(fā)

14、數(shù)據(jù)包只花了 40 毫秒左右的時間。因此，快速重傳在這里發(fā)揮了作用。.與此同時，在圖 7 中可以看到，啟動擁塞控制策略后，CN 對擁塞窗口大小進(jìn)行了調(diào)整，首先是在 40.6 秒左右降到 1 個報文段，然后根據(jù)慢速啟動算法，CN 以指數(shù)形式來提高擁塞窗口大小，即 20,21,22,23,直到將其調(diào)整到慢速啟動閾值(SSTHRESH,SlowStartThreshold)。在這里，由于試驗中定義擁塞窗口大小為 32,因此，發(fā)生網(wǎng)絡(luò)擁塞時，SSTHRESH 調(diào)整為擁塞窗口大小的一半，即 16。從圖 7 中可以看出，擁塞窗口大小增長到 16 后進(jìn)入線性增長階段。.此外，由于擁塞窗口大小的限制，CN 在

15、快速重傳開始后，前面四次 TCP 報文段傳送速率分別是一次發(fā)送20,21,22,23 個 TCP 報文段，這在圖 4 中，表現(xiàn)為紅色三角形在 40.6 秒后的四次發(fā)送數(shù)量分別是 1,2,4,8上述就是根據(jù)數(shù)據(jù)圖對重復(fù) ACK 信令引起的擁塞控制策略進(jìn)行的分析，如果對此有了充分的理解，那么超時重傳的情況也與此類似。因此，接下來我們根據(jù)圖 8 至圖 9 來簡單說明通過超時重傳觸發(fā)發(fā)送端啟用 TCP 擁塞控制策略的情況。-UN圖 8 通信節(jié)點和移動節(jié)點發(fā)送端 TCP 序列號可以看到，從圖 9 中可以看到，50.1 秒左右，由于 MN 開始切換，不能夠正常接收 TCP 報文段；并且由于切換時間較長，M

16、N 長時間內(nèi)都不能夠給 CN 進(jìn)行回應(yīng)。于是當(dāng) CN 等到自己的重傳計時器超時，就再次發(fā)送沒有得到 MN 回應(yīng)的報文段。在 50.1 秒后，CN 分另 I隔了 0.5 秒，1.0 秒，2.0 秒發(fā)送了三次同樣的 TCP 報文段，這對應(yīng)于圖 8 中的標(biāo)記。該超時重傳過程持續(xù)到 MN 最終完成切換配置，并對第三次重發(fā)的報文段進(jìn)行回應(yīng)，于是兩者開始恢復(fù)通信。4 4.小結(jié)通過該試驗，一方面我們試驗數(shù)據(jù)分析和驗證了 TCP 的擁塞控制原理；另一方面，我們可以看到，TCPTAHOE模型并不太適合作為無線網(wǎng)絡(luò)的傳輸協(xié)議。TCP 協(xié)議由于出現(xiàn)的比較早，其性能方面的優(yōu)化主要是基于傳輸網(wǎng)絡(luò)為有線網(wǎng)絡(luò)這個假設(shè)，因此，一旦根據(jù)重傳計時器超時或者重復(fù) ACK 信令判斷出發(fā)生了數(shù)據(jù)包丟失，當(dāng)前的 TCP 協(xié)議就認(rèn)為發(fā)生了網(wǎng)絡(luò)擁塞，于是啟用網(wǎng)絡(luò)擁塞策略來降低傳輸速率，比如慢速啟動，將擁塞窗口調(diào)整為 1 個 TCP 報文段；而實際情況是，我們的傳輸基于無線網(wǎng)絡(luò)，當(dāng)不能夠接收到 ACK 信令的時候，很有可能是因為移動節(jié)點正在進(jìn)行切換或者是無線網(wǎng)絡(luò)的信號不好，因此，需要發(fā)送節(jié)點保持或者加快發(fā)送速率，而不是減速發(fā)送。適合無線網(wǎng)絡(luò)運行的 TCP 協(xié)議已