多媒体网络应用的类型
- 流式存储音频/视频；
- 实时交互语音/视频；
- 流式实况音频/视频；
基本特性：
典型的时延敏感但容忍丢包。
时延抖动：是在相同分组流中分组时延的变动。
流式存储音频和视频
媒体存储在源中
传输到客户机
流式：在所有数据到达之前，客户机播放开始。
- 流。在流式存储视频应用中，客户开始从服务器接收文件几秒之后，通常就开始播放视频。这意味着当客户正在从视频的一个位置开始播放时，与此同时正在从服务器接收该视频的后续部分。这种技术被称为流，它避免了在开始播放之前必须下载整个视频。
- 相互作用。因为媒体是预先录制的，用户可以对多媒体内容进行暂停、前进、倒退、快进等操作。
- 到目前为止，对流式视频最重要的性能测量是平均吞吐量。为了提供连续的播放，网络为流式应用提供的平均吞吐量必须至少与该流视频本身的比特率一样大。
流式视频系统 可分为三种类型：UDP 流、HTTP 流和适应性 HTTP 流。
UDP流
使用UDP流，服务器通过UDP以一种稳定的速率记录下视频块，用与客户的视频消耗速率相匹配的速率传输视频。在将视频块传递给UDP之前，服务器将视频块封装在运输分组中，该运输分组是专门为传输音频和视频而设计的，使用了实时传输协议（RTP）。UDP流的另一种不同的性质是，除了服务器到客户的视频流外，两者间还并行地维护一个单独的控制连接（RTSP）实时流协议，通过该连接，客户可发送有关会话状态变化的命令（如暂停、重新 开始、重定位等）。这种控制连接在许多方面类似于我们在第2章中学习的FTP控制连接。
尽管UDP流已经在多个开源系统和专用产品中得到应用，但它有三个重大不足。
- 由于服务器和控制之间的可用带宽无法预测并且是变化的，恒定速率UDP流不能够 提供连续的播放。
- 它要求如RTSP服务器这样的媒体控制服务器，以对每个进行中的客户会话处理客户到服务器的交互。请求和跟踪客户状态（例如在视频中的客户播放点，视频是否被暂停或播放等）。这增加了部署大规模的按需视频系统的总体成本和复杂性。
- 许多防火墙配置为阻塞UDP流量， 防止这些防火墙后面的用户接收UDP视频。
HTTP
在HTTP流中，视频直接作为具有一个特定URL的普通文件存储在HTTP服务器上。 当用户要看视频时，客户和服务器之间建立一个TCP连接，并且发送一个对该URL的 HTTP GET请求。服务器则尽可能快地在HTTP响应报文中发送该视频文件，这就是说， 以TCP拥塞控制和流控制允许的尽可能快的速率进行处理。在客户端上，字节收集在一个客户应用缓存中。一旦在缓存中字节数量超过了预先设定的阈值，该客户应用程序开始播放，具体而言，它周期性地从客户应用缓存中抓取视频帧，对帧解压缩并在用户屏幕上显示它们。在TCP上使用HTTP也使得视频穿越防火墙和NAT （它们常常被配置为阻挡UDP流 量但允许大部分HTTP流量通过）更为容易。HTTP流消除了因需要媒体控制服务器（如 RTSP服务器）带来的不便，减少了在因特网上大规模部署的成本。由于所有这些优点， 今天的大多数流式视频应用（包括YouTube和Netflix）都使用HTTP流（在TCP上）作为它的底层流式协议。
适应性 HTTP 流
在DASH中，视频编码为几个不同的版本，其中每个版本具有不同的比特率，对应于不同的质量水平。客户动态地请求来自不同版本且长度为几秒钟的视频段数据块。当可用带宽量较高时，客户自然地选择来自高速率版本的块；当可用带宽量较低时，客户自然地选择來自低速率版本的块。客户用HTTP GET请求报文一次选 择一个不同的块。一方面，DASH允许客户使用不同的以太网接人速率流式播放具有不同编码速率的视频。使用低速3G连接的客户能够接收一个低比特率（和低质量）的版本，使用光纤连接的客户能够接收高质量的版本。在另一方面，如果端到端带宽在会话过程中改变的话， DASH允许客户适应可用带宽。这种特色对于移动用户特别重要，当移动用户相对于基站移动时，通常他们能感受到其可用带宽的波动。
流式实况音频和视频
这种第三类应用类似于传统的电台广播和电视，只是它通过因特网来传输而已。
流式:
重放缓存
重放能够滞后传输几十秒
仍有顶时约束
交互性：
不可能快进
可以暂停，倒带
实时交互语音/视频
如IP电话、视频会议等。
端到端时延要求
在第2章有关应用服务需求的讨论中,我们确定了一些轴，服务需求可以根据它们分类。其中的两个轴（即定时考虑和数据丢失容忍度）对会话式语音和视频应用尤其重要。定时考虑是很重要的，因为音频和视频会话式应用是高度时延敏感的。对于具有两个或更多个交互讲话者的会话来说，从用户讲话或移动开始到该动作显现在其他端的时延应当小于几百毫秒。对于语音，小于150ms的时延不会被人类听者觉察到，150〜400ms的时延能够被接受，当时延超过400ms时，即使不会使对话变得完全无 法理解，也会使语音会话变得令人沮丧。
另一个方面，会话式多媒体应用容忍丢包，即偶尔的丢失只会在音频/ 视频回放时偶尔出现干扰信号，而且这些丢失经常可以部分或者全部地隐藏。这些时延敏感但容忍丢包的特性明显不同于那些弹性数据应用（如Web浏览、电子邮件、社交网络 和远程注册等）的特性。对于这些弹性应用，长时延令人恼火，但并不是特别有害，然而传输数据的完全和完整性是首要的。
实时会话应用的协议
实时协议（RTP）
RTP基础
RTP通常运行在UDP之上：
发送端在每个语音数据块的前面加上一个RTP首部，这个首部包括音频编码的类型、序号和时间戳。RTP首部通常是12字节。音频块和RTP首部 一起形成RTP分组。然后向UDP套接字接口发送该RTP分组。在接收端,应用程序从它的套接字接口收到该RTP分组，从RTP分组中提取出该音频块，并且使用 RTP分组的首部字段来适当地解码和播放该音频块。
RTP并不提供任何机制来确保数据的及时交付，或者提供其他服务质量保证；它甚至不保证分组的交付，或防止分组的失序交付。
RTP允许为每个源分配一个它自己的独立RTP分组流。
RTP分组并非限用于单播应用，它们也可以在一对多和多对多的多播树上发送。对于 一个多对多的多播会话，所有的会话发送方和源通常使用同样的多播组来发送它们的RTP 流。
RTP分组首部
效载荷类型：RTP分组中的有效载荷类型字段的长度是7比特。
序号字段：序号字段长为16比特。每发送一个RTP分组则该序号增加1，而且接收方可以用该序号来检测丢包和恢复分组序列。
时间戳字段：时间戳字段长32比特。它反映了 RTP数据分组中的第一个字节的采样时刻。
同步源标识符（SSRC）。SSRC字段长为32比特。它标识了RTP流的源。
实时控制协议（RTCP）
与RTP协调工作
在RTP会话中每个参与者周期性的向其他参与者传输RTCP控制分组。
每个RTCP分组包含发送方或接收方报告。
统计参数包括分组发送数量，丢失数量，到达间的时延抖动。
会话发起协议（SIP）
SIP不定义要建立的会话类型，而只定义应该如何管理会话。
会话发起协议是一个开放和轻型的协议，其功能如下：
- 提供了在主叫者和被叫者之间经IP网络创建呼叫的机制。它允许主叫者通知被叫 者它要开始一个呼叫。它允许参与者约定媒体编码，也允许参与者结束呼叫。
- 提供了主叫者确定被叫者的当前IP地址的机制。因为用户可能动态地分配到地址（使用DHCP）,而且因为它们可能有多个IP设备，每个都有一个不同的IP地址，所以用户不具有单一的、固定的IP地址。
- 提供了用于呼叫管理的机制，这些机制包括在呼叫期间增加新媒体流、在呼叫期 间改变编码、在呼叫期间邀请新的参与者、呼叫转移和呼叫保持等。
向已知IP地址建立一个呼叫
当Alice给Bob发送一个INVITE报文。该INVITE报文通过UDP发送给SIP的周知端口 5060。（SIP 报文也可以经TCP发送）该INVITE报文包括了对Bob的标识（bob@ 193.64.210.89）、 Alice当前IP地址的指示、Alice希望接收的音频的指示，以及她希望在端口 38060接收RTP分组的指示。在收到了Alice的INVITE报文之后，Bob发送一个SIP响应报文。该响应SIP报文也被发送到SIP端口 5060。Bob的响应包括一个200 ok和他的IP地址的指示、他希望接收的编码和分组化，以及音频数据应该发送到达的端口号。在接收到Bob的响应后，Alice向Bob发送SIP确认报文。在这之后，Bob和Alice可以交谈了。Bob 会根据要求对音频进行编码和分组化，并将音频分组发送给IP地址167. 180. 112. 24的端口号38060。Alice也会根据要求对音频进行编码和分组化，并将音频分组发送给IP地址193. 64.210. 89 的端口号 48753。
从丢包中恢复
向前纠错
FEC的基本思想是给初始的分组流增加冗余信息。以稍微增加传输速率为代价，这些冗余信息可以用来重建一些丢失分组的近似或者准确版本。我们现在概括了两种简单的FEC机制。第一种机制是每发送n个块之后发送一个冗余编码的块。这个冗余块通过异或n个初始块来获得，在这n + 1个分组的组中，如果任何一个分组丢失，接收方能够完全重建丢失的分组。但是如果这一组中有两个或更多分组丢失，接收方则无法重建丢失的分组。通过让组的长度n + 1比较小，当丢失不是很多时，大部分丢失分组都可以恢复。然而组的长度越小，相对增加的传输速率就越大。特别是若传输速率以1/a因子增加的话，例如n=3, 则传输速率增加33%。此外，这个简单的方案增加了播放时延，因为接收方在能够开始播放之前，必须等待收到整个组的分组。
第二个FEC机制是发送一个较低分辨率的音频流作为冗余信息。例如，发送方可能创建一个标称的音频流和一个相应的低分辨率、低比特率的音频流。(这个标称流可能是一 个64kbps的PCM编码，而这个较低质量的流可能是一个13kbps的GSM编码。)这个低比特率流被认为是冗余信息。发送方通过从这个标称流中取出第n个块并附 加上第( n-1)个块的冗余信息，以构建第 n个分组。以这种方式，只要没有连续分组的丢失，接收方都可以通过播放和后续分组一起到达的低比特率编码块来隐藏丢失。当然， 低比特率块比标称块的质量要低。然而，在一个流主要是由高质量块组成、偶尔出现低质 量块并且没有丢失的块的情况下，其整体的音频质量良好。注意到在这种方案中，接收方在播放前只需接收两个分组，因此增加的时延小。此外，如果低比特率编码比标称编码少得多，那么传输速率的额外增加并不大。
为了处理连续丢失，我们能够使用率一个简单的修正方案。发送方不再仅为第〃个标 称块附加上第( n - 1 ) 个低比特率块，而是附加上第( n - 1 ) 个和第( n - 2 ) 个低比特 率块，或者附加第( n-1 ) 个和第( n-3 ) 个低比特率块等等。通过给每个标称块附加 上更多低比特率块，在各种恶劣的尽力而为服务环境下接收方的音频质量变得可接受。在 另一方面，附加的块增加了传输带宽和播放时延。
交织
作为冗余传输的另一种替代方案，VoIP应用可以发送交织的音频。如图所示，发送方在传输之前对音频数据单元重新排序，使得最初相邻的单元在传输流中以一定距离分离开来。交织可以减轻丢包的影响。例如，如果每个单元长为5ms，块是20ms （也就是每 个块4个单元），那么第一个块可能包含1、5、9和13单元；第二个块可能包含2、6、10 和14单元等等、图显示了一个交织流的单个丢包导致重建流中的多个小间隙，这与 在非交织流中将会导致单个大间隙形成对照。
交织能够明显地提高音频流可感觉到的质量。它的开销也较低。交织 明显的缺点是增加了时延。这限制了它在如VoIP这样的会话式应用中的使用，然而它能 够很好地处理流式存储音频。交织的一个主要优点是它不增加流的带宽需求。
差错掩盖
差错掩盖方案试图为丢失的分组产生一个与初始分组类似的替代物。因为音频信号呈现出大量的短期自相似性，故该方案是可行的。正因为如此，这些技术适合于工作在相对小的丢包率（低于15%）和小 分组（4~40ms）的情况。当丢失长度接近音素的长度（5 ~ 100ms）时，这些技术就失效了，因为整个音素可能被听者错过。
也许基于接收方的恢复的最简单方式是分组重复。即用在丢失之前刚到达的分组的副 本来代替丢失的分组。这种方法的计算复杂度低，并且工作得相当好。基于接收方恢复的 另一种形式是内插法，它使用在丢失之前和之后的音频内插形成一个合适分组来隐藏丢 失。内插法比分组重复稍微好一些，但是显然需要更高的计算强度。
内容分发网
为了应对向分布于全世界的用户分发巨量视频数据的挑战，几乎所有主要的视频流公司都利用内容分发网（CDN）。CDN管理分布在多个地理位置上的服务器，在它的服务器中存储视频（和其他类型的Web内容，包括文档、图片和音频）的副本，并且所有试图将每个用户请求定向到一个将提供最好的用户体验的CDN位置。CDN可以是专用CDN,即它由内容提供商自己所拥有；例如，谷歌的CDN分发YouTube视频和其他类型的内容。另一种CDN可以是第三方CDN,它代表多个内容提供商分发内容；例如，Akamia的CDN是一个第三方CDN，在其他用户中分发Netflix和Hulu。
CDN通常采用两种不同的服务器安置原则
深入：
第一个原则由Akamai首创，该原则是通过在遍及全球的接入ISP中部署服务器集群来深入到ISP的接入网中。Akamai在大约 1700个位置采用这种方法部署集群。其目标是靠近端用户，通过减少端用户和CDN集群之间链路和路由器的数量，从而改善了用户感受的时延和吞吐量。因为这种髙度分布式设计，维护和管理集群的任务成为挑战。
邀请做客:
第二个设计原则由Limelight和许多其他CDN公司所采用，该原则是通过在少量关键位置建造大集群并使用专用高速网络连接这些集群来邀请到ISP做客。不是将集群放在接人ISP中，这些CDN通常将每个集群放置在这样的位置上，即同时靠近许多第一层ISP的PoP的位置，例如， 一个大城市中同时靠近AT&T PoP和Verizon PoP的几英里范围内。与深入设计原则相比，邀请做客设计通常产生较低的维护和管理开销，可能以对端用户的较高时延和较低吞吐量为代价。
一旦CDN的集群准备就绪，它就可以跨集群复制内容。CDN可能不希望将每个视频的副本放置在每个集群中，因为某些视频很少观看或仅在某些国家中流行，事实上，许多 CDN没有将视频推入它们的集群，而是使用一种简单的拉策略：如果客户向一个未存储该视频的集群请求某视频，则该集群检索该视频（从某中心仓库或者从另一个集群），向客户流式传输视频时的同时在本地存储一个副本。类似于因特网缓存，当某集群存储器变满时，它删除不经常请求的视频。
CDN操作
在讨论过这两种部署CDN的重要方法后，我们现在深人看看CDN操作的细节。当用户主机中的一个浏览器指令检索一个特定的视频（由URL标识）时，CDN必须截获该请求，以便能够：
①确定此时适合用于该客户的CDN服务器集群；
②将客户的请求重定向 到该集群的某台服务器。大多数CDN利用DNS来截获和重定向请求；
我们考虑用一个简单的例子来说明通常是怎样涉及DNS的。假定一个内容提供商NetCinema,雇佣了第三方CDN公司KingCDN来向其客户分发视频。在NetCinema的Web 网页上，它的每个视频都被指派了一个URL，该URL包括了字符串“video”以及该视频 本身的独特标识符；例如，转换器7可以指派为http：#video. netcinema. com/6Y7B23V。接下来出现如图7-4所示的6个步骤：
- 用户访问位于NetCinema的Web网页。
- 当用户点击链接http：//video, netcinema. com/6Y7B23V时，该用户主机发送了一个 对于 video, netcinema. com 的 DNS 请求
- 用户的本地DNS （LDNS）服务器中继该DNS请求到一台用于NetCinema的权威 DNS服务器，该服务器观察到主机名video, netcinema. com中的字符串“video”。为了将该 DNS 请求移交给KingCDN, NetCinema权威DNS 服务器并不返回一个IP地址，而是向 LDNS 返回一个 KingCDN 域的主机名，如 al 105. kingcdn. com。
- 从这时起，DNS请求进人了 KingCDN专用DNS基础设施。用户的LDNS则发送第 二个请求，此时是对al 105. kingcdn. com的DNS请求，KingCDN的DNS系统最终向LDNS 返回KingCDN内容服务器的IP地址。所以正是在这里，在KingCDN的DNS系统中，指定了 CDN服务器，客户将能够从这台服务器接收到它的内容。
- LDNS向用户主机转发内容服务CDN结点的IP地址。
- 一旦客户收到KingCDN内容服务器的IP地址，它与具有该IP地址的服务器创建 了一条直接的TCP连接，并且发出对该视频的HTTP GET请求。如果使用了 DASH,服务 器将首先向客户发送具有URL列表的告示文件，每个URL对应视频的每个版本，并且客 户将动态地选择来自不同版本的块。
集群选择策略
任何CDN部署，其核心是集群选择策略，即动态地将客户定向到CDN中服务器集群或数据中心的机制。如我们刚才所见，CDN经过客户的DNS查 找得知了该客户的LDNS服务器的IP地址。在得知该IP地址之后，CDN需要基于该IP地 址选择一个适当的集群。CDN —般采用专用的集群选择策略。我们现在简单地介绍一些自然的策略，每种策略都有其优点和缺点。
一种简单的策略是指派客户到地理上最为邻近的集群。使用商用地理位置数据库,每个 LDNS IP地址都映射到一个地理位置。当从一个特殊的LDNS接收到一个DNS请求时， CDN选择地理上最为接近的集群，即离LDNS几千米远的集群，“就像鸟飞一样”。这样的 解决方案对于众多用户来说能够工作得相当好。但对于某些客户，该解决方案可能执行的效果差，因为地理最邻近的集群可能并不是沿着网络路径最近的集群。此外，一种所有基于DNS的方法都内在具有的问题是某些端用户配置使用位于远地的LDNS。在这种情况下，LDNS位置可能远离客户的位置。此外，这种简单的策略忽略了时延和可用带宽随因特网路径时间而变化，总是为特定的客户指派相同的集群。
为了基于当前流量条件为客户决定最好的集群，CDN能够对其集群和客户之间的时延 和丢包性能执行周期性的实时测量。例如，CDN能够让它的每个 集群周期性地向位于全世界的所有LDNS发送探测分组（例如，ping报文或DNS请求）。 这种方法的一个缺点是许多LDNS配置为不会对这些探测进行响应。
发送测量路径性质的外部流量的另一种方法是，使用客户与CDN服务器之间近期和 进行中的流量特点。例如，客户与集群之间的时延能够通过观察TCP三次握手过程中服务 器到客户SYNACK和客户到服务器ACK之间的间隙进行估计。然而，这种解决方案为了 测量到这些集群路径的性质，时不时地需要将客户重定向到（可能的）次优化集群。尽管 仅有少量的请求需要作为探测分组而工作，但选择的客户在接收内容（视频或其他）时可 能经受很大的性能下降。对于集群到客户路径的另一种探测方法是使用DNS请求流量来测量客户和集群之间的时延。具体而言，在DNS阶段（在 图7-4步骤4中），客户的LDNS能够偶尔地定向到不同的权威DNS服务器，这些服务器 可以安装在各个集群位置，产生DNS流量，这些流量则能够在LDNS和这些集群位置之间 测量到。使用这种方案，DNS服务器继续向该客户返回优化的集群，使得交付视频和其他 Web对象不会受到损害。
使客户与CDN服务器匹配的一种非常不同的方法是使用IP任播。IP任播基于的思想是让因特网中的路由器将客户的分组路由到“最近的”集群， 就像由BGP决定的那样。具体而言，如图7-5中所示，在IP任播配置阶段，CDN公司为 它的每个集群指派相同的IP地址，并且使用标准的BGP从每个不同的集群位置来通告该 IP地址。当一个BGP路由器接收到对这个相同的IP地址的多个路由通告时，它对待这些通告就像对相同的物理位置提供了不同的路径（事实上，在这个时候，这些通告对不同的物理位置用了不同的路径）。遵循标准的操作过程，则BGP路由器将根据其本地路由选择机制，对该IP地址选择“最好的”（例如最近的，就像AS跳计数所决定的那样）路由。 例如，如果一个BGP路由（对应于一个位置）离该路由器仅一个AS跳的距离，并且所有 其他BGP路由（对应于其他位置）是两个或更多AS跳，则BGP路由器将通常选择使分 组路由到需要仅通过一个AS的位置（参见4. 6节）。在这个初始配置阶段后，CDN能够从事内容分发的主要工作。当任何客户要观看任何视频时，CDN的DNS返回该任播地址， 而无论该客户位于何处。当客户向该IP地址发送分组时，该分组被路由到“最近的”集 群，如同由预先配置的转发表决定的那样，该转发表用BGP进行配置，如刚才描述的那 样。这种方法具有如下优点，发现的集群最靠近客户而不是最靠近该客户的LDNS。然而， IP任播策略仍未顾及因特网在短时间范围内的动态性质。
除诸如时延、丢包和带宽性能等网络相关考虑外，在设计集群选择策略时还有许多要考虑的重要因素。集群上的负载就是一个这样的因素，即客户不应当定向到过载的集群。ISP交付成本是另外一个因素，即可以选择特定的集群，使得用特定的ISP承载CDN 到客户的流量，兼顾到1SP和集群操作者之间的契约关系中的不同的成本结构。
分组调度
FIFO
优先权
RR（轮询调度）
分组1、2、3
先1后2最后3
WFQ（加权公平排队）
与RR相似，不同点在于,每个类在任何时间间隔内可能收到不同数量的服务。
考纲
多媒体网络
（1） 多媒体网络的应用
（2） 内容分发网络（CDN）的基本原理：CDN在YouTuBe、Netflix中的应用
（3） 综合服务和区分服务
