利用DNS估算IPv6全球采用情況

為了使一臺設備能夠使用恰當命名的互聯(lián)網(wǎng)協(xié)議(IP)與互聯(lián)網(wǎng)上的其他設備進行通信，首先必須為其分配一個唯一的數(shù)字地址。該地址的樣式取決于所使用的IP版本：IPv4還是IPv6。

IPv4于1983年首次部署。它是催生了現(xiàn)代互聯(lián)網(wǎng)的IP版本，并且至今仍然占據(jù)主導地位。IPv6的歷史可以追溯到1998年，但直到最近十年，它才開始獲得巨大的關注——從不到1%上升到30%到40%之間，具體取決于報告方、報告內容和測量方式。

隨著連接設備的增長遠遠超過可用的IPv4地址數(shù)量，并且其成本不斷上升，IPv6提供的更大地址空間本應該使其成為目前的主導協(xié)議。然而，正如我們將看到的，事實并非如此。

Cloudflare多年來一直是IPv6的堅定倡導者，并且我們一直通過Cloudflare Radar密切關注IPv6在互聯(lián)網(wǎng)上的采用情況。Radar已經推出三年了，仍然是一個相對較新的平臺。如果要追溯到更早的時間，我們可以簡單地向APNIC1（五個地區(qū)互聯(lián)網(wǎng)注冊管理機構(RIRs)之一）的朋友求助。通過他們追溯到2012年的數(shù)據(jù)，我們可以看到IPv6在2017年年中之前經歷了一段看似指數(shù)級的增長期，之后進入了線性增長期，目前仍在持續(xù)：

由于兩種協(xié)議之間缺乏兼容性（必須同時為設備分配IPv4和IPv6地址）以及事實上互聯(lián)網(wǎng)上的所有設備仍然支持IPv4，IPv6的采用速度放緩了。然而，IPv6對于互聯(lián)網(wǎng)的未來至關重要，因此需要繼續(xù)努力增加其部署。

Cloudflare Radar與APNIC和當今大多數(shù)其他來源一樣，發(fā)布的數(shù)據(jù)主要反映了互聯(lián)網(wǎng)服務提供商(ISP)部署IPv6的程度：客戶端。這是一個非常重要的角度，直接影響最終用戶，但還有等式的另一端：服務器端。

考慮到這一點，我們邀請您跟隨我們進行一個快速實驗，我們的目的是了解服務器端IPv6的采用情況，以及客戶端實際上（或可能）能夠通過IPv6與服務器通信的頻率。我們將依靠DNS進行此探索，正如一些人所說，結果可能會讓您感到驚訝。

客戶端的IPv6采用情況（來自HTTP）

從Cloudflare的角度來看，截至2023年10月，整個互聯(lián)網(wǎng)的IPv6采用率約為所有流量的36%，根據(jù)一天中的時間和一周中的日期略有變化。如果排除機器人，這一估計值將上升至46%以上，而如果排除人類，則該估計值會下降到近24%。這些數(shù)字指的是通過IPv6提供的HTTP請求在所有啟用IPv6的內容（默認設置）中所占的份額。

對于這項工作來說，最重要的是人類和機器人的數(shù)量。造成這兩種流量采用率差距的原因有很多——從所使用的大量客戶端軟件對IPv6的支持程度不同，到流量來源的眾多網(wǎng)絡內部IPv6部署程度不同，再到這些網(wǎng)絡的規(guī)模不同，等等，但這都是后話了。如果您對某個國家或網(wǎng)絡的數(shù)字感到好奇，可以查閱Cloudflare Radar和我們的2023年度回顧報告。

等式的兩端

讀者可能會指出，對“客戶端-服務器”等式中的“客戶端”一側進行測量，只能說明問題的一半：要讓支持IPv6的“客戶端”通過IPv6與服務器建立連接，服務器也必須支持IPv6。

這就引申出了兩個問題：

1.服務器端采用IPv6的程度如何？

2.客戶端采用的IPv6與服務器端所采用的IPv6的一致性如何？

有幾種可能的答案，取決于我們談論的是用戶、設備還是傳輸?shù)淖止?jié)數(shù)等等。我們將把重點放在連接（稍后就會明白為什么），我們提出的綜合問題是：

在典型的使用模式下，支持IPv6的客戶端在連接互聯(lián)網(wǎng)上的服務器時，能夠使用IPv6的頻率如何？

典型的使用模式包括人們每天訪問某些網(wǎng)站的頻率高于其他網(wǎng)站，或者自動客戶端調用API。我們將通過DNS來了解這一點。

進入DNS

無論是使用傳統(tǒng)的IPv4協(xié)議還是更現(xiàn)代的IPv6協(xié)議，客戶端在嘗試通過名稱與服務器建立連接之前，都必須在互聯(lián)網(wǎng)的電話簿——域名系統(tǒng)(DNS)——中查找服務器的IP地址。

