優酷IPv6改造紀實：視訊行業首家擁抱下一代網路技術

技術小能手發表於2019-01-30

640?wx_fmt=png

阿里妹導讀：2018年雙11前，優酷開啟了IPv6的大門。9月份PC端業務開啟灰度，迎來首位IPv6 VIP使用者後，優酷移動客戶端也馬不停蹄地加入灰度大軍。從0到1，花了幾個月；從10到1000，花了幾天；從1000到50W，只要幾小時。IPv6灰度的馬車一旦起跑，將再也不需要停止。

IPV6在優酷，技術驅動產品的驗證

2018 世界盃期間，我們驗證了IPv6的改造方案和技術可行性，雙11期間優酷PC端和App在國內教育網及一線重點城市都有一定比例的IPV6使用者，享受著高清直播點播服務，體驗著一條剛剛建完的高速大道卻沒有幾輛車的快感。專屬的使用者身份標識，專屬的客戶端網路檢測能力，專屬的會員卡，專屬的紅包，這一切可能不知不覺中就屬於你了。

隨著雙11後阿里集團幾大應用相繼開啟灰度，我們迎來了中國首次IPv6大規模應用上線，優酷不僅能跑而且跑得快。這象徵著優酷大家庭通過雙11、世界盃等的洗禮，已經擁有了一支能戰敢戰，戰則必勝的技術團隊。IPV6不是一個人的功勞，是所有技術人努力的結晶。

今天，我們採用專訪問答的形式，帶你走進優酷IPV6從立項到實踐的全過程。優酷IPV6改造專案，由優酷應用架構吳靈曉（蓋優）負責。應用架構部主要負責整體架構設計實施優化工作，探索從DEVOPS向AIOPS轉變，智慧運維、深度學習、大資料分析、智慧機器人等新技術也有大量的成熟運用。

立項

Q:IPV4和IPV6有哪些區別呢？

安全：IPv6把IPSec作為必備協議，保證了網路層端到端通訊的完整性和機密性。
業務無限擴充套件：不受地址短缺的影響。
個性化服務：流標籤的使用讓我們可以為資料包所屬型別提供個性化的網路服務，並有效保障相關業務的服務質量。
減少開銷：報頭格式大大簡化，從而有效減少路由器或交換機對報頭的處理開銷。
萬物互聯：大容量的地址空間能夠真正地實現無狀態地址自動配置。

Q:為什麼想到要做IPV6改造？

第一，IPV4環境惡化：

640?wx_fmt=png

第二，政策驅動：2017-11-26 中共中央辦公廳國務院辦公廳印發《推進網際網路協議第六版（IPv6）規模部署行動計劃》。2018-05-03 工業和資訊化部關於貫徹落實《推進網際網路協議第六版（IPv6）規模部署行動計劃》的通知。

第三，技術驅動產品業務：IPv6在客戶端-服務端-阿里雲CDN-優酷直播點播業務的全線貫通應用，優酷完成了新網路技術到產品應用的實現，改寫技術服務產品，服務倒逼技術升級的局面，使得IPV6網路技術能夠支撐優酷今後幾年甚至十幾年的業務需求，5G、P2P、人工智慧、AI、物聯網等，在網路技術上已經沒有障礙。

第四，天時地利俱備，差人和：政策支援，集團推動，技術展現為一體，這麼好的機會，不能錯過。

擁有一群打過雙11，打過春晚，打過世界盃的戰友們，沒有什麼事是做不好的。

Q:決定做之後，怎麼列的計劃呢？目標是什麼？

這還真是前無古人，後有來者。誰都沒有經驗，沒有相似可參照的案例，涉及團隊眾多。

各種調查與討論，以及集團相關的計劃安排，整個IPV6專案將分成三步走，包括外網階段，使用者端與接入層支援 v6、內網階段，服務端內部v4/v6雙棧、以及內外網IPv6-only 。

外網改造：實現應用快速對外服務，以web/App請求服務為核心，滿足IPv6生態發展的需求，並且以外網拉動應用的不同需求；
內網改造：應用逐漸擴大到爬蟲、郵箱、DB、儲存等V6直接互動，需要內網伺服器部分採用IPv6，需要整網雙棧交付；
IPv6 Only：當超過50%應用逐步遷移到IPv6後，新應用預設採用v6開發，遺留一些老舊應用、使用者繼續採用IPv4服務，內網採用4over6進行封裝。相對雙棧而言，IPv6 only成本更低，查錶轉發速度更快，只需維護一套協議棧。

阿里網路演進從外到內，從使用者到應用逐層迭代，儘量做到成本最低，效率最高。

640?wx_fmt=png

核心目標

18自然年底，實現全量灰度。還是那句話，要麼不做，要做就做最好。評估後全量灰度目標雖然風險偏大，但努力一把還是可控的。

640?wx_fmt=png

過程

Q:對研發同學來說，需要關心哪些？怎麼確認哪些要改哪些不要改？

