CN106134150A - 实现冗余编码内容数据功能的选择性利用的传输加速器 - Google Patents

Abstract

根据本公开内容的实施例，提供了一种用于将内容递送至客户端设备的用户代理(UA)的传输加速器(TA)系统和方法。实施例由所述TA的请求管理器(RM)来接收所述UA所提供的片段请求，以用于从内容服务器请求内容；以及确定针对所述片段请求中的一个片段请求要请求的冗余编码内容数据的量，以由所述RM在恢复所述片段时使用。

Description

实现冗余编码内容数据功能的选择性利用的传输加速器

优先权和相关申请声明

本申请要求于2014年3月18日递交的名称为“TRANSPORT ACCELERATORIMPLEMENTING SELECTIVE UTILIZATION OF REDUNDANT ENCODED CONTENT DATAFUNCTIONALITY”的共同未决的美国临时专利申请号61/954,987以及于2014年5月28日递交的名称为“TRANSPORT ACCELERATOR IMPLEMENTING SELECTIVE UTILIZATION OFREDUNDANT ENCODED CONTENT DATA FUNCTIONALITY”的美国专利申请序列号14/289,458的优先权；据此通过引用的方式将上述申请的公开内容并入本文。本申请涉及以下申请：于2014年5月28日递交的名称为“TRANSPORT ACCELERATOR IMPLEMENTING EXTENDEDTRANSMISSION CONTROL FUNCTIONALITY”的共同转让的美国专利申请序列号14/289,016；于2014年5月28日递交的名称为“TRANSPORT ACCELERATOR IMPLEMENTING EXTENDEDTRANSMISSION CONTROL FUNCTIONALITY”的序列号14/289,181；于2014年5月28日递交的名称为“TRANSPORT ACCELERATOR IMPLEMENTING ENHANCED SIGNALING”的序列号14/289,348；于2014年5月28日递交的名称为“TRANSPORT ACCELERATOR IMPLEMENTING REQUESTMANAGER AND CONNECTION MANAGER FUNCTIONALITY”的序列号14/289,403；于2014年5月28日递交的名称为“TRANSPORT ACCELERATOR IMPLEMENTING A MULTIPLE INTERFACEARCHITECTURE”的序列号14/289,476；以及于2014年5月28日递交的名称为“TRANSPORTACCELERATOR IMPLEMENTING CLIENT SIDE TRANSMISSION FUNCTIONALITY”的序列号14/289,499；上述申请中的每一个在此与本申请同时递交，并且通过引用的方式将上述申请的公开内容全部明确地并入本文。

技术领域

越来越多的内容通过可用的通信网络来传输。通常，该内容包括许多类型的数据，例如，包括音频数据、视频数据、图像数据等。视频内容(尤其是高分辨率视频内容)经常包括相对大的数据文件或其它数据集合。因此，最终用户设备或其它客户端设备上的消费这种内容的用户代理(UA)经常请求和接收包括期望的视频内容的内容片段的序列。例如，UA可以包括在用户设备上执行的客户端应用或过程，其请求数据(经常是多媒体数据)并且接收所请求的数据，来进行进一步的处理并且可能在用户设备上进行显示。

如今，许多类型的应用依靠超文本传输协议(HTTP)来进行前述内容的递送。在许多这样的应用中，HTTP传输的性能对于用户的应用体验是关键的。例如，实况流式传输具有可以妨碍视频流式传输客户端的性能的若干约束。两个约束尤其突出。第一，媒体段随时间一个接一个地变为可用。该约束阻止客户端连续地下载数据的大部分，这继而影响下载速率估计的准确性。由于大多数流式传输客户端在“请求-下载-估计”循环上操作，所以其在下载估计不准确时通常不能很好地进行。第二，当观看实况活动流式传输时，用户通常不想要遭受从实际的实况活动时间线的长延迟。这样的行为阻止流式传输客户端构建大型缓冲器，这继而可能导致更多的重新缓冲。

在流式传输客户端通过传输控制协议(TCP)来操作(如大多数基于HTTP的动态自适应流式传输(DASH)客户端一样)的情况下，客户端典型地基于估计的可用性调度来请求片段。在未接收到片段的分组的情况下，现有的TCP协议用于减慢对数据的传输并且重新请求在分组中携带的丢失数据。例如，接收方将仅确认(ACK)直到下一期望字节(NextByteExpected)，其中下一期望字节指代在丢失分组中携带的片段的数据的第一字节。在那之后，如果接收到携带超出下一期望字节但是不包括片段的字节下一期望字节的数据的无序分组，则接收方将发送出与下一期望字节对应的重复ACK，并且发送方将会将这样的重复ACK解释为网络拥塞的迹象，因此通过减小拥塞窗的方式来减慢发送速率。因此，对内容数据的丢失或延迟部分的恢复可能是有问题的，这不仅由于重传这样的数据中涉及的延迟，还由于响应于网络拥塞的相关联的检测而经常减慢发送速率。

虽然通过冗余编码数据技术(例如，前向纠错(FEC)编码)来前摄地解决未能被客户端接收的至少某个级别的内容数据是可能的，但是当使用这些技术(当被应用于流式传输内容时)时必须谨慎。取决于协议的设计，前摄地发送冗余编码数据可以消耗额外的带宽，这是由于用于支持潜在的丢失数据的恢复的数据编码的冗余。然而，没有这些冗余的流式传输内容可能遭受不期望的端到端延迟，尤其是当被应用于实况流式传输并且使用TCP作为底层递送协议时。前述内容在流式传输客户端通过TCP来操作(例如，作为DASH客户端)的情况下尤其是这样，这是由于协议的用于确保数据的递送但是可能具有延迟或减小速率的递送的操作。

发明内容

根据本公开内容的实施例，提供了一种用于由客户端设备的传输加速器(TA)来加速将内容递送至所述客户端设备的用户代理(UA)的方法。实施例的所述方法包括：由所述TA的请求管理器(RM)来接收所述UA所提供的片段请求，以用于从内容服务器请求内容；以及确定针对所述片段请求中的一个片段请求要请求的冗余编码内容数据的量，以由所述RM在恢复所述片段时使用。

根据本公开内容的实施例，提供了一种用于由客户端设备的传输加速器(TA)来加速将内容递送至所述客户端设备的用户代理(UA)的装置。实施例的所述装置包括：用于由所述TA的请求管理器(RM)来接收所述UA所提供的片段请求，以用于从内容服务器请求内容的单元；以及用于确定针对所述片段请求中的一个片段请求要请求的冗余编码内容数据的量，以由所述RM在恢复所述片段时使用的单元。

根据本公开内容的实施例，提供了一种用于由客户端设备的传输加速器(TA)来加速将内容递送至所述客户端设备的用户代理(UA)的计算机程序产品。所述计算机程序产品包括非暂时性计算机可读介质，所述非暂时性计算机可读介质具有记录在其上的程序代码。实施例的所述程序代码包括：用于由所述TA的请求管理器(RM)来接收所述UA所提供的片段请求，以用于从内容服务器请求内容的程序代码；以及用于确定针对所述片段请求中的一个片段请求要请求的冗余编码内容数据的量，以由所述RM在恢复所述片段时使用的程序代码。

根据本公开内容的实施例，提供了一种被配置用于由客户端设备的传输加速器(TA)来加速将内容递送至所述客户端设备的用户代理(UA)的装置。所述装置包括至少一个处理器，以及耦合到所述至少一个处理器的存储器。实施例的所述至少一个处理器被配置为：由所述TA的请求管理器(RM)来接收所述UA所提供的片段请求，以用于从内容服务器请求内容；以及确定针对所述片段请求中的一个片段请求要请求的冗余编码内容数据的量，以由所述RM在恢复所述片段时使用。

附图说明

图1根据本公开内容的实施例，示出了适于由实现冗余编码内容数据的选择性利用的传输加速器来提供内容传输的系统。

图2示出了描绘本公开内容的实施例的传输加速器的固定冗余编码内容数据配置请求管理器的操作的流程图。

图3示出了描绘本公开内容的实施例的传输加速器的自动冗余编码内容数据配置请求管理器的操作的流程图。

图4根据本公开内容的实施例，示出了描绘已接收数据、挂起数据和迟到数据的时间线。

图5示出了如可以在本公开内容的实施例的请求管理器和用户代理之间实现的应用编程接口。

图6根据本公开内容的实施例，示出了适于由实现冗余编码内容数据的选择性利用的传输加速器来提供内容传输的系统，其中，冗余编码内容数据是由单独的源或提供者来提供的。

具体实施方式

本文中使用的词语“示例性”意味着“作为示例、实例或说明”。本文中描述为“示例性”的任何方面不必被解释为优选于其它方面或者比其它方面有优势。

在本描述中，术语“应用”还可以包括具有可执行内容(诸如：对象代码、脚本、字节代码、标记语言文件以及补丁)的文件。另外，本文中所引用的“应用”还可以包括本质上不可执行的文件(诸如可能需要被打开的文档或需要被访问的其它数据文件)。

如在本描述中使用的，术语“内容”可以包括具有视频、音频、视频和音频的组合的数据，或在一个或多个质量等级处的其它数据，质量等级由比特速率、分辨率或其它因素确定。内容还可以包括可执行内容(诸如：对象代码、脚本、字节代码、标记语言文件以及补丁)。另外，“内容”还可以包括本质上不可执行的文件(诸如可能需要被打开的文档或需要被访问的其它数据文件)。

如在本描述中使用的，术语“片段”指代可以由用户设备请求的和/或在用户设备处接收的内容的一个或多个部分。

如在本描述中使用的，术语“流式传输内容”指代可以根据实现实时内容传输或在一段时间内的内容传输的一个或多个标准，从服务器设备发送并且在用户设备处接收的内容。流式传输内容标准的示例包括支持解交织(或多个)信道的那些标准和不支持解交织(或多个)信道的那些标准。

如在本描述中使用的，术语“组件”、“数据库”、“模块”、“系统”等等旨在指代计算机相关的实体，要么是硬件、固件、硬件和软件的组合、软件，要么是执行中的软件。例如，组件可以是，但不限于是：在处理器上运行的过程、处理器、对象、可执行文件、执行的线程、程序和/或计算机。通过说明的方式，在计算设备运行上的应用和计算设备两者可以是组件。一个或多个组件可以存在于过程和/或执行的线程中，并且组件可以位于一个计算机中和/或分布在两个或更多计算机之间。此外，这些组件可以从具有存储在其上的各种数据结构的各种计算机可读介质中执行。组件可以诸如根据具有一个或多个数据分组(例如，来自与本地系统、分布式系统中的另一个组件进行交互，和/或跨越诸如互联网的网络通过信号的方式与其它系统进行交互的一个组件的数据)的信号通过本地和/或远程过程进行通信。

如本文所使用的，术语“用户设备”、“用户装置”和“客户端设备”包括：能够从网络服务器请求和接收内容并且向网络服务器发送信息的设备。这样的设备可以是固定设备或移动设备。术语“用户设备”、“用户装置”和“客户端设备”可以可互换地使用。

如本文中所使用的，术语“用户”指代在用户设备或客户端设备上接收内容并且向网站发送信息的个人。

