媒体客户端稳定状态的服务器侧预测的制作方法

背景

本申请一般涉及网络上的数据通信。

相关技术的简要描述

分布式计算机系统在现有技术中是众所周知的。一个这样的分布式计算机系统是通常由服务提供商操作和管理的“内容分发网络”或“cdn”。服务提供商通常代表第三方(客户)提供内容分发服务，该第三方(客户)使用服务提供商的共享基础设施。这种类型的分布式系统有时被称为“覆盖网络”，并且通常是指由网络或多个网络链接的自主计算机连同旨在促进各种服务(诸如内容分发、应用程序加速或外包起源站点基础设施的其他支持)的软件、系统、协议和技术的集合。cdn服务提供商通常通过数字属性(例如网站)提供服务，这些数字属性在客户门户中提供，并且然后部署到网络。

所描述的覆盖网络类型提供从网络中的服务器到客户端的基于http的流式传输，该客户端接收视频流并将其回放到屏幕。客户端可能在台式计算机、移动设备(智能手机、平板电脑)、机顶盒、智能电视或电器或任何其他联网的设备上运行。对于典型的基于http的流式传输用例，客户端通过dns将名称(例如，cdn主机名)解析为ip地址，并建立到关联该地址的服务器的tcp连接。一旦建立起来，客户端发送针对所需内容(例如，媒体片段)的httpget请求。服务器在标准http响应主体中用内容数据进行响应。该连接保持开放，以用于进一步的请求和响应。

虽然内容分发网络提供了显著的优势，但通常它们包括专用平台来支持多个第三方运行时环境的内容分发，这些第三方运行时环境又是基于他们自己的专有技术、媒体服务器和协议。随着终端用户数量的增加，实现并且在全球范围内和有规模地保持可能会很昂贵。此外，与此同时，内容提供商(例如大型广播机构、电影发行商等)希望他们的内容以如下方式在线分发：补充诸如广播电视(包括高分辨率或“hd”电视)和dvd的传统媒体。该内容也可以以不同的比特率提供。终端用户也希望与内容进行交互，如同他们现在能够通过卫星或有线分发的传统的基于dvr的内容进行交互一样。另一个复杂情况是，随着越来越多的终端用户现在使用移动设备(诸如)在移动环境中接收和查看内容，基于互联网的内容分发不再局限于诸如桌面的固定线路环境。

今天，许多终端用户遇到基于http的流式传输问题，例如启动时间慢、重新缓冲和低比特率。这些用户的连接通常显示出足够高的带宽用于高质量视频，但是服务器和客户端之间的往返时间和丢包特性会对流式传输性能产生负面影响，这主要是因为标准的基于tcp的实现在这样的网络上的操作效率低下。

通过额外的背景，回放分段的媒体的媒体客户端会频繁地请求媒体节段。在回放期间，媒体客户端通过两个主回放状态-缓冲状态和稳定状态。在缓冲状态期间，媒体播放器将尝试建立前向缓冲区。该缓冲区的目的是允许客户端避免由吞吐量波动引起的回放中断。要建立这样的缓冲区，客户端通常请求节段的速度必须比回放它们更快。一旦媒体播放器建立了足够的缓冲区，那么其必须不可避免地将回退到稳定状态，从而以与播放它们的相同的速率来请求节段。

在现有技术中，通常服务器对于客户端的回放状态不充分了解或不了解。无状态服务器尤其如此，他们不知道他们参与了媒体回放会话。状态服务器也是如此，它可能意识到它们正在分发媒体流，但仍然不知道客户端的回放状态。在这种情况下，通常媒体必须由最接近的服务器和在某些情况下最贵的服务器来服务，即使不需要保持给定的服务质量(qos)。

概述

本公开提供了一种服务器侧技术来确定媒体客户端何时停止缓冲并且达到其正在接收的媒体内容的“稳定状态”回放。知晓客户端何时处于稳定状态对内容分发网络非常有用，因为该网络可以动态优化其分发以适应该回放阶段。例如，在启动期间，分发网络可能希望尽可能快地向客户端分发内容。在稳定状态期间，当客户端更容忍较低的吞吐量时，分发网络可能会选择将分发切换到成本较低的服务器或具有较高缓存亲合力的服务器。

