简介
视频
- 高比特率。
- 能被压缩。
- 原因：空间冗余，图像内部有冗余空间，如空白；时域冗余，图像和后续图像完全一样或类似。
- 可压缩生成多重版本。
音频
- 脉冲编码调制（Pulse Code Modulation, PCM）。
- 采样。固定速率采样。
- 量化。每个采样值近似为有限数值中的一个。
- 级联。所有样本的量化值连在一起。
- 使用压缩减小比特率。如MP3等。
多媒体应用类型
- 流式存储的音频和视频。
- 流。从一个位置开始播放的同时，从服务器接收后续部分。
- 相互作用。用户可对媒体内容暂停、前进、后退等。
- 连续播放。根据初始记录的时序播放，需要及时接收数据，否则会停止或者帧跳过。
- 会话式 IP语音和视频。
- 称为因特网电话，或者IP语音（Voice-over-IP, VoIP）。
- 高度时延敏感（delay-sensitive）。
- 容忍丢包（loss-tolerant）。
- 流式实况音频和视频。类似流式存储媒体。
流式存储视频
- 分为UDP流、HTTP流、适应性HTTP流。
- 广泛使用客户缓存（client buffering）。
- 吸收分组在客户和服务器中时延的波动，使时延大的特殊分组不被注意。
- 即使暂时带宽低于消耗，也能连续播放。
UDP流
- 通过UDP，用与客户视频消耗速率相匹配的速率传输视频。
- 使用的客户端缓存小，通常小于1s。
- 通过单独的控制连接，发送暂停等命令。类似FTP控制连接，使用实时流协议（Real-Time Streaming Protocol, RTSP）。
- 缺点：
- 带宽减小时，恒定速率UDP流很可能无法连续播放。
- 需要RTSP服务器，增加成本。
- 许多防火墙**阻塞**UDP流量。
HTTP流
- 使用 HTTP GET 请求获得给定URL的文件。通过缓存等技术避免UDP的缺点。
- 预取视频。尝试以高于消耗速率的速率下载视频，增加客户缓存。
- 客户缓存和TCP缓存。客户缓存变满，会引起TCP缓存变满，减小发送窗口，服务器降低发送速率。
- 提前终止和重定位。
- 使用HTTP字节范围首部，从视频文件的某个字节开始发送数据，较早的请求终止。
- 因为重定位可能浪费缓存，所以缓存取适当长度或者字节范围首部受限。
DASH
- 经HTTP的动态适应性流（Dynamic Adaptive Streaming over HTTP, DASH），将视频编码为不同比特率的几个版本，分配不同URL，用户根据带宽选择版本。
- DASH可以在可能的最好质量下实现连续播放。
- 用户通过测试带宽选择下载版本，减轻服务器的压力。
CDN
- 单一数据中心的问题：
- 数据中心到客户经过许多ISP，某段链路吞吐量小，甚至小于视频消耗速率。
- 流行视频在相同链路中发送多次，浪费带宽。
- 单点故障问题。
- 内容分发网（Content Distribution Network, CDN）采取拉策略，用户请求的视频未存储在CDN上，CDN从另一个集群或者中心仓库请求视频，向客户传输视频并在本地存储副本。CDN删除不常使用的视频，类似LRU。
- CDN通过DNS截获和重定向对视频的请求，步骤：
- 用户访问netchina页面。
- 点击视频链接video.netcinema.com/xxxxx，发送DNS请求。
- 本地DNS服务器（LDNS）中继请求到NetChina权威DNS服务器，服务器因为video向LDNS返回KingCDN域的主机名，如a1105.kingcdn.com。
- LDNS向KingCDN的主机发起DNS请求，得到KingCDN**内容分发服务器的IP地址**。
- LDNS向用户转发CDN节点IP地址。
- 用户根据IP创建TCP连接，发起HTTP GET请求获取视频。
- 使用IP任播（IP anycast）为客户分配CDN服务器。为每个CDN集群指派相同IP地址，BGP路由器选择最好的路由（如地理最近、流量最佳等）。
- Netflix使用第三方CDN，谷歌的YouTube使用自己的CDN，迅雷看看使用P2P交付。
IP语音
尽力而为服务的限制
- 丢包。VoIP默认运行在UDP上，会产生分组丢失，可以通过FEC弥补。
- 端到端时延。时延超过400ms严重影响交互性，超过阈值（如400ms）延时的分组需要丢弃。
- 分组时延抖动。端到端时延对不同的分组可能有波动，可以使用序号、时间戳、播放时延消除。
消除时延抖动
- 两种机制：
- 发送方为每个块产生时间戳（timestamp）。
- 接收方延时播放（delaying playout），使得大多数分组在预定播放之前被接收。
- 两种播放时延。
- 固定播放时延。端到端时延抖动大，选用较大播放时延；时延抖动小，选用较小播放时延。
- 适应性播放时延。类似TCP往返时间的估计。
t，时间戳；r，分组接收时间；p，分组播放时间。
- 平均网络时延：
- 平均时延偏差：
- 播放时间（K为常数，例如4）：
- 平均网络时延：
- 固定播放时延。端到端时延抖动大，选用较大播放时延；时延抖动小，选用较小播放时延。
丢包恢复
- 前向纠错（Forward Error Correction, FEC）。增加冗余信息纠错，这样也会增加传输带宽和播放时延。
- 异或n个初始块。可恢复1个分组的丢失。
- 附加较低分辨率的音频。可附加之前一个或几个分组的低分辨率音频。
- 交织（interleaving）。传输之前对数据单元重新排序，接收之后重建。
- 差错掩盖。产生与丢失分组类似的分组，如重复分组或者内插法等。
实时会话应用协议
RTP
- 实时传输协议（Real-time Transport Protocol），运行在UDP上，传输媒体块。
- RTP不保证交付，不提供质量服务。RTP分装的内容仅为端系统可见。
- RTP也可用于多播，如多方的视频会议。
- RTP首部
- 有效载荷类型。指示音频编码类型，如PCM,GSM。
- 序号。每发送一个RTP分组，序号+1.
- 时间戳。RTP分组第一个字节采样时刻。
- 同步源标识符SSRC。表示RTP源，是新的流开始是随机分配的数。
SIP
- 会话发起协议（Session Initiation Protocol, SIP），用于经过IP网络建立呼叫。
- SIP地址。
- 类似电子邮件地址，如sip:bob@193.64.210.89。
- 能够被包括在Web页面中。
- SIP代理提供用户IP地址或者包括用户状态的URL（可以根据呼叫者有不同响应）。SIP代理是通过每个用户的SIP注册器确定用户的IP地址。
- 发起会话的步骤（217.123.56.89上的jim@umass.edu对197.87.54.21上的keith@upenn.edu发起VoIP）：
- Jim向umass的SIP代理发送INVITE报文。
- 该代理向SIP注册器upenn.edu**请求DNS**，并**转发**INVITE报文。
- keith并没有在该upenn注册器上注册，upenn注册器返回重定向报文指向Keith@eurecom.fr。
- umass代理向eurcom.fr**请求DNS**,并**转发**INVITE报文。
- 该注册器知道keith@eurecom.fr的IP地址，将报文转发给keith的SIP主机。
- keith主机通过注册器代理返回SIP响应到jim主机。
- jim发送SIP确认，并开始会话。
支持多媒体的网络
- 三种方法
尽可能利用尽力而为服务
- 进行网络定制（network dimensioning）。设计一个网络拓扑，取得给定的端到端性能。
- 由于经济、组织上的问题，定制被限制。
区分服务
- 方法
- 标记分组，使路由器区分不同类型的流量分组，例如VoIP优先于HTTP。
- 提供流量隔离的度，使一种流量不受另一种流量异常的影响，这需要流量监管（traffic policing）。例如，VoIP流量超过带宽，也能保证一定的HTTP流量。
- 提供流量隔离时，尽可能有效使用资源。例如，VoIP不使用带宽时，HTTP可以使用更多的带宽。
- 调度机制
- 先进先出（First-In-First-Out）。
- 优先排队（priority queuing）。分组放入某个优先级类，优先传输高优先级的类，每个优先级类通常使用FIFO。
- 加权公平排队（Weighted Fair Queuing, WFQ）。每个类被分到一个权值，每个类至少获得权值比例的带宽。
- 漏桶监管。
- 监管平均速率、峰值速率、突发长度。
- 分组需要获得令牌才能发送。漏桶最多容纳b个令牌，每秒加入r个令牌。这样任何t时间内，进入网络的最大速率为 rt+b。
- 漏桶流可以采用WFQ调度机制。
- 因特网区分服务体系结构（Diffserv）的功能
- 边界功能：分组分类、流量调节。
- 核心功能：转发。路由器每一条行为只基于分组标记，不区分分组来源，即路由器将这些分组作为一个聚合体。
- Diffserv的缺点
- 多个ISP之间协作困难。
- 如果网络运行负载不大，绝大多数情况里Diffserv效果不明显。
每连接服务质量保证
- 资源预留（resource reservaton）。一旦呼叫预约的资源，则需确保它所具有的资源。
- 呼叫准入（call admission）。如果请求的资源不可用，呼叫被阻塞；否则，接收呼叫的QoS需求。
- 呼叫建立信令。资源预留协议（resource Reservation Protocol, RSVP）用来协调资源的预留和呼叫准入。
1638
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