图1示出了根据本文的概念适于通过通信网络提供内容(诸如可以包括音频数据、视频数据、图像数据、文件数据等)传输的系统100。因此，客户端设备110被示为经由网络150与服务器130相通信，据此根据本公开内容的概念，服务器130可以向客户端设备110传输存储在数据库140中的各种内容。应当认识到的是，虽然在图1中仅表示了单个客户端设备和单个服务器和数据库，但是系统100可以包括多个任何这些设备或全部这些设备。例如，服务器130可以包括服务器群中的服务器，其中，可以集中地和/或在分布式配置中放置多个服务器，以服务对内容传输的高级别的需求。替代地，服务器130可以与传输加速器120共置在相同的设备上(例如，通过I/O元件113直接连接到传输加速器120，而不是通过网络150)，诸如当内容中的一些或全部内容位于同样共置在设备上并且通过服务器130被提供给传输加速器120的数据库140(高速缓存)中时。同样，用户可以拥有多个客户端设备，和/或多个用户设备均可以拥有一个或多个客户端设备，根据本文中的概念，所述客户端设备中的任何或全部适于内容传输。

客户端设备110可以包括可操作用于经由网络150接收内容传输的各种配置的设备。例如，客户端设备110可以包括有线设备、无线设备、个人计算设备、平板或板计算设备、便携式蜂窝电话、启用WiFi的设备、启用蓝牙的设备、电视机、一对具有显示器的眼镜、一对扩充实境眼镜、或者连接到网络105的可以使用任何可用方法或基础设施来与服务器130进行通信的任何其它通信、计算或接口设备。客户端设备110被称为“客户端设备”，这是因为其可以运作为或连接到作为服务器130的客户端来运作的设备。

所示出的实施例的客户端设备110包括多个功能块，这里被示为包括处理器111、存储器112和输入/输出(I/O)元件113。虽然为了简单起见没有在图1中的表示中示出，但是客户端设备110可以包括额外的功能块，诸如用户界面、射频(RF)模块、相机、传感器阵列、显示器、视频播放器、浏览器等，它们中的一些或全部可以被根据本文概念的操作利用。前述功能块可以通过一个或多个总线(诸如总线114)可操作地连接。总线114可以包括逻辑和物理连接，以允许所连接的元件、模块和组件进行通信和互操作。

存储器112可以是任何类型的易失性或非易失性存储器，并且在一个实施例中，可以包括闪存。存储器112可以永久地安装在客户端设备110中，或者可以是可移动存储器元件，诸如可移动存储器卡。虽然被示为单个元件，但是存储器112可以包括多个分立的存储器和/或存储器类型。

存储器112可以存储或以其它方式包括各种计算机可读代码段，诸如可以形成应用、操作系统、文件、电子文档、内容等。例如，所示出的实施例的存储器112包括对传输加速器(TA)120和UA 129进行定义的计算机可读代码段，所述计算机可读代码段被处理器(例如，处理器111)执行时提供可如本文所描述的来操作的逻辑电路。存储器112所存储的代码段可以提供除前述TA 120和UA 129之外的应用。例如，根据本文实施例，存储器112可以存储诸如浏览器的应用，用于从访问服务器130访问内容。这样的浏览器可以是网页浏览器，诸如超文本传输协议(HTTP)网页浏览器，其用于访问和观看网页内容并且用于经由HTTP与服务器130(通过连接151和152经由网络150)进行通信，如果服务器130是网页服务器的话。举一个示例，可以将HTTP请求从客户端设备110中的浏览器通过连接151和152经由网络150发送给服务器130。可以将HTTP响应从服务器130通过连接152和151经由网络150发送给客户端设备110中的浏览器。

UA 129可操作用于从服务器(诸如服务器130)请求和/或接收内容。例如，UA 129可以包括请求数据(诸如多媒体数据)并且接收所请求的数据来进行进一步的处理并且可能在客户端设备110的显示器上进行显示的客户端应用或过程，诸如浏览器、DASH客户端、HTTP流式传输(HLS)客户端等。例如，客户端设备110可以执行代码，包括用于回放媒体的UA129，诸如独立媒体回放应用或被配置为在互联网浏览器中运行的基于浏览器的媒体播放器。在根据实施例的操作中，UA 129决定在流式传输内容会话期间的各个时间点请求传输内容文件的哪些片段或片段序列。例如，UA129的DASH客户端配置可以操作用于诸如基于最近的下载状况，决定在每个时间点从内容的哪个表示(例如，高分辨率表示、中等分辨率表示、低分辨率表示等)请求哪个片段。同样，UA 129的网页浏览器配置可以操作用于作出针对网页或其部分等的请求。典型地，UA使用HTTP请求来请求这样的片段。

根据本文概念，TA 120适于提供对期望内容(的片段或片段序列例如，前述如可以用于提供视频流式传输、文件下载、基于网页的应用、通用网页等的内容片段)的增强的递送。实施例的TA 120适于允许通用或传统UA(即，尚未被预先设计为与TA进行交互的UA，其仅支持用于作出片段请求的标准接口，诸如实现标准化TCP传输协议的HTTP 1.1接口)仍然受益于使用执行那些请求的TA。另外或替代地，实施例的TA 120提供增强型接口来有助于向被设计为利用增强型接口的功能的UA提供进一步的益处。实施例的TA 120适于根据现有的内容传输协议来执行片段请求，诸如使用TCP通过实现标准化TCP传输协议的HTTP接口，由此允许通用或传统媒体服务器(即，尚未被预先设计为与TA进行交互的媒体服务器)对请求进行服务，同时提供片段至UA和客户端设备的增强的递送。

在提供前述增强的片段递送功能的过程中，本文实施例的TA 120包括如本文描述的架构组件和协议。例如，在图1中示出的实施例的TA 120包括请求管理器(RM)121和连接管理器(CM)122，它们合作以提供各种增强的片段递送功能，如下文进一步描述的。

除了前述形成应用、操作系统、文件、电子文档、内容等的代码片段之外，存储器112还可以包括或以其它方式提供由客户端设备110的功能块使用的各种寄存器、缓冲器和存储单元。例如，存储器112可以包括播出缓冲器，诸如可以提供用于假脱机片段的数据的先进先出(FIFO)存储器，以用于由服务器130进行流式传输和由客户端设备110进行回放。

实施例的处理器111可以是能够执行指令以控制客户端设备110的操作和功能的任何通用或专用处理器。虽然被示为单个元件，但是处理器111可以包括多个处理器或者分布式处理架构。

I/O元件113可以包括和/或耦合到各种输入/输出组件。例如，I/O元件113可以包括和/或耦合到显示器、扬声器、麦克风、键盘、指向设备、触摸感应屏、用户界面控制元件、以及允许用户提供输入命令和从客户端设备110接收输出的任何其它设备或系统。任何或全部这样的组件可以用于提供客户端设备110的用户界面。另外或替代地，I/O元件113可以包括和/或耦合到磁盘控制器、网络接口卡(NIC)、射频(RF)收发机以及促进客户端设备110的输入和/或输出功能的任何其它设备或系统。

在访问和播放流式传输内容的操作中，客户端设备110经由网络150使用链路151和152来与服务器130进行通信，以获得内容数据(例如，如前述片段)，当所述内容数据被呈现时提供内容的回放。因此，UA 129可以包括内容播放器应用，其被处理器111执行用于在客户端设备110中建立内容回放环境。当发起特定内容文件的回放时，UA 129可以与服务器130的内容递送平台进行通信，以获得内容标识符(例如，一个或多个列表、清单、配置文件或识别期望内容的媒体段或片段以及其定时边界的其它标识符)。关于媒体段和其定时的信息被UA 129的流式传输内容逻辑单元用于控制请求针对内容回放的片段。

服务器130包括可操作用于向客户端设备提供期望内容的一个或多个系统。例如，服务器130可以包括可操作用于将内容经由网络150流式传输至各个客户端设备的标准HTTP网页服务器。服务器130可以包括内容递送平台，其包括可以将内容递送至用户设备110的任何系统或方法。可以将内容存储在一个或多个与服务器130相通信的数据库中，诸如所示出的实施例的数据库140。数据库140可以存储在服务器130上或可以存储在通信地耦合到服务器130的一个或多个服务器上。数据库140的内容可以包括各种形式的数据，诸如视频、音频、流式传输文本、以及可以在一段时间内由服务器130传输给客户端设备110的任何其它内容，诸如实况网络广播内容和存储的媒体内容。

数据库140可以包括多个不同的源或内容文件和/或任何特定内容的多个不同的表示(例如，高分辨率表示、中等分辨率表示、低分辨率表示等)。例如，内容文件141可以包括特定多媒体编译的高分辨率表示，并且因此当被传输时的高比特速率表示，而内容文件142可以包括该相同的特定多媒体编译的低分辨率表示，并且因此当被传输时的低比特速率表示。另外或替代地，任何特定内容的不同表示可以包括前向纠错(FEC)表示(例如，包括内容数据的冗余编码的表示)，诸如可以由内容文件143提供的。根据本文实施例，统一资源定位符(URL)、统一资源标识符(URI)和/或统一资源名称(URN)与这些内容文件中的全部内容文件相关联，并且因此这样的URL、URI和/或URN(可能与诸如字节范围的其它信息一起)可以用于标识和访问请求的数据。

网络150可以是无线网络、有线网络、广域网(WAN)、局域网(LAN)或适于如本文描述的内容传输的任何其它网络。在一个实施例中，网络150可以包括互联网的至少一部分。客户端设备110可以通过双向连接(诸如由网络连接151表示的)来连接到网络150。替代地，客户端设备110可以经由单向连接(诸如由启用多媒体广播多媒体系统(MBMS)的网络提供的连接)来连接(例如，连接151、152和网络150可以包括MBMS网络，并且服务器130可以包括广播多播服务中心(BM-SC)服务器)。连接可以是有线连接或者可以是无线连接。在一个实施例中，连接151可以是无线连接，诸如蜂窝4G连接、无线保真(WiFi)连接、蓝牙连接或另一种无线连接。服务器130可以通过双向连接(诸如由网络连接152表示的)来连接到网络150。服务器130可以通过单向连接(例如，使用如在3GPP TS.26.346中描述的协议和服务的MBMS网络或ATSC 3.0网络)来连接到网络150。连接可以是有线连接或者可以是无线连接。

在图1中示出的实施例的客户端设备110包括TA 120，其可操作用于提供根据本文概念的对期望内容的片段或片段序列的增强的递送。如上所述，所示出的实施例的TA 120包括RM 121和CM 122，它们合作以提供各种增强的片段递送功能。实施例的UA 129与RM121之间的接口124以及RM 121与CM 122之间的接口123提供HTTP类似的连接。例如，前述接口可以采用标准HTTP协议以及包括额外的信令(例如，使用与HTTP的那些信令技术类似的信令技术来提供的)来支持根据本文实施例的增强的片段递送的某些功能方面。

在根据实施例的操作中，RM 121从UA 129接收针对片段的请求并且决定从CM 122请求什么数据以可靠地接收和恢复请求的片段。根据本文实施例，RM 121适于从通用或传统UA(即，尚未被预先设计为与RM进行交互的UA)接收片段请求并且对其进行响应，由此提供了与这样的传统UA的兼容性。因此，RM 121可以操作用于将UA 129从TA 120的扩展的传输协议操作隔离。然而，如将从接下来的论述中更加全面地理解的，UA129可以适于扩展的传输协议操作，据此RM 121和UA 129合作以实现扩展的传输协议操作的一个或多个特征，诸如通过使用RM 121和UA 129之间的信令来实现这样的特征。

由实施例的RM 121向CM 122作出的数据请求(本文中被称为“块请求”，其中，所请求的数据包括“块”)的大小可以远小于UA 129所请求的片段(并且其为RM 121正在恢复的片段)的大小。因此，来自UA 129的每个片段请求可以触发RM 121生成和向CM 122作出多个块请求，以恢复该片段。

