本文參考：https://blog.csdn.net/qq_36267931/article/details/105315739
AODV路由協議詳解
本文目錄：
本文是對AODV路由協議的原理描述，作者同時在android平台對AODV路由協議做了代碼實現，有需要的可以自行下載https://download.csdn.net/download/qq_36267931/12589470
移動Ad Hoc網絡概述
“Ad Hoc”一詞起源於拉丁語，可以翻譯為“for this purpose only”，意譯為“特別的，臨時的網絡”。
移動Ad Hoc網絡（Mobile Adhoc Network，MANET）專指用於移動無線設備的Ad Hoc網絡，用於其它用途的Ad Hoc網絡有無線網狀網絡（wireless mesh network，WMN）和無線傳感器網絡（wirelss sensors networks，WSN）等。
移動Ad Hoc網絡中的節點一般是可以通過無線方式與其它設備進行數據接收和轉發的移動設備，比如手機和手提筆記本。每一個節點既是接收數據的主機，也是負責轉發數據的路由器。因為節點的路由器身份，移動Ad Hoc允許在沒有無線訪問接入點（wireless access point）的情況下節點之間的數據雙向傳輸，網絡中的數據可能需要經過節點的多跳傳輸才能到達目的節點。
移動Ad Hoc網絡允許節點動態地進入和離開網絡，網絡拓撲動態的變化所可能造成的路由失效，可以通過修復路由或重新發現新路由等辦法解決。
總結一下，移動Ad Hoc網絡具有以下特點：
(1)自組織，無需無線訪問接入點即可通信，每個節點都充當路由器。
(2)自適應，允許網絡拓撲的動態變化，可以進行路由的重新發現與修正。
(3)易部署，無需部署無線訪問接入點即可實現節點之間的通信。
(4)網絡控制頻繁，由於網絡拓撲可能經常變化，移動Ad Hoc網絡需要大量的網絡控制信息來維護路由。
(5)安全性與可靠性待加強，由於網絡通過無線的方式傳輸，對比有線方式可靠性較差，且容易受到攻擊與竊聽。移動Ad Hoc網絡中節點需要相互信任，因為數據可能會經過中間節點轉發到目的節點，這也需要一定的機制檢驗節點的安全性。
由於移動Ad Hoc網絡的以上特點，傳統的路由協議如RIP（Routing Information Protocol,路由信息協議）和OSPF（Open Shortest Path First，開放式最短路徑優先協議）無法很好的在移動Ad Hoc網絡上運行。目前常見的應用於移動Ad Hoc網絡的路由 Routing)、DSR（Dynamic Source Routing）、AODV（Ad Hoc On-Demand Distance Vector）和ZRP（Zone Routing Protocol）等。本文將會使用AODV路由協議作為移動Ad Hoc網絡的路由協議。
AODV協議概述
AODV路由協議是為Ad Hoc網絡中的節點（移動設備）進行相互數據傳輸而設計的。
它是一個按需路由協議，按需指節點不會存儲網絡中所有節點的路由信息，只有在需要向目的節點傳輸數據時，才會檢查路由表，如果沒有路由，則會向網絡廣播發送路由請求，這是路由發現過程，是為了來獲取到目的節點的路由。
路由請求（RREQ）、路由回復（RREP）、路由錯誤（RERR）和活躍路由檢測（HELLO）是AODV路由協議定義的四種信息類型。
這些信息用UDP進行傳輸，所以可以使用IP協議的地址，比如可以使用節點自身的IP地址作為RREQ信息中的源地址，可以使用255.255.255.255進行全域的廣播。
當源節點要與目的節點通信但雙方還沒有建立連接時，或者連接已經建立但路由過期或者失效，源節點向地址255.255.255.255發送RREQ消息尋求到目的節點的路由，收到RREQ消息的節點如果自身是目的節點，或者路由表中存在到目的節點的合法路由，則產生RREP消息單播到源節點，停止廣播RREQ消息；如果收到RREQ消息的節點不是目的節點和有到目的節點路由的中間節點，則把RREQ消息繼續廣播到除了接收端外的所有接口。
當網絡檢測到鏈路故障，會發送RERR給特定節點，通知其他節點更新路由。HELLO信息是RREP信息的一個特例，通過廣播HELLO信息可以檢測節點與其直連節點之間的連接情況。
一旦源節點與目的節點成功建立連接，並且網絡拓撲結構無變化和無鏈路故障發生，AODV路由協議就停止發揮作用。當源節點需要跟新目的節點進行通信時，重復發送RREQ的過程來發現到新目的節點的路由。
路由循環（routing loops）和計數到無窮（count to infinity）是基於距離向量算法的路由協議都需要解決的問題，AODV路由協議采用遞增的序列號來解決上述問題。RREQ、RREP、RERR信息報文中都含有序列號字段。使用序列號可以讓節點分辨信息報文的新舊情況，方便節點用新的信息報文來更新路由表中由舊信息報文產生的路由信息。
AODV路由協議支持在小規模的網絡中運行，節點數目范圍在數十到數千，而且要求相互通信的節點之間需要完全信任，因為數據在傳輸到目的節點的過程中可能會需要其他中間節點分析數據和轉發。
總的來說，AODV路由協議具有以下的優點：
(1)不需要實時維護路由表，只有需要時才尋求路由和更新路由表。
(2)支持組播，擴展性里良好
(3)中間節點可以代替目的節點回復，減少了路由發現過程的延時，提高了收斂速度
(4)所有節點和信息報文中都有序列號，避免了路由循環和計數到無窮的問題
(5)被國內外廣泛研究，有許多基於AODV路由協議的改進協議
但與此同時也存在一些缺點：
(7)路由發現過程需要廣播報文，對網絡資源消耗較大
(8)安全性問題，網絡中每個節點必須互相信任，到目的節點的消息能被轉發的中間節點明文接收，有一定的安全隱患
AODV協議消息格式
這一節將會介紹AODV路由協議所定義的三種消息–RREQ、RREP、REER的數據格式。HELLO消息為設定了特殊值的RREP消息，會在RREP的介紹中進行描述。最后還會對另外一種特殊的消息RREP-ACK做一個簡要描述。
RREQ消息格式
當節點需要與某個目的節點傳輸數據，但沒有目的節點的合法路由，可以向全網廣播RREQ消息，向網絡尋求到目的節點的路由，並且在約定的時間內等待攜帶有到目的節點路由信息的RREP消息回來，若規定時間內無收到RREP回復，則重發RREQ消息，直到達到最大發送次數。
其他節點根據收到RREQ消息的接口建立從當前節點到源節點的反向路由。表1是RREQ的消息格式介紹，介紹了每個字段的名稱與比特數。表2是對RREQ各個字段的解釋。
RREP消息格式
RREP消息用於單播回復RREQ消息，目的是為了告知發送RREQ消息的源節點到目的節點的路由。通過RREP消息可以建立從收到RREP消息的節點到RREP消息中的目的節點的正向路由，用於以后發送數據到目的節點。表3介紹了RREP的消息格式，給出了每個字段的位置與比特數。表4是對RREP部分字段的解釋。
Hello消息用於活躍節點向所有鄰近節點廣播自身的存在，當一個節點處於正在使用的路由中時，需要定時向鄰近節點廣播Hello消息，若鄰近節點收到Hello消息，則更新路由表中對應節點的生存時間。
Hello消息是一種特殊的RREP消息，其特殊之處在於為某些字段設置了特殊值，描述如表5
RERR消息格式
當鏈路發生故障導致一個或者多個目的節點不可達時，RERR消息就會被發送，設計RERR消息是為了能通知網絡中其他節點哪些目的節點因為故障導致不可訪問，表6是RERR消息的格式，表7是對RERR消息中部分字段的解釋。
RREP-ACK消息格式
RREP-ACK消息格式用於回復標志位A設為1的RREP消息。這經常發生於節點懷疑鏈路不可靠或者只能單向傳播，RREP-ACK意義在於告知發送RREP的節點目的節點已經收到RREP消息，並且暗示了鏈路是雙向傳播和可靠的。
表8是RREP-ACK消息格式的介紹，可以看到RREP-ACK消息中只有兩個字段，較為簡單。表9是對RREP-ACK消息中兩個字段的解釋。
AODV協議過程
路由表和序列號
每一個節點都需要維護自己的路由表，每一個路由表條目字段見表10。
每一個路由表條目負責到一個目的IP地址的路由，為了保證路由的及時更新，路由表需要對目的序列號進行維護，以便過期或受損的路由能及時被發現。
每一個節點的路由表條目中都必須維護到目的節點的序列號，在三種情況下節點會更新路由表中的序列號：
(1)目的IP地址為自己的路由表條目。節點發送RREQ消息（見2.3.2）前，自身序列號加一，以便通知其他節點路由需要重新搜索。另外在發送回復RREQ消息的RREP消息前，把自身序列號更新為舊的序列號和RREQ中目的序列號中兩者的最大值。
(2)節點收到AODV控制消息，即RREQ、RREP和RERR。若控制消息中的序列號比路由表中的大，即控制消息中的路由更新，此時用大的序列號更新路由表序列號；若兩個序列號相等，但路由表中的跳數字段比控制消息中的跳數字段+1要大，即控制消息中的路由更短，此時用控制消息更新路由表中的相關字段，如下一跳，網絡接口。
(3)到目的節點的路徑過期或者損壞。在沒有收到下一節點回復的RREP-ACK或者鏈路層通知發生鏈路損壞時，需要把所有受鏈路影響不可達的路由表條目中的目的序列號都加一，並設置標志位不合法，這樣可以避免后續該節點重新使用損壞的鏈路。
發送RREQ消息
源節點發送RREQ消息是為了向網絡尋求到目的節點的路由。發送RREQ消息的過程見圖 1。
圖1中可以看到，發送RREQ消息的起因是源節點無法找到到目的節點的合法路由，若存在到目的節點的合法路由，則整個過程結束。無合法路由時，源節點開啟定時器，構建好RREQ消息后，向IP地址255.255.255.255發送RREQ消息，在發送RREQ消息后，在規定等待時間NET_TRAVERSAL_TIME毫秒內等待相關節點回復RREP消息，如果及時收到回復，則過程結束，如果超時仍未收到回復，則采用二進制指數退避的方法更新等待時間，重新開啟定時器計時和發送RREQ消息，直到發送次數超過RREQ_RETRIES或者收到RREP回復，則結束，數據會被丟棄，並通知上層協議無法建立到目的節點的路由。
RREQ消息的構建過程具體如下：RREQ消息中的目的IP地址字段為目的節點IP地址，如果源節點路由表中有目的節點的序列號（但已過期）,則填進序列號字段，如果沒有，則消息中的U標志位設為1。每個節點維護自己的唯一的RREQ ID，每次發送RREQ消息，則給RREQ ID加一，然后再填入RREQ中的字段。跳數字段設為0。
二進制指數退避方法設置等待時間的過程如下，第一次等待時間為NET_TRAVERSAL_TIME毫秒，第二次為NET_TRAVERSAL_TIME2毫秒，第三次為NET_TRAVERSAL_TIME2*2毫秒，每一次的等待時間都是上一次的兩倍，這是為了避免網絡堵塞。
RREQ消息使用廣播發送，所以可能會造成網絡中存在大量的RREQ消息。為了控制RREQ消息的傳輸范圍，我們可以修改IP頭部中的TTL字段，避免每一次RREQ消息都被網絡中所有節點接收。舉個例子，一開始TTL設置為1，則RREQ消息只能發送到源節點的鄰近節點，如果目的節點不在這些鄰近節點中，則再次發送RREQ消息，此時TTL設置為2，則收到RREQ消息的節點就會更多，當最終源節點收到RREP回復時，可能有的節點還沒有收到過源節點發送的RREQ消息，這樣就有效的避免了大量的RREQ消息在網絡中傳播。
處理和轉發RREQ消息
圖2 是處理和轉發RREQ消息的過程。當節點收到RREQ消息，它會判斷在過去的PATH_DISCOVERY_TIME內是否有收到具有相同源IP地址和RREQ ID的RREQ消息，如果有，則丟棄新收到的RREQ消息，過程結束。這個判斷的原因是節點可能從不同的鄰接節點處收到相同的RREQ消息（因為RREQ消息為廣播轉發）,而收到的第一個RREQ消息暗示着一條從源節點到該節點的最短路徑，所以保留第一條RREQ消息，而后面相同的RREQ消息則丟棄，避免重復處理。
下面討論RREQ消息是第一次收到的情況。
首先，搜索是否存在到源IP地址的反向路由，如果沒有則建立反向路由。反向路由即當前節點到源IP地址所在的節點的路由，具體來說是當前節點知道通過哪個接口把數據轉發到源節點。反向路由的建立過程和更新過程具體如下：
(1)RREQ中的源節點序列號跟路由表中目的IP是源節點的表項的序列號進行比較，路由表中個更新為兩者最大值
(2)路由表對應表項合法目的序列號標志位設為1
(3)路由表對應表項中的下一跳字段設為收到RREQ消息的上一個節點的IP地址，這個地址可以在IP頭部獲取到，一般跟RREQ消息中的源IP地址不同
(4)路由表對應表項中的跳數字段從RREQ中復制
更新或創建反向路由后，判斷自身是否為目的節點或者有到目的節點的路由，如果是目的節點，則向源節點發送RREP消息，過程結束；如果有到目的節點的路由，則除了向源節點發送RREP消息外，可能還需要向目的節點發送免費RREP消息，具體過程見2.3.4 。
如果節點不是目的節點和沒有到目的節點的路由，而且IP頭部中的TTL大於1，節點就把IP頭部TTL減一，RREQ中的跳數加一，最后把RREQ消息廣播到255.255.255.255地址，過程結束，若TTL等於1，則無需廣播轉發，直接丟棄RREQ消息。
產生RREP消息過程
節點在兩種情況下會產生RREP。
第一種情況節點是RREQ指向的目的節點，如果自身維護的序列號加一后跟RREQ中的目的序列號相等，則加一，然后新的值復制進RREP消息中的目的序列號字段，並把跳數字段設為0.，最后把RREP通過反向路由單播發送消息回發送RREQ的源節點。
第二種情況是RREQ消息中D標志位(Destination Only)為0，節點為中間節點，擁有到目的節點的路由，且路由活躍不過期，具體來說就是路由表中對應目的序列號大於等於RREQ中的序列號。節點把路由表中目的節點相關表項的目的序列號填進RREP的目的序列號字段中，並通過RREQ消息所在的IP頭部更新到發送RREQ消息的源節點的路由，進而建立反向路由。RREP中的Hop Count字段設置為中間節點路由表中到目的節點的Hop Count字段，RREP中的lifetime字段設置為路由表中到目的節點的表項中的expire time減去當前時間，即該RREP在路由表表項過期后也同時過期，上述更新完RREP消息后，即可單播到發送RREQ消息的源節點。
如果RREQ中的G標志位（免費路由標志）設為1，在發送RREP給源節點之后，還需要發送一個免費RREP（gratuitous RREP）到目的節點，免費RREP也是RREP消息，部分字段設置如下：
(1)跳數字段設置為中間節點到源節點的跳數
(2)目的IP地址字段設置為發送RREQ的源節點的IP地址
(3)源IP地址字段設置為RREQ中的目的IP地址字段
(4)生存時間字段設置為中間節點路由表中維護的到發送RREQ源節點的生存時間
設置完成后免費RREP會根據路由表選擇到目的節點的下一跳發送到目的節點。
發送免費RREP消息的目的在於假設目的節點發送了一個RREQ到源節點，然后這個免費RREP就是中間節點代替源節點來回復這一不存在的RREQ消息，這樣目的節點就可以建立到源節點的反向路由。如果不發送免費RREP消息，目的節點可能不知道RREQ消息的存在，也無法建立到源節點的路由，而只有中間節點具有到源節點的路由，使得后續目的節點與源節點的雙向傳輸無法進行。
接收和轉發RREP消息過程
圖3是接收和轉發RREP消息的過程。當一個節點收到RREP消息，它根據RREP中的目的IP地址字段判斷自己是否為RREP消息目的節點（即發送RREQ的源節點），如果是RREP目的節點，則根據RREP的進入接口更新路由，建立從RREQ源節點到RREQ目的節點的正向路由，用於以后從源節點到RREQ目的節點的數據傳輸。如果節點不是RREP消息目的節點，則判斷是否存在到RREQ目的節點的正向路由，如果不存在，則創建一個無序列號的到RREQ目的節點的路由，如果有，跟存在的正向路由做比較，及時調整和更新正向路由。以下幾種情況所存正向路由會被更新：
(1)路由表中對應表項的序列號標記為非法
(2)RREP中的目的序列號比路由表中對應選項的合法的目的序列號要大
(3)兩個序列號相等，但路由表中序列號標記為不活躍
(4)兩個序列號相等，但RREP中的跳數表項加一小於路由表中對應表項的跳數
到RREQ目的節點的路由表表項被創建或者更新后，該表項會被標記為活躍路由，目的序列號設為合法，下一跳設定為收到RREP消息的IP頭部的IP地址，跳數設置為RREP中的跳數加一，過期時間設置為當前時間加上RREP消息中的生存時間字段，最后把序列號改為RREP消息中的目的序列號，隨后RREP消息會根據之前已經建立好的反向路由發送到下一個節點，至此整個接收和轉發RREP的過程結束。
正向路由更新后，后續RREQ源節點可以通過每一個中間節點的正向路由與目的節點進行數據傳輸。
鏈路中可能存在一些單向鏈路，RREQ廣播時無法發現，但RREP單播回復RREQ時，可能會因為單向鏈路導致傳輸失敗，此時若不處理單向鏈路，源節點因為收不到RREP回復會多次發送RREQ，直到超時。所以如果鏈路中可能存在單向鏈路，下一跳節點可以采用發送RREP-ACK或者鏈路層確認機制來通知上一個節點鏈路失敗，然后上一個節點會把下一跳節點拉入黑名單，在BLACKLIST_TIMEOUT時間段內忽視所有從下一跳發送來的RREQ消息，此時源節點因為收不到RREP消息，選擇再次發送RREQ，因為是廣播發送，所以上一個節點可能會從其他節點收到該RREQ消息，雖然路由距離可能比已經在黑名單的節點要長，但可以作為單向鏈路的一個替代。
當需要下一跳節點發送RREP-ACK消息，RREP消息中A標志位必須設為1。
Hello消息發送與處理過程
當節點處於一條活躍路由中時，需要通過向鄰近的節點廣播Hello消息來通知鄰近節點自身的存活。Hello消息發送過程見圖4。首先節點判斷自己是否處於活躍路由中，如果是，則開啟定時器，每過HELLO_INTERVAL毫秒，節點檢查自己過去HELLO_INTERVAL毫秒內是否送過廣播（Hello消息或者RREQ），如果沒有，則廣播Hello消息。當節點判斷自己不再處於活躍路由中，則可以結束Hello消息發送過程。
節點可以通過監聽在一段時間內是否收到鄰近節點的消息來判斷與鄰近節點的連接是否正常。Hello消息處理過程見圖5。如果在過去的DELETE_PERIOD時間內，已經從鄰近節點收到Hello消息，然后接下來的ALLOWED_HELLO_LOSS * HELLO_INTERVAL內都沒有從鄰近節點收到任何消息，那么節點就會假設與該鄰近節點的鏈路已斷開，此時應該發送RERR消息，當節點收到Hello消息，且存在反向路由，則更新到發送Hello消息節點的路由的生存時間，並且用Hello中的目的序列號更新路由表中對應序列號，若不存在反向路由，則丟棄Hello消息。
發送和處理RERR消息
發送和處理RERR消息統稱為路由修復過程，路由修復過程發生於檢測到鏈路故障或者收到無法處理的數據時。
RERR消息可以廣播發送也可以單播發送，一個節點一秒不能發送超過RERR_RATELIMIT 條RERR。
(1)生成RERR消息
RERR消息可以廣播發送也可以單播發送，一個節點一秒不能發送超過RERR_RATELIMIT 條RERR。
節點在三種情況下會發送RERR消息，第一種是路由表中存在的活躍路由的下一跳節點發生鏈路故障；第二種是收到一個數據包指向某個目的節點，但路由表中無在修復的或活躍的指向目的節點的路由；第三種是從鄰近節點收到RERR消息。
下面分情況討論RERR消息的產生。
第一種情況中，把路由表中所有以故障節點為下一跳的條目中的目的IP地址放入RERR消息中的不可達目的IP地址字段或者額外的不可達目的IP地址字段，然后把路由表中對應目的序列號+1，並填入RERR消息中。
第二種情況中，只有一個目的節點不可達，把它的目的IP地址復制入RERR消息中，路由表中序列號+1后也放入RERR消息中。
第三種情況中，假設節點從鄰近節點A收到RERR消息，則路由表中所有下一跳為A的條目中所有的目的IP地址都復制到新的RERR消息中，並且把路由表中對應目的序列號+1，並填入新RERR消息中。
(2)更新自身路由表
在發送RERR消息前需要更新路由表，除了對應目的序列號+1，還有以下操作，先把把指向RERR中目的節點的路由入口設為無效，隨后路由表生存時間字段設置為當前時間+DELETE_PERIOD，最后在超過生存時間后才執行刪除路由入口的操作。
(3)決定轉發節點
在生成了RERR消息和更新自身路由表后，節點需要決定把RERR消息轉發到哪些鄰近節點。路由表中因為RERR消息導致無效的路由條目中，有一個上游節點列表（list of precursors），里面存放着使用這條路由的上游節點，其中有的是鄰近節點，而這些節點就是RERR消息需要轉發到的節點。
(4)路由修復過程
當鏈路發生故障，所有直接使用該鏈路的鄰接點都產生一個RERR消息，然后這些節點會將RERR消息轉發到其他節點，其他節點也一樣處理，直到所有受影響的節點都收到RERR消息。無論是源節點還是中間節點，當鏈路故障后需要再次發送數據到受影響的目的節點，則需要再次發送RREQ消息來發現到目的節點的路由，在重新建立路由之前的數據都需要緩存起來。
小結
主要對AODV路由協議進行了詳細的介紹，在對AODV協議做了一個總體概述后，詳細的介紹了AODV的控制消息RREQ、RREP、RERR、RREP-ACK和Hello的消息格式和用途，並對部分消息字段做出了解釋，接着分小結介紹了每一種控制消息的發送和處理過程。