CN105191251B - 基于站点的服务器选择 - Google Patents

基于站点的服务器选择 Download PDF

Info

Publication number
CN105191251B
CN105191251B CN201480012519.XA CN201480012519A CN105191251B CN 105191251 B CN105191251 B CN 105191251B CN 201480012519 A CN201480012519 A CN 201480012519A CN 105191251 B CN105191251 B CN 105191251B
Authority
CN
China
Prior art keywords
website
handling capacity
data
estimation
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201480012519.XA
Other languages
English (en)
Other versions
CN105191251A (zh
Inventor
马克·沃特森
隗炜
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Netflix Inc
Original Assignee
Netflix Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Netflix Inc filed Critical Netflix Inc
Publication of CN105191251A publication Critical patent/CN105191251A/zh
Application granted granted Critical
Publication of CN105191251B publication Critical patent/CN105191251B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/764—Media network packet handling at the destination 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Hardware Redundancy (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

在一个实施例中，一种方法包括：接收从第一站点处的第一服务器计算机流传输的第一数据；至少部分地基于从第一服务器计算机流传输的第一数据的第一吞吐量，收集第一站点的第一吞吐量数据；接收从第二站点处的第二服务器计算机流传输的第二数据；至少部分地基于从第二服务器计算机流传输的第二数据的第二吞吐量，收集第二站点的第二吞吐量数据；至少部分地基于第一吞吐量数据和第二吞吐量数据之间的比较，从第二站点处的第二服务器计算机切换到第一站点处的第三服务器计算机；其中该方法有一个或多个专用计算设备执行。

Description

基于站点的服务器选择
技术领域
本公开总地涉及数据通信网络。本公开更具体地涉及基于来自多个站点的性能数据对数字媒体的流传输技术。
背景技术
本部分描述的方法是可以执行的方法，但不一定是先前已经想到或者执行的方法。所以，除非明确指示，否则不应该认为本部分描述的任何方法仅因为被包括在本部分而是现有技术。
通常，在客户端计算机开始从服务器计算机下载数字媒体之前，客户端最初被提供以已经被编码供使用不同比特率进行递送的一个或多个文件的一个或多个统一资源定位符(URL)的列表。在该列表中，客户端一般被提供以针对可用的每个比特率文件的多个URL。比特率文件包含经编码的媒体内容。URL可以指向网络上的一个或多个服务器(例如，内容递送网络(CDN)或者数据中心处的单个服务器计算机)。
例如，客户端可以接收特定比特率文件的第一URL和第二URL，该特定比特率文件是例如，具有1080比特率的以H.264格式编码的电影“泰山”(以下称为“泰山1080比特率文件”)。第一URL可以指向位于单个服务器上的泰山1080比特率文件的副本。第二URL可以指向位于CDN上的泰山1080比特率文件的副本。客户端可以接收有关URL的元数据。例如，第一URL可以具有第一偏好和第一权重，从而第一偏好和第一权重分别大于与第二URL相关联的第二偏好和第二权重。标签可以与每个URL相关联，从而第一标签可以指示第一URL指向位于单个服务器上的比特率文件，并且第二标签可以指示第二URL指向位于CDN上的比特率文件。
在接收到一个或多个URL的列表之后，当流传输会话开始时，客户端首先选择其希望首先从其进行下载的URL，然后按照偏好的次序测试每个URL，直到客户端找到以最小吞吐量阈值提供比特率文件的URL为止。如果没有URL满足最小吞吐量阈值，则客户端比较每个URL的根据与每个URL相关联的权重进行加权的加权吞吐量，然后客户端继续使用具有最佳加权吞吐量的URL。所以，与每个URL相关联的权重是用于选择URL的第二因素。指派给每个URL的权重被用于预测性地在URL分别指向的服务器之间分配负载。
以上方法具有若干缺陷。例如，特定URL的吞吐量很大程度上取决于客户端和服务器之间的网络路径；但是，没有基于类似地位于网络拓扑中的多个服务器和客户端的位置执行优化。另外，客户端在流传输会话开始时测量可用URL的吞吐量；因此，客户端无法基于历史吞吐量数据选择使用哪个URL。另外，一些URL仅可以被意图用作最后采用的故障转移，但是由于没有规则防止客户端切换到另一URL来优化吞吐量，所以客户端可能不考虑URL的意图用途来使用URL。另外，所有比特率必须被存储在所有服务器上，以确保针对一个比特率文件所做的吞吐量测量精确地预测利用不同比特率文件将实现的吞吐量。
附图说明
在附图中：
图1示出了根据实施例的互联网络。
图2示出了根据一个实施例的确定从哪个服务器下载比特率文件的示例性的基于站点的处理。
图3示出了根据实施例的分别针对两个客户端的与等级视图相关联的站点。
图4示出了根据一个实施例的确定从哪个服务器下载比特率文件的示例性的基于站点且基于等级的处理。
图5示出了根据一个实施例的确定从哪个服务器下载比特率文件的示例性的基于站点且基于估计吞吐量的处理。
图6示出了可以实施实施例的计算机系统。
具体实施方式
在下面的说明中，出于阐释的目的，提供了很多具体细节以提供对本发明的透彻理解。但是，将明白的是，本发明可以在没有这些细节的情况下被实施。在其他实例中，公知的结构和设备被以框图形式示出，以避免不必要地模糊本发明。
在本文中，根据以下大纲描述实施例：
1.0 一般概述
2.0 网络拓扑
2.1 站点
2.2 示例网络的概述
2.3 示例性的基于站点的URL选择处理的概述
2.4 等级
2.5 示例性的基于站点且基于等级的URL选择处理的概述
3.0 收集历史数据
3.1 基于站点的历史数据
4.0 基于历史数据估计吞吐量
4.1 历史平均
4.2 指数平滑-自适应方法
4.3 核密度估计器(Kernel Density Estimator，KDE)
4.3.1 M-Kernel实施方式
4.3.2 优化的M-Kernel实施方式
4.3.3 针对演进数据的修改后的KDES
4.4 示例性的基于站点且基于估计吞吐量的URL选择处理的概述
4.5 具有基于优先级的比特率文件的服务器
4.6 探测
5.0 实施机制-硬件概述
6.0 公开的其他方面
1.0 一般概述
在实施例中，一种方法包括：接收从第一站点处的第一服务器流传输的第一数据；至少部分地基于从第一服务器流传输的第一数据的第一吞吐量，收集第一站点的第一吞吐量数据；接收从第二站点处的第二服务器流传输的第二数据；至少部分地基于从第二服务器流传输的第二数据的第二吞吐量，收集第二站点的第二吞吐量数据；至少部分地基于第一吞吐量数据与第二吞吐量数据之间的比较，从第二站点处的第二服务器切换到第一站点处的第三服务器；其中，该方法由一个或多个专用计算设备执行。
一些实施例可以提供一种客户端至少部分地基于服务器所位于的站点来精确地确定服务器的感知吞吐量的有效方法。在一个实施例中，一种方法包括至少部分地基于从位于特定站点处的一个或多个其他服务器接收到的历史吞吐量来选择位于相同站点处的特定服务器。另外，客户端被限制请求从位于特定站点的服务器下载比特率文件，除了其他服务器发生故障或者不可用的情况以外。
在一些实施例中，诸如核密度估计之类的数据挖掘技术可以改善站点处的一个或多个服务器的估计吞吐量的精确度。优化核可以被呈现，以实时估计吞吐量。作为所给出的方法的副产品，服务器可以有选择地在可以为高吞吐量或者低开销服务器的特定服务器上存储流行媒体。在例如，通过流传输数据通信来递送电影、TV节目、或者其他视听媒体的联网计算机系统中，这些实施例是有用的。
2.0 网络拓扑
网络上的客户端计算机与服务器计算机之间的数据吞吐量可以基于很多因素，这些因素例如是穿越的网络数目、穿越的任何网络的带宽、穿越的任何网络的拥塞、客户端的性能、以及服务器的性能。
为了减少延时并且避免网络由于拥塞变得过载，服务器可以位于ISP网络、对等链路、以及转接网络(transit network)中。在一些情况下，维护ISP网络、对等链路、以及转接网络中的服务器会很昂贵，或者具有有限带宽。
2.1 站点
如果第一服务器和第二服务器位于相同的站点上，则客户端与第一服务器之间的吞吐量类似于客户端与第二服务器之间的吞吐量。如果第一服务器和第二服务器位于相同的站点处，则第一服务器和第二服务器可以位于网络拓扑中的相同位置。因此，客户端从第一服务器下载的数据可以与客户端从第二服务器下载的数据穿越相同的网络并且沿相同的路径，因为服务器相对于客户端的位置基本相同(即使不是完全相同)。为了便于表达，当两个服务器被描述为处于相同站点时，这两个服务器在网络拓扑中位于非常接近的位置，从而使得这两个服务器的位置之间的差异可被忽略。例如，第一服务器可以位于第一建筑物中，并且第二服务器可以位于街道对面的第二建筑物中(它们是网络拓扑中被类似放置的节点)。
CDN可以被看做单个站点。尽管CDN处的所有服务器可以处于不同的地理位置，但是CDN的所有服务器被预期针对任何给定客户端类似地执行操作。另外，去往CDN上的比特率文件的链接可以被转发给任意数目的位置中的任意数目的服务器，但是CDN将被当做处于单一位置处的单个服务器。所以，在一些示例或实施例中，当提到服务器时，服务器可以是整个CDN，所有服务器在整个CDN中具有类似的性能或吞吐量。
可以基于包括但不限于服务器的互联网协议地址、两个服务器计算机的邮件地址、服务器之间的物理距离、服务器之间的共享接入点、或者这些因素的任意组合在内的多个因素，自动确定两个服务器处于相同站点中。另外，在一些情况下，基于有关两个服务器的网络拓扑、性能、或者吞吐量的特定知识或者测试，两个服务器可以被手动地指定为共享相同站点。
被指定处于相同站点中的服务器被预期具有相似的吞吐量。例如，两个服务器可以共享相同的房间，但是如果第一服务器以第二服务器访问存储器的一半速率访问存储器，则在很多实施例中，第一服务器的吞吐量将比第二服务器差很多。因此，第一服务器和第二服务器应该被指定处于不同站点中，而不考虑这两个服务器的物理上的接近。
2.2 示例网络的概述
图1是示出根据实施例的全部互连的四个网络的框图。尽管图1出于示出清楚示例的目的阐述了一个实施例，但是其他实施例可以省去、添加、重新排序、和/或修改所示出的任何元件。
在图1中示出的实施例中，网络100包括网络112、网络114、和网络116(统称为“网络110”)；客户端122和客户端126(统称为“客户端120”)；服务器132、服务器134、服务器136、服务器137、和服务器138(统称为“服务器130”)；站点142、站点144、站点146、和站点148(统称为“站点140”)；对等点180；以及控制服务器190。术语“服务器”可以指代包括一个或多个核心、处理器、计算机、或者集群的服务器计算机。
网络112包括客户端122和服务器132。网络112被通信地耦合到网络114和对等点180。网络112还通过网络114和对等点180被通信地耦合到网络116。网络114包括服务器134。网络114被通信地耦合到网络112、网络116、以及对等点180。网络116包括客户端126、服务器136、以及服务器137。网络116被通信地耦合到网络114和对等点180。网络116还通过网络114和对等点180被通信地耦合到网络112。
客户端120是相对于服务器的客户端计算设备。例如，客户端120可以是台式计算机、膝上型计算机、平板电脑、电话、其他移动设备、游戏台、机顶盒、流媒体播放器、盘播放器、电视、或者能够流传输来自服务器的媒体内容并且为用户播放该媒体内容的任何其他计算设备。
客户端122通过网络112被通信地耦合到服务器132。客户端122通过网络112和网络114被通信地耦合到服务器134。客户端122通过网络110、或者通过网络112、对等点180、以及网络116被通信地耦合到服务器136和服务器137。客户端122通过网络112和对等点180被通信地耦合到服务器138。客户端122还被通信地耦合到控制服务器190。
客户端126通过网络116被通信地耦合到服务器136和服务器137。客户端126通过网络116和网络114被通信地耦合到服务器134。客户端126通过网络110、或者通过网络116、对等点180、以及网络112被通信地耦合到服务器132。客户端126通过网络116和对等点180被通信地耦合到服务器138。客户端126还通信地耦合到控制服务器190。
服务器130是向客户端120中的一个或多个客户端提供比特率文件或者部分比特率文件的计算设备。每个服务器130可以是数据中心处的计算机、CDN提供的服务器网络、或者能够提供比特率文件或部分比特率文件的任何其他计算设备。
服务器132在站点142处。服务器134在站点144处。服务器136和服务器137在站点146处。服务器138在站点148处。在图1中示出的实施例中，服务器136和服务器137都在站点146处，但是在一些实施例中相同网络中的服务器可以在不同站点处。
对等点180是能够减少延时并且增加网络110中包含的元件之间的吞吐量的对等点。对等点180可以包括服务器138，并且可以包括一个或多个路由器、交换机、或者其他联网基础设施元件。
控制服务器190是向客户端提供URL列表的计算机。在图1中，控制服务器190通过网络110和对等点180被通信地耦合到客户端120和服务器130。另外，控制服务器190可以存储表示客户端120和服务器130的状态、容量、或者其他特性的数据，或者具有到这些数据的访问。控制服务器190可以在会话开始时与任何一个客户端120联系。替代地，控制服务器190可以调控客户端120，并且可以通过会话调控客户端120的行为(例如，当用户开始观看或者收听特定的比特率文件时、以及当用户停止观看或者收听特定的媒体时)。
2.3 示例性的基于站点的URL选择处理的概述
图2示出了根据一个实施例的确定从哪个服务器下载比特率文件的示例性的基于站点的处理。尽管图2示出了根据一个实施例的示例步骤，但是其他实施例可以省去、添加、重新排序、和/或修改所示出的任何步骤。出于示出清楚示例的目的，可以参考图1描述图2，但是在其他实施例中不要求使用图1的特定布置。
在步骤205，播放特定电影的输入被接收。例如，客户端122接收播放特定电影的输入。在步骤210，URL列表被接收。例如，客户端122向控制服务器190查询具有特定电影的比特率文件的服务器130。控制服务器190返回URL列表，其中每个URL指向服务器130之一上的特定比特率文件。每个URL还包括可以包括每个比特率文件的比特率、每个服务器的偏好值、以及每个服务器所位于的站点的元数据。
在步骤220，未经测试的站点处的第一URL被选择。例如，客户端122可以至少部分地基于客户端122已经确定其应该首先尝试下载的初始比特率、以及与具有初始比特率的可用比特率文件的每个服务器相关联的偏好，选择下载比特率文件的第一URL。客户端122可以基于诸如客户端122的设备特性(例如，分辨率和性能)、可用比特率、以及指派给URL的偏好和权重之类的多个因素，来确定初始比特率。在选择第一URL后，客户端122开始从第一URL指向的服务器136下载比特率文件。客户端122可以缓存所下载的内容。
在步骤230，处理测试吞吐量是否低于最小阈值；如果是，则控制返回到步骤220，否则控制变换到步骤290。例如，客户端122确定从站点146处的服务器136接收到的吞吐量在特定最小阈值以下。因此，客户端122继续到步骤220。最小阈值可以是预定值，或者可以基于诸如，客户端122正在尝试下载的比特率文件的长期平均比特率、客户端122已经尝试、或者将要尝试下载的比特率文件的多个部分的实际编码数据尺寸、客户端122上的缓冲器的尺寸、或者客户端122上的缓冲器的充满程度等的很多因素。
在步骤220，示例继续，客户端122确定第二URL指向也处于站点146处的服务器137；但是，客户端122将不尝试从第二URL下载比特率文件，因为站点146已经通过从服务器136下载比特率文件被测试，并且吞吐量被确定是不充足的。因此，客户端122认为服务器137将提供同样不充足的吞吐量。相应地，客户端122将选择URL列表中的第三URL(例如，在这种情况下位于不同的未经测试的站点的服务器132)。客户端122切换到服务器132，并且继续重新访问步骤230。
在重新回到的步骤230，客户端122确定从服务器132接收的吞吐量不在最小阈值以下。因此，客户端122继续到步骤290。
在步骤290，流传输继续。例如，客户端122继续从当前URL下载比特率文件。基于包括但不限于时间间隔、客户端122上的缓冲器的大小、或者客户端122上的缓冲器的充满程度的多个因素，客户端122可以返回到步骤230，以验证当前站点仍然在递送等于或大于最小阈值的吞吐量。
2.4 等级
为了减轻昂贵且有限的战略服务器(strategic server)的负载，客户端可以被限制使用指定的服务器或者站点，除非诸如可用性或者切换之类的一些条件被满足。例如，可以至少部分地基于是否存在具有期望比特率文件的不太昂贵的服务器，来限制客户端请求比特率文件。代价不总是指钱；在一些实施例中，可以使用带宽、存储空间、吞吐量、或者会对花销或者性能产生影响的多个因素来计算代价。还可以至少部分地基于是否存在客户端可以利用最小吞吐量从其流传输的非战略服务器，来限制客户端请求比特率文件。另外，在另一示例中，可以至少部分地基于是否存在没有过载的非战略服务器来限制客户端请求比特率文件。
在一个实施例中，站点被与使用等级值来标识的被称为等级的抽象概念相关联。客户端可以从第一等级站点请求比特率文件。但是，基于包括所选择的比特率文件在第一等级站点上的可用性、第一等级站点的实际或者估计吞吐量、或者第一等级站点的故障在内的一个或多个因素，客户端可从第二等级站点请求比特率文件。另外，客户端可以基于包括前面列出的因素在内的任何因素的组合，从第二等级站点请求比特率文件。客户端还可以基于包括以下讨论的探测在内的因素的任意组合，在相同等级的站点之间自由切换。
其他实施例可以包括两个以上等级。类似地，这些实施例可以出于很多原因、或者包括但不限于上面已经列出的原因在内的原因的组合，对切换等级施加限制。
同一站点针对不同客户端可以被与不同的等级相关联。由于客户端可以位于网络拓扑中的任意位置，所以特定站点可以更便宜地向相比其他客户端的一些客户端递送内容。因此，站点可以基于特定客户端、客户端的位置、客户端设备、客户端的类型、或者很多其他因素，被动态地与等级相关联。
针对所有客户端或者客户端的特定集合，站点可以被静态地与特定等级相关联。但是，其他站点可以被基于特定客户端的位置动态地与特定等级相关联。
图3示出了根据实施例的分别针对两个客户端的与等级视图相关联的站点。尽管图3示出了具有两个客户端的实施例，但是其他实施例可以省去、添加、重新排序、和/或修改所示出的任何元件。
在图3示出的实施例中，使用图1示出的实施例作为示例，等级视图310和等级视图320分别示出了针对客户端122和客户端126的不同等级指派。等级视图310包括等级312、等级314、以及等级316。等级视图320包括等级322、等级324、以及等级326。在实施例中，等级视图可以包括三个以上或三个以下等级，并且可以具有指派给等级的任意数目的站点。在实施例中，任意数目的站点可以被指派给等级。
至少部分地基于站点142和站点144具有到客户端122的最短路径，站点142和站点144被指派到作为客户端122的第一等级的等级312。类似地，基于相同的因素，站点146和站点144被指派到作为客户端126的第一等级的等级322。
至少部分地基于站点146具有到客户端122的更大距离，站点146被指派到作为客户端122的第二等级的等级314。类似地，至少部分地基于相同因素，站点142被指派到作为客户端126的第二等级的等级324。
至少部分地基于站点148位于对等点180处，站点148被指派到作为客户端122的第三等级的等级316。尽管客户端122和站点148之间的拓扑可以指示相对于站点146和客户端122，站点148和客户端122之间存在较短距离，但是维护站点148有可能是更贵的，并且因此保留站点148用于不存在其他替代时的客户端请求。因此，在图3所示出的实施例中，站点148可以被静态地指定为所有客户端120的第三等级站点。类似地，至少部分地基于相同因素，站点148被指派到作为客户端126的第三等级的等级326。
在实施例中，客户端自主地遵守在等级内的服务器或者站点之间切换、以及在等级之间切换的规则。替代地，服务器可以管理客户端，其中客户端被服务器指令哪些服务器或者站点是客户端被允许从其下载数据的。
2.5 示例性的基于站点且基于等级的URL选择处理的概述
图4示出了根据一个实施例的确定从哪个服务器下载比特率文件的示例性的基于站点且基于等级的处理。尽管图4示出了根据实施例的示例步骤，但是其他实施例可以省去、添加、重新排序、和/或修改所示出的步骤中的任意步骤。
出于示出清楚示例的目的，可以使用图1和图3中示出的实施例来描述图4。但是，其他实施例可以使用客户端、服务器、基础架构、和等级的其他布置。现在参考图4，在步骤405，播放特定电影的输入被接收。例如，客户端122接收播放特定电影的输入，如前面在步骤205中所讨论的。在步骤410，URL列表被接收。例如，客户端122接收URL列表，如前面在步骤210中所讨论的。但是，在步骤410中返回的URL列表还在元数据中包括根据等级视图310针对客户端122每个站点被指派到的等级。
在步骤420，处理选择第一未经测试的等级的未经测试的站点处的第一URL。例如，客户端122至少部分地基于以下三点选择下载的第一URL：1)客户端122已经确定的其应该首先尝试下载的初始比特率；2)与指向具有初始比特率的比特率文件的每个URL相关联的偏好；以及3)被指派到等级312的站点。因此，在步骤420，客户端122开始从位于站点142处且被指派到站点142的服务器132下载比特率文件，其中，站点142针对客户端122被指派到第一等级312。与步骤220不同，只要客户端122的第一等级312处的服务器上存储有可用比特率文件，客户端122就不被允许从位于站点146的服务器136下载比特率文件，因为站点146被指派到了第二等级314。可用性可以基于比特率文件的URL是否被包括在URL列表中、或者基于URL指向的服务器是否正在正确地执行。
在步骤430，处理测试吞吐量是否低于最小阈值；如果是，则控制变换回步骤420，否则控制转移到步骤490。例如，客户端122确定从站点142处的服务器132接收的吞吐量低于最小阈值。因此，客户端122进行到步骤420。
在步骤420，客户端122基于与最初在步骤430中讨论的相同因素，选择另一URL。由于比特率文件的副本没有被存储在服务器134上，所以客户端122被允许从服务器136下载比特率文件，因为服务器136位于被指派到第二等级314的站点146处。客户端122继续重新访问步骤430。
在重新访问的步骤430，客户端122确定来自位于站点146的服务器136的吞吐量不低于最小阈值。因此，客户端122进行到步骤490。在步骤490，客户端122继续从站点146处的服务器136下载比特率文件。
3.0 收集历史数据
历史数据可以是在过去发生的流传输数据传送的吞吐量数据的集合。吞吐量可以是客户端在特定时间量中从服务器接收的数据量。例如，客户端可以从服务器请求特定比特率文件的2秒块。吞吐量可以是接收所请求的2秒块所花费的秒数去除所请求的2秒块的大小。吞吐量数据随后被作为历史数据中的采样点存储。
存储与服务器相关联的历史数据可能是不高效的。例如，至少部分地基于客户端已经收集的历史数据，客户端可以确定开始比特率应该是多少、以及从哪个服务器请求比特率文件。使用图1中示出的实施例作为示例，客户端122可以接收包括针对比特率文件的服务器136和服务器138的URL在内的URL列表。客户端122可以从服务器136请求比特率文件的2秒块，并且存储客户端接收该2秒块所花费的秒数。客户端122随后可以开始从服务器138下载2秒块，并且存储所观察到的吞吐量。然后，客户端122可以被提供以针对新比特率文件的新URL列表，该新URL列表包括服务器137和服务器138，而不包括服务器136。如果历史数据仅与特定服务器相关联，则客户端122不能估计针对服务器137的吞吐量，即使服务器136和服务器137处于相同站点。另外，客户端122不可以基于与服务器138相关联存储的历史数据来确定开始比特率，因为不存在与服务器137相关联的历史数据。不幸的是，客户端122还可以尝试从服务器137下载比特率文件，即使与服务器136相关联的历史数据示出与服务器137处于相同站点的服务器136具有比服务器138更低的吞吐量。这个问题在存在大量服务器并且客户端被提供以每个URL列表中的不同服务器时被放大。在本公开中，仅与特定服务器相关联的历史吞吐量数据被称为基于服务器的历史数据。
3.1 基于站点的历史数据
基于站点的历史数据包括客户端在特定时间量中从服务器接收的数据量。但是，该历史数据与服务器所位于的站点而不是服务器本身相关联。客户端可以使用基于站点的历史数据来精确估计客户端尚未使用的其他服务器的吞吐量。另外，通过收集基于站点的历史数据，客户端可以减少其存储器使用并且可更快地计算更精确的估计；在基于站点的实施方式中，如果估计模型需要一定数目的数据点，则客户端仅需要一组所需要的数目的数据点。
客户端可以使用基于站点的历史数据来精确估计客户端尚未使用的其他服务器的吞吐量。基于站点的历史数据是针对整个站点的吞吐量数据的集合。即使吞吐量数据可能不是从特定站点处的每个服务器接收的，但是客户端可以使用针对特定站点的所有服务器的基于站点的历史数据(鉴于站点处的所有服务器被预期具有类似的吞吐量)。
客户端可以通过收集基于站点的历史数据更快地计算出更精确的估计。在基于站点的实施方式中，由于针对站点的所有历史数据可以被包括在相同数据集中，所以估计可以更快地收敛。相反，在基于服务器的实施方式中，相同站点中的每个服务器仍然必须提供充足的吞吐量信息，来给出相关或者有用的估计。另外，站点的吞吐量中的任何变化将被更快地反映在估计中，因为整个吞吐量数据被存储在相同的历史数据集中。
在基于客户端站点的历史数据可以使用图1中示出的实施例描述的实施例中，对于每个服务器上的一个或多个比特率文件，客户端122被提供以包括服务器136和服务器138的URL的URL列表。客户端122可以从服务器136请求比特率文件的2秒块，并且可以基于2秒块的大小存储客户端接收2秒块花费的时间。客户端122然后可以从服务器138下载2秒块，并且存储所观察到的吞吐量。随后，客户端122可以被提供以针对新的一组比特率文件的新URL列表，该URL列表包括服务器137和服务器138而不包括服务器136。如果历史数据是基于站点的，则客户端122可以正确地估计服务器137的吞吐量，因为服务器136和服务器137应该具有相似的性能。因此，客户端122可以基于所存储的与站点146和148二者相关联的历史数据来确定开始比特率。另外，客户端122也可以不尝试从服务器137下载新比特率文件或者新比特率文件的一部分，如果与站点146相关联的历史数据示出服务器137所属于的站点146比服务器138所属于的站点148更低的吞吐量。这种解决方案的优点在位于每个站点的服务器的数目增加时被放大。
4.0 基于历史数据估计吞吐量
不正确地估计吞吐量会降低用户的体验质量。例如，如果客户端至少部分地基于历史数据估计开始比特率低于实际的可用吞吐量，则用户至少最初将被呈现以较低质量的视频。但是，如果客户端估计开始比特率高于实际的可用吞吐量，则客户端至少最初将会花很长时间来缓冲足够的数据以开始回放。
不幸的是，吞吐量数据可能是有噪声的，这意味着吞吐量的单独实例可能比正常感知的大或者小，并且多个因素可以确定客户端和服务器之间的吞吐量，任何数目的条件可以临时或者永久性地改变吞吐量。
在实施例中，统计方法可以被用来降低噪声从而更精确地估计吞吐量。在实施例中，移动平均可以被用来估计吞吐量。其他实施例可以实现估计吞吐量的其他方法(例如，内插函数、核函数、平滑函数)。在下面的部分中，吞吐量数据被看作包括大于零的实数的无界序列的数据流。例如，如果客户端在0.5秒中接收到1兆比特的数据块，则吞吐量可以被表示为2(其是2兆比特/秒的简写)。每个测量出的所观察到的吞吐量数据可以被当作流中的新数据点。
4.1 历史平均
在实施例中，历史平均被用来估计吞吐量。历史平均可以使用较小的存储器，并且可以在恒定时间O(1)内被计算出来。历史平均将流中的最新输入的数据点xn、和前一历史平均为Hn-1作为参数，其中n是流中到目前为止的采样数目：
4.2 指数平滑-自适应方法
数据流的特性会随着时间变化。例如，移动客户端设备可以从一个网络下载特定比特率文件，然后从另一网络下载另一比特率文件。作为具体示例，假设用户首先观看连接到无线路由器的电话上的电影，并且随后观看连接到蜂窝网络时的相同电话上的另一电影。在这种情况下，优选的是向最近的吞吐量数据赋予更大的权重，因为从一个站点感知的带宽会基于哪个互联网服务提供商正被使用而大幅变化。
因此，在指数函数被用于估计吞吐量的实施例中，该函数使用较小的存储器并且可以在恒定时间O(1)中被计算出来。指数函数将流中最新输入的数据点xn、阿尔法参数α、以及指数函数的前一结果En-1作为参数：
En(α，xn)＝(α)xn+(1-α)En-1
在以上的指数平滑函数中，α是0到1之间的数，从而使得更大的α具有赋予最近的采样的更大的权重。使用指数平滑，客户端可以基于参数α更精确地估计随时间逐渐变化、或者急剧变化的演进流。
所以，在利用移动客户端的示例中，估计吞吐量根据客户端改变其在网络拓扑中的位置而自适应地改变。另外，α也可以是基于采样流的拉普拉斯或梯度、或者指数函数的输出改变的函数。
4.3 核密度估计器(KDE)
在实施例中，诸如核密度估计之类的数据挖掘技术可以被用来提高估计吞吐量的精确度。因此，历史数据可以被表示为概率密度函数(PDF)，并且流中的每个新数据点也可以被表示为新PDF而不仅仅是流中的离散数据点。
替代地，基于直方图分析的估计可以被使用；但是，在一些实施例中，使用基于直方图的分析可能需要更多存储器，并且还可能需要一次以上的数据传递(more than onepass over the data)。例如，作为计算直方图的常用的预处理步骤，整个数据的初始传递被执行，以确定域的跨度。另外，一些基于直方图的方法使用确定直方图中的每个柱的大小的另一预处理步骤，这通常需要数据集的一次以上传递。
核密度估计器(KDE)是估计随机变量的PDF的非参数函数。核密度估计是数据平滑方案，其中有关人口的推论是基于有限的数据采样的。特别地，KDE严重依赖于采样，而不知道实际的底层分布的先验知识。另外，KDE随着采样数目的增加而变得更加精确。
PDF是描述随机变量具有特定值的可能性的函数。随机变量落在特定区域的概率由该随机变量在该区域上的密度的积分给出。PDF在每个地方都是非负的，并且其在整个域上的积分等于1。例如，在正态分布中，有50％的机率随机变量小于或等于零，因为正态分布下有50％的面积被包括在负无穷和零之间。
在实施例中，在n个采样上的具有核函数K、和带宽h的KDE可以被定义为：
在以上KDE中，h可以是大于零的任意数，但是可以基于包括核K在内的任意数目的因素而被调节。替代地，如下面讨论的，h可以是由数据流参数化的函数。K可以是任何核，例如，K可以是高斯核、一致核(uniform kernel)、或者抛物线核，但是从实用观点看，选择有界核(例如，抛物线核、三权重(triweight)核、余弦核)在计算上有利，尽管不要求核的范围在所有实例中都是非负的。
尽管使用KDE在很多方面是有利的(一些已经在上面列举)，但是随着采样数目n的增多，存储数据流并且计算KDE变得更加昂贵。具体地，存储数据流所需的空间、以及KDE的计算代价随着采样大小线性增加。所以，KDE难以实时计算，尤其是对于随着历史数据持续增长而不断增长的数据流。
4.3.1 M-Kernel实施方式
在实施例中，可以使用M-Kernel实施方式。M-Kernel实施方式通过保留最后m个条目降低了计算代价和存储器代价，其中m小于n。M-Kernel是具有平均数带宽以及权重的核。M-Kernel的总和估计n个经处理元素之后的KDE：
使得：
术语X*可以是任何合并运算符，包括n个元素中的m个元素以外的元素的历史平均或者指数加权和。
例如，如果流中的数据点是4、3、2、1，其中4是流中被接收的最后数字，m等于3，并且等于1，则流的M-Kernel等于：
另外，如果流中的下一个数据点是5，则M-Kernel等于：
进一步地，如果流中的下一个数据点是6，则等于X*，则：
在该示例中，m+3个元素(X*、m、和n)可以被要求停留在存储器中，从而停留在M-Kernel中。因此，M-Kernel可以对n个元素的KED进行实时近似。
但是，M-Kernel方法做出了在所有情况下都不可能为真的若干统计假设。例如，M-Kernel方法要求为常数，这会导致更大的数值误差。另外，通常的正态分布被用于K，但是存在可以用来减少计算时间的其他核。
4.3.2 优化的M-Kernel实施方式
在实施例中，可以使用优化的M-Kernel。例如，K可以是可以比其他核更快计算的抛物线核，因为运算符是简单的乘法和加法运算：
另外，为了减少数值误差，采样和M-Kernal二者的带宽可以为：
从而使得是至少部分地基于m个采样的估计标准偏差。因此，在优化的实施例中可以是：
以上的优化的M-Kernel函数可以进一步减少计算代价并且最小化统计误差。
4.3.3 用于演进数据的修改后的KDES
如以上讨论的，数据流可以随时间变化。因此，在实施例中，可以将KED、M-Kernal、或者优化的M-Kernal与以上讨论的指数平滑函数相结合。例如，优化后的M-Kernel可以被修改为结合指数平滑：
4.4 示例性的基于站点且基于估计吞吐量的URL选择处理的概述
图5示出了根据一个实施例的确定从哪个服务器下载比特率文件的示例性的基于站点且基于估计吞吐量的处理。尽管图5示出了根据一个实施例的示例步骤，但是其他实施例可以省去、添加、重新排序、和/或修改所示出的任何步骤。
出于示出清楚示例的目的，可以使用图1示出的实施例作为参考来描述图5。但是，可以使用其他网络布置来执行其他实施例。现在参考图5，在步骤505，播放特定电影的输入被接收。例如，客户端122接收播放特定电影的输入，如先前在步骤205中所讨论的。在步骤510，URL列表被接收。例如，客户端122接收URL列表，如先前在步骤510中讨论的。
在步骤520，基于偏好和估计吞吐量选择URL。例如，客户端122至少部分地基于以下三点来选择下载的第一URL：1)客户端122确定其应该首先尝试下载的初始比特率；2)与指向具有期望初始比特率的比特率文件的每个URL相关联的偏好；以及3)每个URL指向的每个站点的估计吞吐量(如果可用的话)。客户端122可以基于在步骤220中已经讨论的多个因素来确定初始比特率。另外，客户端122可以基于URL列表中包括的站点的估计吞吐量来确定初始比特率。在选择第一URL后，客户端122开始从站点146处的服务器136下载比特率文件，并且存储所观测到的吞吐量数据。
在步骤530，处理测试吞吐量是否低于最小阈值。如果是，则控制变换回步骤520，否则控制变换到步骤540。例如，客户端122确定从站点146处的服务器136接收的吞吐量高于特定最小阈值。因此，客户端122进行到步骤540。
在步骤540，处理测试更高的比特率是否可用；如果是，则控制变换到步骤520，否则控制变换到步骤590。例如，客户端122尝试通过针对具有更高比特率的比特率文件的可用性检查URL列表，来最大化用户的体验质量。客户端122确定更高的比特率在站点144处的服务器134处可用，则继续进行到步骤520。
在步骤520，客户端122选择指向站点144处的服务器134的URL，然后客户端122切换到站点144处的服务器134。客户端122存储来自站点144处的服务器134的感知吞吐量数据，实时确定估计吞吐量，并且继续重新访问步骤530。为了公开的目的，实时确定估计吞吐量意味着：在接收到下一个感知吞吐量数据之前，至少使用最近的感知吞吐量数据来确定估计吞吐量。
在重新访问的步骤530，客户端122确定从站点144处的服务器134接收的吞吐量低于特定最小阈值。因此，客户端122进行到步骤520。
在步骤520，客户端122切换回站点146处的服务器136。客户端122继续下载第一比特率文件，并且存储来自站点146处的服务器136的感知吞吐量。客户端122随后进行到重新访问步骤530。
在重新访问的步骤530，客户端122确定从站点146处的服务器136接收的吞吐量高于特定最小阈值。因此，客户端122重新访问步骤540。
在重新访问的步骤540，客户端122再次尝试通过针对具有更高比特率的比特率文件的可用性检查URL列表，来最大化用户的体验质量。即使客户端122确定更高的比特率在客户端144处的服务器134上可用，客户端122也正确地估计出来自站点144的吞吐量不足以支持实时下载更高比特率。因此，代替切换，客户端122进行到步骤590。
在步骤590，流传输数据传递继续。例如，客户端122继续从当前URL下载比特率文件，如先前在步骤290中所描述的。
4.5 具有基于优先级的比特率文件的服务器
为了向用户提供最佳的体验质量，设备寻求下载当时具有最高的可用比特率的比特率文件。将所有比特率文件存储在服务器上也有缺陷。因此，比特率文件可以被赋予优先级，从而使得最受欢迎的比特率文件被存储在更多的服务器上(尤其是高吞吐量或者低延时服务器)。实施例可以通过客户端维护基于站点的历史数据并使用以上描述的技术实时地正确估计吞吐量来最小化较差的质量体验，并且利用已经被选择性地放置在特定服务器上的比特率文件来进行高效操作。
例如，在客户端存储历史吞吐量数据可防止客户端尝试切换回第二服务器，以再次尝试下载以上实例中描述的第二比特率文件。精确估计第二服务器的吞吐量的技术可防止客户端尝试从第二服务器下载第二比特率。
4.6 探测
客户端可以探测服务器或者站点，以收集或者更新历史数据。例如，客户端可以连接到站点处的服务器，以收集历史数据并估计站点的吞吐量(客户端目前还没有针对该站点的历史数据)。在另一示例中，客户端可以检测到客户端已经改变了在网络拓扑中的位置，并且探测客户端已经具有其历史数据的站点处的服务器，以更新估计吞吐量。当客户端的缓冲器足够满以继续实时播放所缓存的媒体时，客户端也可以选择探测服务器或者站点(即使客户端探测的服务器具有非常差的吞吐量)。
5.0 实施机制-硬件概述
根据一个实施例，这里描述的技术由一个或多个专用计算设备执行。专用计算设备可以是执行这些技术的硬连线设备，或者可以包括数字电子设备(例如，被永久性地编程以执行这些技术的一个或多个专用集成电路(ASIC)或者现场可编程门阵列(FPGA))，或者可以包括被依照硬件、存储器、其他存储设备、或者组合中的程序指令进行编程以执行这些技术的一个或多个通用硬件处理器。这些专用计算设备还可以结合定制的硬连线逻辑、ASIC、或者具有定制的编程以实现这些技术的FPGA。专用计算设备可以是台式计算机系统、便携式计算机系统、手持设备、计算设备、或者包括硬连线和/或程序逻辑以执行这些技术的任何其他设备。
例如，图6是示出可以实现本发明的实施例的计算机系统600的框图。计算机系统600包括总线602或者用于传送信息的其他通信机构、以及与总线602耦合用于处理信息的硬件处理器604。硬件处理器604可以是例如，通用微处理器。
计算机系统600还包括耦合到总线602的、用于存储信息和将被处理器604执行的指令的主存储器606(诸如，随机存取存储器(RAM)或者其他动态存储设备)。主存储器606还可以被用于在指令被处理器604执行期间存储临时变量或者其他中间信息。这些指令在被存储在处理器604可访问的非暂态存储设备中时，使得计算机系统600变成被定制为执行指令规定的操作的专用机器。
计算机系统600还包括耦合到总线602、用于存储用于处理器604的指令和静态信息的只读存储器(ROM)608或者其他静态存储设备。存储设备610(例如，磁盘或者光盘)被提供并且被耦合到总线602，用于存储信息和指令。
计算机系统600可以经由总线602被耦合到用于向计算机用户显示信息的显示器612(例如，阴极射线管(CRT))。输入设备614(包括数字字母键和其他键)被耦合到总线602，用于向处理器604传送信息和命令选择。另一类型的用户输入设备是光标控制616(例如，鼠标、轨迹球、或者光标方向键)，用于向处理器604传送方向信息和命令选择、以及用于控制显示器612上的光标移动。输入设备一般具有在第一轴(例如，x)和第二轴(例如，y)两个轴中的两个自由度，这使得设备能够指定平面中的位置。
计算机系统600可以使用定制的硬连线逻辑、一个或多个ASIC或FPGA、固件、和/或与计算机系统结合促使或者编程计算机系统600作为专用机器的程序逻辑，实现这里描述的技术。根据一个实施例，这里的技术由计算机系统600响应于处理器604执行主存储器606中包含的一个或多个指令的一个或多个序列执行。这些指令可以被从诸如存储设备610之类的另一存储介质读入主存储器606。包括在主存储器606中的指令序列的执行使得处理器604执行这里描述的处理步骤。在替代实施例中，硬连线电路可以替代软件指令被使用、或者可以结合软件指令被使用。
这里使用的术语“存储介质”是指存储使得机器以特定方式进行操作的数据和/或指令的任何非暂态介质。这种存储介质可以包括非易失性介质和/或易失性介质。非易失性介质包括例如，诸如存储设备610之类的光盘或磁盘。易失性介质包括诸如主存储器606之类的动态存储器。常见形式的存储介质包括例如，软盘、柔性盘、硬件、固态驱动、磁带、或者任何其他磁数据存储介质、CD-ROM、任何其他光数据存储介质、具有孔洞图案的任何物理介质、RAM、PROM、以及EPROM、FLASH-EPROM、NVRAM、任何其他存储器芯片或者暗盒。
存储介质不同于传输介质，并且可以结合传输介质使用。传输介质参与在存储介质之间传输信息。例如，传输介质包括同轴线缆、铜线、和光纤(包括包含总线602的线缆)。传输介质还可以采用声波或光波的形式，在无线电波和红外线数据通信期间生成的声波或者光波)。
各种形式的介质可以被用于将一个或多个指令的一个或多个序列运载到处理器604供执行。例如，指令最初可以被装载在磁盘或者远程计算机的固态驱动器上。远程计算机可以将指令加载到其动态存储器中，并且使用调制解调器在电话线上发送指令。计算机系统600本地的调制解调器可以接收电话线上的数据，并且使用红外发射器将数据转换为红外信号。红外探测器可以接收红外信号中运载的数据，并且适当的电路可以将数据放置在总线602上。总线602将数据运载到主存储器606，处理器604从主存储器606提取指令并执行指令。由主存储器606接收的指令在被处理器604执行之前或者之后可以可选地被存储在存储设备610上。
计算机系统600还包括耦合到总线602的通信接口618。通信接口618提供到连接到本地网络622的网络链路620的双向数据通信耦合。例如，通信接口618可以是综合服务数字网(ISDN)卡、电缆调制解调器、卫星调制解调器、或者提供到相应类型的电话线的数据通信连接的调制解调器。作为另一示例，通信接口618可以是提供到兼容的LAN的数据通信连接的局域网(LAN)卡。无线链路也可以被实现。在任何这样的实施方式中，通信接口618发送并接收运载表示各种类型的信息的数字数据流的电、电磁、或者光信号。
网络链路620一般通过一个或多个网络提供到其他数据设备的数据通信。例如，网络链路620可以通过本地网络622提供到主计算机624或者由互联网服务提供商(ISP)626操作的数据装置的连接。ISP 626接着通过现在被统称为“互联网”628的全球分组数据连接网络来提供数据通信服务。本地网络622和互联网628均使用运载数字数据流的电、电磁、或者光信号。运载去往或者来自计算机系统600的数字数据的通过各种网络的信号、网络链路620上的信号、以及通过通信接口618的信号是传输介质的示例形式。
计算机系统600可以通过一个或多个网络、网络链路620、以及通信接口618发送消息并接收数据(包括程序代码)。在互联网示例中，服务器630可以通过互联网628、ISP 626、本地网络622、以及通信接口618来发送对于应用程序的请求代码。
接收代码在被接收和/或被存储在存储设备610或者其他非易失性存储设备中供随后执行时，可以由处理器604执行。
在前述说明中，已经参考根据实施方式而变化的多个具体细节描述了本发明的实施例。所以，唯一且排他地指示本发明，并且是申请人意图作为本发明的，是本申请的权利要求的设置，具体地这些权利要求中包括任何后续的修正。
6.0 公开的其他方面，
在前述说明中，已经参考根据实施方式而变化的多个具体细节描述了本发明的实施例。所以，唯一且排他地指示本发明，并且是申请人意图作为本发明的，是本申请的权利要求的设置，具体地这些权利要求中包括任何后续的修正。针对权利要求中包含的术语明确阐述的任何定义将覆盖权利要求中所使用的这些术语的含义。因此，没有在权利要求中明确陈述的限制、元件、特性、特征、优点、或者属性不应该以任何方式限制权利要求的范围。说明书和附图被认为是说明性的而非限制性的。
本文描述的主题的多个方面在下面列出的条款中给出：
1.一种方法，包括：接收从具有多个服务器计算机的第一站点处的第一服务器计算机流传输的第一数据；至少部分地基于从第一服务器计算机流传输的第一数据的第一吞吐量，收集第一站点的第一吞吐量数据；接收从第二站点处的第二服务器计算机流传输的第二数据；至少部分地基于从第二服务器计算机流传输的第二数据的第二吞吐量，收集第二站点的第二吞吐量数据；至少部分地基于第一吞吐量数据和第二吞吐量数据的比较，从第二站点处的第二服务器计算机切换到第一站点处的第三服务器计算机；其中，该方法由一个或多个专用计算设备执行。
2.如条款1中任一项的方法，其中，第一吞吐量数据是在第一会话期间收集的，第二吞吐量数据是在第二会话期间收集的。
3.如条款1-2中任一项的方法，包括：实时地基于第一吞吐量数据计算第一吞吐量估计；实时地基于第二吞吐量数据计算第二吞吐量估计。
4.如条款1-3中任一项的方法，包括：从第三服务器计算机切换到第三站点处的第四服务器计算机；收集第三站点的第三吞吐量数据；实时地基于第三吞吐量数据计算第三估计；其中第三站点的吞吐量数据尚未被收集超过阈值时间量。
5.如条款1-4中任一项的方法，包括：实时地基于第一吞吐量数据计算第一吞吐量估计；实时地基于第二吞吐量数据计算第二吞吐量估计；其中从第二站点处的第二服务器计算机到第一站点处的第三服务器计算机的切换是基于第一吞吐量估计和第二吞吐量估计的。
6.如条款1-5中任一项的方法，包括：实时地基于第一吞吐量数据计算第一吞吐量估计；实时地基于第二吞吐量数据计算第二吞吐量估计；其中第一吞吐量估计和第二吞吐量估计至少部分地基于核密度估计器。
7.如条款1-6中任一项的方法，包括：实时地基于第一吞吐量数据计算第一吞吐量估计；实时地基于第二吞吐量数据计算第二吞吐量估计；其中第一吞吐量估计和第二吞吐量估计至少部分地基于核密度估计器，其中第二吞吐量数据不是演进的。
8.如条款1-7中任一项的方法，包括：实时地基于第一吞吐量数据计算第一吞吐量估计；实时地基于第二吞吐量数据计算第二吞吐量估计；其中第一吞吐量估计和第二吞吐量估计至少部分地基于核密度估计器，其中第二吞吐量数据是演进的。
9.如条款1-8中任一项的方法，包括：实时地基于第一吞吐量数据计算第一吞吐量估计；实时地基于第二吞吐量数据计算第二吞吐量估计；确定在第二站点处的第二服务器计算机上能够使用更高的比特率；确定第二吞吐量估计小于为了实时播放更高比特率所需的吞吐量。
10.如条款1-9中任一项的方法，包括：接收等级数据；至少部分地基于等级数据将第一站点关联到第一等级；至少部分地基于等级数据将第二站点关联到第一等级；至少部分地基于等级数据将第三站点关联到第二等级；在第一站点和第二站点不再能够被使用的情况下，从第一站点处的第三服务器计算机切换到第三站点处的第四服务器计算机，其中第一站点和第二站点不再能够被用于接收从第一站点或第二站点处的任何服务器计算机流传输的第三数据。
11.一种存储一个或多个指令序列的非暂态计算机可读数据存储介质，所述一个或多个指令序列在被执行时使得一个或多个处理器执行条款1-10中所述的方法中的任意方法。
12.一种包括指令的计算机程序产品，所述指令在一个或多个处理器上被执行时实现条款1-10中所述的方法中的任意方法。
13.一种具有处理器的计算设备，所述处理器被配置为执行条款1-10中所述的方法中的任意方法。

