無線網絡中選擇性重傳機制性能分析與改進

摘要：分析了SACK機制的性能，根據TCP協議改進思想，通過模擬仿真展示了改進后無線網絡中SACK機制的性能。

關鍵詞：無線網絡； TCP協議； SACK機制

中圖分類號：TP319.3文獻標志碼：A

文章編號：1001—3695(2007)03—0238—03

0引言

以移動PC和PDA為代表的無線處理終端的逐漸普及和無線通信技術的迅猛發展已經預示，無線通信網絡將成為網絡通信中一種不可或缺且占有很大業務比例的網絡通信業務，可以相信無線網絡將承擔越來越多的通信業務。在日本，筆記本在整個PC中的占用率已經超過了40％，而在全世界范圍內已有越來越多的用戶選擇使用筆記本和PDA進行工作或娛樂，所以無線網絡業務急劇增加，同時對無線網絡能否提供高質量的服務提出了嚴峻的考驗。

無線網絡的迅速發展迫使人們必須在無線網絡中提供可靠、高效的網絡協議，因此如何在無線網絡中提供高效率的網絡協議機制是一個研究的熱點問題。與有線網絡相對應，按照范圍和拓撲結構可以將無線網絡分為以下幾種類型：無線廣域網（WWANs）；移動Ad hoc網絡（MANETs）；無線局域網（WLANs）。與傳統的有線網絡相比，無線網絡擁有以下幾個特點：有限的帶寬、高延遲時間、高比特出錯率和一段時間的斷鏈現象。這些特點對研究無線網絡提出了新的挑戰，在制定無線網絡協議時必須充分考慮以上因素再提出解決的方案，而絕對不可以照搬有線網絡中的協議。

TCP是一種在當前Internet中得到廣泛應用的可靠的傳輸層協議[4，7]，它能在比特出錯率很小的有線網絡環境長時間地使用已經顯示了其良好的性能。TCP機制的原理就是每一個TCP報文發送者都會保持記錄一個往返時延，依靠這個往返時延發送方擁有一個時間限制。如果發送的報文在時間限制中沒有得到接收方的確認那么就將已發送過的報文進行重傳，正是這種機制保證了TCP協議的可靠性。因為TCP協議在Internet中良好的性能得到了廣泛的認可，所以通過改進TCP協議使其繼續在無線網絡中提供可靠高效的服務是一個理所當然的研究熱點。但是不能夠將有線網絡中的TCP協議直接搬移到無線網絡上實現、使用，在文獻[2]中已經說明未經改進的TCP協議在無線網絡上性能表現十分低下。無線網絡中較高的比特出錯率這一特點導致了很容易在同一窗口中出現多個報文丟失的情況，而報文的丟失又將直接導致不必要的重傳，報文不必要的重傳很可能造成網絡擁塞，嚴重時還可能造成網絡崩潰[13]。在1986年10月，由于擁塞崩潰的發生，美國的LBL到UC Berekley之間的數據吞吐量從32 kbps跌落到了40 bps[12]。選擇性重傳機制（SACK機制）的設計初衷就是為了處理一個窗口中同時丟失多個報文的情況[6]，因此在無線網絡中對TCP協議的改進都已經加入了SACK機制。在文獻[3]中已經提出了在無線網絡中實現一種簡單的基于TCP協議的Snoop協議。在Snoop協議中對移動終端中TCP協議代碼進行了改進，通過改進移動終端使其能進行SACK處理也就是可以進行重傳，而在基站中可以產生SACK就可以實現SACK機制在無線網絡中的運行。而我們知道對于擁有較大帶寬和較大延遲的LFNs類型的網絡來說，SACK表現出了很好的性能[3]。在具體實現中基站可以將任何一個傳輸窗口中遺失的報文進行存儲記錄，然后對移動終端發送NACK進行確認。該機制對于在一個窗口中丟失多個報文的情況是很合適的，而NACK報文的設計就是在SACK機制上改進而成的。

1SACK機制運行原理及其在無線網絡中的實現

1．1SACK機制運行原理

早在1988年Braden和Jacobson在IETF的RFC 1072[5]中就提出了選擇性重傳機制（SACK Mechanism），但是直到1996年才由Mathis，Mahdavi等在RFC 2018[6]中詳細規定了SACK機制的實現方案并分析了其性能和與之相關的一些問題。相比于文獻[5]，文獻[6]中SACK機制更易于實現并對魯棒性進行了分析。