對研發的同學來說，只需要關心客戶端APP/PC端網頁及服務端的改造。

客戶端基本上涉及到基礎網路包NetworkSDK等集團二方包的升級。使用httpdns解析的，需要改造實現客戶端網路的判斷和接收httpdns服務端下發的AAAA記錄；使用localdns解析的，需要改造實現DNS服務請求引數中新增AAAA記錄解析的標識。使用三方庫的，要升級至最新版並確認支援IPV6，不支援的需要考慮更換三方庫。

IP 欄位是否正確
extra : {'firstIp': 'xxxxx'} 是否正確攜帶
探測埋點
弱網、DNS耗時的情況下，探測能否正常
網路切換特別頻繁的場景

PC端/服務端要關心的就多一點了，只要你的業務處理中有以下任意一點的，都是要做業務改造的，也就是寫Bug。

640?wx_fmt=png

1.IP地址庫使用：是否有用到地址庫，對使用者IP進行地域來源等判斷。有的話需要升級到IPV6地址庫，並更新呼叫方法。

2.IP地址格式判斷：是否對使用者IP進行驗證，有的話需要加入IPV6地址格式的正規表示式判斷。

3.IP地址儲存：是否對IP有存庫等儲存操作，需要修改相應欄位的長度，IPV6長於IPV4，MySQL 建議欄位型別 VARBINARY(16)。

4.依賴鏈路上的修改：是否會將IP作為介面引數傳遞給下游依賴業務。有的話，下游依賴業務也需要改造。

5.客戶端IP地址的取得方式：是否從客戶端請求的頭部獲取。是的話，那麼在雙棧環境中，同一請求，你只能獲取到V4和V6地址中的一個，不可能兩個都獲取。

如果是通過請求正文中的某個欄位，把客戶端地址傳上來的，那麼，你需要考慮是否需要獲取客戶端的v4v6的所有地址。是的話，那麼就需要擴充套件請求欄位，將v4,v6分成兩個欄位提交，同時服務端也需要做接收改造處理。

6.日誌，資料的採集等資料產品的改造：是否用了第三方的採集工具，如果採集工具不支援IPV6的話，那麼採集上來的資料會和服務端的請求日誌無法對齊，產生GAP。類似還包括廣告投放與監測等分別屬於多方的業務場景。

從業務上來看，需要區分IPv4使用者請求和IPv6使用者請求，並分開進行資料分析。所以資料產品資料儲存等都需要能夠支援使用者IPv6資料的採集。

7.安全產品：內容安全：文字安全過濾，七層流量清洗等等，安全產品改造，業務升級二方包/客戶端。

8.監控：以使用者IP作為判斷條件/統計條件的監控配置，需要改造。

9.大資料統計：以使用者IP作為判斷條件/統計條件的內容，需要業務改造。

10.依賴服務：原有阿里雲產品需要更新為支援IPV6的產品，VPC，ECS，OSS，CDN等都是更換範圍。

Q:改造中主要遇到哪些問題呢？

1.沒有IPV6環境：辦公網不具備IPv6接入環境，阻塞業務開發；內網尚未改造，無法打通日常（測試）環境。

一開始，基礎環境還沒有具備的時候，我們使用IPV6 over ipv4鏈路VPN的方式連入測試環境，需要PC/客戶端加證書改hosts，移動端無法改hosts的，需要root，越獄，各種凌亂，但至少業務測試可以開始啟動。

然後，我們加強了基礎網路和IT合作，在多個園區部署多個IPV6的接入環境，打通IPV6出口，打通辦公網和機房的IPV6鏈路，慢慢實現外網IPV6，日常環境通，預發通，正式通，慢慢使業務能夠測試逐步提升到IPV4相同的測試體驗，通過域名劫持等手段，跳過了Hosts配置的尷尬，達到標準的測試效率。

2.OS網路模組問題：需要讓容器支援從請求頭部獲取IPV6地址，那麼就需要把使用者IP一級一級透傳過來，就需要在各級的伺服器上升級網路模組，擴充套件報文頭部。例如toa模組，toa模組是為了讓後端的realserver能夠看到真實的clientip而不是lvs的dip。

同時，tengine/nginx等應用需要升級到支援IPV6的版本（支援新toa模組等），由於歷史原因存在各種老版本無法升級，導致升級受阻。

我們通過推動應用接入統一接入改造，避免自行升級網路模組帶來的風險。

通過老版本應用的升級，去nginx的方式，統一升級安裝tengine-proxy（安裝在ecs測試機器或宿主機上都可以），為了能減少業務改造工作量，在接入層架構我們做了大量的改造。

3.地址庫特殊需求：優酷有自己的地域編碼，優酷廣告業務還有廣協提供的地域編碼，還有業務使用集團的地址庫，總之地址庫各種不統一。