在一个实施方式中，实现本公开的功能的装置操作服务器程序代码，该代码提供到媒体客户端的分段的媒体分发。该装置可以包括诸如内容分发网络(cdn)的覆盖网络中的边缘服务器，并且可以在诸如移动设备、机顶盒等的客户端设备上支持媒体客户端。服务器程序代码在硬件平台上执行，并且可操作以从媒体客户端接收对媒体流的节段的请求。对节段的每个请求在请求时间被接收。服务器程序代码然后计算评估为第一条件和第二条件的函数。该函数至少部分地根据给定数量的最近的请求的节段请求时间计算。第一条件向服务器推断在客户端处已经发生从第一状态到第二状态的转变，而第二条件向服务器推断在客户端发生从第二状态到第一状态的转换。第一状态是客户端缓冲或启动状态，而第二状态是客户端回放稳定状态。当客户端处于(由服务器程序代码确定的)客户端回放稳定状态时，如果适当(例如，由于较低的分发成本)，可以将新的节段的请求重定向到另一个服务器。在一个变型中，服务器程序代码还从媒体客户端接收关于客户端已经达到第二状态的肯定指示，并且该指示的接收也可以用于触发新的节段的请求到另一个服务器的重定向。

根据另一具体方面，描述了在具有第一和第二媒体服务器的覆盖网络中分发媒体流的方法，每个媒体服务器能够将分段的媒体内容分发到发送请求的媒体客户端。覆盖网络可以是提供分段媒体的基于http的分发的内容分发网络(cdn)，并且可以在诸如移动设备、机顶盒等的客户端侧设备上支持媒体客户端。该方法开始于将媒体客户端与第一媒体服务器相关联。当第一服务器从媒体客户端接收对媒体内容的节段的请求时，所请求的给定数量的最近的节段的请求时间被用于由第一服务器生成对媒体客户端何时从启动或缓冲状态转变到稳定状态的预测。响应于在第一服务器处接收到新的节段的请求，并且在第一服务器预测媒体客户端已经完成向稳定状态的转变时，新的节段的请求被重定向到第二媒体服务器。

前述已经概述了所公开主题的一些更相关的特征。这些特征应被解释为仅仅是说明性的。通过以不同的方式应用所公开的主题或通过如将要描述的修改主题可以获得许多其它有益的结果。

附图简述

为了对本主题公开及其优点的更彻底理解，现在参考结合附图的下面的描述，其中：

图1是示出配置为内容分发网络(cdn)的已知的分布式计算机系统的框图；

图2是代表性的cdn边缘机配置；

图3描绘了从缓冲转变到稳定状态的客户端(接收并呈现分段的内容的媒体客户端或客户端播放器)的图；以及

图4描绘了本公开的服务器侧预测技术的处理流程。

详细描述

图1示出了已知的分布式计算机系统。

在已知的系统中，如图1所示，分布式计算机系统100被配置为覆盖网络(例如，cdn)，并且被假定为具有在互联网周围分布的一组机器102a-n。通常，大多数机器是位于互联网边缘附近的服务器，即位于或邻近终端用户接入网络。网络运行指挥中心(nocc)104管理系统中各种机器的操作。诸如网站106的第三方站点将内容(例如，html、嵌入页面对象、流媒体、软件下载等)的分发卸载到分布式计算机系统100，并且特别是卸载到“边缘”服务器。通常，内容提供商通过将给定的内容提供商域或子域使用别名(例如，通过dnscname)到由服务提供商的权威域名服务管理的域来卸载其内容分发。期望内容的终端用户被引导到分布式计算机系统以更可靠和高效地获得该内容。尽管未详细示出，但是分布式计算机系统还可以包括其他基础设施，诸如分布式数据收集系统108，该分布式数据收集系统108收集来自边缘服务器的使用和其他数据、跨越一个或多个区域集合该数据，并且分发该数据到其他后端系统110、112、114和116，以便于监控、记录、警报、计费、管理和其他操作和管理功能。分布式网络代理程序118监控网络以及服务器负载，并向dns查询处理机制115、提供网络、流量和负载数据，dns查询处理机制115对由cdn管理的内容域具有权威性。分布式数据传输机制120可以用于向边缘服务器分发控制信息(例如，分发元数据以管理内容，以促进负载平衡等)。

如图2所示，给定机器200包括运行支持一个或更多个应用程序206a-n的操作系统内核(例如linux或变体)204的商品硬件202。为了促进内容分发服务，例如，给定机器通常运行一组应用，例如http(web)代理207、名称服务器208、本地监控进程210和分布式数据收集进程212。更一般地，代理207是包括程序指令的软件，该指令被保存在存储器中并且由处理器(或多个处理器)根据需要来执行。

