無線局域網(wǎng)WLAN(Wireless LAN)是最后一跳為無線鏈路" title="無線鏈路">無線鏈路的網(wǎng)絡(luò)，具有覆蓋面積廣、帶寬高、安裝簡易和使用方便等優(yōu)點，因此被大規(guī)模應(yīng)用。研究無線移動寬帶接入互聯(lián)網(wǎng)的基礎(chǔ)理論與關(guān)鍵技術(shù)具有重要意義，提供高性能的無線互聯(lián)網(wǎng)傳輸層協(xié)議是實現(xiàn)無線寬帶接入互聯(lián)網(wǎng)的關(guān)鍵。
1 傳統(tǒng)TCP協(xié)議在無線環(huán)境下的局限性
　　目前互聯(lián)網(wǎng)使用的傳輸控制協(xié)議TCP是為固定主機和有線網(wǎng)絡(luò)設(shè)計的。在TCP中，發(fā)送端根據(jù)接收端ACK的反饋信息判斷網(wǎng)絡(luò)狀況，并假設(shè)丟包都是由網(wǎng)絡(luò)擁塞造成的。當(dāng)發(fā)生丟包時，發(fā)送端減小發(fā)送窗口，以減小網(wǎng)絡(luò)的負(fù)載，避免擁塞。有線網(wǎng)絡(luò)的拓?fù)浣Y(jié)構(gòu)變化不大，鏈路狀況比較穩(wěn)定，因此這種假設(shè)是成立的，但在無線環(huán)境下，丟包很可能是由無線鏈路本身的高誤碼率或移動主機切換等情況引起的，傳統(tǒng)TCP缺乏針對不同丟包狀況的處理機制，而將丟包都歸結(jié)為擁塞，錯誤地進行擁塞控制，從而導(dǎo)致TCP性能嚴(yán)重下降。
2 現(xiàn)有方法及不足
　　為解決上述問題，近年來一些文獻[1～3]相繼提出一些適應(yīng)無線環(huán)境的TCP改進版本。這些改進的協(xié)議都是為了解決最后一跳為無線鏈路的網(wǎng)絡(luò)帶來的問題，如無線鏈路高隨機誤碼率，移動主機在不同接入點AP(Access Point)之間切換等。但它們?nèi)匀槐Ａ袅嗽糡CP以發(fā)送端為控制中心的特點，所以效果并不理想。
　　2003年，Hsieh等人提出了一種以接收端為控制中心的傳輸層協(xié)議RCP(Reception Control Protocol)^[4]。它只是將控制中心移到了接收端，僅考慮了無線移動主機作為客戶端的情況，而忽略了服務(wù)器位于無線鏈路、無線互聯(lián)網(wǎng)中多樣化服務(wù)以及異構(gòu)環(huán)境等情況。
3 MCP協(xié)議的提出與初步實現(xiàn)
3.1 MCP協(xié)議概述
　　為更好地適應(yīng)無線鏈路網(wǎng)絡(luò)中的最后一跳，本文提出了以移動主機為控制中心的傳輸層協(xié)議稱為MCP(Mobile host Control Protocol)。該協(xié)議將以發(fā)送端為中心的傳輸層協(xié)議和以接收端為中心的傳輸層協(xié)議有機結(jié)合，以移動主機為控制中心，讓移動主機控制整個傳輸過程。在WLAN中，當(dāng)從固定主機向移動主機傳輸數(shù)據(jù)時，采用以接收端為中心的控制機制；而當(dāng)從移動主機向固定主機傳輸數(shù)據(jù)時，采用以發(fā)送端為中心的控制機制。
　　在WLAN中，MCP協(xié)議具有傳統(tǒng)TCP協(xié)議不具備的優(yōu)點：移動主機可以根據(jù)網(wǎng)絡(luò)狀況判斷丟包原因，根據(jù)不同原因采取不同的丟包恢復(fù)策略，從而可以避免TCP由于缺少丟包原因檢測機制而造成的傳輸性能下降；同時，移動主機可以根據(jù)不同的無線鏈路狀況采取不同的擁塞控制策略" title="控制策略">控制策略，克服了TCP協(xié)議使用單一擁塞控制策略，從而更好地適應(yīng)不同的無線鏈路；MCP協(xié)議在處理移動主機切換時也有很大優(yōu)勢，傳統(tǒng)TCP協(xié)議在切換過程中發(fā)送數(shù)據(jù)包失敗時只能等待超時重傳，同時觸發(fā)丟包恢復(fù)機制，這樣不但使原AP中緩存的數(shù)據(jù)包失效，而且浪費了傳輸時間，在MCP協(xié)議中，移動主機能夠在第一時間判斷切換是否完成，并主動請求發(fā)送端重傳丟失的數(shù)據(jù)包，從而提高了傳輸性能。
3.2 MCP的初步實現(xiàn)
　　MCP協(xié)議的初步實現(xiàn)主要是在仿真軟件NS-2^[5]上完成以移動主機為中心的連接建立、擁塞控制、丟包恢復(fù)等功能模塊。
3.2.1 MCP采取移動主機為中心的數(shù)據(jù)發(fā)送機制
　　傳統(tǒng)TCP采用DATA-ACK機制，即發(fā)送端主動發(fā)送數(shù)據(jù)包，接收端在收到數(shù)據(jù)包時發(fā)送相應(yīng)的確認(rèn)信息ACK，發(fā)送端收到ACK后，根據(jù)ACK信息判斷網(wǎng)絡(luò)狀況，采取適當(dāng)?shù)乃俾世^續(xù)發(fā)送。
　　在MCP中，當(dāng)移動主機作為發(fā)送端時，采用上述的DATA-ACK機制；當(dāng)移動主機作為接收端時，則采用REQ-DATA機制，即移動主機主動發(fā)送數(shù)據(jù)請求包，發(fā)送端在收到請求包之后，根據(jù)其中的要求進行發(fā)送。具體方法是：接收端將接收窗口的右值填入請求包頭部的adno字段，發(fā)送端只維護一個變量seqno，用來指向下一個要發(fā)送的數(shù)據(jù)包的序號，發(fā)送端每收到一個請求包，就讀取包頭的adno字段，并發(fā)送序號從seqno到adno的數(shù)據(jù)包。
3.2.2 MCP的連接建立過程
　　傳統(tǒng)TCP的連接建立是通過三次握手過程實現(xiàn)的。MCP的連接建立同樣通過三次握手過程實現(xiàn)，只是在一次連接建立的過程中，移動主機要向固定主機指明此次連接采用的控制機制。具體方法是：如果移動主機作為發(fā)送端，在建立連接的過程中會告知接收端采用以發(fā)送端為中心的控制機制；當(dāng)移動主機作為接收端時，則會在連接建立的過程中指明采取以接收端為中心的控制機制。
3.2.3 MCP的流量控制策略
　　傳統(tǒng)TCP協(xié)議在發(fā)送端維護擁塞窗口(cwnd)和慢啟動門限(ssthresh)兩個變量，以完成流量控制。當(dāng)cwnd小于ssthresh時，采用慢啟動機制(Slow Start)，用來探測網(wǎng)絡(luò)的可用帶寬，每個數(shù)據(jù)包被應(yīng)答后，cwnd就加1；當(dāng)cwnd大于ssthresh時，采用擁塞避免機制，以避免發(fā)生擁塞，并盡可能利用可用帶寬，每個數(shù)據(jù)包被應(yīng)答之后，cwnd＝cwnd+1/cwnd。MCP的流量控制機制與TCP基本相同，只是當(dāng)移動主機作為接收端時，上述兩個參數(shù)要在接收端進行維護。
3.2.4 MCP的丟包恢復(fù)策略
　　在傳統(tǒng)TCP中，當(dāng)發(fā)送端收到重復(fù)的ACK(DupACK，通常是連續(xù)三個相同序號的ACK包)時，就認(rèn)為發(fā)生丟包，從而采用快速重傳機制，重發(fā)序號為DupACK＋1的數(shù)據(jù)包，并對cwnd和ssthresh重新賦值，避免進入慢啟動階段；當(dāng)重傳定時器RTO(Retransmission TimeOut)超時，發(fā)送端會重新發(fā)送那個沒有收到ACK的數(shù)據(jù)包，同時進入慢啟動階段。
　　在MCP中，作為接收端的移動主機如果發(fā)現(xiàn)接收包序號連續(xù)三次發(fā)生亂序，就認(rèn)為發(fā)生丟包，此時接收端主動發(fā)送一個重傳請求包，要求發(fā)送端重發(fā)丟失的數(shù)據(jù)包。
　　為了將重傳請求包與數(shù)據(jù)請求包加以區(qū)別，在請求包頭加入loss字段和rtxno字段。如果是重傳請求包就將包頭loss字段設(shè)置成1，然后將rtxno字段設(shè)置成請求重發(fā)的數(shù)據(jù)包序號。如果是正常的數(shù)據(jù)請求包，則包頭的loss字段就設(shè)置成0。接受端收到請求包時首先檢查包頭的loss字段，如果loss為1，則重傳rtxno對應(yīng)的數(shù)據(jù)包，如果loss為0，則進行正常的數(shù)據(jù)包發(fā)送。
4 仿真實驗與性能比較
　　為了驗證MCP協(xié)議的可行性，在仿真軟件NS-2下進行了3組對比實驗。實驗采用的WLAN場景中，無線鏈路帶寬為11Mbps，有線鏈路帶寬為100Mbps。
　　實驗1：研究移動主機作為接收端時，MCP協(xié)議的發(fā)送窗口隨時間的變化情況。
　　分別采用初步實現(xiàn)的MCP和TCP協(xié)議從有線主機向無線主機發(fā)送FTP數(shù)據(jù)，仿真時間為0～500s，從中分別截取兩種協(xié)議在0～30s之間發(fā)送窗口隨時間的變化情況，得到MCP和TCP發(fā)送窗口隨時間變化如圖1所示。

