為了使一台裝置能夠使用恰當命名的網際網路通訊協定 (IP) 與網際網路上的其他裝置進行通訊，首先必須為其指派一個唯一的數字位址。該位址的外觀取決於所使用的 IP 版本：IPv4 還是 IPv6。
IPv4 於 1983 年首次部署。它是催生了現代網際網路的 IP 版本，並且至今仍然佔據主導地位。IPv6 的歷史可以追溯到 1998 年，但直到最近十年，它才開始獲得巨大的關注——從不到 1% 上升到 30% 到 40% 之間，具體取決於報告方、報告內容和測量方式。
隨著連線裝置的增長遠遠超過可用的 IPv4 位址數量，並且其成本不斷上升，IPv6 提供的更大位址空間本應該使其成為目前的主導通訊協定。然而，正如我們將看到的，事實並非如此。
Cloudflare 多年來一直是 IPv6 的堅定倡導者，並且我們一直透過 Cloudflare Radar密切關注 IPv6 在網際網路上的採用情況。Radar 已經推出三年了，仍然是一個相對較新的平台。如果要追溯到更早的時間，我們可以簡單地向 APNIC1（五個地區網際網路註冊管理機構 (RIRs)之一）的朋友求助。透過他們追溯到 2012 年的資料，我們可以看到 IPv6 在 2017 年年中之前經歷了一段看似指數級的增長期，之後進入了線性增長期，目前仍在持續：
由於兩種通訊協定之間缺乏相容性（必須同時為裝置指派 IPv4 和 IPv6 位址）_以及_事實上網際網路上的所有裝置仍然支援 IPv4，IPv6 的採用速度減慢了。然而，IPv6 對於網際網路的未來至關重要，因此需要繼續努力增加其部署。
Cloudflare Radar 與 APNIC 和當今大多數其他來源一樣，發佈的資料主要反映了網際網路服務提供者 (ISP) 部署 IPv6 的程度：用戶端。這是一個非常重要的角度，直接影響終端使用者，但還有等式的另一端：伺服器端。
考慮到這一點，我們邀請您跟隨我們進行一個快速實驗，我們的目的是瞭解伺服器端 IPv6 的採用情況，以及用戶端實際上（或可能）能夠透過 IPv6 與伺服器通訊的頻率。我們將依靠 DNS 進行此探索，正如他們所說，結果可能會讓您感到驚訝。
用戶端的 IPv6 採用情況（來自 HTTP）
從 Cloudflare 的角度來看，截至 2023 年 10 月，整個網際網路的 IPv6 採用率約為所有流量的 36%，根據一天中的時間和一周中的日期略有變化。如果排除傀儡程式，這一估計值將上升至 46% 以上，而如果排除人類，則該估計值會下降到近 24%。這些數字指的是透過 IPv6 提供的 HTTP 請求在所有啟用 IPv6 的內容（預設設定）中所占的份額。
對於這項工作來說，最重要的是人類_和_傀儡程式的數量。造成這兩種流量採用率差距的原因有很多——從所使用的大量用戶端軟體對 IPv6 的支援程度不同，到流量來源的眾多網路內部 IPv6 部署程度不同，再到這些網路的規模不同，等等，但這都是後話了。如果您對某個國家或網路的數據感到好奇，可以查閱 Cloudflare Radar 和我們的 2023 年度回顧報告。
等式的兩端
讀者可能會指出，對「用戶端-伺服器」等式中的「用戶端」一側進行測量，只能說明問題的一半：要讓支援 IPv6 的「用戶端」透過 IPv6 與伺服器建立連線，伺服器也必須支援 IPv6。
這就提出了兩個問題：
伺服器端採用 IPv6 的程度如何？
用戶端採用 IPv6 與伺服器採用 IPv6 的一致性如何？
有幾種可能的答案，取決於我們談論的是使用者、裝置還是傳輸的位元組數等等。我們將把重點放在_連線_（稍後就會明白為什麼），我們提出的綜合問題是：
在典型的使用模式下，支援 IPv6 的用戶端在連接網際網路上的伺服器時，能夠使用 IPv6 的頻率如何？
典型的使用模式包括人們每天造訪某些網站的頻率高於其他網站，或者自動用戶端呼叫 API。我們將透過 DNS 來瞭解這一點。
進入 DNS
無論是使用傳統的 IPv4 通訊協定還是更現代的 IPv6 通訊協定，用戶端在嘗試透過名稱與伺服器建立連線之前，都必須在網際網路的電話簿——網域名稱系統 (DNS)——中查找伺服器的 IP 位址。
在 DNS 中查找主機名稱是一個遞迴過程。要查找伺服器的 IP 位址，必須在多個 DNS 權威伺服器上追蹤網域階層（伺服器名稱的點分隔元件），直到其中一個伺服器傳回所需的回應。不過，大多數用戶端不會直接這樣做，而是讓一個稱為遞迴解析程式的中間伺服器代勞。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 能夠很好地統計用戶端嘗試查找 IPv4 位址（A 類查詢）的頻率_與_嘗試查找 IPv6 位址（AAAA 類查詢）的頻率，覆蓋了大部分可觀察到的網際網路。
但是，用戶端如何知道何時詢問伺服器的 IPv4 位址或 IPv6 位址？
簡而言之，可以使用 IPv6 的用戶端會同時請求 IPv4 和 IPv6 位址，即為它們希望連接的每台伺服器進行單獨的 A 和 AAAA 查找。這些支援 IPv6 的用戶端在獲得非空 AAAA 答覆時將優先透過 IPv6 進行連接，無論它們是否也獲得非空 A 答覆（正如我們將看到的，它們幾乎總是會得到非空的 A 答覆）。推動這種現代性偏好的演算法被稱為 Happy Eyeballs，如果您對細節感興趣，可在此查看。
我們現在可以開始查看一些實際資料了…
用戶端的 IPv6 採用情況（來自 DNS）
第一步是透過從 1.1.1.1 的角度測量用戶端 IPv6 部署並將其與我們開始時的 HTTP 請求數量進行比較來建立基準線。
計算用戶端使用 IPv6 連接到 1.1.1.1 的頻率很有誘惑力，但由於以下幾個原因，結果會產生誤導，其中最重要的一個原因隱藏在顯而易見的地方：在用戶端可用來透過 1.1.1.1 服務執行 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)
但是，當涉及手動設定時4，人類會發現 IPv6 位址不如 IPv4 位址好記，而且不太可能進行設定，因此認為 IPv4 位址就足夠了。
與此相關但不太明顯的干擾因素是，許多支援 IPv6 的用戶端即使設定了 1.1.1.1 的 IPv6 位址，仍然會透過 IPv4 執行 DNS 查找，因為分散查找可用位址是一種流行的預設選項。
從 DNS 用戶端活動評估 IPv6 採用情況的更合理方法是計算 AAAA 類型查詢占 A 類型查詢總量的百分比（假設 IPv6 用戶端始終同時執行這兩種查詢5，如前所述）。
那麼，從 1.1.1.1 的角度來看，按查詢量計算，用戶端的 IPv6 採用率估計為 30.5%。這略低於我們從 HTTP 流量中觀察到的同期資料 (35.9%)，但兩種不同視角之間的差異並不出人意料。
關於 TTL 的說明
不僅遞迴解析程式會快取 DNS 回應，大多數 DNS 用戶端也有自己的本機快取。您的 Web 瀏覽器、作業系統甚至是家用路由器都會保留答案，希望能加快後續查詢的速度。
每個答案在快取中保留的時間取決於隨 DNS 記錄傳回的存留時間 (TTL) 欄位。如果您熟悉 DNS，可能會想知道 A 和 AAAA 記錄是否具有相似的 TTL。如果不相似，則對於這兩種類型種的一種，我們可能會收到更少的查詢（因為它在用戶端層級快取的時間更長），從而使最終的採用數據產生偏差。
這裡的圓形圖細分了 1.1.1.1 回應 A 和 AAAA 查詢時傳回的最小 TTL6。兩種類型之間存在一定差異，但差異很小。
伺服器端的 IPv6 採用情況
下圖顯示了 A 和 AAAA 類型查詢獲得非空回應的頻率，揭示了伺服器端的 IPv6 採用情況，讓我們更接近我們想要的答案：
按查詢量計算，伺服器採用 IPv6 的比例估計為 43.3%，明顯高於用戶端。
雙方同時接受的頻率
如果由 1.1.1.1 處理的 IP 位址查詢中有 30.5% 可以使用 IPv6 位址連接到預定目的地，但其中只有 43.3% 的查詢得到了非空回應，那麼這就為我們提供了一個很好的基礎，說明用戶端和伺服器之間的 IPv6 連線頻率大約為 13.2%。
熱門網域的潛在影響
根據 Radar 前 100 清單中的網域的查詢量衡量，IPv6 伺服器端採用率為 60.8%。如果我們從整體計算中排除這些網域，之前的 13.2% 數字將下降至 8%。這是一個顯著差異，但並不意外，因為前 100 個網域占 1.1.1.1 所有 A 和 AAAA 查詢量的 55% 以上。
如果今天在這些非常受歡迎的網域中有更多部署 IPv6，那麼觀察到的採用率就會明顯提高，支援 IPv6 的用戶端使用 IPv6 建立連線的機會也會隨之增加。
結束語
觀察整個網際網路採用 IPv6 的程度可能意味著不同的事情：
計算具有 IPv6 網際網路存取能力的使用者；
計算支援 IPv6 的裝置或這些裝置（用戶端和/或伺服器）上的軟體；
計算流經 IPv6 連線的流量（以位元組為單位）；
計算 IPv6 連線（或單個請求）的比例。
在本次練習中，我們選擇查看連線和請求。考慮到只有從幾個不同的角度才能真正理解基本現實，我們看到了三種不同的 IPv6 採用數據：
在計算 Cloudflare CDN 提供的 HTTP 請求時為 35.9%（用戶端）；
在計算 1.1.1.1 處理的 A 和 AAAA 類型 DNS 查詢時，為 30.5%（用戶端）；
對同樣來自 1.1.1.1 的 AAAA 類型 DNS 查詢的積極回復率為 43.3%（伺服器端）。
我們從 DNS 角度結合了_用戶端_和_伺服器端_的數據，來估計透過 IPv6 而非 IPv4 與第三方伺服器建立連線的頻率：僅為 13.2%。
要提高這些數字，ISP、雲端和託管提供者以及企業都必須提高其網路裝置的 IPv6 可用率。但是，大型網站和內容來源在使支援 IPv6 的用戶端更頻繁地使用 IPv6 方面也發揮著關鍵作用，因為在對 Radar 前 100 的網域的查詢中，有 39.2%（占 1.1.1.1 的所有 A 和 AAAA 查詢的一半以上）仍然限於僅 IPv4 的回應。
對於全面採用 IPv6 的目標，網際網路還沒有完全實現。但是，所有相關各方的持續努力可以幫助它繼續向前發展，甚至可能加速進展。
在伺服器端，Cloudflare 多年來一直透过為所有网域提供免費的 IPv6 支援來推進這項全球性的工作。在用戶端，1.1.1.1 應用程式會自動為您的装置啟用 IPv6，即使您的 ISP 不提供任何 IPv6 支援。而且，如果您碰巧管理僅 IPv6 的網路，1.1.1.1 的 DNS64 支援也可以滿足您的需求。
***
1Cloudflare 的公用 DNS 解析程式 (1.1.1.1) 與 APNIC 合作營運。您可以在原始公告部落格文章和 1.1.1.1 的隱私權原則中閱讀更多相關資訊。
2有關 DNS 如何工作的更多資訊，請參閱我們網站中的「What is DNS?」區段。如果您喜歡動手學習，我們建議您看看 Julia Evans 的「mess with dns」。
3任何遞迴解析程式都已經事先知道 13 個根伺服器的 IP 位址。Cloudflare 還透過向 E 和 F-Root 執行個體提供 Anycast 服務來參與 DNS 的最頂層，這意味著 1.1.1.1 不需要走很遠就能完成第一個查找步驟。
4使用 1.1.1.1 應用程式時，會自動設定全部四個 IP 位址。
5為了簡單起見，我們假定純 IPv6 用戶端的數量仍然少得可以忽略不計。總體而言，這是一個合理的假設，我們所掌握的其他資料集也證實了這一點。
61.1.1.1 與其他遞迴解析程式一樣，傳回調整後的 TTL：記錄的原始 TTL 減去自上次快取記錄以來的秒數。空 A 和 AAAA 答覆將按照 RFC 2308 指定的網域授權機構起始 (SOA) 記錄中定義的時間進行快取。