SACK機制要解決的問題是：當一個窗口出現多個報文丟失的情況時，因為TCP發送方只能在一個往返時延中獲知一個報文的丟失情況，所以很有可能發送方在收到確認前會再次進行報文的發送，這樣就造成了不必要的重傳。而SACK機制再加上選擇性重傳策略可以解決這個限制：接收端在接收到了來自于發送端的報文后就會發回SACK報文，以通知發送端哪些報文已經成功接收，這樣發送方根據SACK報文可以只將那些需要重傳的報文進行重傳，從而避免了不必要的重傳。

在文獻[6]中SACK機制擁有兩種TCP選項：①允許選項也就是SACK-permitted選項；②SACK選項，用于在已經建立的網絡連接上進行傳送。SACK-permitted選項的格式如圖1所示。其中2Bytes的選項可以在SYN中傳送，用來通知。一旦連接建立，TCP發送方就可以接收SACK報文了。因此，SACK-permitted選項不能在非SYN段中傳送。

SACK選項的格式如圖2所示。SACK選項被數據接收方發送用于通知發送方已經有哪些非連續的數據塊被接收方正確接收并被裝入隊列。在選項中，除了類型和長度2Bytes的域以外，其余都是數據塊的左右邊界。左邊界代表該數據塊的第一個32bits序列號；而右邊界代表緊接著該數據塊最后一個序列號的下一個32bits序列號。如果一個SACK選項中擁有n個數據塊，那么一共需要8n+2Bytes，因此對于最大只有40Bytes的TCP選項來講[7]，其最多也就只能容納下四個數據塊。但是一般又將SACK選項與時間戳選項一起使用[8]，如果去掉時間戳選項的10Bytes，那么一個SACK選項中就只能有三個數據塊了。擁有三個數據塊就說明在三個連續的ACK報文中每個SACK塊可以被重復三次。但是如果所有通告某一SACK塊的ACK報文都丟失了，那么接收方就會認為那個SACK塊中的數據接收方并沒有接收到，從而造成了不必要的重傳。由此可見，SACK塊數量上的限制是現有SACK機制的瓶頸。從理論上來講，如果一個SACK選項中數據塊個數為n就意味著對于同一個SACK塊來說其擁有n次機會被ACK報文通告給接收方，因此ACK中SACK塊數量越多，那么不必要重傳出現的概率就越小；而如果SACK選項中可以表示的數據塊過少，那么不必要重傳出現的概率就非常大。當SACK選項中只能表示一個數據塊時，則與原始的TCP協議沒什么差別了，對于減少不必要的報文重傳將是于事無補。因此現在的焦點在于如何使用最少的比特空間來表示SACK塊信息。基于這樣的思想在RFC 2883[9]中提出了一種新的機制，即DSACK，在其具體實現中SACK的第一塊用于放置最近接收到的重復報文信息，這樣就可以減少在ACK報文中的SACK信息。這種思想正越來越被接受，特別是對于無線網絡。在文獻[10]中提出了兩種對TCP SACK機制的改進，可以進一步壓縮SACK塊的信息。對于無線網絡這一比較特殊的網絡環境來說，因為其比特丟失率較高，所以ACK報文的丟失概率遠遠大于有線網絡，最大限度地增加SACK塊的數量是最為緊迫的策略，這正是無線網絡中急需的改進方案。

1．2無線網絡中SACK機制的實現情況

針對無線網絡中存在的問題，目前對TCP協議改進的增強方案可以分為三種：端到端（E2E）方式；分段TCP（Split-TCP）方式；鏈路層（LL）的改進。在端到端方式中，E2E-SACK是將TCP RENO與SACK機制結合在一起;分段連接方式中，Split-SACK協議是在基站中將一個TCP連接分為兩個連接，但是與有線網絡不同的是在無線網絡中除了提供TCP RENO機制以外還要提供SACK機制；鏈路層協議中的LL-SACK與LL-STCP-AWare協議均擁有SACK機制。

以上的例子說明在無線網絡中SACK機制已經得到了很大程度的認可，很多協議都已經支持和實現了SACK機制，因此對無線網絡中SACK機制的進一步改進將會具有重大的意義。

2SACK機制的改進方案