对于流媒体，根据受支持的媒体格式的要求，早期一代cdn中的cdn机器包括一个或更多个媒体服务器，如windows媒体服务器(wms)或flash服务器。使用专用媒体服务器的可备选方案使用http作为传输协议。例如，在美国公开号20110173345中描述了基于http的直播流和基于vod的分发的架构，其公开的内容通过引用并入本文。该方法在cdn中实现，并且包括使用记录层记录要分发的内容流并使用播放器层播放流的高级功能。记录流的步骤包括当流以源格式在cdn入口点处被接收时开始的一组子步骤。然后流被转换成中间格式(if)，其是用于在cdn内分发流的内部格式，并且包括流清单、一组一个或更多个片段索引(fi)以及一组if片段。当发送请求的客户端与cdnhttp代理(例如代理)相关联时，播放器进程开始。响应于在http代理处接收对流或其一部分的请求，http代理(从归档或数据存储)取回流清单和至少一个片段索引。使用片段索引，if片段被取回到http代理、转换为目标格式并且然后响应客户端请求来被服务。源格式可能与目标格式相同或不同。优选地，http代理经由http访问、高速缓存和服务所有片段。在另一个实施方式中，按需分发流(vod)的方法使用转换层(代替记录层)来管理if组件的创建和/或处理。

以上描述的cdn边缘服务器类型可以被配置为：优选地使用利用配置系统分发给边缘服务器的配置文件，优选地在特定于域的、客户特定的基础上，提供一个或更多个扩展内容分发特征。给定的配置文件优选地是基于xml的，并且包括一组促进一个或更多个高级内容处理特征的内容处理规则和指令。配置文件可以经由数据传输机制分发到cdn边缘服务器。美国专利no.7,111,057示出了用于分发和管理边缘服务器内容控制信息的有用的基础设施，并且这个和其他边缘服务器控制信息可以由cdn服务提供商本身或者操作起源服务器的内容提供商客户(经由外部网等)提供。

由于cdn基础架构由多个第三方共享，因此有时在此将其称为多租户共享基础设施。cdn进程可以位于可以在因特网上公共路由的节点处，可以位于在位于移动网络中、位于基于企业的私有网络中或邻近的基于企业的私有网络中的节点内或邻近该节点，或者可以位于其任何组合中。

元数据可配置的覆盖网络web代理(例如图2中的代理207)有时在本文中被称为全局主机进程。

cdn可以包括存储子系统，例如在美国专利号7,472,178中描述的，其公开内容通过引用并入本文。

cdn可以操作服务器缓存层级以提供客户内容的中间缓存；在美国专利号7,376,716中描述了一个这样的高速缓存层级子系统，其公开内容通过引用并入本文。

cdn可以以美国公开号20040093419中描述的方式在客户端浏览器、边缘服务器和客户起源服务器之间提供安全的内容分发。如上所述，安全的内容分发一方面在客户端和边缘服务器进程之间强制执行基于ssl的链接，而另一方面，在边缘服务器进程和起源服务器进程之间执行基于ssl的链接。这使能经由边缘服务器的待分发的经ssl保护的网页和/或其组件。

作为覆盖，cdn资源可用于促进企业数据中心(可能是私有管理)和第三方软件即服务(saas)提供商之间的广域网(wan)加速服务。

cdn还可以提供客户端侧软件来促进诸如hd流式传输的各种内容分发功能。在一种方法中，客户端包括两个组件。第一个是一种非持久的浏览器内媒体播放器，其可以基于第三方组件来促进媒体内容的分段分发。第二个是可以执行“客户端侧”内容分发的持久守护程序形式的界面。客户端侧分发意味着从cdn边缘服务器和运行界面的其他终端用户下载内容，并且先前已经下载了相同的内容。

对于典型的基于http的流式传输用例，客户端通过dns将名称(例如，域名、主机名等)解析为ip地址，并建立到关联该地址的服务器的tcp连接。一旦建立起来，客户端发送针对所需内容(例如，媒体片段)的httpget请求。服务器在标准http响应主体中用内容数据进行响应。该连接保持开放，以用于进一步的请求和响应。

以上述作为背景，现在描述本公开的主题。

媒体客户端稳定状态的服务器侧预测

本文的方法假设媒体客户端播放分段的媒体。

