IETF在RFC2432和RFC3918中定义了组播性能测试的性能指标和测试方法，在具体的测试过程中，需要根据网络模型和流量模型，对性能指标进行取舍，并确定性能测试中的各项参数。本文以某用户的业务需求与组网为例，介绍组播性能的测试思路和方法。
文/袁亚屏
1 用户的业务需求
A公司计划在公司内使用组播业务。如图1所示，A公司的组网是典型的“一总部，多分支”架构，各个分支和总部之间通过GRE隧道相连。组播源在公司总部，总部的各个部门和各分支机构都有接收组播数据的需求。
图1 A公司办公网示意图
分析此组网可以看出，核心路由器将承受比较大的性能压力，它需要维护所有的组播表项，同时承担组播转发和主要的组播数据复制工作，因此需要对核心路由器的组播吞吐量进行比较全面的评估。同时，从接收者角度考虑，整个网络的组播延迟和组加入/离开延时也需要进行测试。
按照A公司的整体规划，总部的部门数量会达到10个，分支机构的数量会达到30个，组播流的数量会达到100条。综合这些因素考虑，以下详细介绍需要测试的性能指标及方法。
2 吞吐量
2.1 混合吞吐量
A公司的网络同时承载单播和组播业务，组播流量预计会占到总流量的30%，因此混合吞吐量这一指标需要纳入测试范围，这个指标体现了DUT在同时承载单播和组播业务时的能力，即设备无丢包的向一定数量的出接口转发单播和组播混合流量的能力。
混合流量的发送方式需要遵循一定的方法：单播流量应该以轮转方式轮流从每个出接口发出，而组播流量则应该从每个接口都发出一份。而且各条流的发送次序也有明确的定义。
假设混合吞吐量测试环境中包括6条组播流（编号为m1~m6）和三个出接口，每个接口对应一条单播流量，源接口发送流量的次序如图2所示。
u表示单播流量，u的下标表示该流量对应的出接口序号；m表示组播流量，m的下标表示对应的组播流的序号。
图2 组播混合吞吐量测试的流量发送次序
混合吞吐量测试需要针对不同的包长进行测试，针对A公司的实际情况，使用常用的64、128、256、512、1024、1280、1500字节包长即可。
针对A公司的需求，需要测试100条组播流对应40个出接口的情况下的混合吞吐量，每个接口对应1条单播流量，组播流量占总流量的30%，测试组网如图3所示。
图3 组播混合吞吐量测试组网
这个性能指标是用来测试在出接口数量固定的情况下，组播吞吐量和组的数量的关系。该测试是一个反复循环的过程，组的数量持续增加，并最终达到组规格。测试结果将是一张表格，标示出每次测试的组数量、吞吐量等信息。
对于A公司来说，由于组的最大数量和出接口的最大数量都可以固定，测试可以简化，直接测试在40个出接口，100个组的情况下的组播吞吐量即可，这样可以显著的节约测试时间。
2.3 组播总体吞吐量
这个性能指标衡量的是设备的组播复制能力，和组转发矩阵的测试在不断增加组的数量相比，组播总体吞吐量的测试是在不断的增加出接口的数量。该测试也是个反复循环的过程，出接口的数量持续增加，增加到何时为止由测试人员指定。测试结果也是一张表格，标示出每次测试的出接口数量和吞吐量等信息。
对于A公司来说，由于组的最大数量和出接口的最大数量都可以固定，测试可以简化，直接测试在40个出接口，100个组的情况下的组播吞吐量即可。因此A公司的组转发矩阵测试和组播总体吞吐量测试可以合并进行。
上面三个性能指标基本上能够衡量被测设备的组播吞吐量性能了，一方面考虑了组播流的数量的增加（组转发矩阵），一方面考虑了出接口的不断增加（组播总体吞吐量）。
此外，对于A公司来说，封装吞吐量也需要纳入测试范围。
2.4 封装/解封装/重封装吞吐量
这三个性能指标是在考察被测设备将组播报文封装到单播报文中/从单播报文中解出/解出后再次封装到单播报文中的能力。如果组播流量要经过不支持组播的网络，将组播报文封装在隧道中变成单播报文进行传输是常用的方法，这三个性能指标就是用来考察被测设备做这些工作的能力。
由于涉及到单播和组播的转换，这三个性能指标的测试基本组网分别如图4、图5、图6所示。
图4 解封装吞吐量测试基本组网
图5
封装吞吐量测试基本组网
图6
再封装吞吐量测试基本组网
这三个性能指标的测试方法基本相似，需要确定的参数有出接口的数量、组的数量、包长，每个出接口的隧道数量、每个隧道的组数量、隧道的封装方法等等。
需要注意的是报文在经过隧道封装后会变大，对于封装吞吐量测试来说如果测试报文的包长选择不当会导致报文在封装之后需要分片处理，进而降低被测设备的性能，因此在测试中需要避免这种情况的发生。
对于A公司来说，由于组播流量是从总部发往分支，分支不会向总部发送组播数据，分支之间也不会发送组播数据，因此只需要进行封装吞吐量的测试。其中出接口数量为1，组的数量为100，出接口的隧道数量为30。每个隧道的组数量也是30，隧道的封装方式为GRE，这些参数都可以确定，只要测试不同包长情况下的吞吐量即可。
3 延迟
组播延迟
和单播延迟的定义类似，组播延迟表示组播数据经过被测设备所消耗的时间。由于组播流量是一入多出的，因此在每个出接口应该分别测量延迟，最终得到的延迟是一组数据，如表1所示。
|
|
出接口1 |
出接口2 |
出接口3 |
出接口4 |
出接口5 |
|
延迟 |
latency1 |
latency2 |
latency3 |
latency4 |
latency5 |
表1 出接口组播延迟测试结果
对于A公司来说，在测量组播延迟时需要将整个组网纳入测试范围，而不仅仅是测试核心路由器的延迟。它的组播环境中，出接口包括两类接口，一类是总部的各个部门的接收者连接的接口；另一类是各个分支机构的接收者所连接的接口。进行组播延迟测试时，A公司的网络可以抽象成如图7所示。
图7
针对组播延迟测试对A公司网络进行逻辑划分
由于Internet的存在，分支机构对应的接口上的延迟一般来说会比较大，因此A公司的组播延迟数据可以根据出接口的位置分成两部分来分别进行分析，进而来评估是否能够满足组播应用的需要。
4 开销
“开销”很容易和“延迟”混淆。延迟体现了被测设备在转发报文过程中消耗的时间，而开销是一个更综合的概念，包括了协议报文交互的时间，协议状态机运行需要的时间，转发表项建立的时间和转发报文消耗的时间等几个方面。从实际应用来讲，开销更能直接体现用户的使用体验。
对于A公司来说，和测试组播延迟相同，也需要将整个组网纳入测试范围。
组加入/离开延时
用来衡量开销的性能指标包括组加入延迟和组离开延时。其中组加入延时指的是从接收者发送IGMP的report消息开始到收到组播数据所经过的时间。组离开延时指的是从接收者发送IGMP的leave消息开始到收到最后一个组播报文所经过的时间。由于出接口数量可能多于一个，所以这些延时数据也是成组出现的。
同样，由于Internet的存在，分支机构对应的接口上的组加入/离开延时一般来说会比较大，因此A公司的组加入/离开延时数据可以根据出接口的位置分成两部分来分别进行分析，进而来评估是否能够满足组播应用的需要。
5 容量
组播组容量
容量实际上就是一些表项相关的性能规格，对于组播性能来说最重要的就是组播组容量。
组播组容量指被测设备能够支持的最大组的数量，测试方法如下：
所有的目的接口初始状态下会加入一定数量的组播组，然后源接口开始发送针对这些组的流量；如果所有组的流量都有至少一个数据包发送到了所有的目的接口，则说明这个循环的测试是成功的。
接下来所有目的接口上增加加入组的数量，并调整源接口的流量覆盖所有的组，然后重复进行上面的测试。
如果测试出现失败（如果至少一个组在至少一个接口上出现一个报文都没有被正确转发的情况，即视为测试失败），则停止测试，上次成功的测试中的组数量就是被测设备的组容量。
对于A公司来说，可以按照组播应用的需求，直接进行40个出接口，100个组的组播组容量测试，如果测试失败，可以直接判定目前网络不能满足组播业务的需求，需要进一步找到性能瓶颈，进行优化。
6 结束语
组播性能测试的指标很多。对于用户来说，需要在对自身需求、应用模型和流量特点进行充分分析的基础上，选取适当的指标进行测试，并慎重选择测试中的组数量、出接口数量、流量大小等参数，这样才能得到自己想要的性能数据。性能测试终究是为实际应用服务的，选取合适的性能指标进行测试并合理安排测试步骤，选取测试参数，可以达到事半功倍的效果。