作者：吳靈曉(蓋優)
演進路線
階段一（2020年末）
本階段完成線上所有服務的IPv6改造，全面支援IPv6雙棧的訪問支援；融入阿里雲的IPv6生態體系，內網環境全面支援IPv4/IPv6雙棧；提升使用者端側IPv6流量佔比，IPv6流量佔比不低於總量的40%。
- 管：全面完成優酷主站廣域網、集團級資料中心核心網路、網際網路出口IPv6網路改造，IPv6在多地域多運營商開通。汰換無法通過升級支援IPv6的核心路由器，交換機。建立CDN專屬資源池，全部選用支援IPv4/IPv6的CDN節點。引入IPv6-only的專線鏈路，適時降低IPv6接入成本；
- 雲：全面完成企業網際網路域名伺服器IPv6改造，支援AAAA記錄和IPv6域名解析請求，主要核心業務域名全部配置A及AAAA記錄。使用阿里雲HTTPDNS服務，支援移動端的IPv4/IPv6雙棧及IPv6-only環境下的域名解析能力。優酷相關的服務及介面全面上雲，新增的ECS，CDN等資源全部選用支援IPv6區域的資源產品；
- 端：各手機端應用APP以及web瀏覽器端全部支援IPv4/IPv6雙棧及IPv6-only環境下的網路通訊能力。嘗試引入使用者功能體驗引導方案，讓使用者可以直觀地體驗到IPv6帶來的收益。端側測試 IPv6流量佔比不低於總量的40%；
- 安全：全面完成優酷網際網路出口安全防護系統的IPv6改造，應用內的安全防護外掛全面支援IPv6環境，確保整體安全防護能力不下降。建立IPv6下獨立的監控體系，覆蓋基礎監控及應用監控，具備和IPv4相同的監控能力。
階段二（2021-2022年）
本階段全面支援IPv6-only的訪問支援；全部融入阿里雲的IPv6-only生態體系，內網環境全面支援IPv6-only雙棧；IPv6雙棧+only比例不低於80%， IPv6流量佔比不低於總量的60%。
- 管：全面完成主站機房及CDN節點機房的IPv6出口改造，包括所有內地以及熱門海外節點。IPv6流量全面跑在專用鏈路上，全面實現IPv6下的流量收益能力；
- 雲：全面完成企業網際網路域名伺服器IPv6改造，支援AAAA記錄和IPv6域名解析請求，所有業務域名全部配置A及AAAA記錄。優酷相關的服務及介面全部使用IPv6環境的資源產品，內部網路環境全部切換到IPv4/IPv6雙棧模式；
- 端：全端全站支援IPv6-only訪問，用於體驗無差異化。使用者產品體驗設計上全面傾向IPv6，引導使用者汰換老設施老終端。IPv6雙棧使用者比例不低於80%，並逐步引導IPv6-only模式；
- 安全：進一步強化IPv6的網路安全能力，全面提升防護等級，及時發現並解決IPv6環境下衍生出的新業務形態的安全挑戰。對邊緣計算、物聯網、車聯網、雲遊戲等新領域，具備全網同等級別的安全保障能力。
階段三（2023-2025年）
本階段全面完成所有機房及CDN節點的改造，全部支援IPv6-only的訪問；IPv6-only比例不低於80%， IPv6流量佔比不低於總量的80%。
- 管：全面完成IPv6-only改造；
- 雲：全部使用雲上產品，所有產品都支援IPv6-only；
- 端：IPv6-only比例不低於80%，淘汰雙棧模式。對不足20%的IPv4使用者提供最小功能集的降級服務，鼓勵升級到IPv6-only；
- 安全：進一步強化IPv6-only場景下的安全防護、安全監管、災難備份與恢復等能力，提升IPv6環境下娛樂網、物聯網、車聯網、雲端計算、雲遊戲、VR/AI智慧等領域安全保障能力。
實施指南
網路
機房網際網路出口
建設改造中心機房IPv6網際網路出口
跟隨阿里集團整體節奏，核心服務所在的中心機房全部完成網際網路出的改造，支援IPv6。在五大城網出口所在地的中心機房，全部完全IPv6改造。優先選用BGP對接方式，方便網際網路出口域內域外路由協議的統一規劃。提前做好IPv6降費提速準備，優先排程IPv6流量，提高IPv6流量令牌優先順序，在同等環境下優先路由。
建設改造CDN節點機房IPv6網際網路出口
由阿里雲進行統籌安全改造地域與時間節點，業務同步做好按地域引流工作。
改造升級骨幹網VIP+LVS
替換不支援通過升級支援IPv6的老舊設施，包括大量的核心路由器，交換機及負載均衡裝置。對網際網路出口部分的硬體防火牆、入侵檢測裝置等安全防護裝置進行更新，不支援更新進行替換。優化路由配置，路由配置及快取使用配比，使改造後的IPv4網路效能不下降的同時，IPv6網路效能略優於IPv4。各安全防護能力達到與IPv4出口等同或者優於IPv4環境下的防護能力。
改造升級應用服務測試環境
通過隧道方式打通生產機房與測試機房之間的IPv6鏈路，升級企業跳板機代理伺服器支援IPv6，支援IPv6環境下登入測試環境滿足業務需求。
改造企業園區網路VPN系統
攜同阿里企業智慧網團隊進行IT辦公網路的改造，接入IPv6網際網路出口，升級園區內路由器交換機以及VPN裝置。升級VPN客戶端，支援IPv6環境下的使用者遠端登入，完善遠端接入環境IPv6安全防護策略，強化IPv6安全防護能力。
域名解析DNS/HTTPDNS及回落
業務域名網路雙棧設計及開啟
DNS核心升級：對業務域名開啟多CNAME能力。業務域名分別配置IPv4-only及IPv6雙棧的CNAME域名，具備權重調節能力。可以按地域按運營商自由地控制IPv4及IPv6雙棧折解析比例。對走localdns的PC/H5端進行IPv6的灰度流量控制，實現IPv4協議和IPv6協議共存。IPv6->IPv4的回落能力由瀏覽器提供，部分過舊的瀏覽器不支援快速回落能力。
HTTPDNS核心升級：HTTPDNS服務本身部署在IPv6環境，具備IPv6網際網路出口，提供IPv6 VIP及域名AAAA解析保障。同時，升級HTTPDNS服務本身，可以根據請求客戶端的網路狀態，以及使用者請求引數，對請求的域名下發AAAA解析記錄，確保客戶端執行在IPv6環境中，可以正常解析到業務域名的AAAA記錄。
HTTPDNS的快速回落：HTTPDNS在獲取到客戶端支援IPv6時，會把域名的AAAA記錄及A記錄同時下發給客戶端。當客戶端建聯IPv6不成功時，會同時開始建立IPv4連線，以確保使用者體驗無影響。
同時，針對一些特殊的業務域名，例如：沒有實現PC端降級以及對降級產生的延遲無法容忍。可以去掉權威DNS中業務域名的AAAA記錄，將AAAA記錄只配置在HTTPDNS中，可以滿足客戶端走IPv6，PC端走IPv4，既滿足了IPv6的需求又可以讓PC業務無損。
動態IPv6比例控制能力
IPv6建設初期，建連成功率低於IPv4，RT也高於IPv4，導致業務無法整體切換到IPv6。同時，已經切過去的部分，也可能因為網路變更影響網路質量，需要臨時關閉IPv6。這些切換操作，如果都由運維同學手動操作的話，那麼像優酷這樣有幾十上百個域名的，完成一次操作需要花上1-2天的時間，時率上不可接受。因為需要建設一套包含DNS以及HTTPDNS的域名切換系統，可以批量切換域名及HTTPDNS的配置，做到PC和移動端的業務同步。同時，切換時要具備彈效能力，IPv6從100%降到0%，不能一下子切掉，需要90%-80%-70%----0%執行，確保不會給網路裝置和伺服器以及網路出口帶來跳變。同時，需要獲取業務成功率的監控資料，如果切換過程中，成功率出現下跌的話，系統能夠中止切換或者自動回滾到上一級比例，發出報警讓運維同學介入排查。
網路質量資料獲取設計
客戶端埋點上報支援IPv6
在手機客戶端以及PC端中，通常會使用埋點技術將端側執行資料及錯誤情況，上報至採集伺服器。大部分的資料上報中，並不會主動將客戶端的IPv4及IPv6都帶上，導致服務端並沒有可靠的資料來源去分析IPv6下的業務情況。所以，需要改造採集服務端，支援和客戶端進行IPv6建連，確保在IPv6雙棧及IPv6-only環境下埋點資料可以正常上報。同時，在app啟動，使用者鑑權，網路變化等場景發生時，主動從服務端的應答結果中取到客戶端的出口IP，並把這些資訊儲存在本地快取中，在埋點上報時帶上IP地址。這樣採集端就可以收集到客戶端的真實出口IP，如果的雙棧的話，還可以同時收集到IPv4,IPv6地址並自動關聯。從根本上解決了雙棧環境時，服務端無法同時獲取IPv4,IPv6的問題，有助於網路質量資料分析。
資源管理、運維繫統改造
實現IPv4,IPv6資源區分管理能力
隨著IPv6深入改造及政策支援，對使用IPv6環境的資源裝置，流量頻寬，排程引流等，將出現區別於IPv4環境的使用場景和計量計費規則。慢慢地IPv6將會在某些應用場景上出現成本上的優勢，而現有的資源管理系統上新建網路管理、應用效能管理、認證伺服器、DNS/DHCP等支撐系統推薦採用IPv6單棧建設，存量支撐系統推薦進行雙棧化改造，具備對IPv6裝置、應用或使用者的基於機器學習、知識圖譜、神經網路等AI加持的智慧運維、終端識別、應用識別、智慧調優、智慧漫遊、大資料安全分析等管理能力，待網元裝置、應用或使用者完成IPv6單棧改造後，支撐系統需同步完成IPv6單棧切換。
實現IPv6環境獨立運維能力
改造並開啟運維繫統雙棧協議，使系統具備在IPv6網路環境下對雙棧伺服器、網路裝置、應用容器、監控採集、資料庫快取中介軟體、配置遠端推送及使用者資料的管理能力。對於暫時不支援IPv6的系統及裝置，提供NAT地址轉換、降級IPv4等方式，來進行管理，待改造完成上線後，逐步開啟IPv6能力。
應用與服務
介面服務及PC端頁面
新建應用
新建應用的部署，選用支援IPv6的主站機房資源或者阿里雲地域，機房出口到負載均衡使用雙棧標準。
- Web容器環境：選用支援IPv6協議的最新版本Tengine，安裝toa模組，支援透傳IPv6頭資訊至應用服務。
- 開發環境及OS系統：應用的開發編譯選用支援IPv6協議的作業系統，如Windows server 2003以上版本、MAC OS 10以後，以及Linux系統的CentOS 7或者Alios 7U等。
- 測試環境：辦公網環境與測試機房通過IPv6專線打通，辦公網提供IPv6的無線/有線接入點，同時保留了原來的IPv4接入點。開發同學可以接入IPv6接入點進行日常開發和辦公事務處理，需要訪問不支援IPv6的公網服務時，可以切換到IPv4網路環境。
- 業務場景1 IP地址庫：使用IP地址庫服務對使用者歸屬地進行定位判斷處理的，需要升級到最新版本的IP地址庫資料服務，並具備定期升級能力。確保IPv6地域歸屬判斷的準確性。
- 業務場景2 IP地址格式統一：因為IPv6地址可以略寫的原因，導致直接按字串進行判斷的話，會把有略寫和無略寫的IPv6判斷成不是一個IP地址，從而導致業務處理出現偏差。同時，部分瀏覽器請求會自動略寫IPv6地址，JAVA網路包,CURL等，不會主動略寫IPv6地址，這會增長服務端處理的複雜性，所以需要前置一個公共處理，將所有的IPv6地址都經過公共處理進行標準化，統一業務處理邏輯，減少業務間不一致問題。
- 業務場景3 IP地址儲存：一般服務端日誌落庫，使用者資訊落庫等常規處理中，會把使用者IP儲存到資料庫等儲存中，對於嚴格限制資料型別和長度的資料庫，需要依據儲存型號進行定義，原來的IPv4只需要32位字串或者長整型資料就可以儲存，而IPv6需要擴大到128位，同時長整型也存不下，需要高64位和低64位拆分儲存等方式進行處理。
- 業務場景3 介面傳遞：某些使用http get方式將多個使用者IP通過引數形式傳遞時，需要注意get的1024B的上限，原來傳遞IPv6時10個使用者一起傳遞沒有問題，但現在改用IPv6時10個使用者的IP長度就會超過get上限，需要改用post或者調低上限。
- 業務場景4 存在IP地址的hardcopy：不能把上下游呼叫介面的IP地址直接寫在程式碼中或者配置檔案中，因為上下游完成IPv6改造的時間並不完全一致，上線時間也不一致，會導致出現線上故障。需要全部改為域名方式呼叫。
- 客戶端IP出口地址的取得方式：在雙棧環境中，同一請求，你只能從請求頭部中獲取到IPv4 IPv6地址中的一個，不可能兩個都獲取。如果希望同時獲取IPv4 或者IPv6地址，那麼只能選擇重複請求，或者是通過引數將客戶端地址傳上來。需要擴充套件請求欄位，將v4,v6分成兩個欄位提交，同時服務端也需要做接收改造處理。
- 日誌分析邏輯：眾所周知，為了方便日誌分析和拆解，所有的業務日誌都會定義一個統一的格式，日誌輸了的各個欄位之間統一使用||等分隔符分隔或者按欄位長度固定。使用分隔符的，需要考慮到不能再使用:了，因為IPv6中帶了這個符號。使用固定長度分隔的，也需要考慮到對IP地址不能再固定32位長度了，要調整到128位，同時要向下相容IPv4，IPv4也要補齊到128位。
- 第三方庫的更新：選用支援IPv6協議的第三方SDK版本，如果三方庫不再更新支援IPv6，那就需要尋找置換方案。
- 安全部署環境：接入層安全控制元件，限流外掛，ACL白名單外掛等應用安全服務應支援IPv6協議。
- 降級能力：需要從業務邏輯上原生考慮IPv6網路不可用時，如何降級至IPv4來繼續提供服務。
存量應用改造
存量應用可進行程式碼IPv6重構開發或雙棧支援介面開發。對於不支援IPv6改造或者暫時無法改造的，需要單獨劃定小叢集區域，來提供IPv4-only的服務能力。
- 接入層改造：制定IPv6升級計劃，申請IPv6的VIP，將負載均衡的RS指向新的IPv6接入層，確保IPv4與IPv6的流量隔離。
- 基礎映象升級：原業務使用過舊，版本過低的OS映象打包時，需要升級到最新支援IPv6的基礎映象，並用最新的OS進行編輯打包。
- 業務系統改造：依據上述新建應用的業務場景梳理內容，對存量業務邏輯進行排查，存在上述場景的需要進行業務程式碼的重構，業務邏輯的修改，使存量業務滿足IPv6環境下執行需求。
- 替換Web容器環境：升級最新版本Tengine，升級最新toa模組，支援透傳IPv6頭資訊至應用服務。
- 升級開發環境及OS系統：應用的開發編譯選用支援IPv6協議的作業系統，如Windows server 2003以上版本、MAC OS 10以後，以及Linux系統的CentOS 7或者Alios 7U等。
進行IPv6測試環境下的迴歸測試
存量應用一般都經過嚴格的IPv4環境下測試，但不能保證在IPv6下一定是沒有問題。所以需要在IPv6的測試環境下，對存量應用以及新建應用進行迴歸測試。包括對所有有改動功能點的全量測試，以及沒有改動但屬於核心功能點的覆蓋性測試。
驗收
應用改造完成後，進行線上灰度驗收，按照國家網站/應用IPv6升級改造驗收督查指標相關要求進行測試驗證，在域名IPv6支援度、頁面IPv6可達性、業務IPv6支援度、應用服務質量、IPv6安全防護等方面開展測試。
移動終端及APP
Windows/mac端IKU應用
接入HTTPDNS服務，在客戶端整合HTTPDNS服務SDK包，IKU應用具備手機移動客戶端相同的IPv6引流灰度能力。替換IKU應用端中的網路包，具備IPv6的網路通訊能力。開發在IPv6弱網條件下的降級能力，在使用者可以接受的延遲時間內，切換到IPv4通訊，保障使用者體驗無損。逐步關閉低OS版本的使用許可，關閉低版本應用的上線使用，推動使用者端進行OS或者裝置的升級，提高IPv6使用率。
安卓/Iphone/Ipad 手機客戶端
這塊佔比最大，同時使用者裝置型別也是最豐富的，需要通過不斷的版本更新，來降低舊版本的佔有率，達到提升IPv6使用率的目標。
- 終端IPv6支援度評估：將安裝優酷APP的終端按照機型，OS版本，效能， IPv6下通訊能力分類。對新上市機型進行逐臺驗證，分別進行IPv6支援度評估。
- 客戶端APP基礎套件升級：基礎網路包NetworkSDK等集團二方包進行升級，實現支援IPv6的協議棧解析以及基礎降級能力。使用第三方網路庫的，例如：libcurl，需要升級到最新版本，同時通過業務邏輯彌補上缺失的自動降級能力。
- 升級IP地址：部分APP中整合有小型的IP地址庫，因為資料包大小的問題，基本上小型IP庫都沒有包含IPv6的資料。需要重新評估IP庫資料包大小與APP整體包大小的關係，如果整合支援IPv6 IP庫資料包過大的話，那需要通過服務端判斷的方式來替代本地的IP庫。
- 端側埋點服務的改造：埋點的正常上報，是整體評估IPv6下業務可用性和使用者體驗一致性保障的前提。特別是在弱網、斷網、降級回落的情況下，資料可以正常上報。IPv6 下埋點是否正確檢測出網路環境的變化，網路切換導致的RT變化等，需要根據業務邏輯和使用者操作場景，進行埋點的改造。
大屏OTT端
大屏端的硬體汰換率低於手機端，大量不支援IPv6的老裝置還在繼續使用著。大屏端APP使用的基礎架構需要和安卓手機端進行統一，在APP層面上支援IPv6網路環境下的正常使用，參考上述安卓手機端進行改造。對於硬體部分，能通過升級OS韌體方式來支援IPv6的，要積極推動硬體廠商進行並推送更新。無法通過升級方式來支援，考慮到硬體的整體使用週期及壽命，逐步提醒更新。
雲及CDN
雲產品的選型
新建場景
跟據阿里雲的IPv6改造計劃，選用已經完成改區域的雲產品，使用業務原生支援IPv6環境。
存量場景
因為雲產品支援IPv6後需要對原產品進行升級或者置換後，才能開啟IPv6支援，所以對於存量使用的雲產品，有一個遷移的過程。需要把流量遷到已經改造完成的地域後，對原有地域的雲平臺進行雙棧化改造，包括ECS，ENV容器叢集控制中心、容器編排系統、VPC/虛擬閘道器、負載均衡等進行IPv6支援改造，釋放原有資源重新申請新的IPv6資源，來快速獲取IPv6支援能力。改造完成後再把流量逐步切回，釋放掉臨時資源。
CDN的IPv6支援
普通加速域名
依據阿里雲CDN改造計劃，將各地域各運營商已經改造完成的IPv6 CDN節點加入到排程域。排程演算法需要支援IPv6 VIP，當區域內IPv6節點資源不足或者沒有IPv6節點時，是進行跨省跨區域排程，還是降級IPv4。從使用者體驗角度來說，IPv6資源不足時降級IPv4是對使用者沒什麼影響的。也可以通過計算支援IPv6的CDN頻寬與總頻寬的比例，並確定各地域的IPv6引流比例。阿里雲控制檯開啟IPv6功能，並配置圖片域名的灰度比例。從流量入口上就控制處IPv6的灰度總量，確保不會出現IPv6資源不足或者無資源可排程的問題。
302排程域名
302域名跳轉時，會有前述IPv6地址縮寫的問題，瀏覽器訪問時會自動用縮寫後的IPv6地址跳轉，APP內使用libcurl等網路庫時，並不會觸發自動縮寫，以獲取到的IPv6地址原樣進行請求。需要302節點配置縮寫前和縮寫後兩套IPv6的VIP，確保任何場景下都可以跳轉。在HTTPS的VIP證照中，需要加簽IPv6的VIP，確保https下也可以正常跳轉。
免流域名
免流排程域需要分配IPv6的VIP組，將需要向運營商報備的免流節點IP都劃入進去，並且具備IPv6功能的開啟和關閉能力，確保在運營商報備完成前不啟用IPv6節點，運營商報務完成後又能及時啟用節點，避免出現免流失效或者免流排程域水位過高的問題。
安全
IPv6網路安全整體原則：配合IPv6演進的不同階段，明確網路、服務、應用app以及新業務場景下，IPv6網路安全的能力範圍和保障方案，強化IPv6安全防護能力以及多端共享、邊緣計算、雲遊戲、物聯網等新型業務場景下的安全防護能力。
限流能力
限流能力需要具備IPv4/IPv6雙棧場景下的應用能力，能夠對總流量進行限制，也可以分別對IPv4,IPv6進行限制。具備在系統能力飽和的情況下，怎麼樣優先讓IPv6的請求能力盡快得到處理並響應，保障IPv6優先的使用者體驗。
ACL黑白名單及安全策略
確保IPv6安全體系防護的完整性與高效性，對防火牆、入侵檢測、行為審計、流量清洗等網路安全裝置，進行統一升級以支援IPv6環境下的正常工作。隨著IPv6的發展，IPv6的地址數量將遠遠超過IPv4，現有的ACL黑白名單容量將無法滿足，需要提前進行擴容改造。對於IPv6安全防護能力存在風險的節點，應進行網路安全裝置升級或替換。從應用業務層面以及安全管理層面進行IPv6安全策略制定與配置，保證IPv6的安全策略包含了所有的IPv4策略。
IPv6+創新
IPv6+5G
隨著移動網際網路的發展，越來越多的裝置接入到行動網路中，從某種程度上來講，5G和IPv6是相輔相成的，目標是一致的，都是儘可能將更多的裝置互聯，達到萬物互聯的境界。IPv6解決了萬物互聯上裝置數量受限的問題，因為地址數量不足，IPv4可能無法滿足每一個人都接入10裝置。接入IPv6的話，別說每個人10個裝置，10億個也沒有問題。同時，5G是解決了萬物互聯質量上的問題，高速率低延遲是5G網路的核心優勢。量和質的問題，被IPv6+5G一起給解決了，移動裝置的需求爆炸式增長的時代還會不到來嗎？5G的技術應用得到了極大的滿足，當成本降至合適程度時，IPv6+5G可以替代wifi，不再需要NAT地址轉換，不需要切換流量。只要安全能力滿足，你和世界都是實時聯通的。
IPv6+P2P分享
可以想象，今後家中每個帶電的裝置都會成為計算中心，娛樂中心，看優酷將不再受限於客戶端裝置，走到哪裡看到哪裡，每個人都會是內容的消費者同時也會是內容的生產者，片段化的時間能夠最合理的利用，最大程度解放雙手，隨時隨地享受娛樂盛宴。
那麼這就代表著一個終端既是服務提供方，又是服務消費方，既要為其它裝置提供請求入口，又要主動請求其它服務。現有IPv4+NAT方案，限定了P2P分享的範圍，最終能共享到的資源及資料很少，IPv6下理想狀態是全網都不再需要NAT，任何裝置不需要做地址轉換都可以直接請求到網內的所有裝置。這樣就極大的推展了P2P可達範圍，資源及資料幾乎可以全覆蓋。我為人人，人人為我，全面符合我們的政治遠景。
關注【阿里巴巴移動技術】微信公眾號，每週 3 篇移動技術實踐&乾貨給你思考！