译者 | 弯月
出品 | CSDN（ID：CSDNnews）

一句话概括本文：IPv6的速度比IPv4快约39%（仅限本地！）。

为了搞清楚如题所示的问题，我们决定分析30天内一系列监控代理收集的匿名数据。为了简单起见，我们只分析客户端到默认网关的往返时间（Round Trip Time，即RTT）。这段子路径并没有覆盖访问互联网资源的完整过程，只包括第一段旅程（通常通过Wi-Fi传输），其不确定性也最大。

有许多细微的差别都可能会影响我们的初步结果，包括但不限于数据集的大小、设备的差异、操作系统、介质、协议、CoS 类型等等。然而，由于困难重重，我们决定研究一个简单但便于比较的指标。如果你对我们的数据和分析结果有任何想法或建议，请在下方留言。

方法

为了回答这个问题，我们使用了一种名叫PanSift的工具，希望借助这个工具保证Wi-Fi传输和远程故障排除。我们收集了 240 万个网络相关的网关数据点。为了收集这些数据，我们随机选择了16个macOS机器，然后每30秒收集一次数据（我们的数据保留期限最长为30天）。

这16台macOS机器全天在线，并支持双协议栈（即单个节点同时支持IPv4和IPv6两种协议栈），而不仅仅是只有本地连接。这样可以让比较更公平，因为发出的流量都要遍历连接中的全部节点和网关。另外，请注意PanSift不会对数据做规范处理，并保留完全保真的指标。这样，我们就可以进行细粒度分析，甚至追溯故障排除。在过滤出同时支持IPv4和IPv6的数据后，我们总共得到了 342,980 个有效数据点。

深层技术揭秘

PanSift代理每30秒通过命令ping（IPv4）和ping6（IPv6）发送3个ICMP echo_requests，同时还将COS（服务等级）设置为“Best Effort”。ping和ping6使用的选项如下：

-c 3：发送3个请求，然后停止。

-i 1：两个请求之间等待1秒（默认）。

-k BE：Best Effort，普通类（默认）。

注意：虽然上述选项是默认值，但我们还是明确地给出了选项，这样可以提醒自己以后进行进一步的调整。我们还为网关的 ICMP 设置了5秒的父进程超时。先发送IPv4请求，然后是IPv6，我们求出3个请求的平均延迟，作为结果数据点（使用以毫秒为单位的浮点值）。

然后查询Influx后端（时间序列数据库）。数据框中的数据跨越 macOS 版本 10.11.x、10.14.x、10.15.x、11.6.x 和 12.x，设备类型从 iMAC 到 Mini，但主要是 Macbook Airs和 MacBook Pro。

然后，使用Influx的脚本语言Flux，简单比较了IPv4和IPv6。

注意，为了简单起见，我们还将（浮点）值四舍五入为整数，以便快速、公平地比较IPv4和IPv6。

结果

表 1.0：IPv4 与 IPv6 的总延迟结果

图 1.0：IPv4 的总延迟结

果

图 2.0：IPv6 的总延迟结果

表 2.0：WLAN 的 IPv4 与 IPv6 的延迟

表 3.0：有线 IPv4 与 IPv6 的延迟*

* 我们需要更广泛的数据集，因为大多数机器的数据来自同时连接了 Wi-Fi / WLAN 的主机。我们记录的有线硬件主要是“USB LAN”和“USB-C LAN”，其中一些硬件的速率可能低于千兆（1000 Mbps）。因此，我们还需要获取不同硬件上的输出，但是 IPv4 和 IPv6 都使用了相同的硬件传输数据。

下一步的计划

接下来，我们打算扩展上面的分析结果，然后看一看：

● 是否与网关的MAC 地址（以及供应商 OUI）有关。

● 是否与某些客户端设备类型、操作系统版本或补丁级别有关。

● 更大的双协议栈设备样本集是否会产生相同的结果。

原文地址：