由RM 121向CM 122作出的块请求中的一些块请求可能是针对已经请求但尚未到达的数据的，并且RM 122已经认为所述数据可能永远不会到达或者可能太晚到达。另外或替代地，由RM 121向CM 122作出的块请求中的一些块请求可能是针对根据原始片段生成的FEC编码数据的，据此RM121可以对从CM 122接收的数据进行FEC解码，以恢复片段或其某个组合。RM 121将恢复出的片段递送给UA 129。因此，根据实施例，可以存在RM的各种配置，诸如可以包括：基本RM配置(RM-基本)，其不使用FEC数据并且因此仅从原始源片段请求数据的部分；以及FEC RM配置(RM-FEC)，其可以从原始源片段请求数据的部分以及根据原片段生成的匹配FEC片段。

实施例的RM 121可能不知道定时和/或带宽可用性约束，由此有助于RM 121和CM122之间的相对简单的对接，并且因此RM 121可以操作用于在RM 121不考虑这样的约束的情况下作出块请求。替代地，RM 121可以适于知道定时和/或带宽可用性约束，诸如可以通过CM 122或客户端设备110内的其它模块供应给RM 121，并且因此RM 121可以操作用于基于这样的约束来作出块请求。

实施例的RM 121适于具有多个不同的CM配置的操作。此外，一些实施例的RM 121可以同时与一个以上的CM对接，诸如以从多个CM请求相同的片段或片段序列的数据块。例如，每个这样的CM可以支持不同的网络接口(例如，第一CM可以具有到设备上高速缓存的本地接口，第二CM可以使用到3G网络接口的HTTP/TCP连接，第三CM可以使用到4G/LTE网络接口的HTTP/TCP连接，第四CM可以使用到WiFi网络接口的HTTP/TCP连接等)。

在根据实施例的操作中，CM 122与RM 121对接以接收块请求，并且通过网络150发送那些请求。CM 122接收对块请求的响应并且将响应传递回至RM 121，其中，根据所接收的块来解决UA 129所请求的片段。CM 122的功能操作用于决定何时请求RM 121所作出的块请求的数据。根据本文的实施例，CM 122适于从通用或传统服务器(即，尚未被预先设计为与TA进行交互的服务器)请求和接收块。例如，CM 122从其请求数据的服务器可以包括标准HTTP网页服务器。替代地，CM 122从其接收数据的服务器可以包括在MBMS服务部署中使用的BM-SC服务器。

根据实施例，如上文关于RM 121所论述的，可以存在CM的各种配置。例如，可以提供多连接CM配置(例如，CM-mHTTP)，由此CM适于通过多个TCP连接来使用HTTP。多连接CM配置可以操作用于诸如根据网络状况、对数据的需求、拥塞窗等来动态地改变连接(例如，TCP连接)的数量。举另一个示例，可以提供扩展的传输协议CM配置(例如，CM-xTCP)，其中，CM在扩展形式的TCP连接(本文中被称为xTCP)之上使用HTTP。这种扩展的传输协议可以提供根据本文概念的适于通过TA 120来促进片段的增强的递送的操作。例如，xTCP的实施例将确认提供回给服务器，甚至当发送的分组丢失时(与当分组丢失时TCP的重复确认机制相反)。这种xTCP数据分组确认机制可以被TA 120用于避免服务器响应于确定数据分组正在丢失而减小发送数据分组的速率。再举另一个示例，可以提供私有协议CM配置(例如，CM-rUDP)，其中，CM使用私有用户数据报协议(UDP)协议，并且发送来自服务器的响应数据的速率可以是以恒定的预先配置的速率的，或者可以在协议内存在速率管理以确保发送速率尽可能的高，而不会不期望地拥塞网络。这种私有协议CM可以与支持私有协议的私有服务器合作来操作。

应当理解的是，虽然已经关于CM 122从服务器130请求来自源文件的数据论述了所示出的实施例，但是源文件可以是在服务器上可用的，或者可以本地地存储在客户端设备上，这取决于CM具有的用于访问数据的接口类型。

此外，根据实施例，客户端设备110能够连接到一个或多个其它设备(例如，置于附近的各种配置的设备)，它们在本文中被称为辅助设备(例如，通过WiFi或蓝牙接口)，其中，这种辅助设备可以具有通过3G或LTE连接(对于不同的辅助设备，潜在地通过不同的载波)到一个或多个服务器(诸如服务器130)的连接。因此，客户端110能够使用辅助设备的连接来向一个或多个服务器(诸如服务器130)发送块请求。在这种情况下，可能在TA 120内存在连接到辅助设备中的每个辅助设备并且向每个辅助设备发送块请求和接收响应的CM。在这样的实施例中，辅助设备可以将针对相同的片段的不同的块请求发送给相同或不同的服务器(例如，相同的片段可以对于多个服务器上的辅助设备是可用的，其中例如，不同的服务器是由相同或不同的内容递送网络提供商来提供的)。

在一些实施例中，还可以使冗余编码内容数据文件(例如，FEC编码数据文件)成为可用的(例如，在一个或多个内容服务器上)，所述冗余编码内容数据文件包含使用冗余编码技术根据匹配源文件而生成的修复符号。例如，针对每个源文件，可以存在一个这种文件，其中，每个冗余编码内容数据文件是使用本领域已知的冗余编码技术(诸如FEC编码技术)根据源文件而生成的。在这样的实施例中，例如，内容文件141可以包括低比特速率(低分辨率)版本的内容，内容文件142可以包括高比特速率(高分辨率)版本的内容，以及内容文件143可以包括经FEC编码版本的内容文件142。虽然对于一些流式传输使用情况，冗余编码数据传输(其中针对纠错来对全部发送的数据进行编码)的实现可能不提供显著的益处，但是根据本文概念，对于许多流式传输使用情况，使用这种冗余编码内容数据(例如，用于加快在先前传输中丢失的内容数据的传输)可能是有优势的。例如，对于实况流式传输，经常要求存在在内容被生成、成为可用、被创建与相同的内容可用于在客户端设备110上回放和观看之间的小的时间间隔。例如，时间间隔可以是1秒或更短。因此，如下文进一步详细描述的，由RM 121向CM 122作出的块请求中的一些块请求可能是针对冗余编码内容数据的。

与前述内容一致，根据实施例，可以存在各种配置的RM，诸如可以包括：基本RM配置(RM-基本)，其不使用冗余编码内容数据，并且因此仅请求来自原始源片段的数据的部分；以及冗余编码内容数据RM配置(RM-FEC)，其可以请求来自原始源片段的数据的部分以及根据源片段生成的匹配冗余编码内容数据片段。适于冗余编码内容数据的RM 121的实施例可以因此使用适当的冗余编码内容数据解码(例如，FEC解码)技术来对从CM 122接收的这样的数据进行解码，以恢复片段或其某个部分。RM121可以随后将恢复出的片段递送给UA129。

如将根据下面的论述更加全面地理解的，实施例的TA 120利用冗余编码内容数据请求来帮助恢复片段，其中，针对任何片段所请求的数据的总量以及针对任何片段何时请求冗余编码内容数据可以变化，并且取决于诸如针对片段已经接收了多少数据和哪些数据的因素。即，诸如在请求的数据单元(例如，片段、块、分组等)丢失或延迟的情况下，实施例使用冗余编码数据作为额外数据来加快对请求的片段的恢复，而不是如典型的利用冗余编码数据来纠正由数据传输导致的损坏的数据。在根据实施例的操作中，关于任何特定片段所请求的冗余编码数据的量(或是否请求任何冗余编码数据)是基于对这样的冗余编码数据的需求来控制的，以加快对片段的递送和恢复。例如，如果响应于片段请求不存在正在接收的高水平的迟到数据，则除了针对片段请求的非冗余编码数据的请求之外，还可以请求少量的冗余编码数据。

TA 120的逻辑单元可以针对任何片段来自动地确定要使用多少冗余编码内容数据(包括没有冗余编码内容数据)。例如，RM 121可以自动地将所请求的冗余编码内容数据的量调至及时地恢复每个片段所需要的冗余编码内容数据的量。在根据实施例的操作中，RM 121针对任何特定的块所请求的冗余编码数据的量可以取决于在下载片段的过程期间经历的迟到数据的总量。因为用于请求和解码冗余编码内容数据的逻辑单元是由实施例的传输加速器(例如，RM 121)实现的，所以UA 129的任何配置(即，甚至不适于使用冗余编码内容数据的那些配置)可以使用不具有任何冗余编码内容数据语义或逻辑的自动RM FEC方法(例如，UA不需要知道FEC数据是否可用以便使自动RM FEC方法操作用于当FEC数据可用时使用这样的FEC数据)。实施例的传输加速器(例如，通过其RM和CM的合作)可以操作用于诸如针对每个片段或片段序列来自动地决定是否使用、何时使用以及使用多少冗余编码内容数据。

下文提供了关于根据本文概念适于使用冗余编码内容数据来提供内容的加速传输的系统的实施例的细节。应当认识到的是，虽然为了提供对于读者来说更容易理解的具体示例，引用FEC编码数据作为示例性冗余编码内容数据，但是本文概念可关于任意数量的适当的冗余编码内容数据类型来应用。例如，可以代替在应用级别处使用的前向纠错或除在应用级别处使用的前向纠错之外使用纠错来对抗分组丢失。举另一个示例，可以使每个片段可用于以反向顺序来请求，而不是仅以通常的前向顺序，在这种情况下，除了从开始到结尾的通常的请求顺序之外，还可以从片段的结尾向开始作出块请求，并且然后以反向顺序的片段恢复一遇到以前向顺序的片段恢复(在两种请求顺序中可能具有请求的数据的一些重叠)，片段就是可恢复的。

TA 120的实施例可以操作用于关于请求的内容的任何或全部片段来利用FEC数据。根据实施例，针对片段可以请求多少超出片段大小F的额外数据可以被提供作为预定量(例如，用于全部片段或用于尚未以其它方式已指定额外数据的量所针对的那些片段的默认量)，可以被动态地确定(例如，取决于当前网络状况)等。在根据实施例的操作中，UA可以将关于要用于每个片段的FEC数据的量以及包含FEC数据的相应的FEC片段的信息提供给RM。因此，根据本公开内容的实施例，UA 129和/或TA 120(例如，RM 121)可以适于利用FEC数据。

如可以根据前述内容认识到的，在对基本RM配置的替代中，实施例的RM 121可以适于使用FEC数据来帮助恢复片段。例如，RM 121的配置可以实现本文中被称为RM固定FEC的FEC的数据技术，据此UA将要用于每个片段的FEC数据的量和包含FEC数据的相应的FEC片段提供给RM。

因此，根据实施例，可以利用UA 129和RM 121之间的信令(诸如用于提供关于与被请求的原始源片段匹配的FEC片段的信息)、紧急因子(X)的信令等。在根据适于使用FEC数据的TA 120的实施例的操作中，UA 129向RM 121提供源片段请求、匹配FEC片段请求以及紧急因子X(例如，具有指定值)，所述紧急因子X对RM多积极地请求超出恢复资源片段所需要的最小限度的数据进行控制，如下文更加详细地描述的。作为响应，实施例的RM 121仅将源片段数据而不将匹配FEC片段数据提供给UA 129。这样的实施例的UA 129向RM 121提供匹配FEC片段请求和紧急因子，使得RM可以使用该信息来帮助加速源片段请求的递送。在对前述内容的变型中，可与适于使用FEC数据的TA 120一起操作的UA 129可以向RM 121提供仅源片段请求，并且RM可以自动地推导相应的匹配FEC片段请求，并且RM可以自动地计算针对每个片段要请求多少FEC，如下文更加详细地描述的。应当认识到的是，在前述配置中的任一配置中，RM 121是客户端设备110的唯一一个需要理解FEC语义(包括提供FEC解码)的组件。

