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

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

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

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

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

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

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

考慮到這一點(diǎn)，我們邀請(qǐng)您跟隨我們進(jìn)行一個(gè)快速實(shí)驗(yàn)，我們的目的是了解服務(wù)器端IPv6的采用情況，以及客戶端實(shí)際上（或可能）能夠通過IPv6與服務(wù)器通信的頻率。我們將依靠DNS進(jìn)行此探索，正如一些人所說，結(jié)果可能會(huì)讓您感到驚訝。

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

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

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

等式的兩端

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

這就引申出了兩個(gè)問題：

1.服務(wù)器端采用IPv6的程度如何？

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

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

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

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

進(jìn)入DNS

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

在DNS中查找主機(jī)名是一個(gè)遞歸過程。要查找服務(wù)器的IP地址，必須在多個(gè)DNS權(quán)威服務(wù)器上跟蹤域?qū)哟谓Y(jié)構(gòu)（服務(wù)器名稱的點(diǎn)分隔組件），直到其中一個(gè)服務(wù)器返回所需的響應(yīng)2。不過，大多數(shù)客戶端不會(huì)直接這樣做，而是讓一個(gè)稱為遞歸解析器的中間服務(wù)器代勞。Cloudflare就運(yùn)營著這樣一個(gè)任何人都可以使用的遞歸解析器：1.1.1.1。

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

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

但是，客戶端如何知道何時(shí)詢問服務(wù)器的IPv4地址或IPv6地址？

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

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

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

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

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

-1.1.1.1(IPv4)

-1.0.0.1(IPv4)

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

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

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

與此相關(guān)但不太明顯的干擾因素是，許多支持IPv6的客戶端即使配置了1.1.1.1的IPv6地址，仍然會(huì)通過IPv4執(zhí)行DNS查找，因?yàn)榉稚⒉檎铱捎玫刂肥且环N流行的默認(rèn)選項(xiàng)。

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

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

關(guān)于TTL的說明

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

每個(gè)答案在緩存中保留的時(shí)間取決于隨DNS記錄傳回的生存時(shí)間(TTL)字段。如果您熟悉DNS，可能會(huì)想知道A和AAAA記錄是否具有相似的TTL。如果不相似，則對(duì)于這兩種類型種的一種，我們可能會(huì)收到更少的查詢（因?yàn)樗诳蛻舳思?jí)別緩存的時(shí)間更長），從而使最終的采用數(shù)據(jù)產(chǎn)生偏差。

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

服務(wù)器端的IPv6采用情況

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

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

雙方同時(shí)接受的頻率

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

熱門域名的潛在影響

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

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

結(jié)束語

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

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

-計(jì)算支持IPv6的設(shè)備或這些設(shè)備（客戶端和/或服務(wù)器）上的軟件；

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

-計(jì)算IPv6連接（或單個(gè)請(qǐng)求）的比例。

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

-在計(jì)算Cloudflare CDN提供的HTTP請(qǐng)求時(shí)為35.9%（客戶端）；

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

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

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

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

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

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

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

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

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

?使用1.1.1.1應(yīng)用程序時(shí)，會(huì)自動(dòng)配置全部四個(gè)IP地址。

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

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

記錄以來的秒數(shù)。空A和AAAA答復(fù)將按照RFC 2308指定的域授權(quán)機(jī)構(gòu)起始(SOA)記錄中定義的時(shí)間進(jìn)行緩存。

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

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