LIVE555再学习 -- 单播、多播、广播、直播、点播 都是个啥?

转自:https://blog.csdn.net/qq_29350001/article/details/78086800

一、单播

简介

       Unicast,是客户端与服务器之间的点到点连接。“点到点”指每个客户端都从服务器接收远程流。仅当客户端发出请求时,才发送单播流。


  Unicast(单播):在客户端与媒体服务器之间需要建立一个单独的数据通道,从一台服务器送出的每个数据包只能传送给一个客户机,这种传送方式称为单播。指网络中从源向目的地转发单播流量的过程。单播流量地址唯一。每个用户必须分别对媒体服务器发送单独的查询,而媒体服务器必须向每个用户发送所申请的数据包拷贝。这种巨大冗余首先造成服务器沉重的负担,响应需要很长时间,甚至停止播放;管理人员也被迫购买硬件和带宽来保证一定的服务质量。文字单播方式下,只有一个发送方和一个接收方。与之比较,组播是指单个发送方对应一组选定接收方的一种通信,任意播是指任意发送方对应一组较为接近的接收方间的一种通信。早期的点对点通信含义类似于单播。如果10个客户机需要相同的数据,则服务器需要逐一传送,重复10次相同的工作。但由于其能够针对每个客户的及时响应,所以现在的网页浏览全部都是采用IP单播协议。网络中的路由器和交换机根据其目标地址选择传输路径,将IP单播数据传送到其指定的目的地。

单播的优点:

1. 服务器及时响应客户机的请求
2. 服务器针对每个客户不同的请求发送不同的数据,容易实现个性化服务。

单播的缺点:

1. 服务器针对每个客户机发送数据流,服务器流量=客户机数量×客户机流量;在客户数量大、每个客户机流量大的流媒体应用中服务器不堪重负。
2. 现有的网络带宽是金字塔结构,城际省际主干带宽仅仅相当于其所有用户带宽之和的5%。如果全部使用单播协议,将造成网络主干不堪重负。现在的P2P应用就已经使主干经常阻塞,只要有5%的客户在全速使用网络,其他人就不要玩了。而将主干扩展20倍几乎是不可能。

二、多播(组播)

简介

多播(multicast):主机之间“一对一组”的通讯模式,也就是加入了同一个组的主机可以接受到此组内的所有数据,网络中的交换机和路由器只向有需求者复制并转发其所需数据。主机可以向路由器请求加入或退出某个组,网络中的路由器和交换机有选择的复制并传输数据,即只将组内数据传输给那些加入组的主机。这样既能一次将数据传输给多个有需要(加入组)的主机,又能保证不影响其他不需要(未加入组)的主机的其他通讯。

多播的优点:

1. 需要相同数据流的客户端加入相同的组共享一条数据流,节省了服务器的负载。具备广播所具备的优点。
2. 由于多播协议是根据接受者的需要对数据流进行复制转发,所以服务端的服务总带宽不受客户接入端带宽的限制。IP协议允许有2亿6千多万个(268435456)多播,所以其提供的服务可以非常丰富。
3. 此协议和单播协议一样允许在Internet宽带网上传输。

多播的缺点:

1.与单播协议相比没有纠错机制,发生丢包错包后难以弥补,但可以通过一定的容错机制和QOS加以弥补。
2.现行网络虽然都支持多播的传输,但在客户认证、QOS等方面还需要完善,这些缺点在理论上都有成熟的解决方案,只是需要逐步推广应用到现存网络当中。

三、广播

简介

广播(broadcast):主机之间“一对所有”的通讯模式,网络对其中每一台主机发出的信号都进行无条件复制并转发,所有主机都可以接收到所有信息(不管你是否需要),由于其不用路径选择,所以其网络成本可以很低廉。有线电视网就是典型的广播型网络,我们的电视机实际上是接受到所有频道的信号,但只将一个频道的信号还原成画面。在数据网络中也允许广播的存在,但其被限制在二层交换机的局域网范围内,禁止广播数据穿过路由器,防止广播数据影响大面积的主机。

广播的优点:

1. 网络设备简单,维护简单,布网成本低廉
2. 由于服务器不用向每个客户机单独发送数据,所以服务器流量负载极低。

广播的缺点:

1.无法针对每个客户的要求和时间及时提供个性化服务。
2. 网络允许服务器提供数据的带宽有限,客户端的最大带宽=服务总带宽。例如有线电视的客户端的线路支持100个频道(如果采用数字压缩技术,理论上可以提供500个频道),即使服务商有更大的财力配置更多的发送设备、改成光纤主干,也无法超过此极限。也就是说无法向众多客户提供更多样化、更加个性化的服务。
3. 广播禁止在Internet宽带网上传输。

四、IP地址

(1)IP地址的分类

参看:IP地址、子网掩码、网络号、主机号、网络地址、主机地址以及ip段/数字-如192.168.0.1/24是什么意思?

