俗話說得好，在家千日好，出門一日難。網絡包一旦出了網關，就像玄奘西行一樣踏上了江湖漂泊的路。今天來給大家普及一下路由協議。
出了網關之後，只有一條路可以走。但是，網絡世界複雜得多，一旦出了網關，會面臨著很多路由器，有很多條道路可以選。如何選擇一個更快速的道路求取真經呢？這裡面還有很多門道可以講。
如何配置路由？
路由器就是一臺網絡設備，它有多張網卡。當一個入口的網絡包送到路由器時，它會根據一個本地的轉發信息庫，來決定如何正確地轉發流量。這個轉發信息庫通常被稱為 路由表。
一張路由表中會有多條路由規則。每一條規則至少包含這三項信息。
目的網絡：這個包想去哪兒？
出口設備：將包從哪個口扔出去？
下一跳網關：下一個路由器的地址。
通過 route命令和 ip route命令都可以進行查詢或者配置。
例如，我們設置 ip route add 10.176.48.0/20 via 10.173.32.1 dev eth0，就說明要去 10.176.48.0/20這個目標網絡，要從 eth0端口出去，經過 10.173.32.1。
上一節的例子中，網關上的路由策略就是按照這三項配置信息進行配置的。這種配置方式的一個核心思想是：根據目的 IP地址來配置路由。
如何配置策略路由？
當然，在真實的複雜的網絡環境中，除了可以根據目的 ip地址配置路由外，還可以根據多個參數來配置路由，這就稱為 策略路由。
可以配置多個路由表，可以根據源 IP地址、入口設備、TOS等選擇路由表，然後在路由表中查找路由。這樣可以使得來自不同來源的包走不同的路由。
例如，我們設置：
<code>ip rule add from 192.168.1.0/24 table 10 ip rule add from 192.168.2.0/24 table 20/<code>
表示從 192.168.1.10/24這個網段來的，使用 table 10中的路由表，而從 192.168.2.0/24網段來的，使用 table20的路由表。
在一條路由規則中，也可以走多條路徑。例如，在下面的路由規則中：
<code>ip route add default scope global nexthop via 100.100.100.1 weight 1 nexthop via 200.200.200.1 weight 2/<code>
下一跳有兩個地方，分別是 100.100.100.1和 200.200.200.1，權重分別為 1比 2。
在什麼情況下會用到如此複雜的配置呢？我來舉一個現實中的例子。
我是房東，家裡從運營商那兒拉了兩根網線。這兩根網線分別屬於兩個運行商。一個帶寬大一些，一個帶寬小一些。這個時候，我就不能買普通的家用路由器了，得買個高級點的，可以接兩個外網的。
家裡的網絡呢，就是普通的家用網段 192.168.1.x/24。家裡有兩個租戶，分別把線連到路由器上。IP地址為 192.168.1.101/24和 192.168.1.102/24，網關都是 192.168.1.1/24，網關在路由器上。
就像上一節說的一樣，家裡的網段是私有網段，出去的包需要 NAT成公網的 IP地址，因而路由器是一個 NAT路由器。
兩個運營商都要為這個網關配置一個公網的 IP地址。如果你去查看你們家路由器裡的網段，基本就是我圖中畫的樣子。
運行商裡面也有一個 IP地址，在運營商網絡裡面的網關。不同的運營商方法不一樣，有的是 /32的，也即一個一對一連接。
例如，運營商 1給路由器分配的地址是 183.134.189.34/32，而運營商網絡裡面的網關是 183.134.188.1/32。有的是 /30的，也就是分了一個特別小的網段。運營商 2給路由器分配的地址是 60.190.27.190/30，運營商網絡裡面的網關是 60.190.27.189/30。
根據這個網絡拓撲圖，可以將路由配置成這樣：
<code>$ ip route list table main 60.190.27.189/30 dev eth3 proto kernel scope link src 60.190.27.190 183.134.188.1 dev eth2 proto kernel scope link src 183.134.189.34 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1 127.0.0.0/8 dev lo scope link default via 183.134.188.1 dev eth2/<code>
當路由這樣配置的時候，就告訴這個路由器如下的規則：
如果去運營商二，就走 eth3；
如果去運營商一呢，就走 eth2；
如果訪問內網，就走 eth1；
如果所有的規則都匹配不上，默認走運營商一，也即走快的網絡。
但是問題來了，租戶 A不想多付錢，他說我就上上網頁，從不看電影，憑什麼收我同樣貴的網費啊？沒關係，咱有技術可以解決。
下面我添加一個 Table，名字叫 chao。
<code># echo 200 chao >> /etc/iproute2/rt_tables/<code>
添加一條規則：
<code># ip rule add from 192.168.1.101 table chao # ip rule ls 0: from all lookup local 32765: from 10.0.0.10 lookup chao 32766: from all lookup main 32767: from all lookup default/<code>
設定規則為：從 192.168.1.101來的包都查看個 chao這個新的路由表。
在 chao路由表中添加規則：
<code># ip route add default via 60.190.27.189 dev eth3 table chao # ip route flush cache/<code>
默認的路由走慢的，誰讓你不付錢。
上面說的都是靜態的路由，一般來說網絡環境簡單的時候，在自己的可控範圍之內，自己搗鼓還是可以的。但是有時候網絡環境複雜並且多變，如果總是用靜態路由，一旦網絡結構發生變化，讓網絡管理員手工修改路由太複雜了，因而需要動態路由算法。
動態路由算法
使用動態路由路由器，可以根據路由協議算法生成動態路由表，隨網絡運行狀況的變化而變化。那路由算法是什麼樣的呢？
我們可以想象唐僧西天取經，需要解決兩大問題，一個是在每個國家如何找到正確的路，去換通關文牒、吃飯、休息；一個是在國家之間，野外行走的時候，如何找到正確的路、水源的問題。
無論是一個國家內部，還是國家之間，我們都可以將複雜的路徑，抽象為一種叫作圖的數據結構。至於唐僧西行取經，肯定想走得路越少越好，道路越短越好，因而這就轉化成為如何在途中找到最短路徑的問題。
咱們在大學裡面學習計算機網絡與數據結構的時候，知道求最短路徑常用的有兩種方法，一種是 Bellman-Ford算法，一種是 Dijkstra算法。在計算機網絡中基本也是用這兩種方法計算的。
距離矢量路由算法
第一大類的算法稱為距離矢量路由（distance vector routing）。它是基於 Bellman-Ford算法的。
這種算法的基本思路是，每個路由器都保存一個路由表，包含多行，每行對應網絡中的一個路由器，每一行包含兩部分信息，一個是要到目標路由器，從那條線出去，另一個是到目標路由器的距離。
由此可以看出，每個路由器都是知道全局信息的。那這個信息如何更新呢？每個路由器都知道自己和鄰居之間的距離，每過幾秒，每個路由器都將自己所知的到達所有的路由器的距離告知鄰居，每個路由器也能從鄰居那裡得到相似的信息。
每個路由器根據新收集的信息，計算和其他路由器的距離，比如自己的一個鄰居距離目標路由器的距離是 M，而自己距離鄰居是 x，則自己距離目標路由器是 x+M。
這個算法比較簡單，但是還是有問題。
第一個問題就是好消息傳得快，壞消息傳得慢。如果有個路由器加入了這個網絡，它的鄰居就能很快發現它，然後將消息廣播出去。要不了多久，整個網絡就都知道了。但是一旦一個路由器掛了，掛的消息是沒有廣播的。當每個路由器發現原來的道路到不了這個路由器的時候，感覺不到它已經掛了，而是試圖通過其他的路徑訪問，直到試過了所有的路徑，才發現這個路由器是真的掛了。
我再舉個例子。
原來的網絡包括兩個節點，B和 C。A加入了網絡，它的鄰居 B很快就發現 A啟動起來了。於是它將自己和 A的距離設為 1，同樣 C也發現 A起來了，將自己和 A的距離設置為 2。但是如果 A掛掉，情況就不妙了。B本來和 A是鄰居，發現連不上 A了，但是 C還是能夠連上，只不過距離遠了點，是 2，於是將自己的距離設置為 3。殊不知 C的距離 2其實是基於原來自己的距離為 1計算出來的。C發現自己也連不上 A，並且發現 B設置為 3，於是自己改成距離 4。依次類推，數越來越大，直到超過一個閾值，我們才能判定 A真的掛了。
這個道理有點像有人走丟了。當你突然發現找不到這個人了。於是你去學校問，是不是在他姨家呀？找到他姨家，他姨說，是不是在他舅舅家呀？他舅舅說，是不是在他姥姥家呀？他姥姥說，是不是在學校呀？總歸要問一圈，或者是超過一定的時間，大家才會認為這個人的確走丟了。如果這個人其實只是去見了一個誰都不認識的網友去了，當這個人回來的時候，只要他隨便見到其中的一個親戚，這個親戚就會拉著他到他的家長那裡，說你趕緊回家，你媽都找你一天了。
這種算法的第二個問題是，每次發送的時候，要發送整個全局路由表 。網絡大了，誰也受不了，所以最早的路由協議 RIP就是這個算法。它適用於小型網絡（小於 15跳）。當網絡規模都小的時候，沒有問題。現在一個數據中心內部路由器數目就很多，因而不適用了。
所以上面的兩個問題，限制了距離矢量路由的網絡規模。
鏈路狀態路由算法
第二大類算法是鏈路狀態路由（link state routing），基於 Dijkstra算法。
這種算法的基本思路是：當一個路由器啟動的時候，首先是發現鄰居，向鄰居 say hello，鄰居都回復。然後計算和鄰居的距離，發送一個 echo，要求馬上返回，除以二就是距離。然後將自己和鄰居之間的鏈路狀態包廣播出去，發送到整個網絡的每個路由器。這樣每個路由器都能夠收到它和鄰居之間的關係的信息。因而，每個路由器都能在自己本地構建一個完整的圖，然後針對這個圖使用 Dijkstra算法，找到兩點之間的最短路徑。
不像距離距離矢量路由協議那樣，更新時發送整個路由表。鏈路狀態路由協議只廣播更新的或改變的網絡拓撲，這使得更新信息更小，節省了帶寬和 CPU利用率。而且一旦一個路由器掛了，它的鄰居都會廣播這個消息，可以使得壞消息迅速收斂。
動態路由協議
基於鏈路狀態路由算法的 OSPF
OSPF（Open Shortest Path First，開放式最短路徑優先）就是這樣一個基於鏈路狀態路由協議，廣泛應用在數據中心中的協議。由於主要用在數據中心內部，用於路由決策，因而稱為內部網關協議（Interior Gateway Protocol，簡稱 IGP）。
內部網關協議的重點就是找到最短的路徑。在一個組織內部，路徑最短往往最優。當然有時候 OSPF可以發現多個最短的路徑，可以在這多個路徑中進行負載均衡，這常常被稱為等價路由。
這一點非常重要。有了等價路由，到一個地方去可以有相同的兩個路線，可以分攤流量，還可以當一條路不通的時候，走另外一條路。這個在後面我們講數據中心的網絡的時候，一般應用的接入層會有負載均衡 LVS。它可以和 OSPF一起，實現高吞吐量的接入層設計。
有了內網的路由協議，在一個國家內，唐僧可以想怎麼走怎麼走了，兩條路選一條也行。
基於距離矢量路由算法的 BGP
但是外網的路由協議，也即國家之間的，又有所不同。我們稱為外網路由協議（Border Gateway Protocol，簡稱BGP）。
在一個國家內部，有路當然選近的走。但是國家之間，不光遠近的問題，還有政策的問題。例如，唐僧去西天取經，有的路近。但是路過的國家看不慣僧人，見了僧人就抓。例如滅法國，連光頭都要抓。這樣的情況即便路近，也最好繞遠點走。
對於網絡包同樣，每個數據中心都設置自己的 Policy。例如，哪些外部的 IP可以讓內部知曉，哪些內部的 IP可以讓外部知曉，哪些可以通過，哪些不能通過。這就好比，雖然從我家裡到目的地最近，但是不能誰都能從我家走啊！
在網絡世界，這一個個國家成為自治系統 AS（Autonomous System）。自治系統分幾種類型。
Stub AS：對外只有一個連接。這類 AS不會傳輸其他 AS的包。例如，個人或者小公司的網絡。
Multihomed AS：可能有多個連接連到其他的 AS，但是大多拒絕幫其他的 AS傳輸包。例如一些大公司的網絡。
Transit AS：有多個連接連到其他的 AS，並且可以幫助其他的 AS傳輸包。例如主幹網。
每個自治系統都有邊界路由器，通過它和外面的世界建立聯繫。
BGP又分為兩類，eBGP和 iBGP。自治系統間，邊界路由器之間使用 eBGP廣播路由。內部網絡也需要訪問其他的自治系統。邊界路由器如何將 BGP學習到的路由導入到內部網絡呢？就是通過運行 iBGP，使得內部的路由器能夠找到到達外網目的地的最好的邊界路由器。
BGP協議使用的算法是路徑矢量路由協議（path-vector protocol）。它是距離矢量路由協議的升級版。
前面說了距離矢量路由協議的缺點。其中一個是收斂慢。在 BGP裡面，除了下一跳 hop之外，還包括了自治系統 AS的路徑，從而可以避免壞消息傳的慢的問題，也即上面所描述的，B知道 C原來能夠到達 A，是因為通過自己，一旦自己都到達不了 A了，就不用假設 C還能到達 A了。
另外，在路徑中將一個自治系統看成一個整體，不區分自治系統內部的路由器，這樣自治系統的數目是非常有限的。就像大家都能記住出去玩，從中國出發先到韓國然後到日本，只要不計算細到具體哪一站，就算是發送全局信息，也是沒有問題的。
小 結
好了，這一節就到這裡了，我來做個總結：
路由分靜態路由和動態路由，靜態路由可以配置複雜的策略路由，控制轉發策略；
動態路由主流算法兩種，距離矢量算法和鏈路狀態算法。基於兩種算法產生兩種協議，BGP協議和 OSPF協議。
最後，再給你留兩個思考題：
路由協議要在路由器之間交換信息，這些信息的交換還需要走路由嗎？不是死鎖了嗎？
路由器之間信息的交換使用什麼協議呢？報文格式是什麼樣呢？
如果你對我的文章感興趣，歡迎訂閱我的專欄，來與我交流網絡協議的相關問題
閱讀更多 InfoQ 的文章
