基于移動(dòng)主機(jī)的傳輸控制協(xié)議的研究與實(shí)現(xiàn)_第1頁(yè)
基于移動(dòng)主機(jī)的傳輸控制協(xié)議的研究與實(shí)現(xiàn)_第2頁(yè)
基于移動(dòng)主機(jī)的傳輸控制協(xié)議的研究與實(shí)現(xiàn)_第3頁(yè)
基于移動(dòng)主機(jī)的傳輸控制協(xié)議的研究與實(shí)現(xiàn)_第4頁(yè)
全文預(yù)覽已結(jié)束

下載本文檔

版權(quán)說(shuō)明:本文檔由用戶(hù)提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

1、    基于移動(dòng)主機(jī)的傳輸控制協(xié)議的研究與實(shí)現(xiàn)        楊震宇,舒炎泰,張 亮 時(shí)間:2008年05月14日     字 體: 大 中 小        關(guān)鍵詞:        摘要:關(guān)鍵詞: 無(wú)線局域網(wǎng) 傳輸控制協(xié)議 移動(dòng)主機(jī)1 傳統(tǒng)TCP協(xié)議在無(wú)線環(huán)境下的局限性目前互聯(lián)

2、網(wǎng)使用的傳輸控制協(xié)議TCP是為固定主機(jī)和有線網(wǎng)絡(luò)設(shè)計(jì)的。在TCP中,發(fā)送端根據(jù)接收端ACK的反饋信息判斷網(wǎng)絡(luò)狀況,并假設(shè)丟包都是由網(wǎng)絡(luò)擁塞造成的。當(dāng)發(fā)生丟包時(shí),發(fā)送端減小發(fā)送窗口,以減小網(wǎng)絡(luò)的負(fù)載,避免擁塞。有線網(wǎng)絡(luò)的拓?fù)浣Y(jié)構(gòu)變化不大,鏈路狀況比較穩(wěn)定,因此這種假設(shè)是成立的,但在無(wú)線環(huán)境下,丟包很可能是由無(wú)線鏈路本身的高誤碼率或移動(dòng)主機(jī)切換等情況引起的,傳統(tǒng)TCP缺乏針對(duì)不同丟包狀況的處理機(jī)制,而將丟包都?xì)w結(jié)為擁塞,錯(cuò)誤地進(jìn)行擁塞控制,從而導(dǎo)致TCP性能?chē)?yán)重下降。2 現(xiàn)有方法及不足為解決上述問(wèn)題,近年來(lái)一些文獻(xiàn)13相繼提出一些適應(yīng)無(wú)線環(huán)境的TCP改進(jìn)版本。這些改進(jìn)的協(xié)議都是為了解決最后一跳為無(wú)

3、線鏈路的網(wǎng)絡(luò)帶來(lái)的問(wèn)題,如無(wú)線鏈路高隨機(jī)誤碼率,移動(dòng)主機(jī)在不同接入點(diǎn)AP(Access Point)之間切換等。但它們?nèi)匀槐A袅嗽糡CP以發(fā)送端為控制中心的特點(diǎn),所以效果并不理想。2003年,Hsieh等人提出了一種以接收端為控制中心的傳輸層協(xié)議RCP(Reception Control Protocol)4。它只是將控制中心移到了接收端,僅考慮了無(wú)線移動(dòng)主機(jī)作為客戶(hù)端的情況,而忽略了服務(wù)器位于無(wú)線鏈路、無(wú)線互聯(lián)網(wǎng)中多樣化服務(wù)以及異構(gòu)環(huán)境等情況。3 MCP協(xié)議的提出與初步實(shí)現(xiàn)3.1 MCP協(xié)議概述3.2 MCP的初步實(shí)現(xiàn)MCP協(xié)議的初步實(shí)現(xiàn)主要是在仿真軟件NS-25上完成以移動(dòng)主機(jī)為中心的連

4、接建立、擁塞控制、丟包恢復(fù)等功能模塊。傳統(tǒng)TCP采用DATA-ACK機(jī)制,即發(fā)送端主動(dòng)發(fā)送數(shù)據(jù)包,接收端在收到數(shù)據(jù)包時(shí)發(fā)送相應(yīng)的確認(rèn)信息ACK,發(fā)送端收到ACK后,根據(jù)ACK信息判斷網(wǎng)絡(luò)狀況,采取適當(dāng)?shù)乃俾世^續(xù)發(fā)送。在MCP中,當(dāng)移動(dòng)主機(jī)作為發(fā)送端時(shí),采用上述的DATA-ACK機(jī)制;當(dāng)移動(dòng)主機(jī)作為接收端時(shí),則采用REQ-DATA機(jī)制,即移動(dòng)主機(jī)主動(dòng)發(fā)送數(shù)據(jù)請(qǐng)求包,發(fā)送端在收到請(qǐng)求包之后,根據(jù)其中的要求進(jìn)行發(fā)送。具體方法是:接收端將接收窗口的右值填入請(qǐng)求包頭部的adno字段,發(fā)送端只維護(hù)一個(gè)變量seqno,用來(lái)指向下一個(gè)要發(fā)送的數(shù)據(jù)包的序號(hào),發(fā)送端每收到一個(gè)請(qǐng)求包,就讀取包頭的adno字段,并發(fā)

