“如無必要，勿增實體”的奧卡姆剃刀原則，從IT人士的角度來看就是“只要能運行，就千萬不要改”，而且各種“殺個程序員祭天”，“耽誤工期遭索賠”等事件依舊層出不窮，IPv4只要還能勉強(qiáng)運行一天，那么IPv6就得晚上位一天。
但問題是IPv4的資源真撐不住幾天了，截至2021年2月26日，APNIC地址池僅剩余折合0.23個A的IPv4地址，最多再有兩年就會盆干碗凈一點不剩了。而且IPv6目前發(fā)展得也很不錯，在基礎(chǔ)軟件中，Windows、Linux已經(jīng)支持IPv6近15年了，目前已經(jīng)非常穩(wěn)定，Docker容器天然支持IPv6，K8s也已經(jīng)穩(wěn)定支持IPv6，但是再好的技術(shù)，沒有改造動力也出不來，雖然IPv6替換口號喊得震天響，但實際的進(jìn)展卻總不如人意。
IPv6目前在各技術(shù)棧當(dāng)中已經(jīng)獲得了廣泛的支持，但是覆蓋面還有待提升，比如在基礎(chǔ)軟硬件平臺中的操作系統(tǒng)方面，目前僅有75%左右節(jié)點會默認(rèn)安裝IPv6協(xié)議棧，有65%左右支持DHCPv6，50%左右支持ND RNDSS；而在網(wǎng)絡(luò)設(shè)備方面，雖然目前絕大多數(shù)的設(shè)備均已經(jīng)支持IPv6協(xié)議，但在無線WIFI尤其是家庭無線WIFI等實際場景中，默認(rèn)使用IPV6地址的無線路由器還不足20%；在應(yīng)用側(cè)對于IPv6的支持度會好一些，如Bing、雅虎、淘寶等眾多網(wǎng)站或者APP均已經(jīng)宣布永久支持IPv6，但由于實際使用IPv6的終端用戶數(shù)量不足，因此目前的互聯(lián)網(wǎng)還幾乎是IPv4的世界。
但最近元宇宙的突然興起，讓情況突然發(fā)生了變化，科技龍頭臉書改名Meta，以堅定自身的轉(zhuǎn)型決心，羅永浩老師也宣傳在還完債之后要從直播界回歸到科技界做元宇宙的創(chuàng)業(yè)項目。當(dāng)然這里不想討論關(guān)于元宇宙的話題，但是元宇宙肯定無從構(gòu)建在一個只有50億個地址池的IPv4空間上。
IPv6全球路由地址有230億億(261)個，號稱可以給地球上每粒沙子分配一個IP，60億人口和500億物聯(lián)網(wǎng)終端，在IPv6協(xié)議看來根本不是什么問題，徹底解除由于IP資源池大小限制網(wǎng)絡(luò)規(guī)模的拓展，這才能和元宇宙的宏大愿景相對應(yīng)。
而且IPV6還能帶來更好的上網(wǎng)體驗，如果有讀者經(jīng)常使用手機(jī)銀行等金融APP可能會發(fā)現(xiàn)這樣一個現(xiàn)象，那就是當(dāng)WIFI與數(shù)據(jù)連接發(fā)生切換時，手機(jī)銀行的登陸狀態(tài)往往也會改變，但移動IPv6協(xié)議改變了這種情況，IPv6的移動終端在改變地理位置時，即使分配到的IPv6地址發(fā)生變化，原有的連接也不會被Terminate。
IPv6報頭還新定義了流標(biāo)簽字段，路由器可根據(jù)源宿地址+流標(biāo)簽唯一標(biāo)識一條端到端的IP業(yè)務(wù)流。實現(xiàn)有序轉(zhuǎn)發(fā)，這對于QoE要求高的短視頻等賽道來說可以大幅提升用戶的使用體驗。
IPv6報文頭中目的IP等字段要比IPV6要長，但卻是定長的，網(wǎng)絡(luò)設(shè)備的算力載體本質(zhì)上也是CPU處理器，這就使它也逃不開CPU體系架構(gòu)的制約，在現(xiàn)代的指令流水線體系中，定長字段就是比變長字段更具效率優(yōu)勢。
我們知道CPU的每個動作都需要用晶體震蕩而觸發(fā)，想執(zhí)行一條指令需要取指、譯碼、取操作數(shù)、執(zhí)行以及取操作結(jié)果等若干步驟，而每個步驟都需要一次晶體震蕩才能推進(jìn)，因此在流水線技術(shù)出現(xiàn)之前執(zhí)行一條指令至少需要5到6次晶體震蕩周期才能完成。
由于取指、譯碼這些模塊其實在芯片內(nèi)部都是獨立的，那么只要將多條指令的不同步驟放在同一時刻執(zhí)行，比如指令1取指，指令2譯碼，指令3取操作數(shù)等等，就可以大幅提高CPU執(zhí)行效率：
但是指令流水線也帶來了分支預(yù)測的問題，一旦一條提令不是后續(xù)執(zhí)行所在的if分支，但處理器卻錯誤的把它放在了流水上，那么這就會造成處理器的空轉(zhuǎn)，帶來極強(qiáng)的懲罰效應(yīng)。
因此這也讓那些不涉及if-else分支定長報文解析可以在現(xiàn)代CPU架構(gòu)下獲得更高的效率，因為非定長的報文肯定要做if判斷來決定報文的解析方式，而一旦分支預(yù)測失敗，那就會迎接流水線執(zhí)行效率下降的懲罰，比如指令5本是不應(yīng)該執(zhí)行的分支代碼，如果在T7也就是指令3取結(jié)果時才發(fā)現(xiàn)這一預(yù)測錯誤，那么還很可能會拖累指令6、指令7也全部陷入預(yù)測失效。那么，下一時刻T8指令8才剛剛開始譯碼，這會造成整個流水線的效率大幅下降。在之前的文章《M1 MAX暴擊，倚天補(bǔ)刀》中曾經(jīng)介紹過，基于ARM這種RISC架構(gòu)的處理器其最大的優(yōu)勢在于可以把指令解碼器做到極致，從而平衡功耗與性能之間的關(guān)系。
所以我們不能認(rèn)為IPV6的IP地址長度更長，轉(zhuǎn)發(fā)效率就會低，真實的情況恰恰相反，IPV6要比V4路由器轉(zhuǎn)發(fā)效率高得多!
在Facebook要All In元宇宙改名Meta之前不久，其實他們剛剛遇到了由于廣域路由協(xié)議BGP造成的全球范圍宕機(jī)問題。在路由設(shè)計方面，IPv6也比IPv4要領(lǐng)先很多，IPv6在設(shè)計之初就認(rèn)為IP體系是聚合的（Aggregation），可自頂向下樹狀分配，路由器可集合路由條目，瘦身路由表。本質(zhì)上講路由算法就是要找到從地點A到地點B最短距離的旅行規(guī)劃問題。而針對這個問題早就有經(jīng)典算法dikjstra解決。為了說清這個IPv6路由聚合（Aggregation）的好處，下面我們先把dikjstra旅行算法做一下介紹。
旅行規(guī)劃的題目可以歸結(jié)為以下說法，用戶有一張自駕旅游路線圖顯示了城市及公路的數(shù)量，高速公路長度、過路費?，F(xiàn)在要通過一個算法，找一條出發(fā)地和目的地之間的最短路徑。如果有若干條路徑都是最短的，那么需要輸出最便宜的一條路徑。
實際在網(wǎng)絡(luò)路由規(guī)劃中，城市代表著網(wǎng)絡(luò)上的節(jié)點，調(diào)整公路代表網(wǎng)絡(luò)上的通道，公路長度一般代表網(wǎng)絡(luò)通道的傳輸性能，過路費用的數(shù)據(jù)在實際工程中可能代表著線路質(zhì)量等參數(shù)。
示例代碼中的變量說明：N、M、S、D分別代表城市個數(shù)、調(diào)整公路條數(shù)、旅行者起始城市編號、旅行者目的地城市編號，其中N（2≤N≤500）是城市的個數(shù)，三維數(shù)組g存儲高速公路的信息，記錄起始城市、終點城市、高速公路長度、收費額，如g[i][j][1]代表編號為i的城市到編號為j的城市之間的距離，g[i][j][2]代表編號為i的城市到編號為j的城市過路的費用，哈希表Path記錄由旅行者的起始城市S到編號為i的城市之間的最短路徑信息，如起始城市S到i之間經(jīng)過j、k最短，那么Path[i]的值應(yīng)該是[j,k]，注意j、k對于順序敏感。Dist數(shù)據(jù)記錄旅行者起始市S到編號為i的城市之間的距離數(shù)值，cost數(shù)據(jù)記錄旅行者起始市S到編號為i的城市之間的花費，到Known數(shù)組記錄城市是否被算法遍歷確認(rèn)，
比如經(jīng)典路由協(xié)議OSPF (Open Shortest Path First)中的SPF最短路徑優(yōu)先其實就非常清楚的表達(dá)出了dijkstra算法的精髓，實際上這個算法就是不斷找到離起點S最近的未確認(rèn)城市A，并嘗試通過A中轉(zhuǎn)能否優(yōu)化到S的距離，如下圖所示：
注：綠色代表起點城市，藍(lán)色代表known狀態(tài)已經(jīng)迭代的城市，紅色代表unknown狀態(tài)的城市
dijkstra算法首先要做的就是找到所有未知節(jié)點中與起始地S最近的城市A，因為經(jīng)城市A現(xiàn)在離S最近，那么經(jīng)城市A中轉(zhuǎn)，就有可能會縮短S到其它目的地城市D的距離。比如上圖當(dāng)中S到A的距離是2，截止目前是S到其它城市中距離最短的一條路徑，那么經(jīng)A跳轉(zhuǎn)則有可能獲得一個比從S直接到D更短的路徑。在上圖例中在使用A行過一輪迭代以后，S到D的距離可以由直接訪問的距離6，優(yōu)化為經(jīng)A中轉(zhuǎn)的距離5。在完成一輪優(yōu)化后A節(jié)點會被記錄為known的狀態(tài)，接下來會用非known狀態(tài)的節(jié)點中找到離起始點最近的那個做下一輪迭代。直到所有城市全部狀態(tài)全部都是known為止。
用動圖展示上述代碼的運行過程如下：
Dijkstra本質(zhì)上是旅行者算法而不是網(wǎng)絡(luò)路由算法。簡單來講dijkstra是為旅行者而設(shè)計的，站在旅行者的角度去考慮問題，但是從網(wǎng)絡(luò)的實際使用情況上看，算法中的旅行者對應(yīng)應(yīng)用層的數(shù)據(jù)包，按照網(wǎng)絡(luò)結(jié)構(gòu)層的分工界限，應(yīng)用層只負(fù)責(zé)提供目的IP地址，具體如何路由到目的IP，完全不是數(shù)據(jù)包的發(fā)送方需要關(guān)心的問題。
而站在網(wǎng)絡(luò)設(shè)備的角度上看，假如上面例程中的城市A是上臺路由器，那么它只需要掌握最優(yōu)路徑上下一個城市C的路由信息就可以了，掌握整個路徑的全貌，費時費力不說，也沒有必要。
更為關(guān)鍵的是Dijkstra算法的時間復(fù)雜度接近于O(n2)，這也決定了IPv4那種散亂的IP分配方式在互聯(lián)網(wǎng)終端越來越多的情況完全難以為繼。我們剛剛也講了Dijkstra每步迭代的之間是有前后順序關(guān)系的，很難像搜索那樣進(jìn)行分布式并行計算改造。因此這也就使得路由協(xié)議必須要限制管理節(jié)點的個數(shù)，因為如果要給整個互聯(lián)網(wǎng)上幾十億節(jié)點跑一遍Dijkstra算法，顯然不是一種可行的計算方案。
因此這里IPv6把路由聚合的策略其實就是把網(wǎng)絡(luò)進(jìn)行分區(qū)的方案。也就是說網(wǎng)絡(luò)數(shù)據(jù)包要先到達(dá)某一區(qū)，進(jìn)區(qū)之后再通過內(nèi)部網(wǎng)關(guān)協(xié)議IGP只處理區(qū)域內(nèi)部的網(wǎng)絡(luò)關(guān)系。IPv6在路由劃分上的清晰策略也是它能夠取代IPv6的最重要原因之一。
IPv6包頭還有很多非常有意義的擴(kuò)展，天然支持IPSEC，安全性得以提升，也增強(qiáng)了對組播和QoS的支持。不過目前我們對IPv6的應(yīng)用還停留在互聯(lián)網(wǎng)邊界層面，對它的這些增強(qiáng)特性使用的還不多，但是元宇宙應(yīng)該是IPv6普及之路上的一大契機(jī)，未來幾何讓我們拭目以待。
本文來自微信公眾號 “CSDN”（ID：CSDNnews），作者：馬超，王麗麗，36氪經(jīng)授權(quán)發(fā)布。