Claims (20)

1.一种用于数据通信网络的方法，包括：
接收从具有多个服务器计算机的第一站点处的第一服务器计算机流传输的第一数据；
至少部分地基于从所述第一服务器计算机流传输的所述第一数据的第一吞吐量，收集与所述第一站点相关联的第一吞吐量数据；
接收从第二站点处的第二服务器计算机流传输的第二数据；
至少部分地基于从所述第二服务器计算机流传输的所述第二数据的第二吞吐量，收集与所述第二站点相关联的第二吞吐量数据；
至少部分地基于所述第一吞吐量数据与所述第二吞吐量数据之间的比较，从所述第二站点处的所述第二服务器计算机切换到所述第一站点处的第三服务器计算机，而不尝试从所述第二站点处的其他服务器计算机进行下载；
其中，所述方法由一个或多个专用计算设备执行。
2.如权利要求1所述的方法，其中，所述第一吞吐量数据是在第一会话期间被收集的，所述第二吞吐量数据是在第二会话期间被收集的。
3.如权利要求1所述的方法，包括：
实时地基于所述第一吞吐量数据计算第一吞吐量估计；
实时地基于所述第二吞吐量数据计算第二吞吐量估计。
4.如权利要求3所述的方法，包括：
从所述第三服务器计算机切换到第三站点处的第四服务器计算机；
收集所述第三站点的第三吞吐量数据；
实时地基于所述第三吞吐量数据计算第三估计；
其中，所述第三站点的吞吐量数据尚未被收集超过阈值时间量。
5.如权利要求1所述的方法，包括：
实时地基于所述第一吞吐量数据计算第一吞吐量估计；
实时地基于所述第二吞吐量数据计算第二吞吐量估计；
其中，从所述第二站点处的所述第二服务器计算机到所述第一站点处的所述第三服务器计算机的切换是基于所述第一吞吐量估计和所述第二吞吐量估计的。
6.如权利要求1所述的方法，包括：
实时地基于所述第一吞吐量数据计算第一吞吐量估计；
实时地基于所述第二吞吐量数据计算第二吞吐量估计；
其中，所述第一吞吐量估计和所述第二吞吐量估计至少部分地基于核密度估计器。
7.如权利要求1所述的方法，包括：
实时地基于所述第一吞吐量数据计算第一吞吐量估计；
实时地基于所述第二吞吐量数据计算第二吞吐量估计；
其中，所述第一吞吐量估计和所述第二吞吐量估计至少部分地基于核密度估计器；
其中，所述第二吞吐量数据不是演进的。
8.如权利要求1所述的方法，包括：
实时地基于所述第一吞吐量数据计算第一吞吐量估计；
实时地基于所述第二吞吐量数据计算第二吞吐量估计；
其中，所述第一吞吐量估计和所述第二吞吐量估计至少部分地基于核密度估计器；
其中，所述第二吞吐量数据是演进的。
9.如权利要求1所述的方法，包括：
实时地基于所述第一吞吐量数据计算第一吞吐量估计；
实时地基于所述第二吞吐量数据计算第二吞吐量估计；
确定在所述第二站点处的所述第二服务器计算机上能够使用更高的比特率；
确定所述第二吞吐量估计小于为了实时播放所述更高的比特率所需的吞吐量。
10.如权利要求1所述的方法，包括：
接收等级数据；
至少部分地基于所述等级数据将所述第一站点关联到第一等级；
至少部分地基于所述等级数据将所述第二站点关联到所述第一等级；
至少部分地基于所述等级数据将第三站点关联到第二等级；
如果所述第一站点和所述第二站点不再能够被使用，则从所述第一站点处的所述第三服务器计算机切换到所述第三站点处的第四服务器计算机，其中，所述第一站点和所述第二站点不再能够用于接收从所述第一站点或所述第二站点处的任何服务器计算机流传输的第三数据。
11.一个或多个存储了一个或多个指令序列的非暂态计算机可读介质，该指令序列在被一个或多个计算设备执行时使得：
接收从具有多个服务器计算机的第一站点处的第一服务器计算机流传输的第一数据；
至少部分地基于从所述第一服务器计算机流传输的所述第一数据的第一吞吐量，收集与所述第一站点相关联的第一吞吐量数据；
接收从第二站点处的第二服务器计算机流传输的第二数据；
至少部分地基于从所述第二服务器计算机流传输的所述第二数据的第二吞吐量，收集与所述第二站点相关联的第二吞吐量数据；
至少部分地基于所述第一吞吐量数据与所述第二吞吐量数据之间的比较，从所述第二站点处的所述第二服务器计算机切换到所述第一站点处的第三服务器计算机，而不尝试从所述第二站点处的其他服务器计算机进行下载。
12.如权利要求11所述的一个或多个非暂态计算机可读介质，还包括在被执行时使得在第一会话期间收集所述第一吞吐量数据的指令序列，还包括在被执行时使得在第二会话期间收集所述第二吞吐量数据的指令序列。
13.如权利要求11所述的一个或多个非暂态计算机可读介质，还包括在被执行时使得执行以下处理的指令序列：
实时地基于所述第一吞吐量数据计算第一吞吐量估计；
实时地基于所述第二吞吐量数据计算第二吞吐量估计。
14.如权利要求13所述的一个或多个非暂态计算机可读介质，还包括：
从所述第三服务器计算机切换到第三站点处的第四服务器计算机；
收集所述第三站点的第三吞吐量数据；
实时地基于所述第三吞吐量数据计算第三估计；
其中，所述第三站点的吞吐量数据尚未被收集超过阈值时间量。
15.如权利要求11所述的一个或多个非暂态计算机可读介质，还包括在被执行时使得执行以下处理的指令序列：
实时地基于所述第一吞吐量数据计算第一吞吐量估计；
实时地基于所述第二吞吐量数据计算第二吞吐量估计；
其中，从所述第二站点处的所述第二服务器计算机到所述第一站点处的所述第三服务器计算机的切换是基于所述第一吞吐量估计和所述第二吞吐量估计的。
16.如权利要求11所述的一个或多个非暂态计算机可读介质，还包括在被执行时使得执行以下处理的指令序列：
实时地基于所述第一吞吐量数据计算第一吞吐量估计；
实时地基于所述第二吞吐量数据计算第二吞吐量估计；
其中，所述第一吞吐量估计和所述第二吞吐量估计至少部分地基于核密度估计器。
17.如权利要求11所述的一个或多个非暂态计算机可读介质，还包括在被执行时使得执行以下处理的指令序列：
实时地基于所述第一吞吐量数据计算第一吞吐量估计；
实时地基于所述第二吞吐量数据计算第二吞吐量估计；
其中，所述第一吞吐量估计和所述第二吞吐量估计至少部分地基于核密度估计器；
其中，所述第二吞吐量数据不是演进的。
18.如权利要求11所述的一个或多个非暂态计算机可读介质，还包括在执行时使得执行以下处理的指令序列：
实时地基于所述第一吞吐量数据计算第一吞吐量估计；
实时地基于所述第二吞吐量数据计算第二吞吐量估计；
其中，所述第一吞吐量估计和所述第二吞吐量估计至少部分地基于核密度估计器；
其中，所述第二吞吐量数据是演进的。
19.如权利要求11所述的一个或多个非暂态计算机可读介质，还包括在执行时使得执行以下处理的指令序列：
实时地基于所述第一吞吐量数据计算第一吞吐量估计；
实时地基于所述第二吞吐量数据计算第二吞吐量估计；
确定在所述第二站点处的所述第二服务器计算机上能够使用更高的比特率；
确定所述第二吞吐量估计小于为了实时播放所述更高的比特率所需的吞吐量。
20.如权利要求11所述的一个或多个非暂态计算机可读介质，还包括在执行时使得执行以下处理的指令序列：
接收等级数据；
至少部分地基于所述等级数据将所述第一站点关联到第一等级；
至少部分地基于所述等级数据将所述第二站点关联到所述第一等级；
至少部分地基于所述等级数据将第三站点关联到第二等级；
如果所述第一站点和所述第二站点不再能够被使用，则从所述第一站点处的所述第三服务器计算机切换到所述第三站点处的第四服务器计算机，其中，所述第一站点和所述第二站点不再能够用于接收从所述第一站点或所述第二站点处的任何服务器计算机流传输的第三数据。
CN201480012519.XA 2013-01-07 2014-01-06 基于站点的服务器选择 Active CN105191251B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13/735,827 US9319458B2 (en) 2013-01-07 2013-01-07 Site-based server selection
US13/735,827 2013-01-07
PCT/US2014/010374 WO2014107678A1 (en) 2013-01-07 2014-01-06 Site-based server selection