5、送序號(hào)從seqno到adno的數(shù)據(jù)包。傳統(tǒng)TCP的連接建立是通過(guò)三次握手過(guò)程實(shí)現(xiàn)的。MCP的連接建立同樣通過(guò)三次握手過(guò)程實(shí)現(xiàn),只是在一次連接建立的過(guò)程中,移動(dòng)主機(jī)要向固定主機(jī)指明此次連接采用的控制機(jī)制。具體方法是:如果移動(dòng)主機(jī)作為發(fā)送端,在建立連接的過(guò)程中會(huì)告知接收端采用以發(fā)送端為中心的控制機(jī)制;當(dāng)移動(dòng)主機(jī)作為接收端時(shí),則會(huì)在連接建立的過(guò)程中指明采取以接收端為中心的控制機(jī)制。傳統(tǒng)TCP協(xié)議在發(fā)送端維護(hù)擁塞窗口(cwnd)和慢啟動(dòng)門(mén)限(ssthresh)兩個(gè)變量,以完成流量控制。當(dāng)cwnd小于ssthresh時(shí),采用慢啟動(dòng)機(jī)制(Slow Start),用來(lái)探測(cè)網(wǎng)絡(luò)的可用帶寬,每個(gè)數(shù)據(jù)包被應(yīng)答后,

6、cwnd就加1;當(dāng)cwnd大于ssthresh時(shí),采用擁塞避免機(jī)制,以避免發(fā)生擁塞,并盡可能利用可用帶寬,每個(gè)數(shù)據(jù)包被應(yīng)答之后,cwndcwnd+1/cwnd。MCP的流量控制機(jī)制與TCP基本相同,只是當(dāng)移動(dòng)主機(jī)作為接收端時(shí),上述兩個(gè)參數(shù)要在接收端進(jìn)行維護(hù)。在傳統(tǒng)TCP中,當(dāng)發(fā)送端收到重復(fù)的ACK(DupACK,通常是連續(xù)三個(gè)相同序號(hào)的ACK包)時(shí),就認(rèn)為發(fā)生丟包,從而采用快速重傳機(jī)制,重發(fā)序號(hào)為DupACK1的數(shù)據(jù)包,并對(duì)cwnd和ssthresh重新賦值,避免進(jìn)入慢啟動(dòng)階段;當(dāng)重傳定時(shí)器RTO(Retransmission TimeOut)超時(shí),發(fā)送端會(huì)重新發(fā)送那個(gè)沒(méi)有收到ACK的數(shù)據(jù)包,

7、同時(shí)進(jìn)入慢啟動(dòng)階段。在MCP中,作為接收端的移動(dòng)主機(jī)如果發(fā)現(xiàn)接收包序號(hào)連續(xù)三次發(fā)生亂序,就認(rèn)為發(fā)生丟包,此時(shí)接收端主動(dòng)發(fā)送一個(gè)重傳請(qǐng)求包,要求發(fā)送端重發(fā)丟失的數(shù)據(jù)包。為了將重傳請(qǐng)求包與數(shù)據(jù)請(qǐng)求包加以區(qū)別,在請(qǐng)求包頭加入loss字段和rtxno字段。如果是重傳請(qǐng)求包就將包頭loss字段設(shè)置成1,然后將rtxno字段設(shè)置成請(qǐng)求重發(fā)的數(shù)據(jù)包序號(hào)。如果是正常的數(shù)據(jù)請(qǐng)求包,則包頭的loss字段就設(shè)置成0。接受端收到請(qǐng)求包時(shí)首先檢查包頭的loss字段,如果loss為1,則重傳rtxno對(duì)應(yīng)的數(shù)據(jù)包,如果loss為0,則進(jìn)行正常的數(shù)據(jù)包發(fā)送。4 仿真實(shí)驗(yàn)與性能比較為了驗(yàn)證MCP協(xié)議的可行性,在仿真軟件NS-

