OpenVPN 把组播扇出到每个客户端，而不是订阅者

“支持组播”回答的是协议问题，却把容量问题留在原处。真正影响运维的，是服务器为一个组包发出多少份副本，以及这些副本由哪些隧道承载。一个订阅了该流的应用收到数据，只能证明某处交付成功。它并不能证明无关客户端省下了带宽。

同一个功能宣称里的三个问题

组播组成员关系问的是接收方有没有加入组。隧道交付问的是报文到底有没有过隧道。复制策略问的是服务器做了几份副本、发给了谁。厂商的说法可能对第一问成立，却对第三问闭口不谈，而成本恰恰在第三问上。

评估一条链路的容量时，要把这三问分开。只有第三问决定服务器侧的出向预算。

用户空间服务器如何处理组包

在 OpenVPN 2.6 传统的用户空间服务器里，到达的广播或组播报文会在 TUN/TAP 输入路径上被分类，然后交给广播扇出例程，而不是按组查表。这个例程遍历各客户端实例，跳过发送方和任何已暂停的实例，在配置了 VLAN 的地方执行检查，并为其余每个客户端各排一份副本。这个循环里没有任何一步去查成员关系表。这就是广播式复制，整套机制仅此而已。

把它看作那条代码路径的性质，而不是普遍规律。加速数据路径、其他实现和不同版本可能表现不同，而这些都不构成必须使用或修复 TAP 的理由。

先给副本做预算，再做任何测量

取有效载荷速率，再乘以符合条件的客户端数量。一条以每秒一兆比特发往二十个客户端的流，会在封装、重传和任何单客户端开销之前，产生每秒二十兆比特离开服务器的载荷。这是算术预算，不是对你部署的测量。

ip -s link show tun0

在固定时间窗口前后各读一次发送字节计数器，窗口内只保留一个已知发送方。用间隔去除，再与有效载荷速率乘以客户端数比较。接近单流速率，说明复制范围受限；接近相乘后的速率，说明每个客户端都在收副本。

计数器里也包含你自己的隧道流量，所以测试窗口要短，主机其余时间要安静。精度不如数量级重要，而分辨一份和二十份只需要数量级。

用两个客户端敲定范围问题

接上一个应当收到该流的客户端，再接一个不应当收到的。启动发送方，然后在同一窗口内观察第二个客户端的隧道计数器。第二个客户端出现增长，就是广泛复制的直接证据，功能清单怎么说都不影响这一点。

把抓包过滤到组地址，免得读到无关流量，并且只抓隧道接口。在繁忙主机上抓物理接口，得到的文件没人能解释，还可能留存你本不打算收集的用户数据。

然后对调角色。如果结果跟着接收方走而不是跟着组走，说明你看到的是能感知成员关系的实现，先前那个假设反而对你有利地错了。

选择限定范围的设计，而不是取消限制

扇出过宽时，正确的做法是采用受支持的限定分发方案，而不是把手里所有控制手段都删掉。可选方案包括把分发点移到更靠近接收方、采用携带源标识与组的源特定订阅模型，或拆分该流，让无关站点永远不落在同一条分发边界上。

把源与组的身份，和“目的地是组播”这个赤裸事实分开。只认得组、认不得源的接收方，和请求了特定频道的订阅者并不是同一类订阅者。两者混在一起，后续容量规划就只能靠猜。

源特定组播频道模型就是这一区分的参照。无论选哪种设计，都要写下符合条件的对端集合、复制的负责人，以及下次要读的计数器；正是这份记录，把带宽上的意外变成已知成本。