这种方法的目标是提供服务器侧技术来确定这样的媒体客户端何时停止缓冲并达到媒体内容的“稳定状态”回放。在现有技术中，并且如上面所提到的，服务器通常对客户端的回放状态不充分了解或不了解。在这种情况下，媒体由最接近的服务器和在某些情况下最贵的服务器来服务，即使不需要保持给定的服务质量(qos)。

本公开提供了这种分发的备选方案，其基于媒体客户端稳定状态的服务器侧预测。

通过额外的背景，并且如上所述，回放分段的媒体的媒体客户端频繁地请求媒体节段。在回放期间，媒体客户端通过两个主回放状态-缓冲状态和稳定状态。在缓冲状态期间，媒体播放器将尝试建立前向缓冲区。该缓冲区的目的是允许客户端避免由吞吐量波动引起的回放中断。要建立这样的缓冲区，客户端请求节段的速度必须比回放它们更快。一旦媒体播放器建立了足够的缓冲区，那么其必须不可避免地将回退到稳定状态，从而以与呈现它们的相同的速率来请求节段。

知晓客户端何时处于稳定状态对内容分发网络非常有用，因为该网络可以动态优化其分发以适应该回放阶段。例如，在启动期间，分发网络可能希望尽可能快地向客户端分发内容。在稳定状态期间，当客户端更容忍较低的吞吐量时，分发网络可能会选择将分发切换到成本较低的服务器或具有较高缓存亲合力的服务器。

图3描绘了从缓冲转变到稳定状态的分段的客户端(即，接收并呈现分段的内容的媒体客户端或客户端播放器)。在这种情况下，目标缓冲区为30秒，并且节段持续时间恒定为6秒。在这种情况下，清楚地看见从最大请求间隔～3000ms的缓冲状态到稳定状态的转变(这是6000ms标记左右的振荡)。

以下描述更通用的回放情况。假设在挂钟时间t1、t2、t3处有一系列被称为s1、s2、s3等的顺序媒体节段。在自适应分段回放的情况下，存在多个比特率版本的内容并且客户端在它们之间进行切换，我们假设请求s1、s2、s3...sn都是针对媒体的相同的比特率版本。每个媒体节段具有持续时间d1、d2、d3。服务器可以通过检查请求之间的时间差来推断客户端回放状态。因此，例如，如果：t2-t1<d1，则客户端处于启动状态，而如果：t2-t1＝d1则客户端处于稳定状态条件。更一般地，考虑到节段n的情况，服务器可以推断如果：tn+i-tn<dn则客户端处于启动状态，并且如果：tn+i-tn＝dn则客户端处于稳定状态。

然而，在现实世界的条件下，等值性从来不是精确的，并且因此，服务器可能会引入阈值h秒，并定义如果：tn+1-tn+dn<h则客户端处于启动状态，并且如果：tn+1-tn+dn>＝h则客户端处于稳定状态。

上述算法允许节段持续时间的变化。对于在服务节段n+1时做出推断的服务器，它必须具有对先前的节段n的请求时间和持续时间的一些了解。这可以由状态服务器或由服务器在对节段n的响应设置cookie来实现，其定义为tn和dn。然后，该cookie将在下一个对节段n+1的请求中进行转发，这为无状态服务器提供必要的信息来推断客户端状态。然而，这种方法有两个问题。第一个是当连接不良的客户端通过以接近其可用吞吐量下载节段来开始回放时，即可能出现模糊的情况，即：t2-t1～＝d1。在这种情况下，服务器会错误地将其视为稳定状态。第二个是服务器对节段n的持续时间dn的了解的要求实际上很难满足，因为对于服务器来说，它只是其分发的另一个二进制对象。

因此，作为替代，本文的方法优选地考虑请求时间的历史值差异。这使得无状态服务器能够推断客户端何时转变到稳定状态。

现在描述根据本公开的优选方法的细节。

考虑在时间tn对节段n的请求。然后，将rn定义为此请求与某个数量(比如二个)请求之间的间隔的比率：

rn＝(tn-tn-1)/(tn-1-tn-2)

现在，将和sη,χ定义为rn的x个先验值之和：

sn,4＝σ(rn-1，...，rn-x)

类似地，sn,2是rn的2个先验值之和：

sn,2＝σ(rn-1，rn-2)

通过经验分析可以看出，如果满足以下布尔条件(条件1)，则可以推断在节段请求n处从缓冲状态到稳定状态的转变：

rn>3andsn,4>3andsn,2>2

类似地，如果满足以下布尔条件(条件2)，则处于稳定状态的客户端已经转变到缓冲(或启动状态)：

