研究使用 34 个月（2014 年 8 月至 2017 年 6 月）的数据，对比 YouTube 在 IPv6 与 IPv4 下的流媒体体验，发现虽然 Happy Eyeballs 使 97% 以上连接优先走 IPv6，但 IPv6 的连接建立与启动延迟约高 100 ms，吞吐更低，卡顿时长也更长。
连接建立与启动延迟：
数据集显示，IPv6 的 TCP 三次握手与 TLS 握手合计耗时比 IPv4 多出约 100 ms，导致视频首帧出现时间推迟。尽管 Happy Eyeballs 以 300 ms 计时器在 2012 年设定，旨在规避 Teredo/6to4 故障，但到 2017 年 6 月这类隧道仅占 0.01%，计时器过大反而让较慢的 IPv6 路径被优先选中。
吞吐与卡顿表现：
音频与视频流的实测吞吐在 IPv6 上均低于 IPv4，差距随时间略有缩小但仍存在。整体卡顿率在两协议均低于 1%，然而一旦发生卡顿，IPv6 样本中 80% 的卡顿持续时间比 IPv4 至少长 1 秒，且该比例在三年内未见下降。
缓存分布与 Happy Eyeballs 计时器：
探测点中 97% 通过 IPv4 命中 Google 全球缓存（GGC），仅 5% 在 IPv6 上命中缓存，缓存缺失直接导致更长的往返延迟与更低吞吐。论文建议将 Happy Eyeballs 计时器从 300 ms 降至 150 ms，实测可在保持 IPv6 优先比例不变的前提下，获得约 10% 的性能边际收益。
对运维与网络工程师而言，关键在于确认本地缓存部署是否覆盖 IPv6，并在浏览器或客户端侧调整 Happy Eyeballs 计时器，同时优化接入网延迟，以消除 IPv6 优先带来的性能劣势。
原文: APNIC Blog（2017-09-27）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog