作者：__ay
參考書目是 《802.11 無線網絡權威指南 第二版影印版》 中文版翻譯的太惡心了。
在無線網絡通信中，MAC層的工作細節和有線網絡差的實在是太大了……
這里僅僅談論無線MAC層的通信機制，MAC以上的有線無線都一樣~~
1. 神馬是RTS/CTS？？
那么說起無線網路，我們其實最最首先考慮通信的可靠性問題，要知道有線網絡的傳輸環境比無線網絡封閉多了，但是其可靠性也比無線網絡高多了，最最起碼有線網絡不要考慮可能的微波，手機信號等因素的干擾。正是由于考慮到其它電子設備比如手機，微波爐等有發射微波功能電子產品，我們空氣中的無線信號受到的干擾遠遠比有線信號的要強的多。所以在無線通信時，要考慮到可能的干擾性，所以需要對每一個發送出去的幀進行確認。過程就如下圖所示。
但是，出現一個問題一個棘手的問題。就是說如何處理所謂的隱藏節點的問題，那啥是隱藏節點咧？
在上一個圖中我們可以yy一種特殊情況： 2號機可以接收到1號和3號的信號，但是1號機無法發現3號機。
那么在1，3號同時發送幀給2號機的時候，2號機沒法回應這2個幀，因為幀沖突了。在無線網絡里，所有主機都公用一個空氣媒介，也就是說在一個主機發送數據的時候其它主機必須保持沉默。那么上述這種情況顯然違背了這個規則，造成的結果就是2號機根本沒法收到數據。
所以這里就又引出一個以太網類似的另一個問題：沖突避免
那么對于這種情況我們則需要有個協調機制，協調誰先發，誰后發
這就引出了2個功能幀
RTS: Request to Send
CTS: Clear to Send
在1號機傳送數據之前，首先發送一個RTS幀給2號機，那么所有接收到RST幀的機器則會保持沉默
但是3號機收不到丫~~
所以2號機會回應1號機一個CTS幀，3號機收到CTS，則保持沉默（這樣所以可能干擾到1/2號機通信的主機都沉默了），然后整個無線網絡媒介就可以被空出來給1號機用來傳送數據幀給2號機了
這就是RTS/CTS機制 發送過程大致如下
但是對于這個機制的使用會消耗額外的計算資源，那么有一個折中的做法就是設置一個RTS的閥值，當網絡數據包長度超過這個閥值的時候就啟用RTS/CTS機制，否則保持自由發送模式。（我發現老外很喜歡中庸之道~）。當然這個機制可能有些人說無法保證沒有沖突，應為可能1,3主機可能同時發送2個RTS包給2號機。這里會有個沖突回避問題，原理和以太網類似，都是遇到發送沖突，那么就隨機選擇回避。這個就是下面要討論的一個問題了。
2 WLAN的沖突回避
無線網絡通信另一個主要的問題就是協調問題，就是如何協調區域內的各個主機進行通信，當然RTS/CTS是一種解決機制，但是這只是個小部分，到底如何讓無線區域內的主機“流暢”的通信，就得涉及到一系列沖突回避策略等問題上了。
首先說一下協調模式：
在以太網中用的是CSMA/DA的方法，所有主機自由發送報文，若沖突了退避一段時間在發就是了。
而在無線網中則有3種協調模式
DCF (Distribution Coordination Function)
區域內的主機傳輸，但是跟以太網的沖突避免一樣，在檢測到沖突后則進行退避。不過需要提的是有時候DCF會采用RTS/CTS機制來減少沖突。這個機制自由性比較強。
PCF (Point Coordination Function)
這個機制依賴于ACCESS POINTS，既需要通過一臺指定的無線主機來協調通信。所以這個機制可以為主機提供無競爭服務，因為AP可以指定誰先發數據誰后發數據，沒有傳輸沖突，真和諧，就是開銷要高一些。
HCF (Hybird Coordination Function)
這個機制是以上兩個機制的折中，一方面提供一個盡力而為的服務，但是又對于通信的步驟要求又不如PCF那么嚴格。這個模式通過維護多個服務隊列，然后再決定為怎樣的主機提供怎樣的服務。
我們以后的討論情景是基于DCF下的。特別在DCF過程中，他的退避算法和以太網的算法很相似。也是隨即退避，隨著發送失敗的次數增加，退避時間的選擇范圍會進行指數增長。當檢測到信道空閑后，要發送數據的主機需要等待DIFS時間間隔后然后進入競爭狀態下，所謂的競爭狀態就是說所有主機會在自己的競爭窗口中隨即選擇一個等待時間，這個等待時間過后則開始發送數據。
首先來說幾個定義：
1.時隙(原文是slot，我們暫且稱之為時隙吧)：這個是退避時間的最小單位，在以太網中退避時間單位是毫秒還是微秒來著我忘了，這個時隙就是無線網絡中的時間單位，這個時隙是根據情況而定的。在高速網絡(網卡處理性能越好)中時隙會越短。時隙可能是2微秒，也可能是4毫秒，反正是在不同網絡中時隙可能不同，這個可以看成退避時間的最小單位。
2.競爭窗口，就是在發送失敗后選擇退避時間的集合。比如說初始的窗口大小是0-31 slots。這就表明在主機需要在0-31 slots里面隨即抽取出一個值來進行等待。打個比方我們的slot設為2微秒，那么在上一次傳輸數據完畢后經過DIFS（下面會介紹到）間隙，我們在自己的競爭窗口(范圍：0-31 slots)隨即選取到了24這個值，那么我們需要等待的時間就是24 slots == 24*2 微秒 == 48 微秒。當然競爭窗口的大小會隨著發送失敗的次數而增加，因為發送失敗次數越多表示網絡負載越大，那么所有無線網主機在檢測到自己發送失敗了以后都要將自己的競爭窗口乘以2，然后再繼續等待發送。不過當失敗次數達到閥值的時候競爭窗口大小就不會增加了。當發送成功以后競爭窗口就會恢復初始值。
有圖有真相，貼個圖繼續分析：
看到初始窗口范圍是0-31，隨著重傳次數增加，窗口也是呈指數增長。當增長到閥值1024大小時就停止增長了，接下來如果還是重傳失敗的話就一直隨機在0-1023 slots中挑出一個值來進行等待。
3 時序
再者就是時序問題了，簡單來說就是如何規定無線主機什么時候該做什么。那首先先得說一下無線網絡監聽機制，這個和有線網絡里面不太一樣。有線網絡里面若物理信道有數據傳輸的話是肯定可以監聽的到的，但無線網絡里面卻不一定。就拿之前那個隱藏節點的例子來說，3號機可能無法通過監聽物理信道來得知一二號機正在傳輸。所以無線網絡通信中，要確定信道是否被占用，引入了虛擬載波監聽。
注：載波監聽和虛擬載波監聽是同時在運行的，只有當這兩個模塊顯示空閑時才表示信道空閑，若其中的一個模塊顯示信道繁忙都表示信道正在被占用。
關于虛擬載波監聽的原理，那么得先介紹一個叫Network Allocation Vector（NAV）這個變量。這個變量會附在無線數據包內的。準備發送數據的主機通過NAV這個值通知其它沉默的主機信道要被占用多長時間來用于傳輸數據。每個主機都會維護一個自己的NAV值，然而這個NAV值每隔1微秒會遞減1，直到遞減為0的時候就表示虛擬載波監聽的信道空閑。
說白了NAV就是個定時器，但是是個動態定時器，當主機沉默時會不斷的收到來自無線網絡中的含有NAV值的數據包，只有當數據包中的NAV值大于自己的NAV值時，主機才會更新自己的NAV值。
比如說 1號主機的NAV值是100，那么收到一個A包，它的NAV值是99，那么1號主機的NAV值就還是100不變。過了10微秒，1號主機又收到一個B包，它的NAV值還是99，但是這個時候1號主機的NAV值是90了(每隔1微秒會遞減1的嘛)，所以1號主機會把自己的NAV值更新為99。直到這個NAV值遞減到0才說明信道可用。
接下來又回到時序問題上，在每幀發送結束后（這里指的是所有主機，特別是沉默的主機，當沉默主機檢測到NAV值是0就表示傳送完畢了）都會有個等待間隙。但這等待間隙類型分4種：
SIFS (short interframe space)
該類型時間間隔最短，這個類型的時間間隔主要用于高優先級別的操作。要發送RTS,CTS,ACK或者是被分片的幀(假設一個幀被分成了3塊，第一部分傳送完畢，等待SIFS間隔繼續發送第二塊，而其他要發送完整幀的主機則需要等待DIFS間隔，這樣就能夠確保這被分片的幀能夠一次性發送完畢，也就是被分片的幀享受更高的傳輸優先級)的時候。
PIFS (PCF interframe space)
PIFS時間間隔其次，在傳輸PCF相關的管理幀的時候采用這類型的時間間隔。這種情況就是一般我們用路由器，路由器的管理幀只要等待PIFS就可以發送了。
DIFS (DCF interframe space)
DIFS時間間隔最長，所有主機要傳輸數據的話必須在上一次傳輸完畢后統一等待DIFS時隙后才能嘗試發送。當然，這里說的是嘗試發送，因為后面還得進入一個競爭間隔。
EIFS (extended interframe space)
這類幀的時間間隔不確定，在傳輸錯誤的時候才會用到。
所以除去EIFS，他們仨的時間關系就是 SIFS<PIFS<DIFS，SIFS等待時間最短，DIFS最長，PIFS居中
。可以發現，時間越短，發送成功率越高，這也就說明優先級越高。顯而易見，RTS/CTS幀，也叫控制幀的發送間隔都是SIFS，因為這類幀的優先級要高于平常的數據傳輸。所以當你要發送RTS之類的幀時就采用SIFS時間間隔，這樣就能夠保證RTS幀能夠更快比使用其它時間間隔的幀發送出去，其它幀接收到RTS報文后就開始保持沉默將不試圖發送幀了。
整個過程串起來就如下圖所示：
先分析上面的那個時間軸，RTS發送出去，收到CTS。然后間隔SIFS就開始發送數據了，這里的幀是分片的，分片的幀需要一次性傳輸完，所以每個幀的等待發送時間是SIFS。里面還可以看到ACK的回復時間也是需要等待SIFS的，因為這幾個類型的幀對保證數據傳輸非常重要，所以享有更高的發送優先級，在這種情況下，其它的無線主機發送數據干擾這次傳輸是不可能的，因為他們需要等待DIFS時間間隔。在他們等待沒完的時候RTS,CTS,ACK，分片幀的傳輸早都開始傳輸了，這些主機接收到數據傳輸信息后只能進入沉默。
那么下面的那個時間軸就更清晰了，這個時間軸其實可以看成是其它沉默無線主機NAV值的情況。
在剛發送第一個RTS幀的時候，其它主機收到了RTS幀中附帶的NAV值，等到0號幀傳送結束后各個主機開始等待DISF時間準備傳輸，但是這個時候發送主機由于在發送分片幀，所以只要等待SIFS時間就發送了，結果是其它主機的DISF時間還沒等待完就收到了1號幀給他們的NAV值，然后再一號幀傳送的這段時間他們又得只能沉默。這個時間軸上面部分表示SENDER通告給其它主機的NAV值的有效期，下面表示Reveiver通告給其它主機的NAV值有效期。
4 無線主機發送過程
綜合上面的所有概念，下面貼個圖來全盤分析下單個無線主機發送數據包的過程
1. 前面的busy段表示主機A監聽到網絡數據繁忙（這里主機A判斷信號方面可能是NAV值沒遞減到0，也可能是物理載波監聽那塊檢測到有數據傳送，還可能是2者兼有）
2. OK,busy段結束后進入等待階段，當然這里要發送數據而且不用RTS/CTS機制的話，那么等待時間應該是DIFS間隔的
3. 進入競爭發送階段，所有主機在自己窗口中隨機選一個時間來等待
4. 假設主機A隨機到的等待時間最短，那么他就開始發送數據了，其它主機發現有數據傳輸了則會進入沉默狀態，等待下一次數據傳輸完畢后進行競爭。
5 重傳
剛才說到了分片，那么連帶重傳一起說了吧
先說說為什么要分片，什么時候分片的問題
在無線網絡通信中，要知道傳輸時受到的干擾是多種多樣的，也就是說無線網絡在MAC層的穩定性是遠遠不如以太網般穩定的。所以在長數據幀傳輸的時候很容易中間被中斷。為了提高穩定性，就把這個幀分片，然后再傳輸，顯然短幀傳輸成功率要高于長幀。這樣設計的目的是為了提高無線MAC層的可靠性。這個就跟你拿IE下一個1G的東西（一次性傳長幀）和拿迅雷下同樣一個1G的東西道理是一樣的，顯然拿迅雷下更穩定些，因為有斷點續傳。那么分片傳輸充其量就是把以前的普通IE下載升級優化成了斷點續傳罷了。
當數據包到指定的分片閥值的時候就對數據包進行分片，同一個幀被分片的部分也會帶有一樣的幀序號，也會有自己的分片編號，也會有個表示為表示這個幀是不是分片幀。這個跟IP分片設計原則是一樣的，這個就不具體說了。
再者就是重傳問題了，神馬時候重傳？
以上篇幅提到過，只有在收到ACK確認后主機才會認為自己發送幀是成功的。同樣，RTS只有在收到CTS后才認為自己的RTS發送成功了。
所以這里涉及到一個問題就是發送失敗如何處理？重傳？對~是重傳，但是一直發送失敗呢？所以對于每個幀都有個重傳計數器（注：競爭窗口大小就是根據這個重傳計數器來決定的），失敗一次就遞增一，但失敗到指定的上限的時候就放棄發送該幀然后向上層協議報告。
然而重傳計數器有2個，分別是長幀重傳計數器和短幀重傳計數器。某幀當長度大于指定閥值的時候，該幀發送失敗則長幀重傳計數器遞增1，反之亦然。這個閥值是可以設定的，重傳上限也可以設定。這么設計是因為長幀會占用更多資源（內存空間，傳輸時間等）以便讓管理員通過調整閥值和各個計數器的重傳上限來優化無線網絡。那么我們來YY一下（純屬YY……我比較沒做過網絡優化這方面的經驗，只是假設下可能的場景~），比如說我希望用來傳輸300字節一下的幀的時間多一些，那么我就設定閥值為300，然后長幀重傳計數器的上限設置低一些，短幀重傳計數器上限設置高一些。
重傳計數器要清零很簡單，有幾種情況
1 RTS幀發送出去若收到CTS幀則清零重傳技術器（當然這個只可能發生在短幀計數器情況下，因為RTS數據幀一般情況下不屬于長幀……當然你要把閥值設成RTS幀大小我也沒話說~）
2 幀數據發送出去，收到ACK確認
3 收到廣播或者多播幀(why？書里面這么寫的，但沒寫為什么，這里的多播和廣播幀是不是值通告NAV值的廣播幀咧？如果是這樣，那么就說得通了。待高手解釋~)
OK，這一篇結束