摘要：本章主要介绍了两种常见的多媒体，即流式存储视频和实时音视频中的相关技术。
关键词：流失存储视频；内容分发网络；IP语言；实时会话协议
目录：
1. 多媒体网络应用的类型
2. 流式存储音视频
2.1 客户端：缓存
2.2 服务器：内容分发网络
3. 流式实时音视频
3.1 IP语言
3.2 实时会话式应用的协议
4. 区分不同的流量
1. 多媒体网络应用的类型
多媒体这个词对于我们来说并不陌生了，什么叫媒体，什么又叫做多媒体呢？多媒体网络又是什么一种什么网络呢？有哪些典型的应用呢？带着这些问题我们来看看书中是怎么一一解答的。
媒体是承载信息的载体，主要有文字、图片、音频、视频。我们的多媒体就是多种媒体的组合。本章主要以音频和视频介绍为主。音频属于波，通过离散的点来代表连续的波，每个点有个值，通过缩放使得其在256以内，然后则可以用一个8比特的字节表示，从而将整个波用而进制的数据流表示。一秒内采的离散点越多，这些离散点拟合的波形就越接近真实的波形，同时文件也越大。视频则是多幅图片连续播放产生，每幅图片就是一帧，一幅图片是由一个二维矩阵组成的。每个元素是一个32位但是写成8个16进制的数，每两个表示一个物理量，比如红绿蓝和透明度。
所以不管是音频还是视频或者音视频都是可以表示为二进制的流，我们可以称其为流媒体。
本章介绍的音视频流主要有存储视频，也就是视频已经存在服务器上了，客户只需要从服务器将音视频接收到客户端；实时音视频流，也就是音视频是实时生产的。
2. 流式存储视频
对于流式存储视频而言，原理上，他和请求一个普通的网页的过程基本上是类似的。但是由于他的文件非常大，不是几秒钟就可以传输完毕，同时要求用户体验很好，不会卡顿，也就是不受到网络状态波动的影响，就如同一个好的悬挂，使汽车走在颠簸的道路上也车上的人也如履平地。
因此，对于流式存储视频而言，需要解决的问题就是，当平均传输速率比播放速率要快的时候，怎么使得客户体验不到网络状态的颠簸。然后分别从客户端和服务器两个角度来看看现在的技术是怎么实现这个需求的。
2.1 客户端：缓存
无论是视频还是普通的文件都是以二进制的流在网络之间传输的。目前的流式存储视频分为UDP流、http流、适应性http流。你会想怎么没有TCP流，HTTP流或者适应性HTTP流就是基于TCP的，也是目前使用最广泛的流式存储视频。而UPD流则主要用于实时音视频流。
客户端采用的技术主要是客户缓存。由于网络状态可能并不是稳定的，通过先缓存一部分，进行观看，即使目前的网络状况不佳，也有足够的缓存可以看到网络状况好转的时候，因为波动是短时间的。这点在很多音频和视频应用上都可以发现这个技术。
当你选择重定位时，也就指定从某一个时刻开始播放的时候，会重新建立TCP连接，视频的块会有序号，服务器会发送从客户需求的时刻的序号块及其之后的块。
我们知道如果网络平均吞吐量比你的播放量要高，那么你就可以连续的观看视频，如果一段时间内发现你的平均吞吐量比播放量低，那么客户端可以手动或者自动选择视频的清晰度以适用当前的网络，也就是适应性的HTTP流，这种流的前提是，服务器会首先准备该视频的不同清晰度的版本。然后当你切换的时候重新建立HTTP连接到指定清晰度指定序号块的视频。
2.2 服务器：内容分发网络
尽管你的网络吞吐量和播放速度都没问题。但如果服务器的发送速度成为了问题，那你依然无法连续顺畅的播放。假如你用一台机器搭建了一个服务器，然后网络带宽是100Mpbs，那要是有1万用户同时观看你的视频，每个视频将大约只有0.01Mpbs，那会应该是没法看的。
怎么办呢？那我就搞8个大型数据中心，每个数据中心分布在全球不同的位置，一个中心大概10万台机器。然后弄30个中规模的集群，每个集群100~500台服务器，然后再弄几百个小集群，每个10几台服务器。不同的服务器负责不同的内容。这样一来，流量被分摊到各个集群中去了，同时每个用户还能连接上离其最近的服务器，降低延迟和丢包。
而关键在于CDN服务器的集群选择策略，也就是一个用户的请求应该由谁来响应。要知道每个CDN服务器上能提供的内容可能都不一样，YouTube上这么多视频不可能一个服务器就装下 了，通常通过DNS服务器匹配一个离你最近的CDN服务器或者对你而言延迟最低的服务器，如果匹配的服务器上正好有你需要的东西，那就最好不过，否则重定向你的请求到其他有你需要资源的服务器上。每个公司采用CDN集群选择策略可能都不一样，这与其CDN的结构以及客户等其他很多因素相关。
3. 流式实时音视频
3.1 IP语音
前面讲的流式存储视频，相当于腾讯视频、优酷视频。而IP语音则相当于是微信电话和微信视频。为什么叫ip语音呢，因为他不同于电话语音，他通过互联网来传输音频而不是电话网。这种实时的音视频对延迟是非常敏感的。我们看看目前是使用何种技术手段，通过互联网实现低延迟的实时音视频通话的。
实时语音和视频类似，以Ip语音为例，这种实时的音视频传输，对于分组时延、时延抖动、丢包都非常敏感。分组时延指的是分组从端到端消耗的时间，时延抖动就是说这个分组的时延他不是固定的，可能第一个分组的时延是100ms，第二个分组是150ms。丢包是自解释的。我们看看这三个因素是如何影响通话质量的，首先如何分组时延高会发生怎样的现象呢？比如时延是5s，我们经常看到新闻连线前方记者时，要等好几秒才有反应，对方说了句，"你好，我叫某某某，然后开始巴拉巴拉"。如果当着你面说，你可能在他说完名字之后，打断他说，等一下，我没听清，请再说一遍，他就会立马再说一遍名字。如果你们之间有5秒的延迟，当你听到他名字的时候，那是5秒之前发送过来的，你想对他说等一下，再说一遍，那不可能，后面会接着播放，巴拉巴拉5秒的时间，然后你再这5秒的时间内不停的喊请你再说一遍名字，请你再说一遍，我说TM的给老子再说一遍你的名字，然后并不管用，你只能说对面的人没救了，等对面的人听到你再说一遍的时候，他立马重复了一遍，结果他又在之后听到好几个再说一遍，然后他不断的重复他的名字。这就是时延高的时候对实时会话产生的重要影响。然后假如我们规定时延不能超过400ms。而你的网络状况不稳定，一会200ms一会500ms，当下一个分组在400之后还没到的时候的，你的应用程序会认为他丢了，即使他500ms的时候回来了，他也不会给你播放，而是直接丢掉。因此即使你的平均时延不高，但是不稳定的话也会影响通话质量。所以不管是时延高还是抖动高最后导致的都是丢包，进而导致通话质量下降。
如何用IP协议提供的尽力而为的服务来保证体验良好的音视频通话是非常重要的。如果你的网络状况好，那通话质量自然好，如果网络状况坏，比如时延高或者抖动厉害呢？首先它也借鉴流式存储视频技术一样，延迟播放先存储几个播放块来消除抖动，只不过延迟播放的时间不能超过能接收的门槛值400ms，最好播放时延就是既可以消除时延抖动又尽可能的小。一般采用适应性播放，就是每说一段话之后观测该段话的通话质量，然后调整下一段话的播放时延。同时尽可能的恢复丢包，就如同拟合函数一样，用离散的点来拟合曲线通过所预测的丢失的包估计值来代替真实值。
总的来讲，实时的音视频通话主要通过UDP协议，利用适应性的播放时延和丢包恢复来尽可能的在网络环境不佳的情况下提供最好的服务。
3.2 实时会话式应用的协议
实时音视频不同于存储音视频，存储音视频利用http协议就可以了。实时音视频需要双方都在线才能接通，对方还可以拒接，所以它必须要先连接上彼此。
目前主要有两个协议：RTP协议、SIP协议
4. 区分不同类型的流量
我们看到音视频的流量是非常大的，如果几种流量共享一个路由器发出，那么带宽将几乎被音视频的流量占据，而使得其他类型的流量得不到服务。因此必须采取手段区分不同的流量。并使各种类型的流量得到合理的资源。
路由器可以采用适当的调度和监管机制来实现。比如采用漏筒和循环队列实现不同类型的流量分配得到不同带宽。比如有三种类型的流量，视频、网页、游戏，这三种流量可以通过ip首部来标记。路由器有三个队列，它会循环送出队列种的分组，但是，而每个队列的长度不同，也就是每个对列分到的时间是不同的。 这样就相当于分到了不同的带宽。某个时间周期内队列的长度是由漏洞来控制的，每个队列有个漏桶，里面有若干令牌，只有拿到令牌才能进入队列排队，这样用户通过控制漏桶的容积和令牌发放速率就可以实现不同的队列具有不同的长度，从而得到不同的带宽，因为一个周期内，越长的对列发送出去的分组就越多。你可以看看你的路由器是否可以调节漏桶的参数。
网友评论