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