如何應對蘋果app 的ipv6 時代？
阿新 • • 發佈：2017-05-12
WeTest導讀
WWDC2015蘋果宣布在ios9支持純IPv6的網絡服務，並且要求2016年提交到app store的應用必須兼容純IPv6的網絡，要求適配的系統版本是ios9以上（包括ios9）。
一、背景介紹
1、你了解IPv6嗎？
IPv6是Internet Protocol Version 6的縮寫，簡單的概括IPv6就是現行的互聯網協議（IPV4）的下一代IP協議。IPv6由128位二進制數組成，可提供龐大的IP地址資源，足以讓地球上每個生物乃至每厘米都能被分配到一個或多個IP地址。將這128位的地址按每16位劃分為一個段，將每個段轉換成十六進制數字，並用冒號隔開。
IPv4地址示例：192.168.191.1
IPv6地址示例：2001:0db8:85a3:08d3:1319:8a2e:0370:7344
2、為什麽要接入IPv6？
目前互聯網廣泛應用的IPv4技術，理論上IPv4是一個32位的二進制數的地址，可編址1600萬個網絡、40億臺主機。但在采用了A、B、C三類編址方式後，可用的網絡地址和主機地址數目大打折扣，歐美資本主義列強掌握著核心技術，留給我國的就更少了。
二、改造方案
要想使應用完全支持IPV6的環境要做的太多了，從協議到硬件，要做一次徹底的大調整。不但客戶端要做ipv6的改造，服務器也要適配ipv6.主要有一下四種對應關系，必須做好以下每一種。
IPv4->IPv4
IPv4->IPv6
IPv6->IPv4
IPv6->IPv6
要做到IPv6和IPv4完全兼容需要做很大的修改，最簡單的協議上要兼容128位的IP地址，路由器，服務器等相關硬件也要升級。應蘋果公司的要求，本次改造我們只關註客戶端從IPv6的網絡環境訪問IPv4的資源。那麽問題來了，現在我們大部分後臺服務器都是使用IPv4接入的，我們要如何做兼容？幸好，從一開始設計IPv6就考慮到了向後兼容的問題，運營商會提供一個中間節點，使用DNS64/NAT64等技術，負責協議的轉換，打通IPv6和IPv4之間的鏈路。(IPv6和IPv4互通技術有很多，這裏只討論apple要求的技術方案DNS64/NAT64)我們要走的服務器必須支持nat/nat64的環境，搭建的wifi環境本來就支持了，我們不改上層的，只改底層的是影響最小。
1、NAT64與DNS64技術
NAT64是一種有狀態的網絡地址與協議轉換技術，一般只支持通過IPv6網絡側用戶發起連接訪問IPv4側網絡資源。但NAT64也支持通過手工配置靜態映射關系，實現IPv4網絡主動發起連接訪問IPv6網絡。NAT64可實現TCP、UDP、ICMP協議下的IPv6與IPv4網絡地址和協議轉換。
DNS64則主要是配合NAT64工作，上海證券通主要是將DNS查詢信息中的A記錄（IPv4地址）合成到AAAA記錄（IPv6地址）中，返回合成的AAAA記錄用戶給IPv6側用戶。DNS64也解決了NAT-PT中的DNS-ALG存在的缺陷。NAT64一般與DNS64協同工作，而不需要在IPv6客戶端或IPv4服務器端做任何修改。NAT64解決了NAT-PT中的大部分缺陷，同時配合DNS64的協同工作，無需像NAT-PT中的DNS-ALG等。
2、舉個栗子
這裏大概描述一下NAT64的工作流程。
（1）IPv6主機發起www.ipv6bbs.cn的AAAA域名解析到DNS64(主機配置的DNS地址是DNS64)
（2）DNS64觸發AAAA到DNS AAAA中查詢;
（3）DNS AAAA返回NULL的信息到DNS64;
（4）DNS64然後觸發A的申請到DNS A中查詢;
（5）DNS A返回www.ipv6bbs.cn的A記錄(11.111.11.11);
（6）DNS64合成IPv6地址(64:ff9b:11.111.11.11)，返回AAAA response給IPv6主機;
（7）IPv6主機發起目的地址為64:ff9b:11.111.11.11的IPv6數據包;由於NAT64在IPv6域內通告配置的IPv6 Prefix，因此這個數據包轉發到NAT64設備上;
（8）NAT64執行地址轉換和協議轉換，目的地址轉換為192.0.2.1，源地址根據地址狀態轉換(64:ff9b:11.111.11.11,1500)->(11.111.11.11,2000);在IPv4域內路由到IPv4 server;
（9）數據包返回，目的地址和端口為11.111.11.11,2000;
按照NAT64的規則，客戶端如果沒有做DNS域名解析的話（微信依賴的是自己實現的NEWDNS），客戶端就需要完成DNS64的工作。這裏的關鍵點是，發現網絡是IPv6-only的NAT64網絡的情況下，我們可以自己補充上前綴64:ff9b::/96，然後進行正常的訪問。然而這裏客戶端能獲取的信息量一般都是很有限的。
註：AAAA記錄(AAAA record)是用來將域名解析到IPv6地址的DNS記錄。用戶可以將一個域名解析到IPv6地址上，也可以將子域名解析到IPv6地址上。
3、開發同學幹了什麽？
Xplaform改造的要點主要有一下4個：
a.換用兼容IPv4及IPv6的API，例如:getaddrinfo,yaoli同學在測試過程中發現，ios9系統在IPv6-only的環境下，返回會的地址信息結構體中port為0，所以這裏需要重新賦值端口號再進行聯網。
b.判斷當前客戶端是處於IPv4-only、IPv6-only還是IPv4和IPv6並存的環境，然後分別使用不同的網絡API，可以參考http://km.oa.com/articles/show/270667。
c.SCNetworkReachabilityCreateWithAddress這個方法最好使用探測域名的方式。如果參數填的是0.0.0.0，蘋果文檔說明這返回的結果不保證能真正出外網。這樣就需要其它輔助的手段嘗試是否能出外網了。
d.使用socket及connect進行的聯網操作。
三、客戶端兼容性測試辦法
1、測試環境搭建
後臺不用改，那客戶端要改如何兼容。我們可以先用蘋果給的測試工具，簡單測試。整體原理如下：
其中，在客戶端的改造叫做Xplaform，需要連接mac機創建的NAT64/DNS64的wifi，就是傳說中的IPV6的網絡環境，再通過有線網絡，路由器，訪問到IPv4的資源。就做到IPv6→IPv4的連接。
下面講解一下IPv6wifi網絡環境的搭建。
（1）工具/準備
體驗網有線接口、iMAC(10.11以上的系統)和iOS9（包括iOS9）以上設備
（2）步驟
接好體驗網的網線，然後打開系統設置找到Sharing圖標，如下：
點擊進入，然後按住option按鍵同時用鼠標點擊下圖的“internet-Sharing”。
這時可以看到下方出現了“Create NAT64 Network”可選菜單，把這個選上，如下圖：
之後用手機連上這個共享的wifi熱點，測試對應的網絡功能即可。
測試重點：
1、IPV4和IPV6網絡環境判斷是否正確
2、UDP和TCP的切換是否正確
3、數據線和音視頻的基本功能
四、經典bug分享
【bug描述】移動4G下無法傳文件。
在移動網絡下無法查看電腦和進入wifiphoto，傳文件，問題出現的初期我們馬上切換到wifi下，發現wifi下是可以的，把sim卡換成聯通的，也可以。唯獨移動的網絡下無法傳文件。初步斷定是對網絡的兼容性問題。
【問題排查】
1、查看socket日誌，發現在connection一直失敗。在建立連接階段一直失敗。我們做該需求的目的在於要增加IPV6的客戶端能通過IPV6的網絡訪問到IPV4的資源。因此，在做IPV6的改造中我們做了一個判斷邏輯，判斷當前網絡環境是IPV4 or IPV6。
2、加日誌驗證，我們把socket綁定的ip地址類型打出來，果然：
在移動數據網絡下走了ipv6的通道。可是各大運營商的網絡應該走的是ipv4才對。
3、review代碼。問題就很明顯了，我們梳理了一下選擇ipv6或者ipv4協議棧的判斷邏輯，原來開發判斷到網關是IPv6的網關之後就不再往下判斷，直接建立連接。然而，我們連接上4G網絡環境的時候，移動基站分發的網關是一個ipv6形式網關，它可以兼容ipv6和ipv4兩種ip（開發同學認為是移動公司兼容ipv6的策略，看來移動公司已經走在我們前面了）。
【解決辦法】
我們更改了IPv6和IPv4協議棧的判斷邏輯：
2、繼續判斷網關語法是否是IPv6格式，
3、最後獲取DNS地址，以上都符合IPv6的語法，即為IPv6的網絡，建立socket走IPv6.
4、如果當前網絡是IPv6的環境，我們就對IP進行兼容性改造IPv6=64:ff9b::/96+IPv4。再通過改造後的IP地址建立socket連接。
5、如果IPv6和IPv4都可以走通，我們優先建立IPv4的連接。
【結果檢查】
打印出建立連接的日誌：
從日誌可以看出，手機連接4G之後得到的是IPv4的地址和IPv6格式的網關。
創建socket時，IPv6失敗，走IPv4的網。
【經驗總結】
邏輯和場景是測試的兩個緯度，二者都要兼顧到。
WWDC2015蘋果宣布在ios9支持純IPv6的網絡服務，並且要求2016年提交到app store的應用必須兼容純IPv6的網絡，要求適配的系統版本是ios9以上（包括ios9）。
一、背景介紹
1、你了解IPv6嗎？
IPv6是Internet Protocol Version 6的縮寫，簡單的概括IPv6就是現行的互聯網協議（IPV4）的下一代IP協議。IPv6由128位二進制數組成，可提供龐大的IP地址資源，足以讓地球上每個生物乃至每厘米都能被分配到一個或多個IP地址。將這128位的地址按每16位劃分為一個段，將每個段轉換成十六進制數字，並用冒號隔開。
IPv4地址示例：192.168.191.1
IPv6地址示例：2001:0db8:85a3:08d3:1319:8a2e:0370:7344
2、為什麽要接入IPv6？
目前互聯網廣泛應用的IPv4技術，理論上IPv4是一個32位的二進制數的地址，可編址1600萬個網絡、40億臺主機。但在采用了A、B、C三類編址方式後，可用的網絡地址和主機地址數目大打折扣，歐美資本主義列強掌握著核心技術，留給我國的就更少了。
二、改造方案
要想使應用完全支持IPV6的環境要做的太多了，從協議到硬件，要做一次徹底的大調整。不但客戶端要做ipv6的改造，服務器也要適配ipv6.主要有一下四種對應關系，必須做好以下每一種。
IPv4->IPv4
IPv4->IPv6
IPv6->IPv4
IPv6->IPv6
要做到IPv6和IPv4完全兼容需要做很大的修改，最簡單的協議上要兼容128位的IP地址，路由器，服務器等相關硬件也要升級。應蘋果公司的要求，本次改造我們只關註客戶端從IPv6的網絡環境訪問IPv4的資源。那麽問題來了，現在我們大部分後臺服務器都是使用IPv4接入的，我們要如何做兼容？幸好，從一開始設計IPv6就考慮到了向後兼容的問題，運營商會提供一個中間節點，使用DNS64/NAT64等技術，負責協議的轉換，打通IPv6和IPv4之間的鏈路。(IPv6和IPv4互通技術有很多，這裏只討論apple要求的技術方案DNS64/NAT64)我們要走的服務器必須支持nat/nat64的環境，搭建的wifi環境本來就支持了，我們不改上層的，只改底層的是影響最小。
1、NAT64與DNS64技術
NAT64是一種有狀態的網絡地址與協議轉換技術，一般只支持通過IPv6網絡側用戶發起連接訪問IPv4側網絡資源。但NAT64也支持通過手工配置靜態映射關系，實現IPv4網絡主動發起連接訪問IPv6網絡。NAT64可實現TCP、UDP、ICMP協議下的IPv6與IPv4網絡地址和協議轉換。
DNS64則主要是配合NAT64工作，上海證券通主要是將DNS查詢信息中的A記錄（IPv4地址）合成到AAAA記錄（IPv6地址）中，返回合成的AAAA記錄用戶給IPv6側用戶。DNS64也解決了NAT-PT中的DNS-ALG存在的缺陷。NAT64一般與DNS64協同工作，而不需要在IPv6客戶端或IPv4服務器端做任何修改。NAT64解決了NAT-PT中的大部分缺陷，同時配合DNS64的協同工作，無需像NAT-PT中的DNS-ALG等。
2、舉個栗子
這裏大概描述一下NAT64的工作流程。
（1）IPv6主機發起www.ipv6bbs.cn的AAAA域名解析到DNS64(主機配置的DNS地址是DNS64)
（2）DNS64觸發AAAA到DNS AAAA中查詢;
（3）DNS AAAA返回NULL的信息到DNS64;
（4）DNS64然後觸發A的申請到DNS A中查詢;
（5）DNS A返回www.ipv6bbs.cn的A記錄(11.111.11.11);
（6）DNS64合成IPv6地址(64:ff9b:11.111.11.11)，返回AAAA response給IPv6主機;
（7）IPv6主機發起目的地址為64:ff9b:11.111.11.11的IPv6數據包;由於NAT64在IPv6域內通告配置的IPv6 Prefix，因此這個數據包轉發到NAT64設備上;
（8）NAT64執行地址轉換和協議轉換，目的地址轉換為192.0.2.1，源地址根據地址狀態轉換(64:ff9b:11.111.11.11,1500)->(11.111.11.11,2000);在IPv4域內路由到IPv4 server;
（9）數據包返回，目的地址和端口為11.111.11.11,2000;
（10）NAT64根據已有記錄進行轉換，目的地址轉換為2001:db8::1,源地址為加了IPv6前綴的IPv4 server地址64:ff9b:11.111.11.11，發送到IPv6主機;
按照NAT64的規則，客戶端如果沒有做DNS域名解析的話（微信依賴的是自己實現的NEWDNS），客戶端就需要完成DNS64的工作。這裏的關鍵點是，發現網絡是IPv6-only的NAT64網絡的情況下，我們可以自己補充上前綴64:ff9b::/96，然後進行正常的訪問。然而這裏客戶端能獲取的信息量一般都是很有限的。
註：AAAA記錄(AAAA record)是用來將域名解析到IPv6地址的DNS記錄。用戶可以將一個域名解析到IPv6地址上，也可以將子域名解析到IPv6地址上。
3、開發同學幹了什麽？
Xplaform改造的要點主要有一下4個：
a.換用兼容IPv4及IPv6的API，例如:getaddrinfo,yaoli同學在測試過程中發現，ios9系統在IPv6-only的環境下，返回會的地址信息結構體中port為0，所以這裏需要重新賦值端口號再進行聯網。
b.判斷當前客戶端是處於IPv4-only、IPv6-only還是IPv4和IPv6並存的環境，然後分別使用不同的網絡API，可以參考http://km.oa.com/articles/show/270667。
c.SCNetworkReachabilityCreateWithAddress這個方法最好使用探測域名的方式。如果參數填的是0.0.0.0，蘋果文檔說明這返回的結果不保證能真正出外網。這樣就需要其它輔助的手段嘗試是否能出外網了。
d.使用socket及connect進行的聯網操作。
三、客戶端兼容性測試辦法
1、測試環境搭建
後臺不用改，那客戶端要改如何兼容。我們可以先用蘋果給的測試工具，簡單測試。整體原理如下：
其中，在客戶端的改造叫做Xplaform，需要連接mac機創建的NAT64/DNS64的wifi，就是傳說中的IPV6的網絡環境，再通過有線網絡，路由器，訪問到IPv4的資源。就做到IPv6→IPv4的連接。
下面講解一下IPv6wifi網絡環境的搭建。
（1）工具/準備
體驗網有線接口、iMAC(10.11以上的系統)和iOS9（包括iOS9）以上設備
（2）步驟
接好體驗網的網線，然後打開系統設置找到Sharing圖標，如下：
點擊進入，然後按住option按鍵同時用鼠標點擊下圖的“internet-Sharing”。
這時可以看到下方出現了“Create NAT64 Network”可選菜單，把這個選上，如下圖：
之後用手機連上這個共享的wifi熱點，測試對應的網絡功能即可。
測試重點：
1、IPV4和IPV6網絡環境判斷是否正確
2、UDP和TCP的切換是否正確
3、數據線和音視頻的基本功能
四、經典bug分享
【bug描述】移動4G下無法傳文件。
在移動網絡下無法查看電腦和進入wifiphoto，傳文件，問題出現的初期我們馬上切換到wifi下，發現wifi下是可以的，把sim卡換成聯通的，也可以。唯獨移動的網絡下無法傳文件。初步斷定是對網絡的兼容性問題。
【問題排查】
1、查看socket日誌，發現在connection一直失敗。在建立連接階段一直失敗。我們做該需求的目的在於要增加IPV6的客戶端能通過IPV6的網絡訪問到IPV4的資源。因此，在做IPV6的改造中我們做了一個判斷邏輯，判斷當前網絡環境是IPV4 or IPV6。
2、加日誌驗證，我們把socket綁定的ip地址類型打出來，果然：
在移動數據網絡下走了ipv6的通道。可是各大運營商的網絡應該走的是ipv4才對。
3、review代碼。問題就很明顯了，我們梳理了一下選擇ipv6或者ipv4協議棧的判斷邏輯，原來開發判斷到網關是IPv6的網關之後就不再往下判斷，直接建立連接。然而，我們連接上4G網絡環境的時候，移動基站分發的網關是一個ipv6形式網關，它可以兼容ipv6和ipv4兩種ip（開發同學認為是移動公司兼容ipv6的策略，看來移動公司已經走在我們前面了）。
【解決辦法】
我們更改了IPv6和IPv4協議棧的判斷邏輯：
1、探測環境
2、繼續判斷網關語法是否是IPv6格式，
3、最後獲取DNS地址，以上都符合IPv6的語法，即為IPv6的網絡，建立socket走IPv6.
4、如果當前網絡是IPv6的環境，我們就對IP進行兼容性改造IPv6=64:ff9b::/96+IPv4。再通過改造後的IP地址建立socket連接。
5、如果IPv6和IPv4都可以走通，我們優先建立IPv4的連接。
【結果檢查】
打印出建立連接的日誌：
從日誌可以看出，手機連接4G之後得到的是IPv4的地址和IPv6格式的網關。
創建socket時，IPv6失敗，走IPv4的網。
【經驗總結】
邏輯和場景是測試的兩個緯度，二者都要兼顧到。
如何應對蘋果app 的ipv6 時代？