IP網路能否像公路交通網路一樣,由每個數據包自行決定轉發路徑?
現有IP網路中的節點,根據路由表決定每個報文下一跳,這需要路由協議不斷維護路由表故帶來額外開銷,同時轉發性能也相應受查表性能的制約。能否設計一種機制,讓每個數據包自行決定轉發路徑,發送端根據拓撲結構和節點繁忙程度事先制定好轉發路徑並將信息記錄在報文中,路徑上節點依此進行轉發。
這個話題很有意思,談談看法。
由IP包的發源地來決定IP包所要走的路經,從IP協議被發明就支持,通過IP Option 以 source route 形式存在的,發源地將IP包所經過每一跳的路由器IP寫在source route里,每經過一跳路由器,檢查IP 包里的 source route list 來決定下一跳,選擇完下一跳,將自己的IP抹去,剩下的就是剩餘跳數的IP,然後也是一跳一跳的方式到達目的地。
即使是這樣,source route 也是靜態設置,並且IP option 最長只有40 bytes,都用於source route 也最多支持8個IP跳數,在現代網路普遍10多跳、幾十跳的場景下,幾乎不可用;另外萬一其中一跳出故障了,就會造成通信障礙。
所以現代IP網路普遍採用基於Destination IP 選路原則,即每一跳通過匹配destination IP 和自己的路由表來選擇更靠近destination 的下一跳路由器;依循以上原則,IP包不斷逼近目的地並最終到達目的地。
@八里土人 提到過IP包僅僅是data,它不是攜帶CPU的智能設備,即使IP包里裝載路由信息,也是由源主機通過動態發現:拓撲鏈路狀態、鏈路的可用帶寬、鏈路的time delay、鏈路的packet loss、鏈路的packet jitter 來動態選路,可以通過RSVP 這個帶寬資源保留協議來創建一條虛擬連接,源主機可以手工靜態選擇路經、或者動態地由協議來選擇滿足帶寬需求的路經。路經信息以label的方式嵌入在IP包頭前,途徑的路由器檢查label,然後選擇下一跳,一直到達目的地。
問題來了,目前的路由協議還不支持動態performance 的測量,比如 time delay ,packet loss,packet jitter,以及 available bandwidth 的互相通告,目前可以通過IP SLA (Service Level Agreement)這個工具來完成以上測量,並把這些信息互相共享,然後由每一台參與其中的路由器來進行路由決策,是希望可用帶寬高的鏈路呢?還是希望packet loss rate 低的鏈路?還是希望 packet time delay 最小的鏈路?然後優先出最優路經。
但這種方案目前還是不具有擴展性,每條路經如果都需要測量,那數量級是非常可怕地巨大,網路里幾乎要被這些測量流量所壟斷。目前這種測量一般用於公司多WAN出口上,可以一直通過測量多個WAN出口的性能指標,來決定流量走哪個出口,而不是靜態地依靠誰的cost 的小,誰的路徑帶寬高。
以後路由協議的發展,會充分考慮這些需求,不僅僅依靠鏈路的靜態cost 值來優選路經,還會加入鏈路的更多動態屬性值如以上三者。
---------補充閱讀---------
很早以前老司機開車,靠的是紙質地圖,開到不熟悉地方停下來研究一下地圖、或公路邊的交通指示,然後繼續前行,慢慢走的多了,路熟悉了,到達一個地方有多條路,司機憑經驗可以找一條最佳路線。以上的方式有點類似目前的IP包的選路。
後來汽車有了電子導航,新司機即使不認得路,照樣可以依靠電子導航到達目的地。
這裡依靠的是:電子導航CPU + 電子地圖 + GPS定位 + 司機的方向盤的操控
而目前的手機導航更是先進,還可以實時提示前方擁堵路段,讓司機提前避開擁堵路段。
這裡依靠的是:手機軟體 + GPS定位 + 4G網路+ 後台伺服器路由信息更新+ 司機的方向盤的操控
但是IP包和老司機+汽車有最大的不同,IP包沒有自己的CPU,沒有自己的計算單元,所以它只能是被動地被路由,最終做出路由優選的決策還是需要依靠每一跳路由器。
路由協議如果能實時更新路徑的最新信息,就如同手機提醒擁堵路段的機制類似,源主機充分了解這些信息,可以提前避免擁堵路段,這可能是最合理的選擇。數據包是data,不是process,沒有計算處理能力。
汽車自帶引擎,還帶了一個有腦子的司機。
你想讓始發端控制數據流向,就是面向連接的協議了,始發端發起請求讓路上都留好通路不一樣的,數據包裡面除了0和1, 什麼都沒有,計算必須依靠其他設備。 不論是傳統的IP網路,現在火的一塌糊塗的SDN,還是號稱牛逼到不行的未來網路(比如NDN),都是靠查錶轉發的。如果數據包能自行決定轉發路徑,那數據包就具有了智能,這顯然是不現實的。
不現實,數據包由主機發出,如果每個數據包都能預先選擇好轉發路徑,那每個主機都勢必要了解全網的拓撲並按照自己的規則選擇其中一條路徑,這個代價太大了,既無必要也看不出來有什麼價值
IPv4有這個可選項,支持選路,不過目前絕大部分路由器都直接忽視了。
開車在路上的時候,寧願有設備幫我找最快的路由。在大多數時候,車輛的無序(自主選擇路由)並非是最佳路線——包括對個體和對整體。
1.全網拓撲結構你知道有多大么?2.節點繁忙程度你事先判斷,到該節點時,是否還準確?
以C家為例簡單介紹一下幾種數據轉發的方式,希望能給題主帶來一點幫助。首先數據轉發最開始,確實是每個數據包都要經過CPU運算(基於目的IP和路由)來轉發,如題主所說這種轉發性能受查表性能限制,我們稱這種轉發方式叫做進程交換。隨著發展,開發了新的轉發規則叫做快速交換,原理是將一個數據流中的第一個包進行完整的進程交換,設備會將第一個包的處理方式緩存起來,後續數據流中的所有數據包將按照緩存的操作方式進行處理。以上兩種都是通過軟體實現轉發,軟體處理肯定不及硬體來的高效,因此C家又推出了CEF(cisco快速轉發)技術。CEF分為控制層面和數據層面兩部分。其中控制層面即通過路由協議來學習RIB;通過ARP協議來學習ARP表。數據層面,通過RIB生產FIB(轉發信息表),通過ARP表生成Adj表,這兩張表是可以直接被硬體調用的來進行數據轉發的。接下來要提的就是重頭戲MPLS(多協議標籤交換),在MPLS中不再是基於IP路由表的轉發,而是通過在IP包中插入一個標籤,利用標籤在路由器上進行轉發。更多的MPLS相關知識答主自行百度吧。
目前有和問題中機制比較類似的技術,就是MPLS-TE。
和一般的IP轉發不同,MPLS使用的不是目的IP地址,而是使用二層頭和三層頭之間的MPLS標籤進行轉發。當一個數據包進入MPLS網路後再ingress LSR上會打上相應標籤,中間傳輸的LSR會根據MPLS轉發表不斷替換標籤直至egress LSR去掉標籤恢復成普通IP報文。因為標籤是在ingress LSR打上的,這就保證了ingress LSR對報文在MPLS網路中轉發路徑的控制權。
MPLS-TE另一個重要組件是RSVP,這是用於鏈路帶寬預留的一個協議,路由器會通過這協議進行帶寬的預留和分配工作。MPLS-TE另一個重要組件是鏈路狀態路由協議的擴展,也就是OSPF和IS-IS的擴展。通過鏈路狀態路由, ingress LSR也就是MPLS-TE隧道起始點可以知曉全網的帶寬預留和剩餘情況,選擇滿足資源的轉發路徑。不可能。
你要自己想去哪裡去哪裡,首先你得有整個世界的詳細到每一戶的地圖呀,其次是實時的交通情況呀,以及在路上如何躲避突發情況呀………你覺得你能做到嗎?
發送端並不可能知道全部internet路由和鏈路利用率。類似的想法有rsvp協議,但是太複雜互聯網上沒人用,區域網內使用情況不清楚。目前QoS還是Dscp實現的多點
推薦閱讀:
※圖靈設計的電腦到底是如何運作的?
※你認為的最美的定律或公式是什麼?
※【philippica】萌萌噠弱受RSA和強攻wiener
※綠茶的硬體瞎談——為什麼從不推薦網購整機?