Publications (2)

Publication Number Publication Date
CN105191251A CN105191251A (zh) 2015-12-23
CN105191251B true CN105191251B (zh) 2019-07-12

Family

ID=50030491

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201480012519.XA Active CN105191251B (zh) 2013-01-07 2014-01-06 基于站点的服务器选择

Country Status (6)

Country Link
US (2) US9319458B2 (zh)
EP (1) EP2941857B1 (zh)
CN (1) CN105191251B (zh)
DK (1) DK2941857T3 (zh)
TR (1) TR201818952T4 (zh)
WO (1) WO2014107678A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9319458B2 (en) 2013-01-07 2016-04-19 Netflix, Inc. Site-based server selection
US9654528B1 (en) 2013-03-11 2017-05-16 Google Inc. Dynamic bitrate selection for streaming media
US20140281002A1 (en) * 2013-03-14 2014-09-18 General Instrument Corporation Devices, systems, and methods for managing and adjusting adaptive streaming traffic

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6477522B1 (en) * 1999-06-10 2002-11-05 Gateway, Inc. Dynamic performance based server selection
CN101414936A (zh) * 2007-10-16 2009-04-22 索尼株式会社 用于有效地执行网络仿真过程的系统和方法
CN101772938A (zh) * 2007-08-21 2010-07-07 株式会社Ntt都科摩 带有在线缓存和对等转发的媒体流式传输

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6195680B1 (en) * 1998-07-23 2001-02-27 International Business Machines Corporation Client-based dynamic switching of streaming servers for fault-tolerance and load balancing
US20020065922A1 (en) * 2000-11-30 2002-05-30 Vijnan Shastri Method and apparatus for selection and redirection of an existing client-server connection to an alternate data server hosted on a data packet network (DPN) based on performance comparisons
US7133368B2 (en) * 2002-02-01 2006-11-07 Microsoft Corporation Peer-to-peer method of quality of service (QoS) probing and analysis and infrastructure employing same
US20050105533A1 (en) * 2003-09-02 2005-05-19 Malolepsy Gary L. Video stream server switching
US8996702B2 (en) * 2005-09-19 2015-03-31 International Business Machines Corporation Method, system, and computer program product for routing sessions to a specific URL in a multi-site environment
US7652990B2 (en) * 2005-11-29 2010-01-26 Alcatel-Lucent Usa Inc. Method and apparatus for providing quality of service level in broadband communications systems
US20080189429A1 (en) 2007-02-02 2008-08-07 Sony Corporation Apparatus and method for peer-to-peer streaming
EP2517434B1 (en) * 2009-12-21 2015-10-07 Koninklijke KPN N.V. Content distribution system
US20120124172A1 (en) * 2010-11-15 2012-05-17 Google Inc. Providing Different Versions of a Media File
US8925022B2 (en) * 2011-05-25 2014-12-30 Motorola Mobility Llc Method and apparatus for transferring content
US9014027B2 (en) * 2012-02-29 2015-04-21 Cisco Technology, Inc. Multi-interface adaptive bit rate session management
US9319458B2 (en) 2013-01-07 2016-04-19 Netflix, Inc. Site-based server selection

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6477522B1 (en) * 1999-06-10 2002-11-05 Gateway, Inc. Dynamic performance based server selection
CN101772938A (zh) * 2007-08-21 2010-07-07 株式会社Ntt都科摩 带有在线缓存和对等转发的媒体流式传输
CN101414936A (zh) * 2007-10-16 2009-04-22 索尼株式会社 用于有效地执行网络仿真过程的系统和方法