在DNS中查找主機名是一個遞歸過程。要查找服務器的IP地址，必須在多個DNS權威服務器上跟蹤域層次結構（服務器名稱的點分隔組件），直到其中一個服務器返回所需的響應2。不過，大多數(shù)客戶端不會直接這樣做，而是讓一個稱為遞歸解析器的中間服務器代勞。Cloudflare就運營著這樣一個任何人都可以使用的遞歸解析器：1.1.1.1。

舉個簡單的例子，當客戶端向1.1.1.1詢問“www.example.com”所在的IP地址時，1.1.1.1會先向DNS根服務器3詢問有關“.com”的信息，然后向.com DNS服務器詢問有關“example.com”的信息，最后向example.com DNS服務器詢問有關“www.example.com”的信息，后者直接了解該信息并用IP地址進行答復。為了讓下一個提出類似問題的客戶端更快地得到答案，1.1.1.1會緩存（暫時記憶）最終答案和中間的步驟。

這意味著1.1.1.1能夠很好地統(tǒng)計客戶端嘗試查找IPv4地址（A類查詢）的頻率與嘗試查找IPv6地址（AAAA類查詢）的頻率，覆蓋了大部分可觀察到的互聯(lián)網(wǎng)。

但是，客戶端如何知道何時詢問服務器的IPv4地址或IPv6地址？

簡而言之，可以使用IPv6的客戶端會同時請求IPv4和IPv6地址，即為它們希望連接的每臺服務器進行單獨的A和AAAA查找。這些支持IPv6的客戶端在獲得非空AAAA答復時將優(yōu)先通過IPv6進行連接，無論它們是否也獲得非空A答復（正如我們將看到的，它們幾乎總是會得到非空的A答復）。推動這種現(xiàn)代性偏好的算法被稱為Happy Eyeballs，如果您對細節(jié)感興趣，可點擊上述鏈接查看。

我們現(xiàn)在可以開始查看一些實際數(shù)據(jù)了…

客戶端的IPv6采用情況（來自DNS）

第一步是通過從1.1.1.1的角度測量客戶端IPv6部署并將其與我們開始時的HTTP請求數(shù)量進行比較來建立基線。

計算客戶端使用IPv6連接到1.1.1.1的頻率很有誘惑力，但由于以下幾個原因，結果會產生誤導，其中最重要的一個原因隱藏在顯而易見的地方：在客戶端可用來通過1.1.1.1服務執(zhí)行DNS查找的IPv4和IPv6地址集合中，1.1.1.1是最容易記住的地址。理想情況下，使用1.1.1.1作為遞歸解析器的支持IPv6的客戶端應配置以下所有四個IP地址，而不僅僅是前兩個：

-1.1.1.1(IPv4)

-1.0.0.1(IPv4)

-2606:4700:4700::1111(IPv6)

-2606:4700:4700::1001(IPv6)

但是，當涉及手動配置時?，人類會發(fā)現(xiàn)IPv6地址不如IPv4地址好記，而且不太可能進行配置，因此認為IPv4地址就足夠了。

與此相關但不太明顯的干擾因素是，許多支持IPv6的客戶端即使配置了1.1.1.1的IPv6地址，仍然會通過IPv4執(zhí)行DNS查找，因為分散查找可用地址是一種流行的默認選項。

從DNS客戶端活動評估IPv6采用情況的更合理方法是計算AAAA類型查詢占A類型查詢總量的百分比（假設IPv6客戶端始終同時執(zhí)行這兩種查詢?，如前所述）。

那么，從1.1.1.1的角度來看，按查詢量計算，客戶端的IPv6采用率估計為30.5%。這略低于我們從HTTP流量中觀察到的同期數(shù)據(jù)(35.9%)，但兩種不同視角之間的差異并不出人意料。

關于TTL的說明

不僅遞歸解析器會緩存DNS響應，大多數(shù)DNS客戶端也有自己的本地緩存。您的Web瀏覽器、操作系統(tǒng)甚至是家用路由器都會保留答案，希望能加快后續(xù)查詢的速度。

每個答案在緩存中保留的時間取決于隨DNS記錄傳回的生存時間(TTL)字段。如果您熟悉DNS，可能會想知道A和AAAA記錄是否具有相似的TTL。如果不相似，則對于這兩種類型種的一種，我們可能會收到更少的查詢（因為它在客戶端級別緩存的時間更長），從而使最終的采用數(shù)據(jù)產生偏差。

這里的餅圖細分了1.1.1.1響應A和AAAA查詢時傳回的最小TTL?。兩種類型之間存在一定差異，但差異很小。

服務器端的IPv6采用情況

下圖顯示了A和AAAA類型查詢獲得非空響應的頻率，揭示了服務器端的IPv6采用情況，讓我們更接近我們想要的答案：

