本文授權轉載，作者：Peak（公眾號：MrPeakTech）

蘋果從2016年6月1號開始，強制所有app必須支持純IPv6的網絡環境。這項舉措將對IPv6的普及起到一定的推動作用，也體現了Apple作為國際大廠的擔當。

大部分App由於使用的是高層API，並不需要做任何的更改就能自然度過這次IPv6的考核，只是對於少部分手寫IPv4地址連server的同學，生活有一點點影響。

請好好學習TCP/IP協議

每次蘋果對技術的推動，都是一次很好的充電學習機會。這裡Peak君拜托大家務必好好學習網絡協議（深鞠躬）。

之前Apple默認開啟ATS，推動HTTPS的使用，ATS可以手動關閉，但據說到2017年所有的HTTP流量都必須帶S了，不然無法通過審核。這很make sense，我知道到HTTPS部署已經變得相當簡易的今天，還有很多很多的App在僥幸走HTTP。

再後來有Apple將APN悄悄過渡到了HTTP2.0通道，HTTP2.0慢慢地走入尋常百姓家。

這次IPv6的推進，是一次對IP layer的復習機會。大部分人包括我自己對HTTP，TCP相對熟悉一些，IP層由於項目當中接觸少，更多還是停留在大學學習的基礎概念上。這次趁著Apple的這股東風，好好翻了幾篇RFC文檔，畫了一張下面的圖，也同時把公司App的socket遷移方案理順了。這當中最重要的兩個概念是DNS64和NAT64。

DNS64

DNS64說白了是用來幫助host獲取IPv6地址的，傳統的DNS服務器可以把域名轉換成IPv4地址，但我們的iPhone設備如果處於IPv6環境下，只能去獲取IPv6的地址。DNS64就像一個中間代理，把傳統服務器返回的IPv4地址通過特殊的映射方式轉換成一個看著像IPv6地址的地址（IPv4的核，IPv6的殼），轉換其實很簡單，用公式可以這樣表達：

64:ff9b::IPv4 = IPv6

NAT64

DNS64幫助拿到IPv6的地址後，接下來就是NAT64登場，幫助IPv6的Packet順利接入IPv4的公網當中。IPv4的公網環境路由器只認識IPv4的地址，所有這裡當然也需要一個中間設備來做協議轉換。NAT64就扮演這個角色。

我在上面的流程圖當中已經比較清晰的畫出了NAT64的工作方式。其實就是內部同時有IPv4和IPv6的網卡，IPv4的網卡配了一個IPv4的地址池子，再通過端口映射的方式將IPv4地址和IPv6地址對應，同時再做一些協議的轉換，畢竟IPv4和IPv6的header完全不同。說白了就是一個內部路由的功能，將奔向IPv4公網的包做了地址和協議的轉換。

一個深坑

博主公司所做的App就屬於Apple重點點名，手寫IPv4地址的典型。socket遷移過程當中踩了一個不大不小的坑，在嘗試使用DNS64服務器將IPv4地址轉換成IPv6地址的過程當中，發現數字端口號會導致奇異bug。

getaddrinfo(ipv4_str, @(port).stringValue.UTF8String, &hints, &res0);

我們一般使用getaddrinfo函數來解析host，如果端口號部分的入參是數字類型，會導致返回的結果裡端口號被修改，當然socket就沒法連成功啦。修改辦法是在DNS query結果裡手動將端口號再改回。

另一個辦法是跳過DNS查詢，直接自己將IPv4的地址轉化成IPv6的地址。類似這樣：

const char* ipv4mapped_str ="64:ff9b::121.43.xx.xxx";

視頻教程

加上之前錄制的Xcode視頻教程，這是第二篇視頻博客，應該也是最後一篇。視頻教程確實不太適合做零散的技術博客分享，而更適合系統性的技術教程。

一是因為廣告長到令人發指，90s的廣告足以磨掉大部分人的耐心，何況等待的是一篇並不怎麼有趣的技術教程。

二是因為視頻不如文字精煉，容易把話說得又臭又長，我個人看別人技術博客也習慣一目十行的搜索感興趣要點，視頻只能靠拖進度條，遠不如文字大綱了然。

至此也是一次有趣的嘗試，收獲了iMovie，keynote等高端技能，以後說不定哪天能派上更有價值的用場。