　　從圖1可以看出，初步實現(xiàn)的MCP協(xié)議的發(fā)送窗口隨時間的變化趨勢與原始TCP基本相同，這從微觀上驗證了兩種協(xié)議在控制發(fā)包速率方面是基本一致的。
　　實驗2：研究MCP協(xié)議的吞吐量和公平性。
　　分別采用初步實現(xiàn)的MCP協(xié)議和TCP協(xié)議從同一個有線節(jié)點向多個無線節(jié)點發(fā)送FTP數(shù)據(jù)。作為接收端的無線節(jié)點數(shù)分別為5、10、15、20和25個，仿真時間均為0～500s，從中截取200～450s之間各個數(shù)據(jù)流的吞吐率，研究各個流之間的公平性和平均吞吐率。公平性指數(shù)的計算公式采用目前比較通用的：
　　
　　其中FI是公平性指數(shù)，n為節(jié)點數(shù)，xi是第i個節(jié)點的吞吐率，當(dāng)FI為1時，說明所有節(jié)點是完全公平的，F(xiàn)I越小說明公平性越差。各個流的公平性指數(shù)隨無線節(jié)點數(shù)變化情況如圖2所示。

　　從圖2可以看出，由MCP協(xié)議得到的公平性指數(shù)與具有良好公平性的原始TCP協(xié)議基本持平，說明初步實現(xiàn)的MCP協(xié)議在WLAN環(huán)境下具有很好的公平性。
　　各個流的平均吞吐量隨無線節(jié)點數(shù)變化情況如圖3所示。

　　圖3中的平均吞吐量是由200～450s內(nèi)各個數(shù)據(jù)流的吞吐量取平均值得到的。從中可以看出，在WLAN下，這種初步實現(xiàn)的MCP協(xié)議的吞吐量同原始TCP協(xié)議十分接近。
　　實驗3：研究MCP協(xié)議和TCP協(xié)議的兼容性。
　　采用兩條FTP數(shù)據(jù)流，其中一條從無線節(jié)點到有線節(jié)點使用TCP協(xié)議；另外一條從有線節(jié)點到無線節(jié)點使用MCP協(xié)議。仿真時間均為0～500s，從中分別截取兩條數(shù)據(jù)流200～450s的即時吞吐量，如圖4所示。