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

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

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

隨著連接設(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)推出三年了，仍然是一個相對較新的平臺。如果要追溯到更早的時間，我們可以簡單地向APNIC1（五個地區(qū)互聯(lián)網(wǎng)注冊管理機(jī)構(gòu)(RIRs)之一）的朋友求助。通過他們追溯到2012年的數(shù)據(jù)，我們可以看到IPv6在2017年年中之前經(jīng)歷了一段看似指數(shù)級的增長期，之后進(jìn)入了線性增長期，目前仍在持續(xù)：

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

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

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

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

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

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

等式的兩端

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

這就引申出了兩個問題：

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

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

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

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

典型的使用模式包括人們每天訪問某些網(wǎng)站的頻率高于其他網(wǎ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ī)名是一個遞歸過程。要查找服務(wù)器的IP地址，必須在多個DNS權(quán)威服務(wù)器上跟蹤域?qū)哟谓Y(jié)構(gòu)（服務(wù)器名稱的點(diǎn)分隔組件），直到其中一個服務(wù)器返回所需的響應(yīng)2。不過，大多數(shù)客戶端不會直接這樣做，而是讓一個稱為遞歸解析器的中間服務(wù)器代勞。Cloudflare就運(yùn)營著這樣一個任何人都可以使用的遞歸解析器：1.1.1.1。

舉個簡單的例子，當(dāng)客戶端向1.1.1.1詢問“www.example.com”所在的IP地址時，1.1.1.1會先向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ù)。為了讓下一個提出類似問題的客戶端更快地得到答案，1.1.1.1會緩存（暫時記憶）最終答案和中間的步驟。

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

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

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

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

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

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

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

-1.1.1.1(IPv4)

-1.0.0.1(IPv4)

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

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

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

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

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

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

關(guān)于TTL的說明

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

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

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

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

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

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

雙方同時接受的頻率

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

熱門域名的潛在影響

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

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

結(jié)束語

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

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

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

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

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

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

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

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

對同樣來自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)樵趯adar前100的域的查詢中，有39.2%（占1.1.1.1的所有A和AAAA查詢的一半以上）仍然限于僅IPv4的響應(yīng)。

對于全面采用IPv6的目標(biāo)，整個互聯(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)用程序會自動為您的設(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如何工作的更多信息，請參閱我們網(wǎng)站中的“什么是DNS？”部分。如果您喜歡動手學(xué)習(xí)，我們建議您看看Julia Evans的“mess with dns”。

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

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

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

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

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

我們保護(hù)整個企業(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)。