宽带网与组播

http://www.mvn.cn/multicast-broadband.htm

自从上世纪末长城宽带壮烈的宽带推广运动以来，宽带网一直面临种种问题，但这些问题归结起来就是一个问题，那就是客户端得不到与其接入带宽相称的足够的数据流。

最早的长城宽带面临的是“宽带无内容”的问题，客户得不到其承诺的视频点播等宽带娱乐，于是投诉、退户甚至诉诸法律。

电信凭借其雄厚的财力和电话线资源后来居上，但很快又面临网速慢、缺内容的投诉，电信网站上的视频点播似乎总是无尽的等待和缓冲。后来P2P软件的出现使得某些比较专业的用户似乎看到了希望，他们用BT、电驴等软件互传电影等娱乐信息也凑合了。没多久电信和网通就高举着和他们没什么关系的版权大旗封杀了BT、电驴等软件。

所有这些都是源于现在宽带网的“上下非对称”的金字塔结构，也就是网络主干的带宽远远小于所有用户带宽之和，但现在网络使用的单播通讯协议却要求网络主干的带宽等于或接近所有用户带宽之和。现在的状况是一个城市或省的网络出口主干的带宽大约相当于其所有客户带宽之和的5％，也就是说假如有5％的客户用BT软件通过网络全速传输数据，那其余95％的客户就不要玩了。现在电信主干上的流量的75％都是P2P应用的流量，已经超过了电信所能承受的极限。

那么采用CDN技术，将网络内容在城域网内就近缓冲行不行呢？答案是：技术上可行经济上行不通。其需要的服务器是一个巨大的天文数字。现在的大中城市的宽带网用户数量都在20万以上，以此数量来计算光购置CDN服务器就需要2亿元左右！这就是为什么电信不用CDN技术来满足客户需求的原因。所以在服务器的服务能力和客户机的需求上也存在着严重的上下非对称结构。

那么这个死结是不是没法解开呢？当然不是，组播协议的数据流特点就是“上下非对称”的，也就是说，在网络主干上的一条数据流通过每层交换机的复制可以变成无数客户端的数据流，形成客户端数据流之和远大于主干数据流的金字塔结构。这一特点正好与现在的网络结构相符。所以说，基于组播协议的流媒体宽带娱乐可以解决这一问题。

举例来说，使用基于组播协议的直播系统可以用一台服务器支持数万客户收看一个或几个频道的网上电视直播。假设一共提供100个频道的电视节目，每个频道是1M的MPEG4高清晰码流，则无论有1万客户还是100万客户，其占用的网络主干都是100M，而3～5台服务器硬件的投资不到100万。

    如果采用我们专利技术的基于组播的VOD系统，客户还可以享受到廉价的点播服务。由于其采用的是组播协议，无论对于网络主干还是VOD服务器的压力都很小。