在图2中将根据实施例的RM固定FEC技术的操作示为流200。在理解实施例的RM固定FEC技术的操作时，假设UA刚刚已经作出针对片段F的请求(框201)，并且因此F初始地是活动的和合格的。所示出的实施例的UA 129还向RM 121提供用于请求与片段请求相关联的FEC数据的量的信息(框202)。这样的信息可以包括与所请求的片段的内容数据对应的FEC数据的源的标识以及用于由RM 121使用FEC数据的其它信息。

应当认识到的是，片段是什么以及如何对其进行标识通常是特定于UA的。然而，片段通常是媒体文件或二进制文件，或这样的文件的字节范围(其通过源标识信息(例如，URL、URI或URN)以及可能通过字节范围来标识)，诸如可以使用HTTP协议或类似协议来请求。因此，在根据实施例的操作中，UA 129向RM 121供应资源标识信息(例如，URL)、相关联的字节范围以及片段大小。类似地，UA 129可以供应针对对应的FEC片段的资源标识信息、相关联的字节范围、片段大小以及符号大小。例如，UA 129向RM 121提供与针对片段F的请求相关联的匹配FEC片段R和符号大小T(以字节为单位)，并且UA 129还可以向RM 121提供片段F的大小FB(以字节为单位)以及FEC片段R的大小RB(以字节为单位)。实施例的数据请求大小优选地是但不限于是T的倍数个字节，除了当FB不是T的倍数时针对F的最后的部分的请求。在一些情况下，例如，当要在已知T的值之前作出请求时，可能无法作出是T的倍数个字节的数据请求。在这些情况下，如本文描述的，典型地选择T的值以使得由未在符号边界上对齐的请求或对请求的响应而导致接收到部分符号仅是所接收的数据的一小部分。

当UA 129是DASH客户端时，可以使用如在名称为“ENHANCED BLOCK-REQUESTSTREAMING USING COOPERATIVE PARALLEL HTTP”的美国专利申请序列号12/887,495中示出和描述的技术来提供FEC文件的生成，据此通过引用的方式将上述申请的公开内容并入本文。在这样的实施例中，如何生成这些FEC文件的逻辑是特定于DASH客户端的。因此，实施例的UA 129可以向RM 121供应关于用于生成FEC文件的逻辑的信息，据此RM 121不需要单独地了解该逻辑。例如，UA 129向RM 121提供的针对匹配FEC片段的资源标识信息可以包括针对片段的URL附加后缀“.raptorq.$T$”，其中，“raptorQ”指示FEC码是在互联网工程任务组(IETF)RFC 6330中指定的RAPTORQ码，并且“$T$”的值是用于编码来自片段的匹配FEC片段的符号大小。举另一个示例，可以针对每个片段，基于片段的大小FB来自动地确定T的值。

在根据实施例的RM固定FEC技术的操作中，UA 129另外地或替代地提供前述紧急因子X，其用于确定(框206)RM 121针对片段要请求多少超过所请求的片段F的大小的额外数据(同样在框202处)。紧急因子的值可以以多种方式来确定，并且可以与片段请求同时确定、在片段请求之前确定、在作出片段请求所针对的流式传输内容会话之前确定等。例如，X的预定默认值(例如，X＝0.1)可以用于一些片段(例如，没有以其它方式为其提供X的值的片段)或用于全部片段。在根据实施例的操作中，UA 129的逻辑单元适于关于一些或全部片段请求来确定使用的紧急因子X的值。例如，可以使用如在名称为“FEC BASED RELIABILITYCONTROL PROTOCOLS”的美国专利号7,447,235中描述的算法来确定如根据本公开内容的实施例利用的紧急因子的值，据此通过引用的方式将上述申请的公开内容并入本文。

RM 121可以前述紧急因子X来请求超出所请求的片段的数据的适当量的FEC数据(框203)。例如，RM 121可以诸如响应于CM 122针对另一个请求已信令准备就绪、在RM 121认为适合作出请求的时间点等，作出一个或多个块请求，所述一个或多个块请求具有与其相关联的所请求的额外数据。同样，RM 121可以诸如响应于CM 122针对另一个请求已信令准备就绪、在RM 121认为适合作出请求的时间点等，向CM 122作出针对额外数据中的一些或全部额外数据的单独请求。

应当认识到的是，当RM 121向CM 122作出片段请求时和/或当CM 122向服务器130作出片段请求时，可以将UA 129所请求的片段再分成更小的请求(例如，前述块请求)。因此，关于特定片段所请求的额外数据的量可以是关于该片段请求的块请求的额外数据的总量(即，可以请求与针对片段的任何或全部块请求相关联的额外数据的某一部分)。同样，除了针对来自原始内容片段的数据的块请求之外或替代针对来自原始内容片段的数据的块请求，所请求的额外数据还可以包括针对FEC数据的一个或多个请求。例如，全部数据请求可以是仅针对FEC数据的，无论整体数据请求的量是片段的大小还是大于片段的大小。

例如，实现RM固定FEC技术的RM 121的实施例可以针对片段F来请求总共(1+X)·FB字节。因此，可以从FEC片段R请求额外的X·FB字节的数据(例如，在已经请求全部来自片段F的数据之后)。在RM 121不使用FEC的情况下，实施例可以设置T＝1和X＝0来使RM固定FEC技术操作无效。

在根据本文的RM固定FEC技术的实施例的操作中，可以诸如当前网络状况来动态地改变请求多少超出片段F的大小的额外数据(例如，如在框206处确定的)。例如，根据实施例，额外的数据量可以是带宽-延迟乘积的函数。例如，如果当前下载速率是DR并且当前往返时间是RTT，则请求的超出F的额外的数据量可以是X·DR·RTT，其中根据该实施例，X可以是固定分数(例如，X＝1/2或X＝0.29)。当CM 122使用TCP作为其底层传输协议时，作为前述内容的近似，可以将允许请求的额外的数据量设置为X·Recwindow，其中Recwindow是当前TCP接收窗大小，或者是平均多少八位字节(字节)或数据驻留在客户端设备处的TCP接收缓冲器中的度量，或者在使用多个TCP连接的情况下，Recwindow是全部TCP接收窗大小的总和或TCP接收缓冲器的平均总字节占用。在这样的实施例中，CM 122可以将这些参数用信号发送给RM 121(例如，CM可以向RM提供对DR和RTT的当前估计或者对Recwindow的当前估计)。

应当认识到的是，在不脱离本文概念的情况下，各种替代可以用于提供RM固定FEC技术。例如，虽然上文已经描述了其中UA操作用于关于请求的片段来确定(例如，在框206处)要使用的FEC数据的量(例如，使用前述紧急因子)的实施例，但是根据本文概念适于使用冗余编码内容数据来提供内容的加速传输的系统的其它组件可以操作用于确定要使用的FEC数据的量。举一个其中除UA之外的其它组件操作用于确定要使用的FEC数据的量的实现方式的示例，实施例的CM可以确定和用信号发送针对每个块请求的schunk，其中schunk是适于CM的目标数据块请求大小。CM可以使schunk基于TCP发送方在接收块请求之后被允许一次发送的数据量，其中，在这种情况下，schunk的值可以基于在块请求将被TCP发送方接收时对针对该TCP连接的当前TCP拥塞窗大小的估计。因此，schunk的值可以被RM用于建立可以请求的与片段请求相关联的每个数据块的大小。

应当认识到的是，针对适当的冗余编码内容数据的信息的一个或多个参数可以另外或替代地(例如，被RM 121)用于确定要请求多少超出请求的片段的数据。因此，在图2中示出的流200的实施例包括框202和206之间的可选数据路径，据此这样的信息可以被传递用于一个或多个确定，如本文描述的。

下文提供了根据本文实施例，显示用于使用FEC片段R、使用如可以由UA 129和CM122提供给RM 121的参数来实现用于片段F的鲁棒的RM固定FEC技术的细节的伪代码：

在确定了超出片段数据的数据量(框206)并且作出了片段和额外数据请求(框203)之后，如适当，根据本文的RM固定FEC技术来操作的RM121可以接收所请求的片段的内容数据以及超出所请求的片段的FEC数据(框204)。应当认识到的是，在图2中描述的操作潜在地涉及：执行与一个框相关联的部分步骤在时间上与来自其它框的其它部分步骤交织。例如，执行框206的部分子步骤可以在时间上与执行框203、204和205的部分子步骤交织。

虽然请求超出所请求的片段的数据的FEC数据可能增加通过网络传输的数据量，但是数据的各个分组可以在不同时间到达(例如，一些数据分组可能被延迟，而其它数据分组被更及时地递送)。所请求的片段数据和FEC数据的各个组合可以用于恢复片段。因此，本文实现RM固定FEC技术的RM 121的实施例可以使用最早接收的足以提供对片段的恢复的数据(无论是片段数据还是片段数据和FEC数据的组合)来恢复片段。因此RM121可以迅速地恢复片段并且将其提供给UA 129用于内容的消费(框205)。

另外或替代地，实施例的RM可以适于关于所请求的片段来自动地确定要使用多少FEC数据。因此，在RM固定FEC配置的替代中，实施例的RM 121可以适于不仅使用FEC数据来帮助恢复片段，而且关于片段来自动地确定要使用多少FEC，由此提供了实现在本文中被称为RM自动FEC的FEC数据技术的RM 121的配置。在一些情形中，出于多种原因，RM自动FEC技术的实现可能是比RM固定FEC技术更期望的。特别地，实施例的RM自动FEC技术将请求的FEC数据的量自动地调至恢复每个片段所需要的FEC数据的量。因此，使针对片段所下载的数据量最小化，这平均来说通常要求比RM固定FEC(当要使用的FEC的量由UA来确定时)更少的整体下载数据。可以使用RM自动FEC来使对所请求的片段的及时递送最大化，同时通常提供与RM固定FEC一样好或更好的及时递送。此外，因为要请求的FEC数据的量是由RM自动地确定的，所以UA不需要指定要使用的FEC的量或并入任何FEC逻辑单元。这简化和降低了对UA的要求，并且通常使RM自动FEC方法可更广地应用于不同的UA配置(例如，包括不包含无论是用于请求还是解码FEC数据的任何FEC逻辑单元的UA配置)。

在图3中将根据实施例的RM自动FEC技术的操作示为流300。为了帮助理解本文实施例的RM自动FEC技术的概念，将RM自动FEC技术描述为对上文提供的RM固定FEC技术的论述的扩展。因此，如上文关于RM固定FEC技术所描述的，对于本文中描述的RM自动FEC技术，假设UA 129刚刚已经作出针对片段F的请求(框301)，并且因此F初始地是活动的和合格的。

在根据所示出的实施例的操作中，RM 121获得针对使用与与片段请求相关联的适当量的冗余编码内容数据的信息(框302)。这样的信息可以包括与所请求的片段的内容数据对应的FEC数据的源的标识以及针对由RM121使用FEC数据的其它信息。例如，当将针对片段F的请求提供给RM 121时，关于匹配FEC片段R和符号大小T的信息可以是可用的或者可以其它方式确定的。虽然UA 129可以向RM 121提供(例如，在框301处)关于使用FEC数据是有用的一些信息，但是实施例的RM 21可以操作用于确定或以其它方式获得用于利用FEC数据的信息。例如，UA 129可以提供FB(其是片段F的以字节为单位的大小)，而RM可以根据FB自动地推导出对应的FEC片段R的以字节为单位的大小RB(例如，使用如在名称为“ENHANCEDBLOCK-REQUEST STREAMING USING COOPERATIVE PARALLEL HTTP”的美国专利申请序列号12/887,495中示出和描述的技术，据此通过引用的方式将上述申请的公开内容并入本文。)

