多媒体网络
应用
视频：高比特率，但可以通过压缩的方式提供多重版本以适应不同的比特率
音频：通过每秒进行n次采样进行量化，并且可以进行压缩MP3 AAC
流式存储视频
都广泛应用了客户端缓存，通过几秒的加载：
- 通过缓存吸收了网络的时延波动
- 如果网络带宽暂时小于消耗速率，那也能继续播放
UDP流
- 实时传输协议RTP
由于UDP没有拥塞机制，所以UDP流能以视频消耗的速率将分组推入网络
- 实时流协议RTSP
这种协议除了一个UDP流，还独立维护一个控制连接，客户可以根据这个控制连接实时控制视频的播放暂停快进等
HTTP流
不借助其他辅助技术，由于TCP的拥塞控制和由于网络带宽的不确定性，流式视频是很难在基于TCP的网络是应用的。但如果借助预取跟客户端缓存，这就有可能了。
HTTP流可以利用HTTP字节范围首部，可以实现范围请求部分数据的效果
- 预取视频
客户通过以高于消耗速率的速率下载视频，这样就能应付某些情况下带宽降低的影响。
- 客户缓存与TCP缓存
当客户端暂停视频播放，客户端缓存一满就会有可能给服务器造成压力，这就导致服务器降低发送速率。
- 适应性HTTP流
DASH（动态适应流），通过视频的多个不同速率的版本来实现自适应。
IP语音
使用互联网传输的实时会话式语音
- 尽力为非服务的限制：无保证
关于丢包问题，使用TCP来实现会话式实时语音是不可接受的。但丢包问题并非是个严重的问题，可以采取纠错码的方式来对抗少量丢包。
对于端到端时延，超过400ms延迟的分组时不可接受的，因此超过这个阈值的分组一般直接就被丢弃了。
关于时延抖动问题，当考虑到路由器的排队时延，很有可能发送方相隔的两个分组时延会扩大。这需要采取一些手段来解决。
接收方消除时延抖动
为了消除抖动，使用两个机制组合一起实现：
- 为每个块设定一个时间戳
- 延迟播放
通过延迟播放的方式可以使接收方有一定的缓冲时间来将延迟到来的分组进行组合。
但这个时延的控制有两种：一种往往是固定时延，另外一种是根据网络状况来决定的动态时延。
丢包处理
- 前向纠错码，通过冗余的方式
- 交织：通过将丢失分摊到各个块上面
- 差错掩盖：音频信号会呈现出大量的短周期相似性，这些即使丢了也不会影响到实际语音
实时会话式应用协议
RTP
基于UDP，
SIP
提供了一个经IP网络创建呼叫的机制
SIP地址：sip:cxk@ismy.wang 这个时候可通过dns来进行解析
SIP报文跟HTTP报文类似
为了可以动态进行地址翻译，使用一个被称为SIP代理的东西来进行注册与发现。
支持多媒体的网络
| 方法 | 粒度 | 保证 | 机制 | 复杂性 | 当前部署 | 问题 |
|---|---|---|---|---|---|---|
| 尽可能利用尽力而为服务 | 公平处理所有流量 | 无或者软 | 应用级支持，CDN,覆盖网络，网络级资源供给 | 最小 | 无处不在 | 偶然出现的丢包和过大的端到端时延 |
| 区分服务 | 不同类型的流量处理不同 | 无或者软 | 分组标识，监管，调度 | 中等 | 某些 | |
| 每连接服务质量(QoS)保证 | 每个源到目的地流处理不同 | 一旦流被准入，软或者硬 | 分组标识，监管，调度，呼叫准人和信令 | 高 | 很少 |
尽力而为网络
只要在网络上砸钱，不断提升带宽，尽力而为的模型就工作的很好。但现实问题是总是需要达到需求与开支的平衡。
区分类型服务
如果某些流量具有高优先级，为了避免高优先级的流量不断传输导致低优先级的流量产生饥饿，就需要一种监管机制来预留少部分资源给低优先级的流量，但这样的话，即使高优先级的链路资源没有流量，低优先级的流量也无法使用这些资源，所以需要进行一个动态管控。
为了实现这个动态管控机制，可以使用漏桶机制跟加权公平队列来实现。
质量保证网络
为了达到这个目的，必须通过资源预留的方式来为网络请求预留空间，如果无法保证这个空间的分配，则请求直接拒绝掉，这跟电路交换思想是一致的