通过抓包简单对比一下单播、广播和组播的区别

通过上次实验，我们大概了解了VLC Media player的使用方法（使用VLC media player初步认识单播、广播和组播）。但是，我们测试的是在同一终端上的，不符合实际的使用场景，接下来，我们来测试一下跨设备的推流。
测试方法之前我们也用过（HCL中虚拟设备的转发性能怎么样？今天我们来测一下），原理很简单，就是将网卡当成网线来使用。首先在VirtualBox的“主机网络管理器”中，新建几个“仅主机（HOST-Only）网络”。

然后我们创建两台Windows 7虚拟机，在主机的网络设置中，把连接方式修改为“仅主机（HOST-Only）网络”，界面名称分别选择新创建的#3、#4网卡，将主机分别接入到对应网络，建议将混杂模式修改为“全部允许”。

然后在HCL中创建一个测试工程，只需要新建一个交换机，然后创建两个Host本地主机，将网卡分别对应到#3、#4网卡即可。

现在，交换机无需做任何配置，然后我们启动Windows虚拟机，配置好IP地址，测试连通性。

1、HTTP单播测试
我们首先测试使用HTTP的单播推流，配置方式请参考之前的文章（使用VLC media player初步认识单播、广播和组播）。
然后我们就可以在两台Windows主机上进行测试了。

当然，可能是受虚拟设备的性能影响，视频稍微有些卡顿。不过视频文件大小是8.47 MB（8884591字节），时长为2分56秒，完全匀速传输的话，需要的带宽为394.4 kbps，与文件信息中的速率整体一致。

然后查看报文交互过程，我们可以发现，经过短暂的TCP协商之后，便开始了流媒体的数据传输。

而且还可以看到TCP实际传输的报文情况。

可以看到，TCP的分片大小主要是1460字节，实际传输的报文总长度为1514字节，出去二层报文头的14字节，符合MTU值为1500字节的设定，即使都按照这个大小进行传输，也需要394.4/1460*1500 = 405.2 kbps的带宽，实际上还要考虑ACK响应报文的传输，实际带宽会明显高于这个值。
播放一共持续2分40秒，实际捕获报文大小为15.6 MB，将近文件大小的2倍，实际速率达到802 kbps。为什么有这种情况呢？
怀疑是和性能低引起的重传有关，因为抓包过程中发现多次出现重传的情况，伴随着也有比较明显的图像卡顿、马赛克等情况出现。

再就是图像转码可能是实际传输速率有所增加。
另一个可能就是有其他垃圾报文数据，毕竟推流端网卡的收发数据总和也才15 MB而已。

2、UDP广播测试
然后我们测试一下UDP广播的报文收发情况。

测试成功，整体播放体验一定程度上优于HTTP单播。然后我们看一下报文交互情况。

我们可以看到，推流的源主机向网络中发送大量的UDP报文，使用的协议是MPEG TS，报文中还携带有音视频的详细信息。
整个过程中，我们没有看到接收端和推流的源主机有任何相关报文交互，说明接收端只要从广播网络中接收想要的报文即可，只要能正常解码就行。

3、RTP组播测试
很早之前学习的时候，记得交换机支持组播是要单独配置的，今天正好验证一下，看看没有任何配置的交换机能否支持组播。

该说不说，卡是真的卡，能看哪一帧完全靠运气，音频也卡，感觉接收的音频长度不足一半。
然后我们按照配置手册开启一下设备的IGMP Snooping，发现状况基本没有改善。同时发现设备的内存利用率比较高。

而如果看报文的话，就比较简单了。

清一色的只有发送到224.2.2.4的UDP报文，如果不是因为这个地址是组播地址，恐怕我们都区分不出来。