现在直播、录播等平台是通过“组播”的方式下发流量的吗？

上海电信IPTV确实是组播的真正应用，但这个IPTV网络是专用网络，只用于IPTV组播流量的传输。

组播有一个潜在的问题，就是组播的接收者未知，可能没有，可能一个，也可能有上千万个。如果被不法分子利用，从成千上万个被控电脑上，往网络里持续注入大流量组播数据，同时接收组播数据，这对网络是一个巨大的挑战。

运营商针对家庭用户的网络入口，可能会直接过滤掉IGMP报文，杜绝可能的网络攻击行为。

但对于企业客户，由于客户有组播数据的传输的需求，所以会特殊配置，一般使用MVPN(Multicast VPN)的方式，组播隧道的方式，每一个客户分配一个组播IP，比如230.1.2.3，把用户的组播封装在230.1.2.3(通常由入口PE封装），在出口PE处做解封装，然后就剩下用户的组播，继续在用户的网络（其它分公司）里传输组播。

隧道方式可以杜绝企业客户的组播数据在运营商的网络里乱窜，只会在PE之间传输，而不会到别处，此谓可控！

网络直播、点播由于面向的用户是全球用户，通过上述的描述，运营商的网络不支持这种流量的组播，既然组播走不通，就选择单播传输。

虽然单播传输，但是心中还是念念不忘组播的好，那组播到底有哪点好？

一个交换机连接50台电脑（用户），如果这50个用户都在看网络直播，假设直播流速为2Mbps, 请问这个交换机从上游下拉的流速是多少？是2Mbps吧？向下游（用户）推送的总流速是多少？ 50*2= 100 Mbps!

意味着虽然有50个用户在看直播，但对上游网络的带宽压力只有 2Mbps。

但如果是单播呢？对上游网络的带宽压力为 50*2 = 100Mbps。

那能否在靠近用户的地方，部署一些类似上文交换机的缓存服务器（Cache Server）？

靠近缓存服务器的用户，每当访问直播服务器时，缓存服务器会根据用户的URL里的URI来检查是否本地有缓存，如果有，直接推送给用户，这样不会对上游网络有任何压力。

如果没有缓存，则代理用户访问直播服务器，将直播数据转发给用户，同时将直播数据缓存在本地，方便别的用户使用。

如果有50个用户使用此缓存服务器，则最多从上游下拉一份数据 2Mbps，而不是100Mbps。

这是一个两全其美的方案，虽然不使用组播，但能到达组播的效果，这个就是CDN (Content Delivery Network）。

这个是系统项目，目前所属行业来讲，直播技术使用的是nginx的HLS多媒体服务（或SRS、BMS)+OBS开源直播平台，用户端使用的是CDN加速，局域网测试1080在迟再2-3秒，如果是广域网的话延迟高10秒以上。

如图示

直播平台整体架构

视频直播链路

视频流转换成不同清晰度

不同的端，不同的网络环境，需要不同码率，以保流畅

播放器的基本实现

SDK在播放器上做层管理

视频相关技术细节

消息发送流程

不同消息通道的优劣对比

心跳及房间结构

用户按需分桶

固定分桶与按需分桶对比

关键词及垃圾文本过滤

大促风险控制

平台化的挑战

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

参考文献： 全民大直播，流媒体选择Nginx是福还是祸？ - charleslei的专栏 - CSDN博客

图片参 互联网直播平台架构案例一 - PetterLiu - 博客园

其实抓包就知道了，是单播。跨三层组播，客户端来自不同的区域，需要运营商支持组播路由协议pim建立组播流量结构，几乎不太可能实现。

谢邀，这方面我用得不多，就简单回答一下

不是，抓包结果反应直播平台的流量是单播的。

基础知识:

igmp协议:tcp/ip协议卷一

组播的实现:RFC0791

广域网上的多播需要路由协议的拓展来支持，明显的是大部分接入宽带路由器普遍不支持。

在国外找到的一些文档翻译:

在实时流单播中，每个连接的用户都有自己的带宽需求从服务器返回，因此服务器需要足够大的互联网连接来满足流的所有请求。即使这是相同的数据传送给许多不同的人也是如此。虽然对于个性化服务至关重要，但单播不适用于大型在线在线活动。

在广播中没有直接连接，但是一些网络被分配给广播;实际上，即使内容不观看，内容也被流传给所有用户 - 因特网路由器基本上不转发广播数据包，因此路由IP网络之间无法进行广播。

在多播中，最终用户通过用他们自己的路由器注册他们对流的兴趣进行调整，然后将路由器注册到所有路由器。然后，路由器确定它们只需要将数据包的一个副本发送到下一个路由器（而不是每个用户一个）。然后，最后一个路由器只需要将数据包一次发送到最终的接入网络，但是在目前的情况下，所有想要数据包的接收者都同时被调入。因此，无论是一个收件人还是数千个（就像企业网络中一样），负载仍然只是一个最终用户。

这意味着许多不同的广播可以同时传送给许多使用互联网的互联网用户，观众人数不再受中央服务器的大小限制（或者在传统的纯播放CDN的情况下，分布式网络的服务器也可以。

原文连接: http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/The-Return-of-Multicast-Why-it-Succeeds-in-a-Live-Linear-World-108621.aspx(科学上网)

rfc的文档还是不链接上来了，请到官网查看。

组播不对，单播也不对。

各个大平台提供“CDN”就近分发，自适应地调整组播和单播。

这也是为什么平台要收份子钱的主要原因。

对平台而言，CDN服务器遍布各地，上线的直播越多他的CDN就越划算。对主播而言，如果没有平台，那么他的机器和网络撑不住那么大的流量的。

好问题，正好和我现在公司的业务完全吻合

首先直播平台不是。

现在主流直播平台是走cdn+p2p分发，也就是融合cdn，我们公司的主要产品。昨天还在给某直播平台的cdn服务器装系统。

其次直播的录播，可以视为文件分发，和优酷，youtube这些视频网站是一样一样。

下班回家再来细讲。

这个问题我也困惑了好久，听了车小胖的回答总算是明白了。我觉得目前主流的宽带接入方式是 PPPoE ，PPPoE 属于点对点连接，想要实现主播应该不可能吧。

谢邀，中间网络可能是，到终端一定不是，车总回答的很详细了，通俗易懂的讲，据我之前学习仅存的一点映像，组播需要端到端，所有网络设备都要做组播相关配置，显然如今的网络，尤其是自己家里的那部分，根本没有达到这种程度的。

大部分都是单播，IPTV应该是采用了组播的。

网上找了下两者的优缺点。

单播的优点：

　　1. 服务器及时响应客户机的请求

　　2. 服务器针对每个客户不同请求发送不同数据，容易实现个性化服务。

单播的缺点：

　　1. 在客户数量大、每个客户机流量大的流媒体应用中服务器不堪重负。

　　2. 现有的网络带宽是金字塔结构，如果全部使用单播协议，将造成网络主干不堪重负。

组播的优点：

　　1. 需要相同数据流的客户端加入相同的组共享一条数据流，节省了服务器的负载。具备广播所具备的优点。

　　2. 由于组播协议是根据接受者的需要对数据流进行复制转发，所以服务端的服务总带宽不受客户接入端带宽的限制。所以其提供的服务可以非常丰富。

　　3. 此协议和单播协议一样允许在Internet宽带网上传输。

组播的缺点：

　　1．与单播协议相比没有纠错机制，发生丢包错包后难以弥补，但可以通过一定的容错机制和QOS加以弥补。

　　2．现行网络虽然都支持组播的传输，但在客户认证、QOS等方面还需要完善，这些缺点在理论上都有成熟的解决方案，只是需要逐步推广应用到现存网络当中。

可以看出，直播这种需要双方互动的更适合用单播。

现在只有三大运营商自己的IPTV业务是组播协议。第三方的互联网应用不可能开放这么基础的网络层应用的。

可控组播可难搞了，各层级设备都要严格测试和配置

也许组播会是以后的发展方向，但现在还是类似传统CDN方式。好像高级一点的有用类似P2P的。

完全不懂网络工程，不过有一段时间（现在没有了），一打开斗鱼就同时有下载和上传的流量，像P2P一样。