替代地，可以响应于针对F或R的至少一部分的请求来获得FB的值。可以根据F的大小FB来自动地确定用于对F进行FEC编码和FEC解码的符号的大小T。例如，在FEC编码器和DEC解码器两者处将T推导作为T＝{4，floor(FB/2048)}中的最大者确保相同的符号大小被用于编码和解码，以及如果FB至少是8千字节，则将F划分成的源符号的数量至少是2048。这可以确保在对接收数据的每个响应中存在接收到的数据的最多0.1％的浪费，所述浪费是由接收对于FEC解码可能是没用的部分符号导致的。例如，对针对一个字节范围的F的块请求的响应可以在响应中包括最多两个部分符号(一个在响应的开始处，一个在结尾处，其中，全部中间响应数据包括完整符号)，其中如果未在其它响应中接收到这些部分符号的剩余部分，则所述两个部分符号对于FEC解码可能是没用的，并且如果FB至少是8千字节，则每响应2个浪费的部分符号最多包括片段F的2/2048＝0.1％。

根据实施例，RM 121可以在不需要来自UA 129的任何输入的情况下自动地生成FEC片段R的URL或适于识别和访问FEC数据的其它信息。如在上文论述的实施例中，可以使数据请求大小为T的倍数个字节，除了针对F的最后的部分的请求(当FB不是T的倍数时，或者直到符号大小T已知为止，例如，一旦响应于针对片段F所发送的数据请求而确定了FB，就可以基于FB来确定T)。在RM 121不使用FEC的情况下，实施例可以设置T＝1，直到T的值已知为止。作为替代，可以使全部请求都不基于T字节对齐，即，实际上T＝1用于全部数据请求，并且然后出于FEC解码的目的(如果FEC解码用于恢复片段)，RM 121将在响应中接收的数据内部地划分为符号。

在根据本文的RM自动FEC技术的操作中，RM 121操作用于动态地和自动地确定要请求多少超出请求的片段的数据(框303)。在片段请求或接近片段请求的时间作出这样的确定，以由此动态地提供关于额外数据的确定，所述确定关于与片段请求是相对同时的网络状况和/或其它情况是及时的。然而，实施例可以另外或替代地操作用于在其它时间(如被确定为是期望的时间)作出这样的确定。应当认识到的是，针对适当的冗余编码内容数据的信息的一个或多个参数可以被RM 121用于动态地确定要请求多少超出请求的片段的数据。

本文的RM自动FEC技术的实施例实现用于确定要请求多少超出请求的片段的数据的一个或多个过程，其与上文论述的RM固定FEC技术(例如，使用根据网络状况改变的预定默认值(因子X))实现的那些过程相同或类似。根据实施例的RM自动FEC技术，针对片段将何时请求这样的额外数据的条件可能不同于RM固定FEC技术。特别地，RM固定FEC技术的实施例操作用于均匀地请求超出所请求的片段的数据(例如，请求针对每个片段的这样的额外数据)，而RM自动FEC技术的实施例操作用于动态地确定将何时请求并且请求多少超出所请求的片段的数据(例如，基于网络状况来请求这样的额外数据)。

实施例的RM 121可以请求片段数据(例如，作为一个或多个块请求)，并且当被确定是适当时，RM 121可以从CM 122请求超出片段数据的额外数据(框303)。在根据实施例的RM自动FEC技术的操作中，关于将何时请求并且请求多少除所请求的片段之外的数据的确定至少部分地基于网络状况(例如，通过网络所请求的迟到数据的量和/或数据的迟到的度量)。

根据针对实施例的RM 121的示例性过程来动态地和自动地确定关于任何特定的片段何时请求额外数据是适当的，并且请求多少这样的数据。从RM 121向CM 122的数据请求的排序被定义用于识别延迟的或迟到的数据分组。例如，从RM向CM的数据请求的排序可以被定义作为RM从CM请求数据的顺序，据此较早请求的数据块在排序上要早于针对数据块的随后请求。在这样的实施例中，数据在块请求中的排序可以被定义为自然排序(即，块请求的第一字节在排序上早于块请求的随后字节)。

使用前述的数据排序，实施例的RM 121可以操作用于：如果RM已经请求了数据的第一部分，但是当RM在请求了数据的第一部分之后请求的数据的第二部分被接收时，仍然尚未接收到数据的第一部分，则认为数据的第一部分迟到(并且可能丢失)。例如，对于RM已经请求但是尚未被接收的数据的一部分：如果在数据的部分之后请求的数据尚未被RM接收，则将数据的该部分定义为“挂起”；并且如果存在在数据的部分之后请求的、已经被RM接收的数据，则将数据的该部分定义为被确认为“迟到”。

除了上文关于RM固定FEC技术定义的变量之外，本文中可以定义变量PK(其是针对片段挂起的数据量)和LK(其是针对片段迟到的数据量)，以关于实施例的RM自动FEC技术来使用。根据前述内容可以认识到的是，可以将UK(其是针对片段所请求的但是未被确认的数据的总量)表达为UK＝PK+LK。还可以定义变量RK(其是针对片段所接收的数据量(如果针对片段两次接收精确相同的数据，则其在RK中仅被记为一次))，以关于实施例的RM自动FEC技术来使用。对于本文提供的示例，将全部前述量假设为是以符号为单位来测量的，尽管根据实施例可以利用其它单位(例如，以字节或八位字节来测量数据量)。

另外，实施例的RM 121可以跟踪在任何时间点看见的针对片段的迟到数据的最大量(例如，变量maxLK可以被初始化为零，并且然后可以每次针对片段的LK的值改变时，重新计算maxLK＝{LK，maxLK}中的最大者)。例如，根据实施例，这样的片段最大迟到数据变量可以用于使迟到变量LK的潜在的高度可变的本质缓和。作为替代，maxLK可以被定义为在片段的S的某个先前窗内的任何时间点的迟到数据的最大量，其中S是可配置参数，例如，S＝10。作为另一个变型，在其内计算最大值的窗可以在先前时间的可配置的持续时间内，或者在先前时间的取决于其它测量(诸如RTT)的持续时间内，或者在先前块请求的可配置的数量内。作为另一个替代，可以独立于底层片段结构来维护LK的值，例如，基于RM独立于从其中生成每个块请求的片段来作出的块请求的排序。

在根据实施例的操作中，每次RM 121接收针对片段的数据时，RK的值增加接收到的数据的量(只要其不是先前针对相同的片段所接收到的精确相同的数据)，UK的值减少该量，PK的值减少先前是挂起的该数据的量，并且LK的值减少先前是迟到的该数据的量。同样，当RM 121接收数据时，如果存在先前请求的仍然挂起的数据，则将该先前请求的数据从挂起重新归类为迟到，并且将该先前请求的数据的大小从PK中减去并且加到LK中。

图4示出了描绘已接收数据、挂起数据和迟到数据以及前述变量的对应值的时间线。在图4的时间线中，RM 121向CM 122作出针对片段的数据块的请求，首先作出针对数据块1(C1)的请求，然后作出针对数据块2(C2)的请求，并且然后作出针对数据块3(C3)的请求。在所示出的示例中，数据块中的每个数据块的大小为8KB，并且每个数据块是在均为4KB的两个分离部分中接收的(符号Ci.j用于指示数据块i的第j部分)。应当认识到的是，下文图4的时间线示出的信息描绘了RK、PK、LK和maxLK的值何时因RM对针对数据块的新请求或RM对针对先前请求的块的数据的接收而改变。

如在图4中表示的场景所示，当RM 121请求数据块1(C1)时，RK＝0(因为数据尚未被接收)，PK＝8KB(因为大小为8KB的数据块1现在挂起)，LK＝0(因为数据尚未迟到)，并且maxLK＝0。在时间线上数据块1的第一部分(C1.1)恰好被RM 121接收之后的点处，RK＝4KB(因为C1.1已经被接收)，PK＝4KB(因为C1.2现在挂起)，LK＝0(因为数据尚未迟到)，并且maxLK＝0。当RM 121请求数据块2(C2)时，RK＝4KB(因为C1.1已经被接收)，PK＝12KB(因为C1.2、C2.1和C2.2现在挂起)，LK＝0(因为数据尚未迟到)，并且maxLK＝0。在时间线上数据块2的第一部分(C2.1)恰好被RM 121接收之后的点处，RK＝8KB(因为C1.1和C2.1已经被接收)，PK＝4KB(因为C2.2仍然挂起)，LK＝4KB(因为C2.2的到达触发C1.2迟到)，并且maxLK＝4KB。当RM 121请求数据块3(C3)时，RK＝8KB(因为C1.1和C2.1已经被接收)，PK＝12KB(因为C2.2仍然挂起，并且现在C3.1和C3.2也挂起)，LK＝4KB(因为C1.2仍然迟到)，并且maxLK＝4KB。在时间线上数据块3的第一部分(C3.1)恰好被RM 121接收之后的点处，RK＝12KB(因为C1.1、C2.1和C3.1已经被接收)，PK＝4KB(因为C3.2挂起)，LK＝8KB(因为现在C1.1和C2.2都迟到)，并且maxLK＝8KB。在时间线上数据块1的第二部分(C1.2)恰好被RM 121接收之后的点处，RK＝16KB(因为C1.1、C1.2、C2.1和C3.1已经被接收)，PK＝4KB(因为C3.2挂起)，LK＝4KB(因为现在仅C2.2迟到)，并且maxLK＝8KB。在时间线上数据块2的第二部分(C2.2)恰好被RM 121接收之后的点处，RK＝20KB(因为C1.1、C1.2、C2.1、C2.2和C3.1已经被接收)，PK＝4KB(因为C3.2仍然挂起)，LK＝0KB(因为C2.2现在已经到达并且不存在其它迟到数据)，并且maxLK＝8KB。在时间线上数据块3的第二部分(C3.2)恰好被RM 121接收之后的点处，RK＝24KB(因为C1.1、C1.2、C2.1、C3.1和C3.2已经被接收)，PK＝0KB(因为不存在挂起数据)，LK＝0KB(因为不存在迟到数据)，并且maxLK＝0KB。

应当认识到的是，虽然在上文示例中，全部数据块都是针对单个片段的，但是所表示的概念适于多个片段。例如，当存在多个片段时，可以每片段来维护RK、UK、PK、LK和maxLK的值，或者可以替代地独立于从其中生成块请求的片段、基于块请求来维护这些值(例如，在先前块的可配置的数量的窗、或者先前字节的可配置的数量的窗、或者先前时间的可配置的持续时间的窗内进行计算)。然而，如果RM请求针对第一片段的第一数据块并且然后RM请求针对第二片段的第二数据块，则第二数据块的部分的到达可以使第一数据块的尚未到达的部分被RM归类为迟到。

使用前述参数，可以作出关于何时请求数据(例如，所请求的片段的数据以及超出所请求的片段的数据)的确定以及请求多少数据。应当认识到的是，可以结合针对片段数据的请求(例如，作为块请求的一部分或与块请求相关联，无论是针对块数据的初始块请求还是重复请求)或者作为针对数据的单独请求(例如，作为针对额外数据的独立请求或作为响应于迟到或丢失数据的独立请求)来请求额外数据。然而，每当RM 121作出针对数据块的请求时，可能存在指定的最小大小数据块(例如，4KB、8KB等)，这可能例如取决于片段的大小或schunk的值(schunk是适于CM 122的目标数据块请求大小)。