rn>3andsn,4<rnandsn,2<＝2

可以看出，在服务器侧实现上述方法所需的唯一信息是最后r个节段的请求时间tn。这是服务器已知的信息，并且只要r是合理的，则可存储在与会话相关联的某个存储结构中。示例将包括由服务器对节段响应设置的cookies，以及存储会话标识符以及r的历史值的外部数据库。r＝4的值足以以合理的精度预测客户端状态转变；然而，这不是对本公开的限制。

上述方法假设客户端顺序地请求节段。一些媒体客户端可以选择并行地请求片段。例如，服务器可能看到对n＝1,2,3的请求都在时间t到达。一旦处于稳定状态，客户端并行请求n个节段的节奏不能超过其顺序地请求相同n个节段的时间段(否则缓冲区会增长或减少)。因此，服务器应考虑对在紧密的时间跨度ts内接收到的节段所接收的n个请求，其中ts<<节段持续时间、等于在时间tn处进行的单个请求。然后，上述方法将保持以确定客户端稳定状态。

图4描绘了服务器侧功能的代表性处理流程，其可以在软件中实现为在一个或更多个处理元件中执行的一组或更多组计算机程序指令。当会话开始时，该过程开始于步骤400。在步骤402，服务器在挂钟时间t接收节段请求。然后在步骤404执行测试以确定关于先前请求的持久状态信息是否存在？如果步骤404的测试结果是否定的，则例程分支转移到步骤406以将时间t添加到会话状态。在步骤406之后，控制返回到步骤402。然而，如果步骤404的测试结果是肯定的，则例程在步骤408继续，以测试是否有足够的请求历史可用来推断客户端状态。当步骤408的测试结果为否定时，例程分支返回到步骤406。然而，如果在步骤408的测试的结果是肯定的，则例程在步骤410继续进行关于客户端状态的推断；以上在代表性示例中描述了该操作。此后，例程在步骤412继续，以测试根据所作出的推论，客户端状态是否已经改变？如果在步骤412的测试的结果是否定的，则例程返回到步骤406，并且不采取任何行动。然而，如果步骤412的测试结果是肯定的，则程序在步骤414继续执行对会话的给定行动。此后，控制返回到步骤406，并且处理完成。

一旦拥有客户端回放状态，服务器就可以应用许多可能的优化，其中几个现在被描述。

例如，节段请求可以被重定向到具有较高往返时间(rtt)但是具有较低的分发成本的服务器。一个实际的例子是丹佛的廉价数据中心。洛杉矶的客户端可以在缓冲阶段由本地当地的洛杉矶服务器服务，并且然后一旦这些客户端进入稳定状态则由丹佛服务。

作为另一个示例，可以将节段请求重定向到在高速缓存中具有该节段的更高可能性的服务器。传统上，客户a和b的内容必须在每个边缘服务器和所有的边缘服务器上争取高速缓存空间。然而想象以下场景：客户a的内容优先缓存在集中式服务器1和客户b的内容缓存在集中式服务器2。边缘服务器只需要缓存最常与缓冲状态相关联的节段(这实际上是每个流的起始节段)，并且然后可以将客户a的处于稳定状态的客户端重定向到服务器1并将客户b的处于稳定状态的客户端重定向到服务器2。因为服务器1不必缓存客户b的任何内容，所以它可以容纳更多的客户a的内容。

进一步优化这种广泛的方法是可能的。

例如，如果服务器存储所传输的总字节以及请求的时间，则在稳定状态下，它将具有其分发的内容的回放速率的估计。通过将其与在客户端和服务器之间可见的吞吐量的估计结合起来，服务器可以对将流量重定向到何处做出更明智的决定。特别地，想象以下场景：在确定客户端已经到达稳定状态之后，洛杉矶的边缘服务器在重定向节段的请求时有选择。它有两个可能的重定向目标-丹佛的数据中心的成本基数为0.8(相对于洛杉矶的1.0)，rtt为50ms，弗吉尼亚州的数据中心的rtt为100ms，成本基数为0.5。服务器确定自身与此客户端之间的吞吐量为4mbps。如果估计节段带宽为1mbps，那么它将重定向到弗吉尼亚州的数据中心，因为在吞吐量和媒体带宽之间存在良好的开销，并且客户端很有可能在更长的rtt上维持必要的qos。如果估计节段带宽是2mbps，那么它会选择处于稍微更接近的rtt的丹佛服务器。如果估计节段带宽是3mbps，则可以选择不重定向，因为增加的rtt可能会影响客户的服务质量并导致其关闭。