Also Published As

Publication number Publication date
EP2941857A1 (en) 2015-11-11
US20160234279A1 (en) 2016-08-11
US20140195646A1 (en) 2014-07-10
CN105191251A (zh) 2015-12-23
US9319458B2 (en) 2016-04-19
US10320874B2 (en) 2019-06-11
DK2941857T3 (en) 2019-01-21
TR201818952T4 (tr) 2019-01-21
EP2941857B1 (en) 2018-10-03
WO2014107678A1 (en) 2014-07-10

Similar Documents

Publication Publication Date Title
CN104468502B (zh) 用于内容分布的服务器选择
US10305947B2 (en) Pre-buffering audio streams
US20170142177A1 (en) Method and system for network dispatching
EP2704402B1 (en) Method and node for distributing electronic content in a content distribution network
US8713192B2 (en) System and method for routing streaming data requests
CN110636339B (zh) 基于码率的调度方法、装置及电子设备
US9124674B2 (en) Systems and methods for connection pooling for video streaming in content delivery networks
US9712854B2 (en) Cost-aware cloud-based content delivery
CN105340245B (zh) 用于适配被配置为接收多媒体内容的客户机终端的下载行为的方法以及对应的终端
US10091675B2 (en) System and method for estimating an effective bandwidth
MX2014007165A (es) Pre-guardado en memoria cache de red de suministro de contenido (cdn) impulsado por aplicacion.
CN108668146B (zh) 一种调整流媒体码率的方法及设备
CN104702592B (zh) 流媒体下载方法和装置
US9712580B2 (en) Pipelining for parallel network connections to transmit a digital content stream
CN105191251B (zh) 基于站点的服务器选择
CN110830565A (zh) 资源下载方法、装置、系统、电子设备及存储介质
CN110072130A (zh) 一种基于http/2的has视频切片推送方法
CN113467910A (zh) 基于业务等级的过载保护调度方法
CN112543357A (zh) 一种基于dash协议的流媒体数据传输方法
CN105794150A (zh) 用于测量端对端互联网应用性能的方法
CN106713456A (zh) 网络带宽统计方法及装置
JP6886874B2 (ja) エッジ装置、データ処理システム、データ送信方法、及びプログラム
KR20140062649A (ko) 라우터 및 그 동작방법
US9678881B2 (en) Data distribution device and data distribution method
Noh et al. Congestion‐aware HTTP adaptive streaming system over SDN‐enabled Wi‐Fi network

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant