多媒体技术原理及应用(马华东第二版)第十章剖析.ppt

第十章基于Internet的多媒体技术 概念与问题 IP组播 IP QoS保障机制 IP多媒体网络的相关问题 10.1 概念与问题 TCP/IP是一个协议组, 主要包括TCP、UDP和IP, 其制定的是传输层和网络层的标准。其中： (1) TCP 称为传输控制协议, 其作用是保证命令或数据能正确无误地到达目的地。TCP是可靠的; (2) UDP 称为用户数据报协议,它和TCP一样都是传输层协议。与TCP不同,它是不可靠的,不对发出的报文进行跟踪,也就不能保证每个UDP报文达到目的地址。但由于它减少了网络开销, 因此效率很高; (3) IP称为互联网协议, 它位于TCP的下一层, 负责完成互联网中包的路由选择, 并跟踪这些包到达不同目的端的路径。IP还要对一些可能出现的情形, 如不同传输介质间的不一致性等进行处理。 现场声音和视频广播 这类似于普通的无线电和电视广播，不同的是传输网络为Internet网。 目前产品如RealNetworks Broadcasters; 声音点播 客户在任何时间任何地点从声音点播服务器读声音文件。许多产品也为用户提供交互功能。 典型产品RealNetworks RealPlayer和VocalTec的Internet Wave; 视频点播 这是一类典型的交互式多媒体服务系统。视频点播系统一般运行在宽带网中。 目前已有很多运行于Internet网上的视频点播产品; IP电话 是在IP网络上进行呼叫和通话, 这种应用支持人们在Internet网上进行通话。目前IP电话价格便宜, 但质量较差。 分组实时视频会议 这类应用系统与IP电话类似，但可传输视频图象并允许多人参加。目前已有许多此类产品。 从多媒体信息传输来讲, Internet提供两种类型的服务： (1)可靠的面向连接服务, 用TCP协议,对信息包时延要求不高; (2)不可靠的无连接服务, 使用UDP协议,不保证不丢包也不保证时延满足需求。 Internet网现在对多媒体包的传送中,各包平等,无优先之分,是尽力传输机制，难以保证多媒体实时应用的需求。 目前应该解决问题：提高网络带宽,减少时延;减少抖动。 解决问题的思路一般从2个方面考虑： (1)扩大链路带宽 费用太大,且易被多媒体业务吃掉; (2)改进Internet协议 采用这种方法对网络系统做较大的变更,对多媒体应用保证端对端带宽,如对IP电话途中每个链路预留带宽。 10.2 IP组播 10.2.1 基本概念 IP地址分5类： (1) A类、B类、C类是基本的因特网地址； (2) D类(-55)用于组播的地址; (3) E类是保留地址。 发送端和接收端及其之间的网络设施都必须具备多播功能。 对本地的IP组播, 主机节点所需要的环境是: TCP/IP协议栈中可支持IP组播； 软件支持Internet组管理协议(IGMP), 这样就可以申请参加组播组和接收组播； 要有IP组播应用软件。 10.2.2 组播路由选择算法 目标—建立一个组播树使组播包传送到目标站点。 1. 泛洪法(Flooding) 当路由器收到一个组播包时它首先会检查是否是第一次收到此包, 若是把该包转发给所有相连节点; 否则简单地丢弃该包。利用这种方式我们可保证所有互连的路由器会至少接到包的一个拷贝。 该算法已经用在OSPF协议中。 简单, 但效率不高。 2.支撑树(Spanning Tree)算法。 这个算法已被IEEE-820 MAC采用,它有效且容易实现。 该算法利用求图的最优支撑树算法, 选择一个互连链路的集合组成一个树结构使任何两个路由器之间只有一条路径。因为树连接了网中所有节点,所以被称为支撑树。 支撑树算法的缺点是: 它把所有流量集中在一个小的链路集合, 且没有考虑组成员特点。 3.反向路径广播（Reverse Path Broadcasting, RPB ） 该方法不是建立一个全网络的支撑树,而是为每个源节点构造一个隐含的支撑树。 4. 修剪的反向路径广播(Truncated Reverse Path Broadcasting, TRPB) 算法克服了RPB算法的局限性。我们知道通过使用IGMP协议, 路由器可决定一个已知的组播组的成员是否在该路由器子网中。如果这个子网是一个叶子子网(不存在连到它的任何其它路由器),该路由器将从支撑树中剪除。这个过程一直到多余的分支被剪除掉为止。 5. Steiner树　 在RPB和TRPB算法中, 源节点和每个目的节点的最短路