文章目录
前言
阅读本文前请注意最后编辑时间，文章内容可能与目前最新的技术发展情况相去甚远。欢迎各位评论与私信，指出错误或是进行交流等。
本文是关于《计算机网络：自顶向下方法（第七版）》的学习分享，内容书写顺序也是按照书中的顺序。本文并不会提及书中的所有内容，主要写重点的知识，以及自己感兴趣的内容。会对原文中的内容进行一定的精简，或者加上个人的理解。
多媒体网络
位于世界各个角落的人们懒散地靠坐在床上或乘坐公共汽车和地铁打发时间时，眼下都使用因特网来按需观看电影和电视节目。 因特网电影和电视分发公司（如北美的 Netflix和Amazon、 中国的"优酷" (Youku) ) 实际上已经成为家喻户晓的品牌。 而人们不仅观看因特网视频，他们也使用诸如YouTube这样的站点来上载和分发用户自己生成的内容，不仅成为因特网视频的消费者，也成为视频的生产者。 此外，网络应
用如Skype、 Google Talk 和微信，不仅允许人们经过因特网打"电话"，而且可以用视频和多方会议来强化这些电话。 事实上，我们能够确定地预测： 几乎所有的视频消费和语音会话都将在因特网的端到端发生，通常更多是以无线终端方式经蜂窝和WiFi 接入网与因特网相连接。 传统的电话和广播电视正快速落伍。
本章以9. 1 节中的多媒体应用的分类方法开始。 我们将看到多媒体应用能够分为流式存储音频／视频、会话式IP音频／视频或流式实况音频／视频等几类。 我们将看到这些应用类型中的每一类都有自己独特的服务需求，这些需求与传统的弹性应用如电子邮件、 Web浏览和远程注册的需求差异很大。 在9.2节中，我们较为详细地研究流式视频。 我们将探讨支撑流式视频的许多基础原则，包括客户缓存、预取和对可用带宽的适应性视频质量。在9.3 节中，我们研究会话式语音和视频。 这种应用不同于弹性应用，对端到端时延高度敏感，但能够容忍偶尔的数据丢失。 此时我们将研究诸如适应性播放、 前向纠错和差错掩盖等技术是如何减缓网络引入的丢包和时延的。 我们还将以学习案例方式审查Skype。 在9.4 节中，我们将学习 RTP 和SIP, 这是两个用于实时会话式语音和视频应用的协议。 在9. 5 节中，我们将研究网络内部的一些机制，这些机制能用于区分一类流量（如会话式语音这样的时延敏感应用） 和其他类型流量 （如浏览Web网页这样的弹性应用）， 并且在多类流量中提供区分服务
多媒体网络应用
我们将多媒体网络应用定义为任何应用音频或视频的网络应用。 在本节中，我们将提供多媒体应用的分类法。 我们将看到在该分类法中的每类应用都具有自己独特的服务要求和设计问题集合。 但在深人讨论因特网多媒体应用前，考虑音频和视频媒体自身的内在特点是有用的。
视频的性质
视频最为显著的特点或许是它的高比特率 (high bit rate)。 经因特网分发的视频的典型传输速率从用于低质量视频会议的 100kbps到用于流式高分辨率电影的3Mbps。 为了比较视频带宽需求与其他因特网应用的带宽需求的不同，我们简要地考虑三个不同的用户，他们每人使用了一种不同的因特网应用。 第一位用户 Frank, 他打算迅速将照片张贴到他的脸书页面上， 我们假设Frank每10秒查找一次新照片，并且这些照片的平均大是200KB。 第二位用户 Martha 正从因特网向她的智能手机流式传输音乐。 我们假定 Martha正在听许多MP3 歌曲， 一首接着一首，都以 128kbps速率进行编码。 第三位用户 Victor则正在观看以2Mbps 编码的视频。 最后，我们假设所有三位用户的会话长度是4000 秒（大约67 分钟） 。 表9-1 比较了这三位用户的比特率和传输的总字节。 我们看到这时流式视频消耗了最多的带宽，其比特率比脸书和流式音乐应用的带宽大10 倍。
因此，当设计网络视频应用时，我们心中必须记住的第一件事是视频的高比特率需求。 鉴于视频的流行性及其高比特率，也许不会对思科公司的以下预测感到惊讶 : 到了 2019 年，流式视频和存储视频将大约占全球因特网流量消费的90%。视频的另一种重要特点是它能被压缩，因而要在视频质量与比特率间进行折中。 视频是一个图像序列，图像通常以恒定的速率显示，例如每秒24 幅或30 幅图像。一个副没有压缩、数字编码的图像由像素阵列组成， 每个像素被编码为一定数量的比特来表示亮度和颜色。 在视频中有两种类型的冗余，它们都可以用来进行视频压缩 (video compression) 。空间冗余是给定图像的内部冗余。 从直觉上讲， 一个主要由空白组成的图像具有高度的冗余，能够有效地压缩而不会明显降低图像质量。 时域冗余反映一幅图像和后续图像的重复程度。 例如，如果一幅图像和后续图像完全一致，没有理由对后续图像再进行编码； 相反，在编码过程中直接指出后续图像是完全一样的则更为有效。 今天现成的压缩算法能够将视频压缩为所希望的任何比特率。 当然，比特率越高，图像质量越好，总体用户视觉体验也越好。
我们也能够使用压缩来生成相同视频的多重版本 (multiple version) , 每个版本有不同的质量等级。 例如，我们能够使用压缩生成相同视频的三个版本，速率分别为300kbs...、1Mbps 和 3Mbps。 用户则能够根据他们的当前可用带宽来决定要观看哪个版本。 具有高速因特网连接的用户可以选择3Mhps 的版本；使用智能手机经过3G 观看视频的用户可以选择300kbps 的版本。 类似地，在视频会议应用中的视频能被"动态"地压缩，以在会话用户之间给定的可用端到端带宽上提供最好的视频质量
音频的性质
数字音频（包括数字化语音和音乐）的带宽需求比视频低得多。 然而，数字音频具有自己独特的性质，当设计多媒体应用时必须考虑这些性质。为了理解这些性质，我们首先考虑模拟音频（由人和乐器所产生）是如何转换为数字信号的：
• 模拟音频信号首先以某种固定速率采样、例如每秒8000 个样本。每个采样值是一个任意的实数。
• 然后每个采样值被"四舍五入"为有限个数值中的一个。 这种操作被称为量化( quantization) 。 这些有限个数值（称为量化值）通常是2 的幂，例如256个量化值。
• 每个量化值由固定数量的比特表示。 例如，如果有256 个量化值，那么每个值（因此每个音频采样）用一个字节来表示。 所有样本的比特表示级联在一起就形成了该信号的数字表示。 举例来说，如果一个模拟信号以每秒8000个样值采样，而且每个样本被量化并用8 比特表示、则得到的数字信号的速率就为每秒64000 比特。 通过音频扬声器播放，这个数字信号则能够转换回来（也就是解码），形成一个模拟信号。 然而，解码后的模拟信号仅是初始信号的近似，并且声音质量也许有明显的下降 （例如，高频的声音可能在解码信号中丢失了）。 通过增加采样速率和量化值的数量，解码信号能够更好地接近初始的模拟信号。 因此（与视频一样），在解码信号的质量和比特率与数字信号存储空间之间存在一种折中。
我们刚才描述的基本编码技术称为脉冲编码调制 (Pulse Code Modulation, PCM)。 语音编码通常采用 PCM, 采样速率为每秒8000 个样本，每个样本用 8 比特表示，得到64kbps 的速率。 音频光盘 (CD) 也使用 PCM, 采样速率为每秒44100 个样本，每个样本用 16 比特表示；这样使得单声道速率为705.6kbps, 立体声速率为 1.411 Mbps。
然而， PCM 编码的语音和音乐很少在因特网中使用。 与视频一样，取而代之的是使用压缩技术来减小流的比特速率。 人类语音能被压缩到小于10kbps并仍然可懂。 一种接近CD 质量立体声音乐的流行压缩技术是MPEG 1 第3 层，更通常的叫法是MP3。 MP3 编码器通常能够压缩为许多不同的速率； 128kbps是最常使用的编码速率，并且能够产生非常小的声音失真。 一种相关的标准是高级音频编码 (AdvancedAudio Coding, AAC), 该标准已经随苹果公司而流行起来。 与视频一样，能够以不同的比特率生成多重版本的预先录制的音频流。
尽管音频比特率通常比视频的比特率小得多，但用户通常对音频的小失误比视频的小失误更为敏感。 例如，考虑在因特网上举行的视频会议。 如果视频信号时不时地丢失几秒，该视频会议很可能继续进行而没有太多的用户抱怨。 然而，如果音频信号经常丢失，用户就可能不得不中止该会话。
多媒体网络应用的类型
因特网能够支持各种各样有用的和娱乐性的多媒体应用。 在本小节中，我们将多媒体应用分为三个大类： 1.流式存储音频／视频； 2.会话式IP语音／视频；3.流式实况音频／视频。如我们很快将看到的那样，这些应用类型中的每种都有自己的服务需求和设计问题的集合。
- 流式存储音频和视频
为使讨论具体化，我们这里聚焦流式存储视频，它通常结合了视频和音频组件。 流式存储音频（例如流式音乐）非常类似于流式存储视频，尽管它的比特率通常要低得多。在这类应用中，依赖的媒体是预先录制的视频（如电影、电视节目）预先录制的体育赛事或预先录制的用户生成的视频（如常在YouTube 上看到的那些）。 这些预先录制的视频放置在服务器上，用户向服务器发送请求按需观看视频。 许多因特网公司今天提供流式视频，包括YouTube 、 Netflix。 流式存储视频具有三个关键的不同特色。
• 流。 在流式存储视频应用中，客户开始从服务器接收文件几秒之后，通常就开始播放视频。 这意味着当客户正在从视频的一个位置开始播放时，与此同时正在从服务器接收该视频的后续部分。 这种技术被称为流 (streaming), 它避免了在开始播放之前必须下载整个视频。
• 相互作用。 因为媒体是预先录制的，用户可以对多媒体内容进行暂停、前进、倒退、 快进等操作。 从一个客户提出这种请求到该动作在客户端表现出来，可接受的响应时间应该小于几秒。
• 连续播放。 一旦视频开始播放，它应该根据记录的时序进行。 因此，为了在客户端播放，必须从服务器中及时接收数据；否则，用户经历视频帧停滞（这时客户等待延迟的帧）或帧跳过（这时客户漏掉延迟的帧）。
到目前为止，对流式视频最重要的性能测度是平均吞吐量。 为了提供连续的播放，网络为流式应用提供的平均吞吐量必须至少与该流视频本身的比特率一样大。 如我们将在9. 2 节所见，通过使用缓存和预取，即使在吞吐量波动的时候，提供连续播放也是可能的，只要平均吞吐量（在5 ~ 10秒区间平均）保持在视频速率之上。
对于许多流式视频应用，预先录制的视频被存储起来，并且从CDN而非从单一的数据中心流式播放。 也有许多 P2P视频流式应用，其中视频被存储在用户主机（对等方）上，不同视频块从可能分布在全球的不同对等方到达。 在得知了因特网流式视频的性能后，我们将在9.2节更加深入地研究流式视频，特别关注客户缓存、预取、对可用带宽的适应性质量和CDN分发。 - 会话式IP语音和视频
在因特网上的实时会话式语音通常称为因特网电话 (Internet telephony) , 因为从用户的角度看，它类似于传统的电路交换电话服务。 它也常被称为 IP 语音 (Voice-over-IP , VoIP) 。 会话式视频与之类似，除了它包括参与者的语音以及视频外。 今天的大多数语音和视频会话式系统允许用户生成具有三个或更多个参与者的会议。 会话式语音和视频广泛地应用于今天的因特网中，因特网公司 Skype、 QQ 和 Google Talk 自称每天都有数亿用户。
音频和视频会话式应用是高度时延敏感 (delay-sensitive) 的。 对于具有两个或更多个交互讲话者的会话来说，从用户讲话或移动开始到该动作显现在其他端的时延应当小于几百毫秒。 对于语音，小于150ms 的时延不会被人类听者觉察到， 150 ~400ms 的时延能够被接受，当时延超过400ms 时，即使不会使对话变得完全无法理解，也会使语音会话变得令人沮丧。
另一个方面，会话式多媒体应用容忍丢包 (loss-tolerant) , 即偶尔的丢失只会在音频／视频回放时偶尔出现干扰信号，而且这些丢失经常可以部分或者全部地隐藏。 这些时延敏感但容忍丢包的特性明显不同于那些弹性数据应用（如Web浏览、 电子邮件、社交网络和远程注册等）的特性。 对于这些弹性应用，长时延令人烦恼，但并不是特别有害，然而传输数据的完全和完整性是首要的。 我们将在9.3节中更加深入地探讨会话式语音和视频，特别关注适应性播放、前向纠错和差错掩盖是如何减缓网络引入的分组丢失和时延的。 - 流式实况音频和视频（直播音频/视频）
这种第三类应用类似于传统的电台广播和电视，只是它通过因特网来传输而已。 这些应用允许用户接收从世界上任何角落发出的实况无线电广播和电视传输。 今天有数以千计、 遍及全球的无线电台和电视台正在因特网上广播内容。在今天的因特网中，这种应用通常是用CDN来实现的 。 由于使用流式存储多媒体，网络必须为每个实况多媒体流提供大于该视频消耗速率的平均吞吐量。 因为事件是直播的，尽管没有会话式语音那么严格，但时延也可能成为问题。 从用户选择观看一个实况传输到播放开始，能够容忍的时延最多为10秒。 我们在本书中将不涉及流式实况媒体，因为用于流式实况媒体的许多技术（如初始缓存时延、适应性带宽使用和 CON分发）都类似于流式存储媒体所使用的技术。
流式存储视频
对于流式视频应用，预先录制的视频放置在服务器上，用户向这些服务器发送请求按需观看这些视频。 用户可能从开始到结束都在观看视频而没有中断它，也可能在视频结束前停止观看它，或者通过暂停、重新定位到后面或前面来与视频交互。 流式视频系统可分为三种类型： UDP流 (UDPstreaming) 、 HTTP 流 (HTTP streaming) 和适应性HTTP流 (adaptive HTTP streaming) 。 尽管在实践中所有这三种系统都在使用，但绝大多数今天的系统应用了 HTTP流和适应性HTTP流。
所有这三种形式的视频流的共同特点是广泛使用了客户端应用缓存，以此来缓解变化的端到端时延和变化的服务器和客户之间可用带宽量的影响。 对于流式视频（存储的和实况的），用户通常能够容忍在客户请求某视频与该流视频在客户端播放之间有几秒的初始小时延。 所以，当视频开始到达客户时，客户不必立即开始播放，反而能够在应用程序缓存中建立该视频的储备。 一旦该客户建立起几秒"已缓存但尚未播放"的视频储备，客户就可以开始视频播放了。 这种客户缓存 (client buffering) 具有两种重要的优点。 第一，客户端缓存能够缓解服务器到客户时延中的波动。 如果某部分的视频数据延迟了，只要它在"接收到但尚未播放"的视频耗尽之前到达，这个长时延将不会被注意到。 第二，如果服务器到客户带宽暂时低于视频消耗速率，用户能够继续享受连续的播放，只要客户应用缓存仍没有完全排尽。
图 9-1 显示了客户端的缓存。 在这个例子中，假定视频以固定的比特率编码，因此每个视频块包含了能在相同固定时间量Δ区间播放的视频帧。 服务器在t0传输第一个视频块，在t0+Δ 传输第二个视频块，在t0+2Δ 传输第三个视频块等等。一旦客户开始播放，每个块应当在前一个块之后播放Δ时间单元。 第一个视频块于t1时刻到达，第二个视频块于t2时刻到达。 第i块的网络时延是服务器传输该块的时间与客户收到该块的时间之间的水平距离；；注意到网络时延随视频块不同而变化。 在此例子中，如果客户在第一块t1 时刻到达就开始播放，那么第二块将不能在t1+Δ时刻及时到达 并进行播放。 在这种情况下，视频播放或将停止运行（等待第二块的到达）或可能漏掉第二块， 即这两种情况都将导致不希望的播放损伤。 相反，如果客户将播放延迟到t3 时刻开始，这时第一块到第六块都已经到达，所有已经收到的块在它们的播放
时间前都能够进行周期性的播放。
UDP 流
我们这里仅简要讨论UDP流。 使用UDP流，服务器通过UDP 以一种稳定的速率，与客户的视频消耗速率相匹配的速率传输视频。 例如，如果视频消耗率是2Mbps, 每个 UDP 分组承载8000 比特视频，则服务器将每隔 (8000 比特） / (2Mbps) =4ms 向其套接字发送一个UDP 分组。 因为 UDP未采用某种拥塞控制机制，所以服务器能够以视频的消耗速率将分组推进网络中，而无TCP 的速率控制的限制。UDP 流通常使用很小的客户端缓存， 缓存空间存储小于1 秒的视频就足够了。
在将视频块传递给UDP之前，服务器将视频块封装在运输分组中，该运输分组是专门为传输音频和视频而设计的，使用了实时传输协议 (Real~Time Transport Protocol, RTP) 或某种类似（可能是专用）的方案。
UDP 流的另一种不同的性质是，除了服务器到客户的视频流外， 两者间还并行地维护一个单独的控制连接，通过该连接， 客户可发送有关会话状态变化的命令（如暂停、重新开始、重定位等）。 这种控制连接在许多方面类似于我们在第2章中学习的FTP控制连接。
尽管UDP 流已经在多个开源系统和专用产品中得到应用，但它有三个重大不足。 首先，由于服务器和控制之间的可用带宽无法预测并且是变化的，恒定速率 UDP流不能够提供连续的播放。 例如考虑以下场景： 视频消耗速率为 1Mbps, 服务器到客户可用带宽通常超过1Mbps, 但每过几分钟就有几秒时间其可用带宽低于 1Mbps。 在这种场景下，以1Mbps 恒定速率经 RTP/UDP传输视频的 UDP流系统很可能将提供不好的用户体验，在可用带宽低于1Mbps之后产生停滞或漏帧。 UDP流的第二个缺点是它要求如 RTSP服务器这样的媒体控制服务器，以对每个进行中的客户会话处理客户到服务器的交互请求和跟踪客户状态（例如视频是否被暂停或播放等）。 这增加了部署大规模的按需视频系统的总体成本和复杂性。 第三个缺点是许多防火墙配置为阻塞UDP流量，防止这些防火墙后面的用户接收UDP视频。
HTTP 流
在HTTP 流中，视频直接作为具有一个特定 URL的普通文件存储在 HTTP服务器上。当用户要看视频时，客户和服务器之间建立一个 TCP连接，并且发送一个对该 URL的HTTP GET 请求。 服务器则尽可能快地在 HTTP 响应报文中发送该视频文件，这就是说，以 TCP拥塞控制和流控制允许的尽可能快的速率进行处理。 在客户端上，字节收集在一个客户应用缓存中。一旦在缓存中字节数量超过了预先设定的阙值，该客户应用程序开始播放，具体而言，它周期性地从客户应用缓存中抓取视频帧，对帧解压缩并在用户屏幕上显示它们。
我们在第3章学习过，当通过TCP传输一个文件时，由于TCP的拥塞控制机制，服务器到客户的传输速率可能变化很大。 此外，分组也能由于重传机制而被大大延迟。 因为TCP的这些特点，在20 世纪90 年代大多数人的看法是流式视频将不可能在TCP上很好地工作。然而，随着时间的推移，流式视频系统的设计者知道了当使用了客户缓存和预取技术时， TCP的拥塞控制和可靠数据传输机制并不一定会妨碍连续播放。
在TCP 上传输HTTP流量，也使得视频穿越防火墙和 NAT (它们常常被配置为阻挡 UDP流报但允许大部分HTTP流量通过）更为容易。 HTTP流消除了因需要媒体控制服务器（如RTSP 服务器）带来的不便，减少了在因特网上大规模部署的成本。 由于所有这些优点今天的大多数流式视频应用（包括YouTube 和Netflix) 都使用 HTTP流（在TCP上）作为它的底层流式协议。
- 预取视频
如同我们刚才所学的那样，客户端缓存可用于缓解变化的端到端时延和变化的可用带宽的影响。 在前面的例子中，服务器以视频播放的速率传输。 然而，对于流式存储视频，客户能够尝试以高于消耗速率的速率下载视频，因此预取将来会被消耗的视频帧。 该预取的视频当然存储在客户应用缓存中。 这样的预取自然伴随TCP流出现，因为TCP拥塞避免机制将试图使用服务器和客户之间的所有可用带宽。
我们来举个简单的例子。 假设视频消耗速率是1Mbps, 而网络从服务器到客户能够以恒定的1.5Mbps速率交付视频。客户则不仅能够以非常小的播放时延播放该视频，而且还能够以每秒500Kb 的量增加缓存的视频数据。 以这种方式，如果后来该客户在一段短暂时间内以小于1Mbps 的速率接收数据，该客户由于在其缓存中的储备将能够继续提供连续的播放 - 客户应用缓存和TCP 缓存
图 9-2 说明了客户和服务器之间 HTTP流的交互。 在服务器侧，视频文件中的白色部分已经通过服务器的套接字进行发送，而黑色部分是留下待发送的部分。 在"通过套接字的门传送"之后。放置在TCP发送缓存中的字节在被传输进因特网。因为 TCP发送缓存显示为满，服务器立即防止从视频文件向套接字发送更多的字节。 在客户侧，客户应用程序（媒体播放器）从TCP接收缓存（通过其客户套接字）读出字节并将字节放入客户应用缓存中。 与此同时，客户应用程序周期性地从客户应用缓存中抓取视频帧，解压缩并显示在用户屏幕上。 注意到如果客户应用缓存大于该视频文件，则从服务器存储器到客户应用缓存移动字节的整个过程等价于普通文件经HTTP的下载过程，即客户直接将视频用TCP允许的尽可能快的速率从服务器中拉出来。
现在考虑在流播放期间当用户暂停视频时将发生的现象。 在暂停期间，比特未从客户应用缓存中删除，甚至比特继续从服务器进入缓存。 如果客户应用缓存是有限的，它可能最终会变满，这将反过来引起对服务器的"反向压力"。 具体而言，一旦客户应用缓存变满，字节不再从客户TCP接收缓存中删除，因此它也会变满。 一旦客户 TCP接收缓存变满，字节不再从服务器TCP发送缓存删除，因此它也变满。一旦客户 TCP发送缓存变满，服务器不能向套接字中发送任何更多的字节。 因此，如果用户暂停视频，服务器可能被迫停止传输，在这种情况下服务器被阻塞，直到用户恢复该视频。
事实上，甚至在常规的播放过程中（即没有暂停），如果客户应用缓存变满，反向压力将引起TCP缓存变满，这将迫使服务器降低其速率。为了决定其产生的速率，注意到当客户缓存删除f比特，它在客户应用缓存中产生了f比特的空间，这依次允许服务器发送额外的f比特。 因此，服务器发送速率不能比客户端视频消耗速率更高。 因此，当使用HTTP流时，一个满的客户应用缓存间接地对服务器到客户能够发送的视频速率施加了限制。 - 流式视频的分析
某些简单的建模将有助于洞察由于应用缓存消耗所产生的初始播放时延和停滞。 如图 9-3所示， B表示客户应用缓存的长度（以比特计）， Q表示在客户应用缓存开始播放之前必须被缓存的比特数量。 （当然， Q<B。) r表示视频消耗速率，即客户在播放期间从客户应用缓存提取比特的速率。 在此情况下，举例来说，如果视频的帧速率是30帧／秒，每（压缩）帧是100000 比特，则 r= 3Mbps。 为了从细节看整体，我们将忽略TCP 的发送和接收缓存。
我们假设无论何时客户缓存都为非空，服务器以一种恒定速率x发送比特。 （这是一种显而易见的简化，因为TCP的发送速率由于拥塞控制而变化)假设在时刻t= 0, 应用缓存为空，视频开始到达客户应用缓存。 我们现在问， 在什么时刻开始播放呢？ 并且在播放过程中，什么时刻客户应用缓存变满呢？
首先，我们来确定，此时Q 比特已经进入应用缓存并且开始播放。 前面讲过比特以速率x到达客户应用缓存，并且在开始播放之前没有比特从其缓存中删除。 所以，建立Q比特所需的时间 （初始缓存时延）是t= Q/x。我们现在来决定客户应用缓存变满的时刻。 我们先观察，如果X< r (即如果服务器发送速率小于视频消耗速率），则客户缓存将决不会满！的确，缓存将以速率r排空并且仅以速率x<r填充。 最终客户缓存将完全排空，此时当客户缓存等待另一个Q/x秒来建起Q 比特的视频时，视频将在屏幕上停滞。 所以，当网络中可用速率小于视频速率时，播放将在连续播放期和停滞播放期之间进行变动。当X> r时，在这种情况下，缓存以x-r 的速率从Q增加到B, 因为比特以速率r消耗但以速率x到达。 注意到当网络中的可用速率大于视频速率时，在初始缓存时延后，用户将享受连续的播放直到视频结束。 - 视频的早期中止和重定位
HTTP 流系统经常利用 HTTP GET 请求报文中的 HTTP 字节范围首部 (HTTP byte range header) , 该首部指示了客户当前要从所希望的视频中获取的字节范围。 当用户要在视频中及时重定位 （即跳跃） 到未来点时，这特别有用。 当用户重定位到一个新位置时，客户发送一个新HTTP请求，用字节范围首部指出服务器应当从文件的哪个字节起发送数据。 当服务器接收到该新的 HTTP请求时，它能够忘记任何较早的请求，而是由字节范围请求中指示的字节开始发送。
在我们讨论重定位主题的时候，我们简要地提及当某用户重定位到视频中的某个未来点或提前终止视频时，某些由服务器发送的已预取但尚未观看的数据将不会被观看， 即导致了网络带宽和服务器资源的浪费。 例如、 假设在视频中的某时刻t0，客户缓存充满B比特，在此时用户重定位到视频中的某个瞬间t> t0+B/r, 然后从这点起观察视频直到结束。在这种情况下，缓存中的所有B 比特将未被观看，用于传输这B 比特的带宽和服务器资源完全被浪费掉了。 在因特网中，有大量的带宽因提前终止而浪费，这些成本可能相当大，特别是对于无线链路 。由于这个原因，许多流系统仅使用了长度适当的客户应用缓存，或者将限制在HTTP请求中使用字节范围首部预取的视频数量。
参考目录
书籍：《计算机网络：自顶向下方法（第七版）》