首先，統一地址庫，要求所有業務必須統一使用集團地址庫。並且協調集團地址庫生產方，滿足優酷使用場景需求，使統一過程中業務改造工作量減少。

再次，對於廣告等必須要使用行業統一地址庫的場景，我們也制定了多套方案去解決。

兜底方案：將廣協地址庫中的地區編碼，加入到集團地址庫中，使集團庫具備行業庫的能力，在行業庫沒有完全產出之前，廣告業務可以臨時使用集團地址庫進行改造和測試，保障業務不受損。

後續方案：主動出擊，聯絡廣協等行業協會，加快產出IPV6地址庫，並且主動無償提供集團地址庫資料，體驗了阿里的企業責任，更加快了整個行業的改造進度。最終行業協會從立項到產出地址庫的時間，只用了不到1個月，而集團收集這些資料花費了一年半的時間。

4.MTU問題：IPV4時代，中間網路三層裝置會進行分片，所以一般設定為1500的最大值，以降低網路開銷。但IPV6協議為了減輕中間網路層裝置繁雜度及成本，中間裝置不再分片，由兩端的協商指定。

導致預設mtu1500的情況下，中間裝置出現大量丟包，原因是NAT轉換，TCP Option等額外疊加，實際超過1500。

短期解決辦法是，開啟SYN Proxy，通過MSS與端進行協商。調整MTU為最小值1280。發現中間層MTU小於1280時，進行網路報障等辦法。

5.客戶端是否IPV6，如何驗證問題：這是一個很現實的問題，我的網路已經是IPV6了，業務也能正常執行，但怎麼確認網路是執行在IPV6上，沒有被降級呢？

主要有以下兩個手段：

1）抓取客戶端日誌：這也是最笨最準確的手段，具體抓日誌的方法有很多，就不再重複介紹了。

2）業務改造，加入網路檢測能力，將優酷客戶端當做網路測試的工具。

640?wx_fmt=jpeg

6.協議回落問題

640?wx_fmt=png

7.安全問題：有運營商的出口能力，黑洞能力進展緩慢或者暫不具備。有安全基礎產品的存在繫結域名後就能直接訪問任意服務，灰度放大。

8.CDN灰度問題：CDN域名由阿里雲進行排程控制，無法和業務同一灰度範圍。增加IPV6專屬CDN域名，通過業務側增加業務邏輯，分別下發不同的域名來實現同一灰度節奏能力。

結果

Q:灰度是如何操作執行的？

通過httpdns方式，提供兩種灰度能力：

基於使用者裝置的白名單
基於地域+運營商+百分比+使用者裝置白名單
基於app版本的全量百分比

通過localdns(ADNS)，提供一種能力：ADNS新開發並上線了一個能力，支援一個域名下配置多CNAME解析功能，並且每條解釋都可以配置權重，通過修改IDNS的cname權重配置來達到比例控制。同時加上自有的線路和運營商的選擇能力，滿足地域級的灰度需求。

我們也開發了自動化的灰度系統，根據起始引數和灰度目標，自動安排灰度比例和時間節奏，實現完全自動化的灰度引流。監控預警+自動回滾能力，邊喝咖啡邊看灰度量，就是這麼實現的。

Q:如何確認業務是否正常呢？

業務層：業務配置的IPV6監控平臺，IPV4與IPV6監控曲線對比。

接入層：IPV6流量大盤，分域名，分介面展示成功量，成功率及RT。

資料平臺：業務指標的大資料分析及報表展示。

基礎網路：省份運營商的鏈路成功率，IPV6使用者佔比，鏈路質量鏈路延遲，IPV6降級IPV4比例等資料。

有了這些，還怕業務有問題嗎？

我們知道，視訊的生命週期，是從採集到製作到生產，最後到視訊的呈現，這裡有很多環節，每個環節上都有非常專業的團隊來保障。在製作環節會做調音、調色，在生產環節會做編碼壓縮，在呈現環節的會做解碼和後處理，每個環節獨立來看都做得不錯。但如果我們站在鏈條的兩端來看，製作側和呈現側看到的視訊效果存在比較大的差異。

但是今天，我們的場景發生了改變，我們有形形色色的終端，有手機、Pad、PC、電視、投影，呈現場景已經不可控的，所以今天我們看到的畫面，已經不是我們的導演原本希望呈現的畫面了。這是今天我們想去解決的問題，當然整個鏈條上的聯動不是靠優酷一家可以解決的，因此我們需要更多產業鏈上的朋友和我們一起來解決這個問題。

當每個人都是導演、演員、編輯、美工的時候，缺少的是什麼？

空間容量，沒有創作空間，沒有辦公空間，沒有消費空間，可持續增量空間。這些不全都是IPV4的錯，但確實IPV4是瓶頸，當一個人有上百個裝置的時候，IPV4肯定滿足不了。

有了IPV6，再多裝置都OK，每個裝置都能互聯互通，萬物互聯。

那麼，智慧化的後期製作變得可能。

640?wx_fmt=png