本文来自CSDN，译者|弯月。
一句话概括本文：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）有关。
●是否与某些客户端设备类型、操作系统版本或补丁级别有关。
●更大的双协议栈设备样本集是否会产生相同的结果。
