導讀：隨著5G的落地，今年，很多用戶將5G手機提上日程。但你知道嗎？就像路上行駛的汽車必須有號牌一樣，每一個設備接入5G，至少需要一個IP地址，用以表示它在網絡上的存在。而目前全球的IPv4地址已經耗盡，所有43億個IPv4地址已分配完畢，這意味著沒有更多的IPv4地址可以分配給ISP和其他大型網絡基礎設施提供商。所以，大家將目光投向了下一代網絡協議IPv6，其地址數量號稱可以為全球的每一粒沙子編上一個地址。
作為5G的基礎架構，優酷從2018年開始IPv6 的全業務改造，從技術策略到全量部署上線總耗時6個月。作為項目的深度參與者，阿里文娛技術專家蓋優將詳解分享這一技術過程，希望對大家有啟發。
作者 | 阿里文娛技術專家 蓋優
概述
什麼是IPv6？IPv6=互聯網網絡層傳輸協議第六版。廣義的講，IPv6 就是下一代互聯網的基礎設施，5G 物聯網的核心基礎。與現行IPv4 相比，它更安全，更高效，更省成本，幾乎用不完的IP 地址，業務無限拓展。
本文將詳解優酷IPv6技術改造實踐，包括遇到的實際問題、技術解法，希望對大家有借鑑。
1.背景
Internet 在形成及演化的初期，經歷了一個紛繁複雜的過程，隨著網絡技術的發展，以IP 協議為核心，包括：地址格式、數據封裝及數據轉發等Internet網絡結構的基本框架，已經穩定 運行30多年不曾改變。5G來臨的時候，Internet的現有結構無法快速適應用戶及上層應用需求。主要體現在以下幾點：
1）IPv4 資源枯竭：海外大量購買資源，私網地址僅可支撐三年；
2）IPv6 用戶增長：海外美國50%，印度、歐洲20%；
3）Apple 審核：2016 年6月起，Appstore 就開啟了IPv6 only 審核；
4）商業競爭態勢：Google、Facebook 已覆蓋50% IPv6 終端，IPv6 雲產品發佈；
5）戰略意義：由於IPv4 報文的限制，使得域名根服務器的總數有限制。IPv6 出現以後，這個限制被打破，可寫入更多的根服務器地址。目前，全球已完成25 臺IPv6 根服務器架設，中國部署了4臺，打破了中國過去沒有根服務器的困境。
（圖 全球 IPv6 根服務器分佈）
2.目標階段
優酷IPv6 項目將分成二步走，包括IPv4/IPv6 雙棧階段，以及內外網IPv6-only 階段。
1）IPv4/IPv6 雙棧改造：實現應用快速對外服務，以Web/APP 請求服務為核心，滿足IPv6生態發展的需求，並且以外網拉動應用的不同需求。爬蟲、郵箱、DB、存儲等直接交互，需要內外網服務器採用IPv4/IPv6 雙棧能力，整網雙棧交付；
2）IPv6 Only：當超過50%應用逐步遷移到IPv6 後，新應用採用IPv6 准入，遺留一些老舊應用繼續採用IPv4 服務，內網採用4over6 進行封裝。相對雙棧而言，IPv6 only 成本更低，查錶轉發速度更快，只需維護一套協議棧，全面開啟IPv6 Only 時代。
3.實施週期
優酷2018 年6月開始，實施了IPv6 的全業務改造，完成客戶端及服務端改造，實現應用快速對外服務。2018 年底，實現全量部署上線，總耗時6個月。所以，與優酷同等用戶規模和服務體量的企業，基本上6個月甚至更短的時間就可以完成整體IPv6 的改造。
（圖 優酷 IPv6 改造計劃）
遇到的問題點及解法
IPv6 整個改造過程中可能會遇到的幾個典型問題和解決方法，簡單的總結如下：
1.沒有IPv6環境
眾所周知，一般應用從開發到上線，至少要經過開發測試環境、預發環境、Beta 環境，最後上正式環境。一開始，基礎環境還沒有具備的時候，我們使用IPv6 over IPv4 鏈路VPN 的方式連入測試環境 ，需要PC/客戶端加證書改Hosts，移動端無法改Hosts 的，需要root 越獄。然後，我們加強了基礎網絡和IT合作，在多個阿里園區部署多個IPv6 的接入環境，打通IPv6 出口，打通辦公網和機房的IPv6 鏈路，實現慢慢外網IPv6，日常環境通、預發通、正式通，慢慢使業務能夠測試逐步提升到IPv4 相同的測試體驗，通過域名劫持等手段，跳過了Hosts 配置的尷尬，達到標準的測試效率。
2.OS網絡模塊問題
需要讓容器支持從請求頭部獲取IPv6 地址，那麼就需要把用戶IP一級一級透傳過來，就需要在各級的服務器上升級網絡模塊，擴展報文頭部。例如TOA 模塊，TOA 模塊是為了讓後端的Real Server 能夠看到真實的ClientIP 而不是LVS的DIP。同時，Tengine/Nginx 等應用需要 升級到支持IPv6的版本（支持新TOA模塊等），由於歷史原因存在各種老版本無法升級，導致升級受阻。我們通過推動應用接入統一接入改造，避免自行升級網絡模塊帶來的風險。
通過老版本應用的升級，去Nginx的方式，統一升級安裝Tengine-proxy（安裝在ECS 測試 機器或宿主機上都可以），為了能減少業務改造工作量，在接入層架構我們做了大量的改造。
3.地址庫特殊需求
首先，統一IP 地址庫，要求所有業務必須統一使用IP 地址庫。其次，協調集團地址庫生產方，滿足優酷使用場景需求，使統一過程中業務改造工作量減少。再次，對於廣告等必須要使用行業統一地址庫的場景，我們也制定了多套方案去解決。
兜底方案：將廣協地址庫中的地區編碼，加入到集團地址庫中，使集團庫具備行業庫的能力，在行業庫沒有完全產出之前，廣告業務可以臨時使用集團地址庫進行改造和測試，保障業務不受損。
長期方案：主動出擊，聯繫廣協等行業協會，加快產出IPv6 地址庫，並且主動無償提供阿里集團地址庫數據，更加快了整個廣協會員單位的改造進度。
4.MTU問題
IPv4 時代，中間網絡三層設備會進行分片，所以一般設置為1500 的最大值，以降低網絡開銷。但IPv6 協議為了減輕中間網絡層設備繁雜度及成本，中間設備不再分片，由兩端的協商指定。導致默認mtu1500 的情況下，中間設備出現大量丟包，原因是NAT 轉換，TCP Option 等額外疊加，實際超過1500。開啟SYN Proxy，通過MSS 與端進行協商，調整MTU 為最小值1280。發現中間層MTU 小於1280 時，進行網絡報障等辦法。
5.客戶端是否IPv6，如何驗證
這是一個很現實的問題，我的網絡已經是IPv6 了，業務也能正常運行，但怎麼確認網絡是運行在IPv6 上，沒有被降級呢？主要有以下兩個手段：
1）抓取客戶端日誌：這也是最笨太最準確的手段。具體抓日誌的方法有很多，就不再重複介紹了；
2）業務改造，加入網絡檢測能力：將優酷客戶端當做網絡測試的工具。
6.協議回落問題
（圖 協議回落）
7.CDN灰度問題
CDN域名由阿里雲等CDN 服務提供商進行調度控制，用戶請求鏈路和業務服務是不一樣的，導致業務服務是IPv6，CDN 走的是IPv4；也可能CDN是IPv6，業務服務是IPv4，無法和業務統一灰度範圍。
解決方案：使用HTTPDNS 能力，讓CDN域名和業務域名共同管理，同步開啟灰度的地域和運營商。同時，增加IPv6專屬CDN 域名，APP 側通過業務側增加業務邏輯，分別下發不同的域名來實現同一灰度節奏能力。當業務服務返回客戶端的出口IP是IPv6 時，調用IPv6的CDN 域名；當業務服務返回客戶端的出口IP 是IPv4時，調用IPv4CDN域名。
架構設計
（圖 優酷 IPv6 改造架構圖）
從客戶端到服務端，所有涉及到的設備、網絡、APP、服務器、業務等都是改造範圍。
1）用戶端的網絡，包括移動網絡和局域網：這部分移動網絡依賴運營商，目前三大運營商的4G IPv6 支持率>70%，固定寬帶內部局域網等總體支持率不足3成，家庭路由器等也需要升級；
2）用戶終端設備：依賴手機等終端設備廠家更新升級固件，小品牌的終端就聽天由命了。部分安卓手機需要分配到64 段的IPv6 才能正常連接上IPv6 的Wi-Fi；
3）OS/瀏覽器：依賴蘋果、谷歌等的更新節奏，需要客戶端OS及瀏覽器都更新至最新版本，老OS 基本不支持；
4）客戶端APP/PC 端網頁：網絡底層包需要支持IPv6 以及降級能力，實施方案中詳細說明；
5）HTTPDNS：基於一定的策略對支持雙棧網絡的客戶端下發IPv6 地址，需HTTPDNS 端改造支持；
6）Local DNS：需要DNS 支持IPv6 解析，同時域名解析記錄中添AAAA 記錄；
7）網絡鏈路：運營商需要支持 IPv6，包括用戶端的出口網絡和服務端的機房出口，網絡路由等；
8）LVS：所有服務的出口，需要支持IPv6，將請求轉發至RS（反向代理服務）
9）反向代理層：將請求轉發至具體業務服務器，並帶上客戶端IPv6 地址；
10）業務服務：請看下一節。
詳細實施步驟
整個改造過程包括：客戶端APP及PC/H5 端/業務服務端的改造，安全測試及灰度保障能力。
1.客戶端APP
1）更新網絡底層包：涉及到集團二方包或者第三方網絡庫的，需要升級到最新版本。第三方網絡庫需要確認具備IPv6 能力，否則需要重新選擇其它網絡庫；
2）升級IP地址庫：端上集成有IP地址庫的，需要升級到包含IPv6 記錄的IP 地址庫；
3）升級HTTPDNS 服務庫：使用HTTPDNS 服務的，需要確認支持AAAA 記錄的下發；使用Local DNS 解析的，需要改造實現DNS 服務請求參數中添加AAAA 記錄解析的標識；
4）改造支持降級能力：使用三方庫已經具備IPv6 鏈路質量不佳時自動降級IPv4 能力的，可以不改造。否則，需要業務或者架構側進行IPv6 網絡質量的判斷，並實現降級功能；
5）探測埋點改造：弱網、DNS 耗時的情況下，探測能否正常，IPv6下埋點是否正常上報；
6）測試手法：所有功能需要在IPv4 only，IPv6/IPv4 雙棧測試通過。IPv6 only 有條件時也需要測試通過。
2.業務服務端/PC端/H5端
1）IP 地址庫使用：是否有用到地址庫，對用戶IP進行地域來源等判斷。有的話需要升級到IPv6 地址庫，並更新調用方法；
2）IP 地址格式判斷：是否對用戶IP 進行驗證，有的話，需要加入IPv6 地址格式的正則表達式判斷；
3）IP 地址保存：是否對IP有存庫等保存操作，需要修改相應字段的長度，IPv6 長於IPv4， MySQL建議字段類型VARBINARY(16)；
4）依賴鏈路上的修改：是否會將IP 作為接口參數傳遞給下游依賴業務。有的話，下游依賴業務也需要改造；
5）客戶端IP 地址的取得方式：如果從客戶端請求的頭部獲取，那麼在雙棧環境中，同一請求，你只能獲取到IPv4 和IPv6 地址中的一個，不可能兩個都獲取。如果是通過請求正文中的某個字段，把客戶端地址傳上來的，那麼，你需要考慮是否需要獲取客戶端的v4 和v6 的所有地址；
6）日誌：當用了第三方的採集工具，如果採集工具不支持IPv6 的話，那麼採集上來的數據會和服務端的請求日誌無法對齊，產生GAP。所以第三方數據產品等都需要能夠支持用戶IPv6 數據的採集；
7）監控：存在用戶IP 作為判斷條件/統計條件的監控配置時，需要改造；
8）大數據統計：存在用戶IP 作為判斷條件/統計條件的內容時，需要業務改造。
3.安全，測試及灰度保障
主要包括上線前的測試保障及上線後的灰度引流能力。
1）測試保障：抓取客戶端日誌；客戶端業務改造，加入網絡檢測能力；客戶端增加IPv6 鏈路日誌，服務端日誌工具支持對IPv6客戶端地址進行分析彙總；IPv6流量壓力測試能力；模擬IPv6 網絡限速，延遲增加能力。
2）灰度引流能力包括兩種方式：
HTTPDNS 方式：基於用戶設備的白名單；基於地域+運營商+百分比+用戶設備白名單；基於APP 版本的全量百分比。
LocalDNS(ADNS)方式：ADNS 新開發並上線了一個能力，支持一個域名下配置多CNAME 解析功能，並且每條解釋都可以配置權重，通過修改IDNS 的CNAME 權重配置來達到比例控制。同時加上自有的線路和運營商的選擇能力，滿足地域級的灰度需求。
3）自動化能力：我們開發了自動化的灰度系統，根據起始參數和灰度目標，自動規劃灰度比和時間節奏，實現完全自動化的灰度引流。監控預警+自動回滾能力，邊喝咖啡邊看灰度量，就是這麼簡單。
小結
IPv6還處於過渡期，目前是IPv4/IPv6雙棧發展階段，需要技術和產品特別關注在雙棧環境下才會出現的問題，而這些問題幾乎沒有資料可參考，非常考驗運維團隊的應變能力。以下是我的一些建議：
IPv6地址還在不斷分配中，IPv6地址庫的建設將是一項長期工程，當IPv6歸屬地與IPv4歸屬地存在偏差時，優先信任哪一邊，需要結合業務特點做判斷；
IPv6建設中最大的投入是監控能力的改造，要讓業務監控全部支持IPv6，否則將無法發現IPv6的網絡問題。在雙棧環境中，不要用總量模式觀察，要在各自的協議棧中觀察；
雙棧特有的IPv6回落IPv4的降級能力，Web端業務不要過度的依賴瀏覽器的能力，因為有些時候它並不靠譜。可以常識拆分業務域名，判斷用戶環境及網絡質量，不同的環境給出不同的域名，來實現降級能力；
雙棧環境下，一個完整的業務流程，可能一部分走IPv4，一部分走IPv6。當業務出現問題時，需要足夠的埋點用來定位原因，因為有些場景下很難再現問題；
IPv6的改造，更多是面向5G為未來的業務場景佈局，當下的用戶體驗並不明顯，所以不需要向產品強調性價比。
閱讀更多 CSDN 的文章
關鍵字: 美好，一直在身邊 2019科技之光 我的第一部5G手機