在根据基本RM自动FEC实现方式的操作中，只要满足RK+PK<K+XK的条件(即，只要针对片段接收到的和挂起的数据量不超过片段的大小加上XK，就可以作出另一个数据块请求)，RM 121就可以(例如，在图3的框303中)根据前述网络状况参数来请求更多针对特定片段的数据。例如，RM 121可以独立于网络状况来设置XK的值以及CM 122向RM 121递送数据的整体模式。对于实施例的RM自动FEC技术，RM可以将XK的值自动地设置为小值(例如，XK可以被设置为{4KB，0.004·K}中的最小者，XK可以被设置为schunk，XK可以被设置为0等)。

在根据更鲁棒的RM自动FEC实现方式的操作中，将LK加到前述不等式的每一边上(回想UK＝PK+LK)，条件可以被写为RK+UK<K+XK+LK(即，只要针对片段接收到的和请求的数据量不超过片段的大小K，加上片段的大小的字节的加常数数量XK，加上针对片段的迟到数据的量LK，就可以作出另一个数据块请求)，据此LK的值提供因所请求的迟到了的数据的量而允许请求(例如，在框303中)多少额外数据。在前述内容的变型中，RM自动FEC实现方式的实施例可以提供在其中允许RM 121请求针对片段的额外数据的操作，只要满足RK+UK<K+XK+α·LK的条件，其中α是适当选择的常数(例如，α＝0.5，α＝1或α＝3)。使用在任何时间点看到的针对片段的迟到数据的最大量，在前述条件中，maxLK可以用于使迟到变量LK的潜在地高度可变的本质缓和。在这样的实施例中，只要满足RK+UK<K+XK+α·maxLK的条件，就可以允许RM 121请求针对片段的额外数据，其中α是适当选择的常数(例如，α＝0.5，α＝1或α＝1.5)。替代地，只要满足RK+UK<K+XK+α·FB·maxLK/W的条件，就可以允许RM 121请求针对片段的额外数据，其中FB是片段的大小以及W是在其内测量maxLK的字节窗。

关于前述内容，应当认识到的是，被归类为迟到的数据(并且因此在LK中计入数据的大小)本质上是被暂时地算作丢失数据的数据。当挂起数据变为迟到时，将该数据的大小从PK中减去并且加到LK中，根据上文阐述的特定条件，这可以潜在地允许针对该片段来请求更多的数据。然而，一接收到任何请求的迟到了的数据，就将其大小加到RK中并且从LK中减去，并且因此在短时间段内被归类为迟到的任何数据将仅在该短时间段内从RK+PK中丢失(仅在该短时间段内贡献LK)。根据使用LK的前述条件，接收的仅稍微迟到的数据将仅在短时间段内贡献LK(例如，如果首先在某个时间t将数据确定为迟到，并且然后数据在时间t+X到达，则该数据尽在t和t+X的之间的时间段期间贡献LK)。例如，如果X＝RTT，其中RTT是当前往返时间，则数据将仅在RTT内贡献LK。因此，如果DR是接收数据的当前速率，并且数据仅在至多一个RTT是无序的接收的，则LK在任何时间点至多是DR·RTT。因此，根据实施例，LK的值量化在任何时间因迟到数据而允许请求多少额外数据。特别地，在前述实现使用LK的条件的实施例中，LK的值是使用RM自动FEC技术对比RM固定FEC技术而允许请求多少额外数据之间的差，这是由针对请求的迟到了的数据的量的自动调整导致的。

如果请求的数据仅在短时间段内是迟到的，则即使大多数数据在至少某个时间段内被归类为迟到，直到其被接收为止(如果其曾经被接收)，并且因此稍微无序地被接收。根据实施例，因迟到数据而请求的额外的数据量通常是小的(即，LK的值将通常是小的)。然而，随着请求的数据仍然是迟到的时间量的增加，在每个时间点将存在更多未解决的请求了但是迟到的数据，并且因此LK的值通常将增加(即，当存在接收的数据的顺序的更显著的差别时，则LK的值通常更大)，并且因此，因迟到数据而允许请求的数据的量将增加。在根据实施例的操作中，迟到数据的到达越延迟，迟到数据对允许请求的额外请求的数据的影响就越大。根据实施例，如果请求的数据永久丢失，则该数据的大小将从其被归类为迟到时起保持为对LK的贡献(或将在时间窗、或字节窗、或块窗、或片段窗内保持，LK是在上述窗内计算的)，并且此后将允许针对该丢失数据来请求额外数据。

与RM固定FEC技术相比，通常针对RM自动FEC技术将XK的值设置为小得多的值，这是因为其用于不同的目的。针对实施例的RM固定FEC技术，XK的值确定可以请求的超出已经被接收(RK)或已经请求但是尚未被接收(UK)的额外数据的量。因此，针对这种RM固定FEC技术，通常根据如下考虑来设置XK的值：诸如期望接收多少无序数据，数据中的一些数据将与其它数据相比多慢地到达，丢失多少数据等。因此，典型地使用针对RM固定FEC技术的一些额外信息(如上文的伪代码所示)来设置XK的值。然而，针对实施例的RM自动FEC技术，LK的值(PK的值比UK的值小LK的值)提供了对无序数据、一些数据比其它数据更慢地到达、以及丢失数据的解释。因此，针对实施例的RM自动FEC技术的XK的角色是确保请求超出真正需要用于恢复片段的一些数据，以便确保如果最后请求的针对片段的数据中的一些数据缓慢到达，则将这些数据归类为迟到。即，通过请求数据的最后XK字节，当其到达时，则任何先前请求的缓慢到达或丢失的数据将被归类为迟到，因此潜在地触发针对该缓慢到达或丢失数据的额外请求。出于该原因，可以针对实施例的RM自动FEC技术来自动地将XK的值设置为小的固定值。

在其中RM请求片段序列的情形中，实施例的RM 121可以计算对多个片段的统计，其可以被RM用于确定针对每个片段要请求多少数据。例如，令avgmaxLK为在多个连续片段的窗内每片段平均最大迟到数据。在根据实施例的操作中，只要满足RK+UK<K+XK+α·avgmaxLK的条件，就可以允许RM 121请求针对片段的额外数据，其中α是适当选择的常数(例如，α＝0.5，α＝1或α＝1.5)。根据实施例，可以使用maxLK的加权移动平均来更新avgmaxLK的值，其中maxLK是针对当前片段的值(例如，将avgmaxLK更新为avgmaxLK＝β·avgmaxLK+(1–β)·maxLK，其中β是适当选择的常数(例如，β<1))。替代地，更新实施例的avgmaxLK的值可以实现逻辑，其中，如果maxLK>avgmaxLK，则avgmaxLK＝β1·avgmaxLK+(1–β1)·maxLK,而如果maxLK≤avgmaxLK，则avgmaxLK＝β2·avgmaxLK+(1–β2)·maxLK,其中0<β2<β1<1。可以根据本文实施例实现的平均逻辑的其它示例是将在过去的连续片段的移动窗内的maxLK的值的第95百分位(或任何其它适当的百分位)用于当前片段。

举RM 121确定何时请求和请求的数据的量的操作的另一个示例，针对迟到数据，RM可以跟踪该数据的迟到，据此RM可以将决策基于：是否可以至少部分地基于数据的迟到来针对片段请求更多的数据。例如，数据的迟到可以被计算为在数据被归类为迟到的时间点之后接收的数据的字节数量。举另一个示例，数据的迟到可以被计算为在数据已经被接收之后请求的该数据的字节数量。可以基于迟到数据的每个部分的迟到来计算其权重因子。例如，如果迟到数据的一个部分的迟到是LB字节，则数据的该迟到部分的权重可以被计算为1+LB/K。举另一个示例，数据的该迟到部分的权重可以被计算为e^LB/K。再举一个示例，数据的该迟到部分的权重可以被计算为2-e^-LB/UK。无论用于计算权重的特定技术如何，总权重wtL可以被计算为全部迟到数据的权重的总和。在根据实施例的操作中，只要满足RK+UK<K+XK+wtL的条件，就可以允许RM 121请求针对片段的额外数据。根据替代的实施例，可以用目前遍及片段的wtL的最大值替代前述条件中的wtL。

无论用于确定何时请求和请求的数据的量的特定逻辑如何，在根据图3中示出的流300的实施例的RM自动FEC技术的操作中，RM 121响应于片段和额外数据请求来接收所请求的片段的内容数据以及超出所请求的片段的FEC数据(框304)。与上文的RM固定FEC技术一样，本文实现RM自动FEC技术的RM 121的实施例可以使用最早接收的足以提供对片段的恢复的数据(无论是片段数据还是片段数据和FEC数据的组合)来恢复片段。此外，通过基于网络状况(例如，迟到数据的量和请求的数据的迟到)来动态地调整关于任何特定片段是否请求和请求多少FEC数据，可以使通过网络传输的数据量的增加最少化或优化。RM 121因此可以在具有对网络拥塞的最小影响的情况下迅速地恢复片段，并且将其提供给UA 129以用于内容的消费(框305)。

在RM自动FEC配置的变型中，实施例的RM 121可以适于不仅自动地确定关于片段要使用多少FEC，而且操作用于自动地确定FEC片段的URL，因此提供了实现在本文中被称为RM自动FEC+URL的FEC数据技术的RM 121的配置。在根据RM自动FEC+URL技术的实施例的操作中，RM 121自动地根据UA提供的源片段的URL来确定FEC片段的URL。实施例的RM自动FEC+URL技术还包括：RM 121确定用于FEC编码和解码的符号的大小(例如，RM基于片段的大小来自动地确定要使用的符号大小，RM读取FEC片段的第一部分，其中，符号大小在FEC片段的前导码中是可获得的等)。应当认识到的是，任何UA配置都可以使用RM自动FEC+URL技术，包括没有被UA使用的任何FEC语义或逻辑的UA(例如，只要FEC片段可用于UA所请求的源片段)。在图5中示出了如可以在被配置用于RM自动FEC+URL操作的UA 129和RM 121之间实现的基本API。

RM自动FEC+URL配置的变型提供了其中实施例的RM 121还适于自动地确定是否使用冗余编码数据的配置，由此提供了实现在本文中被称为RM全自动的FEC数据技术的RM121的配置。在根据RM全自动技术的实施例的操作中，本文实施例的RM 121操作用于自动地确定是否使用FEC数据。在操作中，RM 121和CM 122可以合作来自动地确定(例如，针对每个片段或片段序列)FEC片段是否是可用的。例如，CM 122可以发送针对FEC片段的一个或多个请求，据此RM 121根据响应来确定其可用性(例如，对针对FEC片段的一部分的HTTP请求的为“未发现404”的响应可以用于指示FEC片段不可用)。如果FEC片段不可用，则RM 121和CM122可以根据不使用FEC数据的技术来继续进行操作。然而，如果确定FEC片段可用，则根据本文概念，RM 121和CM 122可以来利用与片段请求相关联的FEC数据技术(例如，实现RM自动FEC+URL技术)。因此，当FEC数据可用于所请求的片段时，FEC数据可以自动地被RM 121和CM 122使用，并且当FEC数据不可用时，RM 121和CM 122可以在不使用FEC数据的情况下仍然进行操作。因此，UA 129的任何配置可以在没有被UA使用的任何FEC语义或逻辑的情况下使用RM全自动方法，无论FEC片段是否可用。