在文獻[10]中展示了兩種改進方案的思想：在表示SACK塊時，與其傳送完整的32bits序列號，不如采用占用空間更小的基序號+偏移序號的方式來表示。也就是說除了第一個SACK塊的左邊界序號是完整的32bits序號來作基序號以外，其他的序號都用偏移序號來表示。因為引入了偏移序號，所以必須增加一個X項用來表示偏移序號空間的大小。這里對于偏移序號的設置有兩種方案：①將第一塊的左邊界基序號作為所有序號的基序號，其他的偏移序號均以它作為基礎。②將除了第一塊SACK塊的左邊界作為基序號以外，其他的偏移序號都是前一個序號的偏移值，這樣的結果可進一步壓縮偏移值空間，但提高了計算的復雜性。圖3顯示了改進方案的效果。

因為相比于第②種方案來說，第①種方案在性能上要稍微遜色一點，所以下面就依照第②種方案通過具體實現RFC 2018[6]中的第三個例子來從理論上分析改進后的效果。在第三個例子中，設定發送方發送的每一個數據段的大小均為500Bytes，起始序列號是5000。在傳送過程中，偶數個數據段丟失了。表1、2分別列出了未經改進和經過改進后的SACK選項運行的結果。

可以看出，使用未經改進的TCP SACK選項，發送到第9段時，就將消耗2+4×8=34Bytes來發送4個SACK塊的信息。而在收到第12段時，因為受到TCP頭部大小的限制，在ACK中只能包含4個SACK塊信息，所以必須將6000—6500塊信息丟失。而對于改進后的SACK選項來講：X=log 2 500=9。那么比特的占用情況為8（類型）+8（長度）+8（X域大小，為了簡便起見就使用1Byte來表示）+32（基序列號）+9×9（偏移序列號）=137bits=18Bytes。與未經改進的SACK選項相比，經過改進的SACK選項在傳送SACK塊信息時所占用的空間大為縮小。對于一個窗口中多個報文遺失這種情況來講，即便在報文丟失數目很大的情況下也可以避免不必要的重傳情況的發生。如果不考慮時間戳這種情況，按照TCP報文頭中的選項最多用40Bytes的空間來計算，那么將擁有40×8-8（類型）-8（長度）-8（X域大小）-32（基序列號）=264bits來容納SACK塊信息，也就是可以最多容納29個SACK塊。在一般情況下，這已經足夠用了。

3仿真結果

為了能夠證明改進后的SACK機制有潛力解決當前SACK機制遇到的問題，通過利用NS2進行仿真來查看效果。圖4、5分別表示了兩種SACK機制的運行情況。

圖4是來源于文獻[10]的仿真結果；圖5是在相同環境下已改進的SACK機制的仿真結果。

從圖4中可以看出，因為未經改進的SACK機制在SACK塊方面的限制，所以39、41、43和45號報文（在圖中用“●”突出表示）不必要地進行了重傳，極大地浪費了網絡資源。而在圖5中可以發現，第39、41、43和45號報文并沒有進行不必要的重傳。根據文獻[11]，可知道不必要的報文重傳可以導致TCP連接吞吐率的下降，所以分析以上的模擬結果可以得出結論：已改進的SACK在實現中擁有比未經改進的SACK機制更佳的性能效果。

4結束語

綜上所述，現在的無線環境已經在很多TCP協議的改進版本中添加了SACK機制，SACK機制已經得到了一定程度的廣泛應用。但是現在這些未經改進過的SACK機制存在一個瓶頸，即最多在ACK中容納下3—4個SACK塊，所以在一些時候就會出現不必要的重傳，浪費了無線網絡資源。本文根據文獻[10]中提出的思想，對SACK塊的表示方法進行改進，最大限度地減少了SACK塊的占用空間，以實現可以在ACK中容納更多的SACK塊，這樣就可以解決未經改進的SACK機制中的瓶頸問題，從而不會造成不必要的重傳，也不會導致TCP吞吐量的下降。最后通過利用NS2進行模擬仿真，從仿真結果中比較未經改進的SACK機制與經過改進的SACK機制的性能表現。本文考慮的是在單跳無線網絡中無線信道易出錯因素對TCP性能的影響以及提出的改進。在下一步的工作中除了要設計到對切換因素的考慮以外，還要對多跳無線網絡中的媒體接入競爭等因素進行考慮。

本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文。