IP地址是一个 32 位的二进制数,通常被分割为 4 个“8 位二进制数”(也就是 4 个字节)。IP 地址通常用“点分十进制”表示成(a.b.c.d)的形式,其中,a,b,c,d 都是 0~255 之间的十进制整数。例:点分十进 IP 地址(100.4.5.6),实际上是 32 位二进制数(01100100.00000100.00000101.00000110)。

然后通过上图可以看出各类网络地址和主机地址分别占有多少位。

而根据网络地址和主机地址所占位数可以看出各类的子网掩码

举个例子,最常用的C类  192.168.1.108 

第1个8位中的第1、2、3 位始终为110,网络地址21位,主机地址8位,则子网掩码为 255.255.255.0

我们今天不是重点不是为了将IP地址的,这部分只做了解。

子网掩码部分参看:IP地址、子网掩码、网络号、主机号、网络地址、主机地址

(2)单播、多播和广播的IP地址

参看:单播、广播和多播地址

单播(unicast)指数据发送过程中只有一个发送方和一个接受方,单播地址就是指接受方接口的地址

1.单播

单播地址是IP网络中最常见的。包含单播目标地址的分组发送给特定主机,一个这样的例子是,IP地址为192.168.1.5(源地址)的主机向IP地址为192.168.1.200(目标地址)的服务器请求网页,如图下图所示。


提示,要发送和接收单播分组,IP分组报头中必须有一个目标IP地址,而以太网帧报头中必须有相应的目标MAC地址。IP地址和MAC地址一起将数据传输到特定的目标主机。

如果目标IP地址属于另一个网络,则在帧中使用的目标MAC地址将为与源IP地址位于同一个网络中的路由器接口的MAC地址。

2.广播

广播分组的目标IP地址的主机部分全为1,这意味着本地网络(广播域)中的所有主机都将接收并查看该分组。诸如ARP和DHCP等很多网络协议都使用广播。

例如:

C类网络  192.168.1.0的默认子网掩码为255.255.255.0(掩码的255个数对应网络的网络地址个数),其广播地址为192.168.1.255,其主机部分为十进制数255或二进制数11111111(全为1);

B类网络  172.16.0.0的默认子网掩码为255.255.0.0,其广播地址为172.16.255.255;

A类网络  10.0.0.0的默认子网掩码为255.0.0.0,其广播地址为10.255.255.255。

在以太网帧中,必须包含与广播IP地址对应的广播MAC地址。在以太网中,广播MAC地址长48位,其十六进制表示为FF-FF-FF-FF-FF-FF(全1为广播mac,主机地址为全1即广播ip地址)。图5.9所示的是一个广播IP分组。

3.  多播

多播地址让源设备能够将分组发送给一组设备。属于多播组的设备将被分配一个多播组IP地址,多播地址范围为224.0.0.0~239.255.255.255 (即D类IP地址)由于多播地址表示一组设备(有时被称为主机组),因此只能用作分组的目标地址。源地址总是为单播地址。3.多播

远程游戏就是一个使用多播地址的例子,很多玩家通过远程连接玩同一个游戏;另一例子是通过视频会议进行远程教学,其中很多学生连接到同一个教室。还有一个例子是硬盘映像应用程序,这种程序用于同时恢复众多硬盘的内容。

同单播地址和广播地址一样,多播IP地址也需要相应的多播MAC地址在本地网络中实际传送帧。多播MAC地址以十六进制值01-00-5E打头,余下的6个十六进制位是根据IP多播组地址的最后23位转换得到的。一个MAC多播地址是01-00-5E-0F-64-C5,如图5.10所示。每个十六进制位相对于4个二进制位。

五、原理

参看:广播、多播与单播的原理

参看:网络基本概念之TCP, UDP, 单播(Unicast), 多播(组播)(Multicast)

单播和广播,相对来说好比较好理解。我们主要来看一下多播。

IP多播首先要知道的是只有UDP有多播,没有TCP多播这样的东西。

为什么要多播?

当一个主机需要向N个主机发送数据时(有的不属于同一子网),假如使用单播,那么将对发送主机产生非常大的性能消耗,同时需要发送主机有足够强大的主机。假如使用广播,那么意味着就算子网中不是目的主机的主机也要接收数据包,对非目的主机产生不必要的消耗。而且,广播还不能跨越子网发送。所以假如可以指定一个组的主机进行发送,那就非常好了。所以就有了多播。

路由器和主机如何确认这是一个多播地址?

多播使用D类地址。所以IP目的地址以“1110”开头的就被认为为多播地址。而剩下的28位可以成为多播的组编号。多播地址还有很多是被预定的了。部分预定如下:
地址                  内容
224.0.0.0 (预定)
224.0.0.1 子网内所有的系统
224.0.0.2 子网内所有的路由器
224.0.0.5 OSPF路由器

路由器怎么知道哪里有需要接受多播分组的主机?