如本文描述的RM自动FEC技术的实现方式的一种潜在的使用情况是结合被配置用于多连接操作(例如，CM-mHTTP配置)的CM 122来实现被配置用于RM自动FEC操作的RM 121，以用于使用DASH或HLS来进行低延迟实况流式传输。

在这样的实况流式传输情形中，应当使在活动被视频相机捕获时与对应的活动被显示在最终用户设备上时之间的端到端延迟最小化。实况流被编码成视频片段的序列，其中例如每个片段包含一秒的视频流。随着产生每个视频片段，其可用于HTTP网页服务器，DASH客户端或HLS客户端可以使用标准HTTP/TCP来从所述HTTP网页服务器访问片段。在更具有挑战性的网络状况中，使DASH或HLS客户端使用多个HTTP/TCP连接，以能够提供比使用单个HTTP/TCP连接来下载视频片段而可能获得的更优质量的视频流是有好处的。

重要性的一个度量是接收方侧延迟，其被定义为可在HTTP网页服务器上获得视频片段直到视频片段准备好在最终设备上回放之间的时间。典型地，接收方侧延迟是端到端延迟的主要贡献者。因此，使接收方侧延迟最小化对于使端到端延迟最小化可以是关键的。在本文实施例的实现方式中，DASH客户端或HLS客户端是UA 129，并且UA使用TA 120(包括RM 121和CM 122)来提供片段进行回放，据此可以使用多个连接来动态地请求FEC数据，以便一接收到用于恢复片段的足够的数据(无论是单独的片段数据还是片段数据和额外数据的组合)，就促进对片段的恢复。

从前述内容中可以认识到的是，除了源内容数据(即，非冗余编码数据)之外，传输加速器的实施例还利用冗余编码数据(诸如FEC数据)来帮助加速对源片段请求的递送。可以使用用于生成冗余编码数据文件的多种已知技术中的任何一种来生成这样的冗余编码数据。例如，根据本文的实施例，可以利用公知的FEC数据文件生成技术。例如，在UA包括DASH客户端的情况下，可以使用如在名称为“ENHANCED BLOCK-REQUEST STREAMING USINGCOOPERATIVE PARALLEL HTTP”的美国专利申请序列号12/887,495中示出和描述的技术来生成适当的FEC数据文件，据此通过引用的方式将上述申请的公开内容并入本文。

应当认识到的是，虽然在本文中已经描述了其中源片段文件和对应的冗余编码数据文件由相同的服务器或服务器群(例如，服务器130)源发的实施例，但是本文概念不受限于这样的实施例。例如，本文实施例的TA 120可以适于关于冗余编码数据的独立的源或提供者来操作，以提供根据本文概念的数据的加速传输。例如，内容提供者可能不具有用于提供针对其内容的FEC数据的期望或资源。在这种情形中，RM 121的实施例可以适于与独立的第三方FEC提供者来操作。在图6中示出的系统600的配置描述了该概念，其中，FEC服务器630提供与服务器130所提供的内容相对应的冗余编码数据。

在本文中，利用冗余编码数据的独立的源或提供者的配置(诸如系统600)可以以多种方式来操作以传输内容。例如，实施例的RM 121操作用于向内容提供者(服务器130)发出源请求并且向FEC提供者(FEC服务器630)发出FEC请求。在这样的实施例中，FEC提供者可以因此从内容提供者独立地取来内容，对其进行FEC编码，以及将经FEC编码的符号发送回RM 121。因此，RM 121可以操作用于立即开始取来针对其请求的任何资源的FEC数据，而不是首先取来全部资源数据，因此避免了由以下操作造成的延迟：FEC提供者首先需要取回源片段本身，并且然后需要在将经编码的符号发送给源之前对数据进行编码。

在利用冗余编码数据的独立的源或提供者的配置的另一个示例中，RM121操作用于经由FEC提供者(例如，FEC服务器630)取来源数据和额外数据两者。在这样的实施例中，FEC提供者可以因此像代理一样操作，从源提供者(例如，服务器130)取来源数据本身，并且在运行时计算FEC数据。该实施例的优点在于：内容提供者不需要应付由使用FEC数据导致的增加的业务(例如，在上文示例中，其中，RM 121在从内容提供者请求源数据并且从FEC提供者请求额外数据，内容提供者将每个数据段发送给FEC服务器630(用于FEC编码)和UA129两者)。

在根据实施例的操作中，FEC提供者(例如，FEC服务器630)可以提供简单通用的冗余编码。例如，正被编码的数据单元(例如，片段)可以仅由内容来固定和确定。同样，FEC符号大小可以由内容来固定和确定。这样的实施例可以用于减少FEC提供者针对不同的客户端对相同的数据重复地进行FEC编码的需求(例如，FEC提供者可以高速缓存受欢迎的内容，因此以网络业务和计算成本换取存储器存储)。

根据本文实施例，FEC提供者对于UA可以是通用的，据此UA可以指定其请求的内容的资源(例如，使用URI)、字节范围、符号大小等，并且FEC提供者可以随后在运行时产生所请求的FEC编码(例如，可以将前述信息在URL查询串中传递给FEC内容提供者)。在根据这样的实施例的操作中，FEC提供者可以精确地提供所请求的FEC数据(或者在这样做是不实际的情况下返回错误代码)。这样的实施例的优点在于：使UA能够挑选最适于其使用情况的参数(例如，与不关心短的端到端延迟的UA相比，提供非常短的端到端延迟的UA可以挑选更短的FEC保护时段)。

根据实施例，本文描述的技术可以适于如下情况：当不存在FEC提供者，并且因此可以不使用FEC数据时。例如，UA可以使用与所描述的相同或类似的算法来识别哪些请求“迟到”，诸如以使用该信息来重新发出针对检测到的迟到部分的重复块请求，而不是请求FEC数据。因此，在根据实施例的操作中，如果TCP连接非常缓慢地接收数据，或者完全停止接收新的数据，则重复请求可以有助于获取丢失部分。

这样的重复请求可以指代以与常规相反的顺序存储的段，使得默认将从两端填充间隙。替代地，UA可以指代常规的段，但是使用多个字节范围来实现对响应的顺序的近似反转(例如，如果从6KB到10KB的洞将需要被填充，则客户端可以使用9KB到10KB、8KB到9KB、7KB到8KB、6KB到7KB的HTTP字节范围，并且因此其将以相反的顺序来接收块)。针对这样的方法的好的块大小将近似是TCP MSS。

根据实施例，客户端可以以类似精神来应用的额外技术是不请求完全分离的块，但是以前摄的方式请求具有重叠的数据部分的块。例如，如果要在2个块中请求流中的200KB的部分，则UA可以在第一块中请求0到100KB，并且在第二块中请求例如94KB到200KB，这产生了6KB的重叠，而不是在第一块中请求从0到100KB，并且在第二块中请求从100KB到200KB。该策略考虑了如下事实：在响应中，块的最后部分比早先部分更易于遭遇大量的延迟。如果任何早先的TCP段丢失，则发送方所接收的重复确认通常将相当快速地触发重传。这对于接近传输的结尾的TCP段并不如此(例如，在那些情况下，发送方可能未接收足够的重复ACK来触发重传，并且因此其将仅在发生超时时(这通常是长的多的时间)才重传数据)。除此之外，块的中间的任何延迟同样易于造成对块的结尾的接收的延迟。

UA的逻辑单元可以实现减少需要的重叠量的策略。例如，UA可以在接近块响应的结尾时禁用“延迟ACK”，因此对于最后几个TCP段，增大了服务器看见重复ACK的可能性。

智能服务器可以用于进一步减少需要的重叠量。例如，实施例的服务器可以针对传输的最后部分，发送比其通常使用的TCP段小得多的TCP段。

虽然已经详细示出和描述了选择的方面，但是将理解的是，可以在其中作出各种替代和改变，而不脱离如通过下文权利要求书来限定的本发明的精神和范围。

Claims (56)

1.一种用于由客户端设备的传输加速器(TA)来加速将内容递送至所述客户端设备的用户代理(UA)的方法，所述方法包括：

由所述TA的请求管理器(RM)来接收所述UA所提供的片段请求，以用于从内容服务器请求内容；以及

确定针对所述片段请求中的一个片段请求要请求的冗余编码内容数据的量，以由所述RM在恢复所述片段时使用。

2.根据权利要求1所述的方法，其中，所述冗余编码内容数据包括前向纠错(FEC)编码数据。

3.根据权利要求2所述的方法，其中，所述RM对所述RM所接收的数据使用FEC解码，以便恢复所述UA所请求的所述片段并且向所述UA提供所恢复的片段。

4.根据权利要求1所述的方法，其中，超文本传输协议/传输控制协议(HTTP/TCP)用于请求所述内容和所述冗余编码内容数据，并且用于响应于所述请求从所述内容服务器传输内容。

5.根据权利要求4所述的方法，其中，与冗余编码内容片段相关联的资源标识信息用于确定针对所述冗余编码内容片段的一部分的HTTP请求，所述冗余编码内容片段的一部分用于提供所述冗余编码内容数据的至少一部分。

6.根据权利要求1所述的方法，还包括：

由所述RM基于所述片段请求中的所述一个片段请求来确定多个块请求，其中，所述多个块请求中的至少一个块请求包括：针对所述片段请求所请求的所述片段的一部分的请求，并且其中，所述多个块请求中的至少另一个块请求包括：针对与所述片段请求所请求的所述片段相关联的冗余编码内容片段的一部分的请求。

7.根据权利要求6所述的方法，还包括：

由所述RM经由多个连接来并行地从所述内容服务器请求所述多个块请求中的两个或更多块请求，所述多个连接由所述TA的连接管理器(CM)来管理。

8.根据权利要求7所述的方法，其中，经由所述多个连接中的第一连接来向内容服务器作出针对所述UA所请求的所述片段的一部分的所述请求，并且经由所述多个连接中的第二连接来向冗余编码内容数据服务器作出针对所述冗余编码内容片段的一部分的所述请求，其中，所述内容服务器和所述冗余编码内容数据服务器是分离的和独立的服务器。

9.根据权利要求6所述的方法，其中，针对片段要请求的所述冗余编码内容数据的量是基于在针对所述片段的块的接收期间、针对所述片段并发地迟到数据的最大量的，其中，如果块内的第一数据已经被所述RM请求但是尚未被接收，并且至少一些第二数据在所述第一数据之后被请求并且已经被接收，则将所述第一数据归类为在特定时间点处迟到。

10.根据权利要求9所述的方法，其中，只要已接收的针对所述片段的数据的总量加上已请求但是尚未接收的针对所述片段的数据的量在所述片段的大小的字节的加常数数量加上直到某一时间点针对所述片段并发地迟到数据的所述最大量以内，所述RM就适于作出针对所述片段的额外的块请求。

11.根据权利要求1所述的方法，其中，所述确定针对片段要请求的冗余编码内容数据的量包括：

基于未足够快地接收针对所述片段先前请求的数据，来确定针对所述片段要请求的额外的冗余编码内容数据，其中，尽管当先前请求的数据到达时，所述先前请求的数据的量足以供所述RM完全恢复所述片段，并且尽管所述先前请求的数据中的全部将被所述RM接收，还确定要请求所述额外的冗余编码内容数据。

12.根据权利要求1所述的方法，其中，所述确定针对片段请求要请求的冗余编码内容数据的量是至少部分地基于当前网络状况的。

13.根据权利要求12所述的方法，其中，所述当前网络状况包括：根据当前下载速率(R)和当前往返时间(RTT)确定的带宽-延迟乘积。

