1、流式存储媒体
- 把注意力转移到网络应用，第一种情况针对早已存储在文件中的流媒体。最常见的例子是在Internet 上观看视频。这是视频点播（ VoD, Video on Demand)的一种形式。其他形式的视频点播使用了服务提供商网络来传送影片，这种网络通常独立于Internet （例如，有线电视网络）。
- Internet 上充满了音乐和视频站点，这些站点流化存储在其上的媒体文件。实际上，处理存储媒体的最简单方式不是流化它。想象一下，你想要创建一个在线电影租赁站点，与苹果的iTunes 竞争。常规的站点允许用户下载视频，然后再观看该视频。这个步骤序列如图所示。
- 当用户单击一个电影时，第1 步中，浏览器给该电影链接的Web服务器发送一个HTTP 请求，请求该电影。接着第2 步，服务器从磁盘上获取该电影（只是一个MP4 或其他某种格式的文件）并将它发回浏览器。使用MIME 类型，例如video/mp4，浏览器查找应该如何显示此文件。在这种情况下，它是一个媒体播放器，显示为辅助应用程序，尽管它可能也是一个插件。浏览器将整个电影保存到磁盘上的一个临时文件中。然后，浏览器启动媒体播放器，并将临时文件的名字传递给它。最后，在第4 步中，媒体播放器开始读取文件并播放该电影。
- 原则上，这种方法完全正确，它将播放出电影。这里没有任何实时网络问题需要处理，因为下载电影只是一次简单的文件下载。唯一的麻烦是在播放电影之前，必须通过网络传输整个电影。大多数客户恐怕都不愿意为他们的“视频点播”等上一个小时。为了避免这个问题而且不改变浏览器的工作方式，站点可以使用如下图的设计。链接到电影的页面不是实际的电影文件。相反，它是一个称为元文件（ metafile ）的文件。元文件是一种非常简短的文件，仅仅给出了电影的名字（可能还有其他关键描述符〉。一个简单的元文件可能只有一行ASCII 文本，看上去像这样：rtsp://joes-movie-server/movie-0025 .mp4
- 浏览器像往常一样得到这个页面，现在是只有一行长的文件，如图中第1 步和第2 步所示。然后，它启动媒体播放器，并将这一行长的文件传递给播放器，如第3 步所示，一切照常进行。媒体播放器读取元文件，发现可以获得电影的一个URL 接着，播放器与joes-movie-server 联系，并向服务器请求该电影，见第4 步。然后，该电影被流式发回给媒体播放器，见第5 步。这种安排的优点在于媒体播放器很快就能启动，仅仅在那个非常短的元文件下载后即可启动。一旦启动后，浏览器就再也不出现在循环中。媒体被直接发给播放器，在整个文件被下载之前就可以播放电影了。
- 图 中，我们展示了两个服务器，因为元文件中给出的服务器通常与Web 服务器不是同一个。事实上，它一般就不是HTTP 服务器，而是一个专门的媒体服务器。在这个例子中，媒体服务器使用了实时流协议（ RTSP, Real Time Streaming Protocol ）。媒体播放器主要完成以下4 项工作：
(1 ）管理用户界面。
(2 ）处理传输错误。
(3 ）解压缩内容。
(4 ）消除抖动。 - 现在大多数媒体播放器都有华丽的用户界面，有的甚至模拟成一个立体声音响，面板上带有各种按钮、旋钮、调节滑块和可视显示窗等。通常播放器的面板膜样可以自由被替换成其他模样，这样的面板称为皮肤（ skin ）。媒体播放器必须管理所有这些事项，并且与用户实行交互。
- 究竟怎么处理传输错误依赖于用什么协议来传输媒体，是像HTTP那样基于TCP 的传输协议，还是像RTP 那样基于UDP 的传输协议。这两种传输协议都可以实际使用。如果使用的是一个基于TCP 的传输协议，那么媒体播放器不需要纠正错误，因为TCP 通过使用重传机制己经提供了可靠性。这是一种简单的处理错误方法，至少对媒体播放器是这样，但它在后面的消除抖动步骤中很复杂。另外，像RTP 这种基于UDP 的传输协议，可以用来移动数据。使用这些协议，没有重传机制。因此，由于网络拥塞或传输错误，造成数据包的丢失将意味着一些媒体数据传不到播放器。这个问题要由媒体播放器来处理。
- 因为客户不喜欢他们的歌曲或电影出现较大的缺口，因此丢包是个问题。然而，丢包的损失又不像传输一个普通文件出现丢包时那么严重，因为少量媒体的丢失不需要降低用户的播放。对于视频，用户不太可能注意到偶尔每秒只出现24 个新帧，而不是25 个新帧。对于音频，播放期间的短暂间隙可以用时间接近的声音来掩盖。用户不可能发现这种替换，除非他们非常非常关注。然而，上述推理的关键在于音频或者视频流中的缺口很小。网络拥塞或传输错误通常会导致整个数据包的丢失，并且丢包往往呈现少量的突发。面对这种问题，有两种策略可以用来降低数据包丢失对媒体丢失的影响： FEC 编码和交错编码。
- 前向纠错( FEC, Forward Error Correction ）适用于应用程序级的简单纠错编码。整个数据包的奇偶校验提供了一个范例：每发送4 个数据包，就据此构造第5 个奇偶包，组成一组一起发送。如图所示中的数据包A 、B 、C 和D。奇偶包P 包含了冗余位，这些冗余位取自4 个数据包中每个数据位的奇偶或“异或”和。我们希望对于大多数5 个包组成的组中所有数据包都能到达接收端。如果果真如此，那么接收器只需简单地丢弃奇偶包。否则，如果只是丢失了校验包，也没有什么损害。
- 然而，有时在传输过程中可能会丢失一个数据包，如图中的B 数据包。媒体播放器只接收到了三个数据包A、C 和D，加上奇偶包P。通过设计，丢失那个数据包中的数据位可以从校验位重构出来。具体而言，假设“＋”代表“异或”或模2加，那么利用异或特征（即X+Y+Y=X ），可重构出B, B=P+A+C+D。
- FEC 可以通过修复一些丢失的数据包，来减缓媒体播放器的损失程度，但它也只能起到一定程度的作用。如果在5 个一组的包中丢失了两个包，那我们无论做什么都无法恢复出丢失的数据。需要注意的FEC 另一个特征是为获得这种保护措施，我们必须支付的成本。每四个包必须生成第五个包，所以带宽的需求量比媒体所需要的多25% 。并且，还增加了接收端解码的延迟，因为我们可能需要等到奇偶包的到达，才可以重新建造出这个奇偶包之前丢失的数据包。
- 第二种策略是所谓的交错编码（ interleaving ）。这种方法的基本原理是这样的：在传输之前把媒体的顺序混合或交错编码起来，然后在接收端拆混或解开交错的媒体。这样，如果一个数据包（或数据包的突发〉丢失，因为发送前的混合操作，丢包的损失将随着时间推移分摊到多个数据包。它不会导致媒体播放时出现一个很大的缺口。例如，一个包可能含有220 个立体声采样值，每个都包含一对16 位数字，通常为5 毫秒的好品质音乐。如果采样值按顺序发送，一个信息包的丢失表现在音乐流中会出现5 毫秒的缺失。相反，如果按如下图所示的方式来发送来样值。所有10 毫秒时间间隔内的所有偶数采样值都通过一个数据包发送，而所有奇数采样值通过下一个数据包发送。现在，丢失3 个包的损失并不代表丢失5 毫秒的音乐，仅仅损失了10 毫秒内对应的每个其他采样值。媒体播放器很容易地就能处理这种损失：使用前面和后面的样本值交叉插入丢失位。造成的结果是这10毫秒的音乐具有较低的临时分辨率，但没有明显的媒体缺失。
- 上面的交错方案只适用于未压缩的采样值。然而，交错发送方式也可以用于压缩后的样本值，只要有一种方法能找到压缩数据流的采样边界。RFC 3119 给出了一个针对压缩音频的交错方案。交错编码是一个有吸引力的技术，使用它时无须增加额外的带宽，这点和FEC 不同：然而，与FEC 一样，交错编码增加了传输延迟，因为需要等待一组数据包都到达（才能被解交错〉。
- 媒体播放器的第三个工作是解压缩内容。虽然这项任务是计算密集型的，但相当简单。棘手的问题在于如果网络协议不能纠正传输错误，播放器如何解码媒体。在许多压缩方案中，后面的数据不能先于较早的媒体被解压缩，直到较早的数据已经被解压缩出来才能解压缩后面的数据，因为以后的数据是相对于以前数据的编码。对于基于UDP 的传输协议，还可能出现丢包。因此，编码过程必须设计成不管丢不丢包都能进行解码。这项需求就是为什么MPEG 采用L帧、P－帧和B－帧的缘故。每个I－帧可以独立其他帧进行解码，以便从任何先前帧的损失中恢复。
- 第四个工作是消除抖动。我们的一般解决方案是使用播放缓冲区。所有的流媒体系统启动播放前缓冲5～ 10 秒的媒体。如果缓冲区被排空，那么媒体播放器不得不被卡住。缓冲的价值在于如果有时由于网络拥塞导致数据到达得缓慢，那么缓冲的媒体将保持播放器的正常播放，直至到达新媒体并且缓冲区被补充填满。需要多大的缓冲区，媒体服务器要以多快的速率发送媒体才能填满缓冲区，这些决策都取决于网络协议。设计中考虑的最大的因素是使用基于UDP 的传输协议还是使用基于TCP 的传输协议。
- 假设采用像RTP 这种基于UDP 的传输协议。进一步假设从媒体服务器到媒体播放器有足够的带宽用来发送数据包，只有少量的丢失，而且网络上的其他流量很少。在这种情况下，数据包可按照播放媒体所需要的准确速率发送。每一个数据包通过网络传输，在一定传播延迟后恰好在播放的适当时间到达媒体播放器，然后被播放出来。此时需要的缓冲很少，因为数据包的延迟没有可变性。如果采用交错编码或FEC 编码，那么需要更多的缓冲，至少需要保证交错或FEC 得以执行的一组数据包。不过这仅仅增加了对少量缓冲的需求。
- 不幸的是，这种场景是不现实的。这里存在两方面的原因。首先，通过网络路径的带宽变化很大，因此，媒体服务器通常不清楚在它尝试流出媒体之前是否有足够的带宽。一个简单的解决方法是以多种分辨率来编码媒体，并让每个用户选择一个由他Internet 连接所支持的分辨率。也就是说以1.5 Mbps或更高速率的编码能带来高质量的媒体，而以512 kbps 或更少速率编码的媒体质量较差。
- 其次，会有一些抖动。这种抖动有两个来源。在网络中通常存在一些相当可观的竞争流量一一它们中的某些可能来自多任务用户本身，他们一边浏览网页一边在观看一个流式电影。这种流量会引起媒体到达时间出现波动。而且，我们所关心的是视频帧和音频来样值的到达，而不是数据包的到达。采用压缩技术后，尤其是视频帧可能很大，也可能很小，这完全取决于该帧的内容。一个动作序列通常比一个静止的景观需要更多的比特来编码。因为这些原因，如果网络带宽恒定，媒体的传递随时间的变化率会有所不同。
- 现在假设使用基于TCP 的传输协议来传送媒体，比如HTTP。因为执行重传机制和等待数据包直到能提供有序的数据包所花费的时间，使得TCP 增加了媒体播放器可观察到的抖动，而且更加显著。然而，TCP 将以网络运载数据尽可能快的速度来发送。如果丢失的包必须修复，那么有时候媒体可能会延迟。但大部分时间，网络将能够以快于媒体播放的速度来传递媒体。如果网络速度明显快于平均的媒体速率，这是常有的情况，那么启动后不久缓冲区将被迅速填满，这样缓冲区是否会被排空很快将不再是一个令人关切的问题。
- 基于TCP 或基于UDP ，并且传输速率超过播放速率， 一个问题是媒体播放器和媒体服务器都愿意遥遥领先于播放点开始处理媒体。它们往往愿意下载整个文件。但是，遥遥领先于播放点开始工作其实是不必要的，这样可能需要大量的存储空间，对避免缓冲区欠载并没有必要。当不想要太早开始处理时，媒体播放器的解决方案是定义一个缓冲区的高水位标记（ high-water mark）。基本原则是服务器不断地输出数据直到缓冲区被填满至高水位标记。然后媒体播放器告诉服务器暂停发送。由于数据将继续源源不断地流来，直到服务器收到暂停请求，缓冲区中高水位标记和缓冲区末尾之间的距离必须大于网络的带宽延迟乘积。在服务器停止后，缓冲区将开始排出。当它降到低水位标记时，媒体播放器告诉媒体服务器重新启动发送。为了避免欠载，在要求媒体服务器恢复发送媒体时，低水位标记必须考虑网络的带宽延迟乘积。
- 要启动和停止媒体流，媒体播放器需要对其进行远程控制。这就是RTSP 协议所提供的功能。该协议在RFC 2326 中被定义，它给播放器提供了控制服务器的机制。除了启动和停止媒体流外，它可以后退或前进到某个位置、播放特定的时间间隔以及快进或者快退。它不提供数据流的传输，这通常是UDP 之上的RTP，或者基于TCP 的HTTP 之上的RTP 的任务。
- 表中列出了RTSP 协议所提供的主要命令。这些命令有一个简单的文本格式，类似于HTTP 消息，并且通常通过TCP 来传递命令。RTSP 也可以在UDP 上运行，但每个命令都需要确认（并且，如果没有获得确认，就必须重新发送〉。
- 尽管TCP 似乎不太适合实时流量的传输，但在实际上它还是经常被采用。最主要的原因是它比UDP 更容易穿过防火墙，尤其是在通过HTTP 端口运行时。大多数管理员把防火墙配置成保护他们的网络被不受欢迎的访客访问。他们几乎总是允许来自远程端口80 的TCP 连接，以便HTTP 和Web 流量通过，因为阻塞该端口将迅速引发校园网的不满。然而，大多数其他端口还是被封锁的，其中包括RSTP 和RTP ，它们分别使用端口554 和端口5004 。
- 因此，流媒体通过防火墙的最简单的方式是假装它是一个HTTP 服务器，正在发送一个普通的HTTP 响应，至少要让防火墙这么认为。使用TCP 还有其他一些优点。因为它提供了可靠性， TCP 给客户提供的媒体是一个完整副本。这很容易让用户倒回到某个播放点观看而不用担心数据丢失。最后， TCP 将尽可能快地缓冲尽可能多的媒体。当缓冲空间变得越来越便宜（当磁盘用于存储时），媒体播放器可以在用户观看的同时下载媒体。一旦下载完成，用户就可以不间断地观看，即使他丢失网络连接也无妨。这个属性对移动电话非常有用，因为对它们而言在运动中与网络的连接可能快速变化着。
- TCP 的缺点是增加了启动延迟（因为TCP 启动需要时间），同时也增加了更高的低水位标记。然而，只要网络带宽超过媒体速率相当多个量级，这点只是很少的一个惩罚。
2、流式直播媒体
- 不仅只有录制的视频在网络上红极一时。直播流媒体也非常受欢迎。使用目前的技术，几乎任何人都可以快速启动流媒体直播，并且所需费用很少。流媒体直播的方法之一是把节目记录到磁盘上。观众可以连接到服务器的存档文件，拖拽任何节目，并下载下来慢慢听。对于预先设定的事件，也可以在现场直播之后把内容存储起来。
- 另一种不同的方法是在Internet 上广播实况。观众们调到正在直播的媒体流，就像打开电视机一样。实况媒体将继续流向播放器，被播放器缓冲起来直到用户已经准备好观看。站在浏览器的角度，它看起来就像流存储媒体一样。对于播放器而言，内容是否来自一个文件或者是通过网络正在发送过来的直播根本不重要，而且通常也不告诉他。
- 重要的是，仍然需要在客户端进行缓冲，以便平滑抖动。实况流媒体总是以它产生的精确速率传输，这个速率也是与它被播放的速度相同。它不能以更快的速率发送。因此，缓冲区必须大到足以处理全方位的网络抖动。实际上， 10～ 15 秒的启动延迟通常就足够了，所以这不是一个大问题。
- 其他重要的区别在于流媒体直播事件通常拥有数百或数千个同时观看相同内容的观众。在这种场景下，流媒体直播很自然的解决方案是使用组播。组播流媒体的方案以如下方式工作。服务器将每个媒体包通过IP 组播一次发给一个组地址。网络给每个组成员传递一份包的副本。要想接收媒体流的客户必须加入该组。客户使用IGMP 就可做到这一点，而不必向媒体服务器发送一个RTSP 消息。这是因为媒体服务器早就已经在发送实时流了（之前第一个用户加入情况除外）。我们所需要的就是安排在本地接收流。
- 由于组播是一个一对多的传递服务，媒体被RTP 包携带，并通过UDP 传输。TCP 仅用在单个发送者和单个接收者之间。由于UDP 不能提供可靠性，可能会丢失一些数据包。为了把媒体丢失水平降低到可接受的水平范围内，我们可以使用前面所述的FEC 和交错编码技术。
- 对于拥有大量客户的服务器来说，以RTP 和UDP 数据包来组播流媒体无疑是最有效的运营方式。否则，服务器有N 个客户时必须发送N 个流，对于同时需要处理大量流事件的服务器来说将需要非常大的网络带宽。实际上Internet 不是这样工作的，看到这里你可能会大吃一惊。通常发生的情况是每个用户与服务器建立一个单独的TCP 连接，媒体流通过该连接传给用户。对客户端来说，这与观看流存储媒体的方式是相同。至于流存储媒体，之所以有这个看似糟糕的选择存在以下几个原因。
- 第一个原因是IP 组播在Internet 上并没有真正获得部署。一些ISP 和网络仅在自己内部支持它，但它通常不支持跨越其网络边界的组播。其他原因还在于TCP 相比UDP 具有某些优势，正如前面所讨论的那样。基于TCP 传输的媒体流几乎能到达Internet 上所有的客户，尤其是当伪装成HTTP 后可穿越防火墙，而且可靠的媒体流传递允许用户执行倒带回放。
- 然而，在一个重要情况下可以用UDP 来组播媒体流：在服务提供商的网络内部。例如，有线电视公司可能决定给客户机顶盒广播电视频道，具体做法是使用IP 技术来代替传统的视频广播。利用IP 包分发广播视频的技术被广泛地称为IPTV。由于有线电视公司可以完全控制自己的网络，所以它可以把自己的网络工程化为支持IP 组播，而且为基于UDP 的分发分配足够的带宽。在服务方面它看起来就像有线电视，但是它的基础是IP，机顶盒是运行UDP 的计算机，电视机只是简单连接到计算机的显示器。
- 返回到Internet 的情形，在TCP 上面直播流媒体的缺点是服务器必须为每个客户端发送一个单独的媒体副本。这对于用户中等数量的客户群是可行的，特别是传输音频流。这里的诀窍在于找到一个具有良好Internet 连接的位置放置媒体服务器，使得它有足够的带宽。通常，这意味着向托管服务提供商租用一台数据中心的服务器，而不是使用家里一台只有宽带Internet 连接的服务器。托管服务提供商的市场竞争力非常激烈，因此租用一台服务器不会很昂贵。
- 事实上，任何人都很容易建立和运营一个流媒体服务器，比如一个Internet 电台。这个电台的主要组成部分如图所示。电台的基础是一台普通PC，带有一个像样的声卡和麦克风。运行流行的软件来捕获音频，并将之编码成各种格式，例如MP4，媒体播放器像往常一样用来收听音频。
- 然后，在PC 上捕获的音频流通过Internet 被送入一个媒体服务器，作为播客的存储文件流或直播媒体流。该媒体服务器具有良好的网络连接，它处理大量通过TCP 连接分发媒体的任务。同时该服务器还承担前端Web 站点的角色，提供电台的介绍页面以及指向可用流媒体内容的链接。所有这些事情都可利用商业软件包来负责管理，也可利用开源软件包来实施，比如icecast 。
- 然而，针对一个拥有非常大量客户群的电台来说，一台服务器使用TCP 将流媒体发送到每个客户端的做法就变得不可行了。简单地说，一台服务器根本没有足够的带宽来做这件事情。对于大型流媒体网站，流媒体的分发使用了一组服务器来完成的，而且这组服务器在地理上是分散的，从而使客户端可以连接到最近的服务器。这就是内容分发网络。