按查詢量計算，服務器端采用IPv6的比例估計為43.3%，明顯高于客戶端。

雙方同時接受的頻率

如果由1.1.1.1處理的IP地址查詢中有30.5%可以使用IPv6地址連接到預定目的地，但其中只有43.3%的查詢得到了非空響應，那么這就為我們提供了一個很好的參考基礎，說明客戶端和服務器之間的IPv6連接頻率大約為13.2%。

熱門域名的潛在影響

根據(jù)Radar前100列表中的域的查詢量衡量，IPv6服務器端采用率為60.8%。如果我們從整體計算中排除這些域，之前的13.2%數(shù)字將下降至8%。這是一個顯著差異，但并不意外，因為前100個域占1.1.1.1所有A和AAAA查詢量的55%以上。

如果今天在這些非常受歡迎的域中有更多的比重部署IPv6，那么觀察到的采用率就會明顯提高，支持IPv6的客戶端使用IPv6建立連接的機會也會隨之增加。

結束語

觀察整個互聯(lián)網(wǎng)采用IPv6的程度可能意味著不同的事情：

-計算具有IPv6互聯(lián)網(wǎng)訪問能力的用戶；

-計算支持IPv6的設備或這些設備（客戶端和/或服務器）上的軟件；

-計算流經IPv6連接的流量（以字節(jié)為單位）；

-計算IPv6連接（或單個請求）的比例。

-在本次實驗中，我們選擇查看連接和請求?？紤]到只有從幾個不同的角度才能真正理解基本現(xiàn)實，我們看到了三種不同的IPv6采用數(shù)據(jù)：

-在計算Cloudflare CDN提供的HTTP請求時為35.9%（客戶端）；

-在計算1.1.1.1處理的A和AAAA類型DNS查詢時，為30.5%（客戶端）；

對同樣來自1.1.1.1的AAAA類型DNS查詢的積極回復率為43.3%（服務器端）。

我們從DNS角度結合了客戶端和服務器端的數(shù)據(jù)，來估算通過IPv6而非IPv4與第三方服務器建立連接的頻率：僅為13.2%。

要提高這些數(shù)字，ISP、云和托管提供商以及企業(yè)都必須提高其網(wǎng)絡設備的IPv6可用率。但是，大型網(wǎng)站和內容源在使支持IPv6的客戶端更頻繁地使用IPv6方面也發(fā)揮著關鍵作用，因為在對Radar前100的域的查詢中，有39.2%（占1.1.1.1的所有A和AAAA查詢的一半以上）仍然限于僅IPv4的響應。

對于全面采用IPv6的目標，整個互聯(lián)網(wǎng)尚未完全實現(xiàn)。但是，所有相關各方的持續(xù)努力可以幫助它繼續(xù)向前發(fā)展，甚至可能加速進展。

在服務器端，Cloudflare多年來一直通過為所有域提供免費的IPv6支持來推進這項全球性的工作。在客戶端，1.1.1.1應用程序會自動為您的設備啟用IPv6，即使您的ISP不提供任何IPv6支持。而且，如果您碰巧管理僅支持IPv6的網(wǎng)絡，1.1.1.1的DNS64支持也可以滿足您的需求。

1Cloudflare的公共DNS解析器(1.1.1.1)與APNIC合作運營。您可以在原始公告博客文章和1.1.1.1的隱私政策中閱讀更多相關信息。

2有關DNS如何工作的更多信息，請參閱我們網(wǎng)站中的“什么是DNS？”部分。如果您喜歡動手學習，我們建議您看看Julia Evans的“mess with dns”。

3任何遞歸解析器都已經事先知道13個根服務器的IP地址。Cloudflare還通過向E和F-Root實例提供Anycast服務來參與DNS的最頂層，這意味著1.1.1.1不需要走很遠就能完成第一個查找步驟。

?使用1.1.1.1應用程序時，會自動配置全部四個IP地址。

?為了簡單起見，我們假定純IPv6客戶端的數(shù)量仍然少得可以忽略不計?？傮w而言，這是一個合理的假設，我們所掌握的其他數(shù)據(jù)集也證實了這一點。

?1.1.1.1與其他遞歸解析器一樣，返回調整后的TTL：記錄的原始TTL減去自上次緩存

記錄以來的秒數(shù)?？誂和AAAA答復將按照RFC 2308指定的域授權機構起始(SOA)記錄中定義的時間進行緩存。

我們保護整個企業(yè)網(wǎng)絡，幫助客戶高效構建互聯(lián)網(wǎng)規(guī)模應用，加速任何網(wǎng)站或互聯(lián)網(wǎng)應用，抵御DDoS攻擊，阻止黑客，并為您的Zero Trust之旅提供協(xié)助。

從任何設備訪問1.1.1.1，使用我們的免費應用加速和保護您的互聯(lián)網(wǎng)。