14.根据权利要求1所述的方法，其中，所述确定针对片段请求要请求的冗余编码内容数据的量包括：

确定针对所述片段请求要请求的数据的总量，所述数据的总量包括经纠错编码的数据的量和未经纠错编码的内容数据的量。

15.根据权利要求1所述的方法，还包括：

由所述RM确定针对所述片段请求要何时请求所述冗余编码内容数据的量。

16.根据权利要求15所述的方法，其中，所述确定要何时请求所述冗余编码内容数据的量包括：

所述RM将先前请求的数据视为迟到。

17.根据权利要求1所述的方法，还包括：

由所述RM动态地调整要请求的与多个片段请求中的每个片段请求相关联的冗余编码内容数据的量。

18.根据权利要求1所述的方法，还包括：

由所述RM确定是否要请求与所述UA所提供的所述片段请求中的任何特定片段请求相关联的冗余编码内容数据。

19.根据权利要求18所述的方法，其中，所述确定是否要请求冗余编码内容数据包括：

由所述TA确定冗余编码内容数据可用于所述UA所提供的所述片段请求中的一个或多个片段。

20.根据权利要求1所述的方法，其中，所述UA不包括用于利用冗余编码内容数据的逻辑单元。

21.根据权利要求20所述的方法，其中，所述冗余编码内容数据包括前向纠错(FEC)编码数据。

22.一种被配置用于由客户端设备的传输加速器(TA)来加速将内容递送至所述客户端设备的用户代理(UA)的装置，所述装置包括：

用于由所述TA的请求管理器(RM)来接收所述UA所提供的片段请求，以用于从内容服务器请求内容的单元；以及

用于确定针对所述片段请求中的一个片段请求要请求的冗余编码内容数据的量，以由所述RM在恢复所述片段时使用的单元。

23.根据权利要求22所述的装置，其中，所述冗余编码内容数据包括前向纠错(FEC)编码数据。

24.根据权利要求23所述的装置，其中，所述RM对所述RM所接收的数据使用FEC解码，以便恢复所述UA所请求的所述片段并且向所述UA提供所恢复的片段。

25.根据权利要求22所述的装置，其中，超文本传输协议/传输控制协议(HTTP/TCP)用于请求所述内容和所述冗余编码内容数据，并且用于响应于所述请求从所述内容服务器传输内容。

26.根据权利要求25所述的装置，其中，与冗余编码内容片段相关联的资源标识信息用于确定针对所述冗余编码内容片段的一部分的HTTP请求，所述冗余编码内容片段的一部分用于提供所述冗余编码内容数据的至少一部分。

27.根据权利要求22所述的装置，还包括：

用于由所述RM基于所述片段请求中的所述一个片段请求来确定多个块请求的单元，其中，所述多个块请求中的至少一个块请求包括：针对所述片段请求所请求的所述片段的一部分的请求，并且其中，所述多个块请求中的至少另一个块请求包括：针对与所述片段请求所请求的所述片段相关联的冗余编码内容片段的一部分的请求。

28.根据权利要求27所述的装置，还包括：

用于由所述RM经由多个连接来并行地从所述内容服务器请求所述多个块请求中的两个或更多块请求的单元，所述多个连接由所述TA的连接管理器(CM)来管理。

29.根据权利要求28所述的装置，其中，经由所述多个连接中的第一连接来向内容服务器作出针对所述UA所请求的所述片段的一部分的所述请求，并且经由所述多个连接中的第二连接来向冗余编码内容数据服务器作出针对所述冗余编码内容片段的一部分的所述请求，其中，所述内容服务器和所述冗余编码内容数据服务器是分离的和独立的服务器。

30.根据权利要求27所述的装置，其中，针对片段要请求的所述冗余编码内容数据的量是基于在针对所述片段的块的接收期间、针对所述片段并发地迟到数据的最大量的，其中，如果块内的第一数据已经被所述RM请求但是尚未被接收，并且至少一些第二数据在所述第一数据之后被请求并且已经被接收，则将所述第一数据归类为在特定时间点处迟到。

31.根据权利要求30所述的装置，其中，只要已接收的针对所述片段的数据的总量加上已请求但是尚未接收的针对所述片段的数据的量在所述片段的大小的字节的加常数数量加上直到某一时间点针对所述片段并发地迟到数据的所述最大量以内，所述RM就适于作出针对所述片段的额外的块请求。

32.根据权利要求22所述的装置，其中，所述用于确定针对片段要请求的冗余编码内容数据的量的单元包括：

用于基于未足够快地接收针对所述片段先前请求的数据，来确定针对所述片段要请求的额外的冗余编码内容数据的单元，其中，尽管当先前请求的数据到达时，所述先前请求的数据的量足以供所述RM完全恢复所述片段，并且尽管所述先前请求的数据中的全部将被所述RM接收，还确定要请求所述额外的冗余编码内容数据。

33.根据权利要求22所述的装置，其中，所述用于确定针对片段请求要请求的冗余编码内容数据的量的单元包括：

用于至少部分地基于当前网络状况来确定冗余编码内容数据的量的单元。

34.根据权利要求33所述的装置，其中，所述当前网络状况包括：根据当前下载速率(R)和当前往返时间(RTT)确定的带宽-延迟乘积。

35.根据权利要求22所述的装置，其中，所述用于确定针对片段请求要请求的冗余编码内容数据的量的单元包括：

用于确定针对所述片段请求要请求的数据的总量的单元，所述数据的总量包括经纠错编码的数据的量和未经纠错编码的内容数据的量。

36.根据权利要求22所述的装置，还包括：

用于由所述RM确定针对所述片段请求要何时请求所述冗余编码内容数据的量的单元。

37.根据权利要求36所述的装置，其中，所述用于确定要何时请求所述冗余编码内容数据的量的单元包括：

用于所述RM将先前请求的数据视为迟到的单元。

38.根据权利要求22所述的装置，还包括：

用于由所述RM动态地调整要请求的与多个片段请求中的每个片段请求相关联的冗余编码内容数据的量的单元。

39.根据权利要求22所述的装置，还包括：

用于由所述RM确定是否要请求与所述UA所提供的所述片段请求中的任何特定片段请求相关联的冗余编码内容数据的单元。

40.根据权利要求39所述的装置，其中，所述用于确定是否要请求冗余编码内容数据的单元包括：

用于由所述TA确定冗余编码内容数据可用于所述UA所提供的所述片段请求中的一个或多个片段的单元。

41.根据权利要求22所述的装置，其中，所述UA不包括用于利用冗余编码内容数据的逻辑单元。

42.根据权利要求41所述的装置，其中，所述冗余编码内容数据包括前向纠错(FEC)编码数据。

43.一种用于由客户端设备的传输加速器(TA)来加速将内容递送至所述客户端设备的用户代理(UA)的计算机程序产品，所述计算机程序产品包括：

非暂时性计算机可读介质，所述非暂时性计算机可读介质具有记录在其上的程序代码，所述程序代码包括：

用于由所述TA的请求管理器(RM)来接收所述UA所提供的片段请求，以用于从内容服务器请求内容的程序代码；以及

用于确定针对所述片段请求中的一个片段请求要请求的冗余编码内容数据的量，以由所述RM在恢复所述片段时使用的程序代码。

44.根据权利要求43所述的计算机程序产品，还包括：

用于由所述RM基于所述片段请求中的所述一个片段请求来确定多个块请求的程序代码，其中，所述多个块请求中的至少一个块请求包括：针对所述片段请求所请求的所述片段的一部分的请求，并且其中，所述多个块请求中的至少另一个块请求包括：针对与所述片段请求所请求的所述片段相关联的冗余编码内容片段的一部分的请求。

45.根据权利要求44所述的计算机程序产品，其中，针对片段要请求的所述冗余编码内容数据的量是基于在针对所述片段的块的接收期间、针对所述片段并发地迟到数据的最大量的，其中，如果块内的第一数据已经被所述RM请求但是尚未被接收，并且至少一些第二数据在所述第一数据之后被请求并且已经被接收，则将所述第一数据归类为在特定时间点处迟到。

46.根据权利要求43所述的计算机程序产品，其中，所述用于确定针对片段要请求的冗余编码内容数据的量的程序代码包括：

用于基于未足够快地接收针对所述片段先前请求的数据，来确定针对所述片段要请求的额外的冗余编码内容数据的程序代码，其中，尽管当先前请求的数据到达时，所述先前请求的数据的量足以供所述RM完全恢复所述片段，并且尽管所述先前请求的数据中的全部将被所述RM接收，还确定要请求所述额外的冗余编码内容数据。

47.根据权利要求43所述的计算机程序产品，其中，由用于确定冗余编码内容数据的量的程序代码来确定针对片段请求要请求的冗余编码内容数据的量是至少部分地基于当前网络状况的。

48.根据权利要求43所述的计算机程序产品，还包括：

用于由所述RM动态地调整要请求的与多个片段请求中的每个片段请求相关联的冗余编码内容数据的量的程序代码。

49.根据权利要求43所述的计算机程序产品，还包括：

用于由所述RM确定是否要请求与所述UA所提供的所述片段请求中的任何特定片段请求相关联的冗余编码内容数据的程序代码。

50.一种用于由客户端设备的传输加速器(TA)来加速将内容递送至所述客户端设备的用户代理(UA)的装置，所述装置包括：

至少一个处理器：以及

存储器，其耦合到所述至少一个处理器，其中，所述至少一个处理器被配置为：

由所述TA的请求管理器(RM)来接收所述UA所提供的片段请求，以用于从内容服务器请求内容；以及

确定针对所述片段请求中的一个片段请求要请求的冗余编码内容数据的量，以由所述RM在恢复所述片段时使用。

51.根据权利要求50所述的装置，其中，所述至少一个处理器还被配置为：

基于所述片段请求中的所述一个片段请求来确定多个块请求，其中，所述多个块请求中的至少一个块请求包括：针对所述片段请求所请求的所述片段的一部分的请求，并且其中，所述多个块请求中的至少另一个块请求包括：针对与所述片段请求所请求的所述片段相关联的冗余编码内容片段的一部分的请求。

52.根据权利要求51所述的装置，其中，针对片段要请求的所述冗余编码内容数据的量是基于在针对所述片段的块的接收期间、针对所述片段并发地迟到数据的最大量的，其中，如果块内的第一数据已经被所述RM请求但是尚未被接收，并且至少一些第二数据在所述第一数据之后被请求并且已经被接收，则将所述第一数据归类为在特定时间点处迟到。

53.根据权利要求50所述的装置，其中，被配置为对代码进行编程以确定针对片段要请求的冗余编码内容数据的量的所述至少一个处理器还被配置为：

基于未足够快地接收针对所述片段先前请求的数据，来确定针对所述片段要请求的额外的冗余编码内容数据，其中，尽管当先前请求的数据到达时，所述先前请求的数据的量足以供所述RM完全恢复所述片段，并且尽管所述先前请求的数据中的全部将被所述RM接收，还确定要请求所述额外的冗余编码内容数据。

54.根据权利要求50所述的装置，其中，由所述至少一个处理器来确定针对片段请求要请求的冗余编码内容数据的量是至少部分地基于当前网络状况的。

55.根据权利要求50所述的装置，其中，所述至少一个处理器还被配置为：

由所述RM动态地调整要请求的与多个片段请求中的每个片段请求相关联的冗余编码内容数据的量。

56.根据权利要求50所述的装置，其中，所述至少一个处理器还被配置为：

由所述RM确定是否要请求与所述UA所提供的所述片段请求中的任何特定片段请求相关联的冗余编码内容数据。