作为另一个变体，客户端播放器可以可选地在其达到稳定状态时向服务器发信号。这可以经由简单的标准化请求报头和/或查询参数来完成。这种方法是无歧义和鲁棒的，并消除了假阳性预测的机会。在掌握所描述的默认隐含预测方案后，操作这种显式方案将是可能的。

所描述的机制使得覆盖网络(例如，cdn)服务器能够推断客户端何时处于稳定状态，使得网络可以动态地优化其分发以适应该回放阶段。在一个实施方式中，在启动期间，分发网络尽可能快地向媒体客户端分发内容。在稳定状态期间，当客户端更容忍较低的吞吐量时，分发网络将分发切换到成本较低的服务器或具有较高缓存亲合力的服务器。

更一般地，每当需要从服务器到客户端的http流式传输时，可以实现本文描述的方法。客户端是指接收视频流并将其播放回屏幕的一侧。客户端可能在台式计算机、移动设备(智能手机、平板电脑等)、机顶盒、智能电视机或任何其他连接的设备上运行。服务器是将流数据发送到客户端的一侧。来自媒体客户端的请求可以遍历诸如网关或其他设备的中间媒介。如本文所提及的，基于http的流式传输是指仅使用http协议来请求和下载对象以构建用于回放的流的任何视频流。非限制性示例包括applehls、adobehds、microsoftsmoothstreaming和mpeg-dash。本文的方法可以用于支持直播和点播流式传输。

本文描述的分发方法改善了视频流式传输质量。该方法可以透明地适应现有的基于http或其他非基于http的流式传输解决方案，因为用于将节段分发到客户端的实际协议对于仅依赖于请求时间的解决方案而言并不重要。

在代表性的实现中，主题功能作为由处理器执行的计算机程序指令在软件中实现。

更一般地，本文描述的技术使用一起促进或提供上述功能的一个或更多个计算相关实体(系统、机器、过程、程序、库、功能等)的集合来提供。在典型的实现中，软件在其上执行的代表机器包括提供给定系统或子系统的功能的商品硬件、操作系统、应用程序运行时环境以及一组应用程序或过程和相关联的数据。如所描述的，功能可以在独立的机器中或跨分布式的机器组实现。该功能可以作为服务提供，例如作为saas解决方案提供。

虽然上面描述了由本发明的某些实施方式执行的操作的特定顺序，但是应当理解，这种顺序是示例性的，因为替代实施方式可以以不同的顺序执行操作、组合某些操作、重叠某些操作等。在说明书中对给定的实施方式的引用指示所描述的实施方式可能包括特定特征、结构或特性，但是每个实施方式可以不必包括该特定特征、结构或特性。

虽然已经在方法或过程的上下文中描述了所公开的主题，但本主题公开还涉及用于执行本文操作的装置。该装置可特别构造成用于期望目的，或它可包括选择性地由存储在计算机中的计算机程序激活或重新配置的通用计算机。这样的计算机程序可存储在计算机可读存储介质中，计算机可读存储介质例如但不限于任何类型的磁盘(包括光盘、cd-rom和磁光盘)、只读存储器(rom)、随机存取存储器(ram)、磁卡或光卡或适合于存储电子指令并每个耦合到计算机系统总线的任何其它类型的介质。

虽然已经分别描述了系统的给定组件，但是普通技术人员将会理解，一些功能可以在给定的指令、程序序列、代码部分等中组合或共享。

优选地，功能性在应用层解决方案中实现，尽管这不是限制，因为所识别的功能的部分可以被内置到操作系统等中。

概括地说，可以实现连接的客户端侧或服务器侧的计算实体的类型没有限制。任何计算实体(系统、机器、设备、程序、过程、实用程序等)可以充当客户端或服务器。

媒体服务器确定应该将新媒体节段的请求重定向到另一个源的特定方式可以变化，并且它可以取决于各种因素，例如成本、性能、负载、延迟及其组合。是否进行这种切换的确定可以由媒体服务器本身执行，或者使用覆盖网络内或与覆盖网络相关联的其他计算实体执行。特定的交换功能本身不是本公开的方面。

新的媒体节段的请求可以以任何方便的方式重新定向，诸如http302重定向命令。

这里的技术提供了对另一技术或技术领域的改进，即媒体分发系统，并提供了对这些系统内的媒体服务器的功能的改进。