8、2下進(jìn)行了3組對(duì)比實(shí)驗(yàn)。實(shí)驗(yàn)采用的WLAN場(chǎng)景中,無(wú)線鏈路帶寬為11Mbps,有線鏈路帶寬為100Mbps。實(shí)驗(yàn)1:研究移動(dòng)主機(jī)作為接收端時(shí),MCP協(xié)議的發(fā)送窗口隨時(shí)間的變化情況。分別采用初步實(shí)現(xiàn)的MCP和TCP協(xié)議從有線主機(jī)向無(wú)線主機(jī)發(fā)送FTP數(shù)據(jù),仿真時(shí)間為0500s,從中分別截取兩種協(xié)議在030s之間發(fā)送窗口隨時(shí)間的變化情況,得到MCP和TCP發(fā)送窗口隨時(shí)間變化如圖1所示。從圖1可以看出,初步實(shí)現(xiàn)的MCP協(xié)議的發(fā)送窗口隨時(shí)間的變化趨勢(shì)與原始TCP基本相同,這從微觀上驗(yàn)證了兩種協(xié)議在控制發(fā)包速率方面是基本一致的。實(shí)驗(yàn)2:研究MCP協(xié)議的吞吐量和公平性。分別采用初步實(shí)現(xiàn)的MCP協(xié)議和TCP協(xié)

9、議從同一個(gè)有線節(jié)點(diǎn)向多個(gè)無(wú)線節(jié)點(diǎn)發(fā)送FTP數(shù)據(jù)。作為接收端的無(wú)線節(jié)點(diǎn)數(shù)分別為5、10、15、20和25個(gè),仿真時(shí)間均為0500s,從中截取200450s之間各個(gè)數(shù)據(jù)流的吞吐率,研究各個(gè)流之間的公平性和平均吞吐率。公平性指數(shù)的計(jì)算公式采用目前比較通用的:其中FI是公平性指數(shù),n為節(jié)點(diǎn)數(shù),xi是第i個(gè)節(jié)點(diǎn)的吞吐率,當(dāng)FI為1時(shí),說(shuō)明所有節(jié)點(diǎn)是完全公平的,F(xiàn)I越小說(shuō)明公平性越差。各個(gè)流的公平性指數(shù)隨無(wú)線節(jié)點(diǎn)數(shù)變化情況如圖2所示。從圖2可以看出,由MCP協(xié)議得到的公平性指數(shù)與具有良好公平性的原始TCP協(xié)議基本持平,說(shuō)明初步實(shí)現(xiàn)的MCP協(xié)議在WLAN環(huán)境下具有很好的公平性。各個(gè)流的平均吞吐量隨無(wú)線節(jié)點(diǎn)數(shù)

10、變化情況如圖3所示。圖3中的平均吞吐量是由200450s內(nèi)各個(gè)數(shù)據(jù)流的吞吐量取平均值得到的。從中可以看出,在WLAN下,這種初步實(shí)現(xiàn)的MCP協(xié)議的吞吐量同原始TCP協(xié)議十分接近。實(shí)驗(yàn)3:研究MCP協(xié)議和TCP協(xié)議的兼容性。采用兩條FTP數(shù)據(jù)流,其中一條從無(wú)線節(jié)點(diǎn)到有線節(jié)點(diǎn)使用TCP協(xié)議;另外一條從有線節(jié)點(diǎn)到無(wú)線節(jié)點(diǎn)使用MCP協(xié)議。仿真時(shí)間均為0500s,從中分別截取兩條數(shù)據(jù)流200450s的即時(shí)吞吐量,如圖4所示。圖4中的即時(shí)吞吐量計(jì)算的是每一秒內(nèi)的吞吐量,從中可以看出,兩條數(shù)據(jù)流并沒(méi)有出現(xiàn)互相壓制的情況,并且它們的即時(shí)吞吐量都在同一均值附近上下波動(dòng)。這就驗(yàn)證了在WLAN下,這種初步實(shí)現(xiàn)的MCP協(xié)議與TCP協(xié)議具有良好的兼容性。上述3組仿真實(shí)驗(yàn),表明了這種初步實(shí)現(xiàn)的MCP協(xié)議在WLAN環(huán)境下,具有與傳統(tǒng)TCP幾乎相同的性能,而且與傳統(tǒng)TCP協(xié)議存在良好的兼容性,從而證明了MCP協(xié)議的可行性,這就為下階段根據(jù)無(wú)線鏈路的特點(diǎn),對(duì)MCP協(xié)議進(jìn)行功能上的改進(jìn)提供了良好的基礎(chǔ)。本文提出的以移動(dòng)主機(jī)為中心的傳輸層協(xié)議MCP將控制中心移到移動(dòng)主機(jī),可以較好地解決最后一跳是無(wú)線鏈路的網(wǎng)絡(luò)帶來(lái)的擁塞控制、丟包恢復(fù)以及切換等傳統(tǒng)TCP及其改進(jìn)版本都不能很好解決的問(wèn)題,是一種從根本上改善無(wú)線互聯(lián)網(wǎng)傳輸層性能的有效途徑?,F(xiàn)階段主要是將以接收端為中心的傳輸層

溫馨提示

  • 1. 本站所有資源如無(wú)特殊說(shuō)明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶(hù)所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒(méi)有圖紙預(yù)覽就沒(méi)有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶(hù)上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶(hù)上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶(hù)因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

最新文檔

評(píng)論

0/150

提交評(píng)論