原创重点：广义广播和狭义广播的定义，以组播逻辑实现单播优点的算法假想

单播 (unicast)：
CLIENT和SERVER之间一对一的通讯模式，交换机和路由器对数据只进行转发而不进行复制，假设有100个CLIENT对SERVER点播同样的一部电影，那么SERVER就需要重复做100次发送动作，对服务器负荷很大。但优点是能够针对每个客户及时响应，满足个性化操作。比如现在的网页浏览、网页里内嵌的在线播放、在线网络游戏就是这种单播方式。单播可以对CLIENT的暂停/继续，快进/快退，拖进度条等操作做出响应。不过如果网络上广泛应用的IPTV SERVER做成满足单播的话，要求点播的CLIENT太多服务器就扛不住了。

广播 (broadcast) ：
这里说的“广播”是指像目前模拟电视信号或广播电台信号那样地广播出来，不管CLIENT看不看听不听，所有线路全部强塞信号过去，这种做法我们姑且发明个词称之为“广义广播”。这样做显然SERVER是最轻松的，只发一份数据出去，让底下的线路自己去复制。显然Internet上不能这样子广播了，太占带宽资源了，所以IP协议里就只允许在同网段里广播，根本就禁止跨网段广播，这就是现在一般所说的同网段内“IP广播”，对应上面我称之为“狭义广播”。

组播 (multicast，或翻译成“多播”)：
我更愿意把组播理解为“广义广播”在INTERNET上的替代品，照我理解纯粹的IPTV应该是只从INTERNET上获得片源，所以必须绕开IP协议的限制来实现“广义广播”的主要目的。组播时SERVER对“一组一组”的CLIENT进行发送；而对同“组”的CLIENT，SERVER只发送一份数据，然后由交换机和路由器有选择地复制并转发给组内成员，CLIENT可以向路由器要求或退出某个小组。这样子既然可以避免浪费带宽向不需要信息的CLIENT强塞数据流，又实现了“广义广播”的主要目的，SERVER负担界于单播和广播之间。值得一提的是从组播的逻辑上来看，是不支持单独用户的暂停/继续、快进快退的。但是我们可以自己设计成支持单播的某些优点。

在逻辑上我假设出这样的组播应用场合：用户A向SERVER点播了电影ABC，这时候整个INTERNET上只有他一人点播，于是SERVER建立“会话a”后提示A等待5分钟后电影开始。5分钟内又有用户B、C、D先后加入这个会话，SERVER分别提示他们该电影在几分钟后开始。5分钟后“会话a”人数不足10人，但等待时间已到，所以开始组播。或者在第3分钟的时候，该会话已达到10人，所以播放开始。当电影进行到第10分钟的时候，用户E查看到这个组播信息，认为反正刚开始不久，就加入该组。在第20分钟的时候，用户F点播同样的电影ABC，这时候服务器建立“会话b”，并提示F等待5分钟后电影开始。其实这个逻辑有那么点像某些QQ游戏里“进入游戏房间”、“房主”、“X秒后开始游戏”的做法。

或者比如暂停，用户在播放过程中按下暂停，然后花N秒接了个电话，在这N秒内，IPTV收到的数据流并不立刻解码并显示出来，而是暂存在FLASH里。假设这个FLASH容量和接收速率计算后得知该FLASH可以缓存该影片60秒，那么假设用户在50秒时回到电视前按下“继续播放”，则IPTV告诉用户已经落后组播50秒，这时候用户可以选择继续占用50秒的缓存，常速播放，那么意味着下一次暂停只能存下10秒；或者他选择2倍速快进追上组播的时间，或者选择丢弃暂存的数据直接跳到组播时间。

上面这两种关于“点播”和“暂停”的假想算法都是满足组播逻辑，然后去追求实现单播优点的。

所以，IPTV应用在网络媒体播放上面应该是以组播为主、单播为辅，这是由INTERNET的特点和目前SERVER技术决定。当然对于用户来说最希望的是个性化的单播了，如果未来SERVER技术上出现某种突破，可以轻松应对几万几十万个单播服务，那么组播方式就可以退出历史舞台了。

本文转自Walzer博客园博客，原文链接：http://www.cnblogs.com/walzer/archive/2006/10/24/538028.html，如需转载请自行联系原作者