上篇实验发现 37% 的 IPv6 解析器无法接收分片 UDP 响应，RFC 7872 显示反方向丢包约 30%。本文继续测量从服务器向终端发送分片 IPv6 包的丢包率，构建基于在线广告框架的实验环境，通过 IPv6 NAT 前端对出站 TCP 包进行强制分片，观察终端主机的实际接收能力。
实验环境与分片机制：
实验利用在线广告框架招募终端主机，仅能在脚本化网页对象获取中植入测量逻辑，端到端仅存在 HTTP(S) 会话。为在不定制平台的前提下实现分片，部署一台前端单元充当 IPv6 NAT：入站指向前端 TCP 80/443 端口的 IPv6 包，重写源地址为前端地址、目的地址为后端 Web 服务器，源端口改为本地生成端口并记录连接表；后端返回的 TCP 包若载荷超过 15 字节，前端在转发至互联网前强制分片。该设计避免了原始套接字编程，仅依赖包级接口处理头部。
平台限制与工程取舍：
常规 TCP 套接字无法满足包级改写需求，实验转而使用 Berkeley Packet Filter (BPF) 接口直接操作数据包。前端需同时维护 NAT 状态表与分片逻辑，所有出站分片包的标识字段、分片偏移量均由前端生成。原文未给出具体分片大小、MTU 设定或重组超时参数，亦未披露广告框架覆盖的终端数量、地理分布及实验持续时间。
对运维与网络工程师的意义：
实验确立了在无侵入式条件下、从服务器侧向海量真实终端发送分片 IPv6 TCP 包的可行路径。工程师可参考该 NAT+BPF 架构，在自有 CDN 或负载均衡层复现测量，排查防火墙、中间设备或主机协议栈对 IPv6 分片的丢弃行为，为 DNSSEC、大响应等场景的 IPv6 部署提供落地依据。
原文: APNIC Blog（2017-08-29）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog