banner.jpg)
相關專題：
重慶郵電學院 重慶400065
摘 要 本文分析了在ad hoc網(wǎng)絡中TCP協(xié)議的主要缺陷，并對目前提出的幾種改進方案進行了比較分析，最后給出了結(jié)論和研究方向。
關鍵詞 Ad hoc網(wǎng)絡 TCP 網(wǎng)絡擁塞 擁塞控制
1 引言
無線ad hoc網(wǎng)絡是一種具有高度動態(tài)拓撲結(jié)構(gòu)的網(wǎng)絡。每一個無線ad hoc網(wǎng)絡由一組移動節(jié)點組成，它們與傳統(tǒng)的蜂窩技術(shù)的根本區(qū)別在于移動節(jié)點之間的通信是在沒有固定基礎設施（例如基站或路由器）支持的條件下進行的。
鑒于TCP/IP已經(jīng)成為事實上的Internet標準協(xié)議棧，作為Internet擴展的無線ad hoc網(wǎng)絡也必將采用它。然而，由于無線ad hoc網(wǎng)中的分組丟失主要由無線差錯和節(jié)點移動性所致，而TCP將所有的分組丟失都歸因于擁塞并啟動擁塞控制和避免算法，所以若在無線ad hoc網(wǎng)中直接采用傳統(tǒng)的TCP協(xié)議將可能導致端到端的吞吐量無謂降低。因此，分析TCP的性能并研究如何使其適應無線ad hoc網(wǎng)絡環(huán)境就變得尤為重要。
2 ad hoc網(wǎng)絡中TCP協(xié)議的主要缺陷
由于ad hoc網(wǎng)絡存在著BER(Bit Error Rate)高、帶寬低、移動性及能量有限等特點，使得原本為固定主機、有線網(wǎng)絡設計的TCP協(xié)議在這種環(huán)境下出現(xiàn)了很多不適應的問題。
�。�1）缺乏有效的錯誤恢復機制。一旦檢測出丟包，TCP便觸發(fā)擁塞控制處理過程，首先重傳未被確認的包，減小擁塞窗口從而降低發(fā)送速率；然后激活擁塞控制機制，包括超時時鐘指數(shù)回退、減小慢啟動閾值；最后進入擁塞避免階段以確保擁塞得以解除。如果丟包是由于ad hoc網(wǎng)絡的BER高或者節(jié)點移動造成的路由故障時發(fā)生的而不是網(wǎng)絡的擁塞，那么TCP的這種錯誤恢復機制會導致協(xié)議性能下降，包括吞吐量的下降和延遲的增加
�。�2）ad hoc網(wǎng)絡中有限的傳輸帶寬。由于移動節(jié)點可用帶寬往往較低，從而使得TCP源端的發(fā)送速率受到限制，使其用較小的擁塞窗口發(fā)送數(shù)據(jù)。在這種情況下，一旦有數(shù)據(jù)包丟失，源端就不能收到足夠多的重復確認包從而觸發(fā)快速重傳，而只能通過超時機制恢復，因而降低了可用帶寬的使用效率并且增加了延遲。
�。�3）由于缺乏有效的錯誤檢測和恢復機制，TCP在ad hoc環(huán)境下的能量使用效率也不高。例如，當無線鏈路上發(fā)生了不頻繁的隨機短暫突發(fā)性錯誤時，TCP源端便降低其擁塞窗口，然后很保守地逐步增加擁塞窗口的大小。在擁塞窗口緩慢地膨脹過程中，無錯（error-free）的傳輸機會便被浪費了，并且增加了通訊時間。而當錯誤持續(xù)時間較長（例如衰減信道、鏈路頻繁的突發(fā)性錯誤、長時間的網(wǎng)絡分割、網(wǎng)絡擁塞）時，TCP源端盡管降低了其擁塞窗口大小，但仍然在嘗試著發(fā)送數(shù)據(jù)，從而造成更多數(shù)據(jù)包的丟失。盡管吞吐量會有所增加，但是卻消耗了更多的能量，降低了能量使用的效率。而在ad hoc網(wǎng)絡中節(jié)點的能量關系到自身以及網(wǎng)絡的壽命，要做到盡可能地低的能量耗費。
3 主要的幾種改進方案
3.1 TCP-Feedback
TCP-Feedback是一種基于反饋的機制，TCP發(fā)送端收到中間節(jié)點傳來的路由故障通知（Route Failure Notification，RFN），確定丟包是由路由故障而不是網(wǎng)絡擁塞造成的。當收到RFN通知后，發(fā)送端認為當前到目的端沒有路由可用，于是進入"snooze"狀態(tài)，凍結(jié)所有和連接有關的變量如計時器和擁塞窗口的大小并不再發(fā)送任何數(shù)據(jù)。如果收到路由協(xié)議攜帶的路由重建通知（Route Re-establishment Notification，RRN）后，發(fā)送端認為到目的端已有可用路由，于是離開“snooze”狀態(tài)，恢復中斷前所有和連接有關的變量并開始發(fā)送數(shù)據(jù)。同時，設置了路由故障計時器防止發(fā)送端無限制地等待RRN通知。發(fā)送端一旦收到RFN通知，路由故障計時器就被觸發(fā)。如果路由故障計時器到期仍未收到RRN，發(fā)送端就認為是由于網(wǎng)絡擁塞造成的丟包，啟動TCP擁塞控制機制。
在路由重建延遲較大的條件下，由于涉及到重傳的次數(shù)較多，這種方案較之標準的TCP性能還是有所增強。但是用何種路由協(xié)議攜帶RFN和RRN信息可使TCP獲得最佳性能，仍有待進一步的研究。
3.2 TCP-ELFN
在TCP-ELFN中，TCP同樣要與路由協(xié)議交互，以獲得路由故障的消息并采取相應的策略。一旦有中間節(jié)點檢查到從發(fā)端到收端的路由故障后，該中間節(jié)點就向源節(jié)點發(fā)送顯式鏈路故障通知（Explicit Link Failure Notification，ELFN），ELFN消息包括發(fā)送端和接收端的主機地址、端口以及TCP序列號，這樣TCP就能區(qū)分丟包是由于路由故障（節(jié)點移動造成的）還是由于網(wǎng)絡擁塞造成的。不過動態(tài)資源路由協(xié)議（DSR）中的路由故障消息需要修改成ELFN。ELFN類似于網(wǎng)絡控制報文協(xié)議ICMP中的“主機不可到達”消息。
當發(fā)送端收到ELFN后，將TCP置為“stand-by”模式。在“stand-by”模式中，發(fā)送端向目的地定時發(fā)送探測包用以檢查路由是否恢復并屏蔽TCP的計時器。收到ACK后，發(fā)端認為到收端已經(jīng)有可用路由，于是TCP離開“stand-by”模式，恢復TCP的計時器的狀態(tài)，同時以中斷前的速率發(fā)送數(shù)據(jù)包。
在Ad hoc網(wǎng)絡中節(jié)點的頻繁移動導致DSR路由協(xié)議存在“無效路由”問題。比如，有節(jié)點向源端響應了“路由請求”消息，但是由于返回的路由涉及到的節(jié)點移走或者其中有鏈路中斷，導致返回路由無效。發(fā)端如果不能迅速檢查到返回路由已經(jīng)失效，TCP由于接收不到ACK將進入擁塞退避狀態(tài)�？梢�，“無效路由”問題會嚴重影響TCP的性能。對于TCP-ELFN中修改后的TCP性能，“無效路由”問題同樣存在較大影響。另外，發(fā)送探測包的間隔和選用何種數(shù)據(jù)包作為探測包都值得進一步的研究。
這種方案比起標準的TCP性能還是有所增強，但是還需要進一步的研究，如選用其他的路由協(xié)議對TCP性能的提高是否會更好以及對于發(fā)送探測包的間隔應該會有更多、更合適的值。
3.3 固定RTO
這種方案的思想就是把任何連接中斷都看作是瞬時的，這樣出現(xiàn)路由故障可以迅速恢復，不用激起TCP指數(shù)退避機制以免造成不必要的長時間的恢復延遲。當連續(xù)兩次重傳都超時，源端認為路由出現(xiàn)故障，屏蔽TCP指數(shù)退避機制，同時以固定間隔而不是以指數(shù)逐漸增加的間隔重傳數(shù)據(jù)包。
如果丟失的分組在第二次重傳計時器（RTO）到期后仍未得到確認，發(fā)送端將RTO的值加倍，然后不斷重傳丟失的分組，但RTO的值不再變化將保持恒定直到路由恢復，重傳的數(shù)據(jù)包得到確認。
研究表明，固定RTO用于按需路由算法可以使TCP性能獲得顯著的提高。盡管如此，固定RTO僅限于無線網(wǎng)絡，對于將來和固定網(wǎng)絡的融合不是很有利。
3.4 ATCP
前面的三種方案都需要對TCP協(xié)議進行修改，但ATCP可以避免這樣的變動。這種方案只是在網(wǎng)絡層和傳輸層之間插入一個中間層ATCP（Ad hoc TCP），ATCP負責監(jiān)視網(wǎng)絡狀態(tài)，通過網(wǎng)絡控制報文協(xié)議的“目的地不可達”消息或ECN機制的顯式擁塞通知（Explicit Congestion Notification，ECN）分別判斷網(wǎng)絡分割或網(wǎng)絡擁塞。當發(fā)送端收到三個重復的ACK，ATCP認為信道有損耗，將TCP置為“persist”模式并迅速從TCP緩存中重傳丟失的分組。在收到下一個ACK后，TCP才能回復到正常狀態(tài)；如果源端收到ICMP的“目的地不可達”消息，ATCP認為出現(xiàn)網(wǎng)絡分割，同樣將TCP置為“persist”模式，但是此時并不重傳分組，直到鏈路重建后才將TCP恢復到正常狀態(tài)；當源端收到表示網(wǎng)絡擁塞的ECN，ATCP僅僅把ECN上傳給TCP，由TCP激起擁塞控制機制。
ATCP同樣可以提高TCP的性能。但是在該方案中假設源端總是可達的，這種假設在Ad hoc網(wǎng)絡中很難滿足，如果該假設不能很好地滿足，那么發(fā)送端就收不到網(wǎng)絡控制報文協(xié)議的“目的地不可達”消息，這樣發(fā)送端會不斷地重傳分組而不是進入預期的“persist”模式，而且ECN機制會引起安全問題，這些不利因素都會影響到ATCP方案。
3.5 TCP DOOR
這個方案與前四個最大的不同在于不需要中間節(jié)點的參與。它的思想是在Ad hoc網(wǎng)絡，節(jié)點的頻繁移動可能導致收端收到無序的數(shù)據(jù)分組，無序的分組可能足以表明在網(wǎng)絡內(nèi)鏈路出現(xiàn)過故障。不僅僅是數(shù)據(jù)分組，發(fā)端同樣也可能收到無序的ACK。TCP DOOR對于收發(fā)雙方都能準確地檢查到無序分組的交付，但是需要在數(shù)據(jù)分組和ACK中增加額外的排序信息。在TCP“選項”字段中，用一個字節(jié)選項表示ACK的排序信息，兩個字節(jié)選項表示數(shù)據(jù)分組的排序信息。發(fā)送端每發(fā)送一個數(shù)據(jù)分組（不管是否是重傳的分組），就對其排序信息中的流序列號增加一次，而標準的TCP不會增加重傳數(shù)據(jù)分組的流序列號。這樣，收端就可以準確地檢查無序分組的交付并通過ACK中的特定比特告知發(fā)送端。每個重傳的ACK，收端都會增加其排序信息中的流序列號，以便發(fā)送端了解自身發(fā)送分組（不管分組是否重傳）的確切順序。因此，這種方案為源端提供了可靠的雙向數(shù)據(jù)流順序的信息，使得TCP發(fā)送端可以采取相應的策略。
檢查到無序分組的交付，TCP發(fā)送端有兩種反應機制：1.臨時屏蔽擁塞控制（temporarily disabling congestion），2.擁塞避免中的立即恢復(instant recovery during congestion avoidance)。前者認為無序分組是由于路由改變而不是網(wǎng)絡擁塞造成的，不必激起TCP擁塞控制機制。因此當檢查到無序分組后，發(fā)送端在一段時間內(nèi)(T1)保持變量如RTO，擁塞窗口大�。╟wnd）不變。對于后者，當檢查到無序分組后，TCP發(fā)送端檢查在前一段時間內(nèi)（T2）是否激起過擁塞控制機制，如果是，發(fā)端將立即恢復到激起擁塞控制之前的狀態(tài)，因為后者認為激起擁塞控制是由于鏈路臨時中斷而不是網(wǎng)絡擁塞造成的。
總地來說，TCP DOOR能顯著提供TCP的性能。同時響應機制中的擁塞避免中的立即恢復的性能要好于臨時屏蔽擁塞控制，而且僅有發(fā)送端檢測機制（即檢測ACK的無序）就足夠了。
在TCP DOOR方案中，假定無序分組是由于路由混亂造成的。這種假定仍有待進一步探究。
4 結(jié)論
上述介紹的幾種方案都是認為丟包是由其他原因而不是由網(wǎng)絡擁塞造成的，因此盡量避免TCP指數(shù)退避機制以提高TCP的性能。這幾種方案各有優(yōu)缺點，在一定程度上改善了Ad hoc網(wǎng)絡中TCP的性能，但都存在一定的局限性。今后對TCP性能改善的研究還需要與路徑不對稱問題、節(jié)點的能源管理、與固定網(wǎng)絡的融合以及安全性等問題結(jié)合考慮。
----《中國數(shù)據(jù)通信》
