为了使一台设备能够使用恰当命名的互联网协议 (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 权威服务器上跟踪域层次结构（服务器名称的点分隔组件），直到其中一个服务器返回所需的响应2。不过，大多数客户端不会直接这样做，而是让一个称为递归解析器的中间服务器代劳。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 如何工作的更多信息，请参阅我们网站中的“什么是 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) 记录中定义的时间进行缓存。