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