这是多播最核心的问题。路由器面对一个IP地址为多播地址的数据包时,该怎么样判断这个数据包的转发方向呢?假如路由器上每一个主机都接收多播分组,那么可以采用广播方式进行扩散。但是简单的扩散会产生回路——解决方法:逆向路径广播。


逆向路径广播规定:当一个路由器收到一个源地址S发往组G的多播分组时,仅当接收该分组的接口位于从路由器到源主机S的最短路径上时才扩散该分组。
这个规定有效地防止了多播数据包的循环转发。整体来看,我们可以理解为一个多播的传播过程就像一些数据不停地从一个树的根节点往叶子节点进行传播的过程。那么,在这棵多播传播网络树中,也许有一些子树是不含有接收多播分组主机的,那么最后在传播树中,最后就不要有那一部分的子树。于是,逆向路径广播协议就有了“剪枝”行为了。


定义:对于基于一个源地址的多播流,如果路由的所有下游接口均没有该组成员或已被剪枝,则它通过其双亲链路向上发送剪枝消息(消息意思是:上游的路由器啊,我这边不接收多播分组数据,你不要传给我了!)。路由器不会把多播分组从剪枝接口转发出去。
当然,这个剪枝行为是不能恒定的,因为随时可以有主机登记为多播目的主机。所以就有与剪枝相对应的行为——嫁接。实现原理很简单:路由器定时删除剪枝信息,下游重新对上剪枝。

通过逆向路径广播的技术,我们可以知道路由器是如何转发多播数据包的。那么在这里我们可以再引出一个问题:怎么知道一个主机是多播接收主机呢?那就是IGMP的工作了。

多播与IGMP协议

IGMP译名为:Internet组管理协议。用于路由器查询与它直连的网络上是否存在组成员。
IGMP是多播技术的一个基本模块。我们可以想象一个多播路由器的工作情况,当它接收到一个多播数据包(假设是224.1.2.3),需要转发时,那么它就要选择合适的接口进行转发。从上文可知,假如接口le1不存在224.1.2.3的多播主机,那么路由器就无需在这个接口中转发。对于一个多播路由器而言,IGMP的功能主要就是维护这个信息:接口是否存在多播主机。
IGMP主要是两个功能:

    1、主机加入多播组
    2、IGMP报告和查询,维护多播组转发表

简略的介绍一下过程,详细可以参考 《TCP/IP详解》

主机加入多播组

主机中,某一个进程希望可以加入多播组(例如,我打开一个直播,意味着主机希望假如这个多播组,以获得直播的数据)。那么,它会定时地发送一个IGMP报告。在这个报文中:

字段 数据
报文类型 IGMP报告
IGMP组地址 组地址
目的IP地址 组地址
源IP地址 主机IP地址

当多播路由器在某个接口中接收到这个报文时。那么就证明,这个接口存在这个多播组的接收主机。以后它就懂得转发它的数据包了。

IGMP的报告与查询

多播是动态的,意味着随时会有主机加入多播组或退出多播组。所以IGMP必需可以合理维护多播组的信息,所以多播路由器必需每隔一段时间就发送查询消息,保证接口中存在多播主机,并以此维护自己的多播分组转发路由表。查询报文简要记述如下:

字段 数据
报文类型 IGMP查询
IGMP组地址 0
目的IP地址 224.0.0.1
源IP地址 路由器IP地址

其中,224.0.0.1意味着它想所有多播组的主机发送查询。每一个允许多播的主机都必要先加入224.0.0.1这个多播组。至此,我们了解完IGMP的两个重要工作后,我们已经可以完全理解:一个主机加入多播分组或离开多播分组的原理。

六、直播和点播

最后我们讲一下,直播和点播。这个从字面上也可以大致看出是什么意思的吧。

直播,比如斗鱼、熊猫直播这种形式的

流媒体技术在音视频直播的应用,大概可以这样分类,

一是广电新媒体网台、IPTV直播/OTT直播为代表的以电视直播业务为主,特点是延时容忍度高,但稳定性、清晰度要求高;

二是秀场/游戏直播/体育直播/移动直播/教育直播等为代表的互动直播,特点是延时要求高;

三是以视频会议为代表的音视频通讯业务,特点是延时要求极高,音频质量要求高。

点播,比如优酷、爱奇艺这种形式的

音视频的点播已经非常成熟,其业务流程一般为 上传-转码-编辑制作-入库-用户请求-网络分发-播放。类型上可以简单分为如下几类:

一是以优酷、爱奇艺等为代表的音视频点播网站,特点是少量上传海量点播;

二是以监控、秀场直播录制为代表的录像点播,特点是海量上传少量点播;

三是以段视频网站,特点是海量上传海量点播。针对不同类型的点播应用,需要架构不同的流媒体系统。

需要说明的是,如前文所述目前点播大多以 HTTP 渐进方式分发,或者以 HLS 切片方式分发(点播的 HLS 只下载一次 M3U8 索引,后续就是 .ts 文件下载了),它更接近文件分发。

猜你喜欢

转载自blog.csdn.net/Fenglin6165/article/details/85619652