实现扩展传输控制功能的传输加速器的制作方法

本申请享有于2014年3月18日递交的、标题为“TRANSPORT ACCELERATOR IMPLEMENTING EXTENDED TRANSMISSION CONTROL FUNCTIONALITY”的共同未决的美国临时专利申请号61/954,936以及于2014年5月28日递交的、标题为“TRANSPORT ACCELERATOR IMPLEMENTING EXTENDED TRANSMISSION CONTROL FUNCTIONALITY”的美国专利序列号14/289,016的优先权；故上述申请的公开内容通过引用被并入本文。本申请与共同转让的以下专利申请相关：于2014年5月28日递交的、标题为“TRANSPORT ACCELERATOR IMPLEMENTING EXTENDED TRANSMISSION CONTROL FUNCTIONALITY”的美国专利申请序列号14/289,181；于2014年5月28日递交的、标题为“TRANSPORT ACCELERATOR IMPLEMENTING ENHANCED SIGNALING”的美国专利申请序列号14/289,348；于2014年5月28日递交的、标题为“TRANSPORT ACCELERATOR IMPLEMENTING REQUEST MANAGER AND CONNECTION MANAGER FUNCTIONALITY”的美国专利申请序列号14/289,403；于2014年5月28日递交的、标题为“TRANSPORT ACCELERATOR IMPLEMENTING SELECTIVE UTILIZATION OF REDUNDANT ENCODED CONTENT DATA FUNCTIONALITY”的美国专利申请序列号14/289,458；于2014年5月28日递交的、标题为“TRANSPORT ACCELERATOR IMPLEMENTING A MULTIPLE INTERFACE ARCHITECTURE”的美国专利申请序列号14/289,476；以及于2014年5月28日递交的、标题为“TRANSPORT ACCELERATOR IMPLEMENTING CLIENT SIDE TRANSMISSION FUNCTIONALITY”的美国专利申请序列号14/289,499；上述申请中的每个申请与本申请同时递交，并且其公开内容的全部通过引用被明确地并入本文。

背景技术：

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

如今许多类型的应用依赖于HTTP来进行前述的内容传送。在许多这种应用中，HTTP传输的性能对于利用应用的用户体验来说是关键的。例如，实况流式传输具有会妨碍视频流式传输客户端的性能的数个约束。两个约束尤其突出。第一，媒体区段随着时间一个接一个变得可用。该约束防止客户端连续地下载很大一部分的数据，而连续地下载很大一部分的数据继而影响下载速率估计的精确性。由于大多数流式传输客户端操作在“请求-下载-估计”循环，其在下载估计是不精确时通常表现不佳。第二，当观看实况事件流式传输时，用户通常不想在实际的实况事件时间轴上遭受长的延迟。这种行为防止流式传输客户端建立大的缓冲区，大的缓冲区继而会造成更多的重新缓冲。

如果流式传输客户端操作在传输控制协议(TCP)上(例如，如大多数HTTP动态自适应流式传输(DASH)客户端所做的那样)，则前述的严格的实况事件时间轴与典型的TCP行为相抵触，其将在存在缺失的或重排序的分组时减慢。内建的TCP拥塞控制机制加剧了在实况流式传输期间的重新缓冲效应，而实况事件的观看者更可能愿意跳过重新缓冲并直接跳至最近的事件时间轴。

对于基于HTTP的文件下载也存在相同的问题，其中存在针对完成下载的最后期限，否则招致惩罚。例如，如果用户尝试访问网络页面、图片、或使用基于网络的应用，则大的下载延时会导致用户离开网络页面或基于网络的应用而去。

点播视频流式传输也遭受类似的约束。例如，在点播流式传输中，客户端设备希望接收按照正确的次序尽可能快地接收点播流，以向用户提供回放。流式传输点播内容的性能受缺失的和重排序的分组、重新缓冲等影响。

技术实现要素：

根据本公开内容的实施例，提供了一种用于由客户端设备的传输加速器(TA)对内容至所述客户端设备的用户代理(UA)的传送进行加速的方法。根据实施例的该方法包括：由所述TA的连接管理器(CM)从内容服务器请求一个或多个内容块；由所述CM接收响应于所述请求所述一个或多个内容块而发送的数据，其中，所接收的数据是出自所述一个或多个内容块中请求的块的缺失的数据；以及由所述CM向所述内容服务器提供针对至少所述缺失的数据的接收确认(ACK)。实施例的该方法还包括：通过通信协议栈将所接收的数据传递给应用，以便组装成一个或多个内容对象，其中所接收的数据是出自所述一个或多个内容块中请求的块的缺失的数据。

根据本公开内容的实施例，提供了一种用于由客户端设备的传输加速器(TA)对内容至所述客户端设备的用户代理(UA)的传送进行加速的装置。根据实施例的该装置包括：用于由所述TA的连接管理器(CM)从内容服务器请求一个或多个内容块的单元；用于由所述CM接收响应于所述请求所述一个或多个内容块而发送的数据的单元，其中，所接收的数据是出自所述一个或多个内容块中请求的块的缺失的数据；以及用于由所述CM向所述内容服务器提供针对至少所述缺失的数据的接收确认(ACK)的单元。实施例的该方法还包括：用于通过通信协议栈将所接收的数据传递给应用以便组装成一个或多个内容对象的单元，其中所接收的数据是出自所述一个或多个内容块中请求的块的缺失的数据。

根据本公开内容的实施例，提供了一种用于由客户端设备的传输加速器(TA)对内容至所述客户端设备的用户代理(UA)的传送进行加速的计算机程序产品。根据实施例的该计算机程序产品包括：具有记录在其上的程序代码的非暂时性计算机可读介质。实施例的该程序代码包括：用于由所述TA的连接管理器(CM)从内容服务器请求一个或多个内容块的代码；用于由所述CM接收响应于所述请求所述一个或多个内容块而发送的数据的代码，其中，所接收的数据是出自所述一个或多个内容块中请求的块的缺失的数据；以及用于由所述CM向所述内容服务器提供针对至少所述缺失的数据的接收确认(ACK)的代码。实施例的该程序代码还包括：用于通过通信协议栈将所接收的数据传递给应用以便组装成一个或多个内容对象的代码，其中所接收的数据是出自所述一个或多个内容块中请求的块的缺失的数据。

根据本公开内容的实施例，提供了一种被配置用于由客户端设备的传输加速器(TA)对内容至所述客户端设备的用户代理(UA)的传送进行加速的装置。实施例的该装置包括至少一个处理器和耦合到所述至少一个处理器的存储器。所述至少一个处理器根据实施例被配置为：由所述TA的连接管理器(CM)从内容服务器请求一个或多个内容块；由所述CM接收响应于所述请求所述一个或多个内容块而发送的数据，其中，所接收的数据是出自所述一个或多个内容块中请求的块的缺失的数据；以及由所述CM向所述内容服务器提供针对至少所述缺失的数据的接收确认(ACK)。所述至少一个处理器还根据实施例被配置为：通过通信协议栈将所接收的数据传递给应用，以便组装成一个或多个内容对象，其中所接收的数据是出自所述一个或多个内容块中请求的块的缺失的数据。

本公开内容的另外实施例提供了一种用于由客户端设备的传输加速器(TA)对内容至所述客户端设备的用户代理(UA)的传送进行加速的方法。实施例的该方法包括：使用在所述UA与可操作用于提供内容的内容服务器之间的通信路径中布置的所述TA，来发起针对所述UA的媒体传输操作，其中，所述TA包括请求管理器(RM)和连接管理器(CM)，所述RM可操作用于控制从所述内容服务器请求所述内容的什么数据，所述CM可操作用于控制何时从所述内容服务器请求所述内容的所述数据，其中，所述RM布置在所述UA与由所述CM使用的通信协议栈之间的通信路径中，用于将接收的所述内容的数据传递给所述UA。该方法还包括：由所述CM向所述RM传递接收的由所CM从所述内容服务器请求的一个或多个内容块的数据，其中，所接收的数据是出自所述一个或多个内容块中的块的缺失的数据，并且由所述CM通过所述通信协议栈传递给所述RM以便组装成内容流，其中，所述RM操作为使所述UA与关于所述缺失的数据的TA操作隔离；将所述一个或多个内容块的所述数据组装成由所述UA请求的内容片段；以及由所述RM向所述UA传递针对于所述UA的所述内容片段作为部分的内容流，其中，由所述RM向所述UA传递的所述内容片段包括用于补全所述缺失的数据的内容数据。

本公开内容的实施例提供了一种被配置用于由客户端设备的传输加速器(TA)对内容至所述客户端设备的用户代理(UA)的传送进行加速的装置。实施例的该装置包括：用于使用在所述UA与可操作用于提供内容的内容服务器之间的通信路径中布置的所述TA，来发起针对所述UA的媒体传输操作的单元，其中，所述TA包括请求管理器(RM)和连接管理器(CM)，所述RM可操作用于控制从所述内容服务器请求所述内容的什么数据，所述CM可操作用于控制何时从所述内容服务器请求所述内容的所述数据，其中，所述RM布置在所述UA与由所述CM使用的通信协议栈之间的通信路径中，用于将接收的所述内容的数据传递给所述UA。该装置还包括：用于由所述CM向所述RM传递接收的由所CM从所述内容服务器请求的一个或多个内容块的数据，其中，所接收的数据是出自所述一个或多个内容块中的块的缺失的数据，并且由所述CM通过所述通信协议栈传递给所述RM以便组装成内容流，其中，所述RM操作为使所述UA与关于所述缺失的数据的TA操作隔离；用于将所述一个或多个内容块的所述数据组装成由所述UA请求的内容片段的单元；以及用于由所述RM向所述UA传递针对于所述UA的所述内容片段作为部分的内容流的单元，其中，由所述RM向所述UA传递的所述内容片段包括用于补全所述缺失的数据的内容数据。

本公开内容的实施例提供了一种被配置用于由客户端设备的传输加速器(TA)对内容至所述客户端设备的用户代理(UA)的传送进行加速的计算机程序产品。该计算机程序产品包括：具有记录在其上的程序代码的非暂时性计算机可读介质。实施例的该程序代码包括：用于使用在所述UA与可操作用于提供内容的内容服务器之间的通信路径中布置的所述TA，来发起针对所述UA的媒体传输操作的程序代码，其中，所述TA包括请求管理器(RM)和连接管理器(CM)，所述RM可操作用于控制从所述内容服务器请求所述内容的什么数据，所述CM可操作用于控制何时从所述内容服务器请求所述内容的所述数据，其中，所述RM布置在所述UA与由所述CM使用的通信协议栈之间的通信路径中，用于将接收的所述内容的数据传递给所述UA。该程序代码还包括：用于由所述CM向所述RM传递接收的由所CM从所述内容服务器请求的一个或多个内容块的数据，其中，所接收的数据是出自所述一个或多个内容块中的块的缺失的数据，并且由所述CM通过所述通信协议栈传递给所述RM以便组装成内容流，其中，所述RM操作为使所述UA与关于所述缺失的数据的TA操作隔离；用于将所述一个或多个内容块的所述数据组装成由所述UA请求的内容片段的程序代码；以及用于由所述RM向所述UA传递针对于所述UA的所述内容片段作为部分的内容流的程序代码，其中，由所述RM向所述UA传递的所述内容片段包括用于补全所述缺失的数据的内容数据。

本公开内容的实施例提供了一种被配置用于由客户端设备的传输加速器(TA)对内容至所述客户端设备的用户代理(UA)的传送进行加速的装置。该装置包括至少一个处理器和耦合到所述至少一个处理器的存储器。实施例的所述至少一个处理器被配置为：使用在所述UA与可操作用于提供内容的内容服务器之间的通信路径中布置的所述TA，来发起针对所述UA的媒体传输操作，其中，所述TA包括请求管理器(RM)和连接管理器(CM)，所述RM可操作用于控制从所述内容服务器请求所述内容的什么数据，所述CM可操作用于控制何时从所述内容服务器请求所述内容的所述数据，其中，所述RM布置在所述UA与由所述CM使用的通信协议栈之间的通信路径中，用于将接收的所述内容的数据传递给所述UA。所述至少一个处理器还被配置为：传递接收的由所CM从所述内容服务器请求的一个或多个内容块中的数据，其中，所接收的数据是出自所述一个或多个内容块中的块的缺失的数据，并且由所述CM通过所述通信协议栈传递给所述RM以便组装成内容流，其中，所述RM操作为使所述UA与关于所述缺失的数据的TA操作隔离；将所述一个或多个内容块的所述数据组装成由所述UA请求的内容片段；以及由所述RM向所述UA传递所述内容片段作为部分的内容流，其中，由所述RM向所述UA传递的所述内容片段包括用于补全所述缺失的数据的内容数据。

附图说明

图1根据本公开内容的实施例，示出了适于扩展的传输协议操作的系统。

图2示出了如可以根据本公开内容的实施例来适应的具有缺失数据的内容流的表示。

图3示出了描绘本公开内容的实施例的传输加速器的操作的梯形图。

图4示出了描绘本公开内容的实施例的传输加速器的请求管理器的操作的流程图。

图5示出了描绘本公开内容的传输加速器的连接管理器的操作的流程图。

具体实施方式

本文使用词语“示例性”来意指“充当示例、实例或说明”。本文描述为“示例性”的任何方面并不必然地被解释为比其它方面优选或有利。

在该描述中，术语“应用”也可以包括具有诸如以下各项之类的可执行内容的文件：目标代码、脚本、字节代码、标记语言文件、以及补丁。此外，本文提及的“应用”也可以包括本质上不可执行的文件，诸如可能需要打开的文档或需要存取的其它数据文件。

如该描述中所使用的，术语“内容”可以包括具有在一个或多个质量级别的视频、音频、视频和音频的组合、或其它数据，质量级别由比特率、分辨率或其它因素确定。内容还可以包括诸如以下各项之类的可执行内容：目标代码、脚本、字节代码、标记语言文件、以及补丁。此外，“内容”还可以包括本质上不可执行的文件，诸如可能需要打开的文档或需要存取的其它数据文件。

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

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

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

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

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

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

客户端设备110可以包括各种配置的设备，其操作用于经由网络150接收对内容的传输。例如，客户端设备110可以包括有线设备、无线设备、个人计算设备、平板电脑或平板计算设备、便携式蜂窝电话、具有WiFi功能的设备、具有蓝牙功能的设备、电视机、具有显示器的一副眼镜、一副增强现实眼镜、或连接到网络150(其可以使用任何可用的方法或基础设施与服务器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)网络浏览器，其通过连接151和152、经由网络150用于访问和观看网络内容以及用于经由HTTP与服务器130通信(如果服务器130是网络服务器的话)。举例而言，可以从客户端设备110中的浏览器通过连接151和152、经由网络150向服务器130发送HTTP请求。可以从服务器130通过连接152和151、经由网络150向客户端设备110中的浏览器发送HTTP响应。

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

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

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

除了前述的形成应用、操作系统、文件、电子文档、内容等的代码段以外，存储器112可以包括或以其它方式提供由客户端设备110的功能块所使用的各种寄存器、缓冲区和存储单元。例如，存储器112可以包括播出缓冲区，诸如可以提供用于使片段的数据假脱机(spool)的先入/先出(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的内容传送平台进行通信，以获得内容标识符(例如，所期望的内容的一个或多个列表、清单(manifest)、配置文件、或标识媒体区段或片段及其时序边界的其它标识符)。关于媒体区段及其时序的信息可以由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可操作用于根据本文的概念来提供对期望内容的片段或片段的序列的增强的传送。如上文所论述的，所示出的实施例的TA 120包括RM 121和CM 122，RM 121和CM 122进行合作以提供各种增强的片段传送功能。实施例的UA 129与RM 121之间的接口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的扩展传输协议操作隔离。然而，如根据以下的论述将更全面理解的，UA 129可以适于扩展传输协议操作，由此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 121已认为该数据可能从没到达或可能到达得太晚。另外地或替代地，由RM 121向CM 122做出的块请求中的一些可以是针对从原始片段生成的FEC编码数据，由此RM 121可以对从CM 122接收的数据进行FEC解码，以恢复该片段或其一些部分。RM 121将恢复的片段传送给UA 129。相应地，根据本文的实施例，可以存在RM的各种配置，诸如可以包括基本RM配置(RM-基本)和FEC RM配置(RM-FEC)，基本RM配置不使用FEC数据并且因此仅从原始的源片段中请求部分数据，FEC RM配置可以从原始的源片段中请求部分数据以及匹配从源片段生成的FEC片段。

实施例的RM 121可能不知道时序和/或带宽可用性约束，从而有助于在RM 121与CM 122之间实现相对简单的接口，因此RM 121可以操作为在不需要考虑RM 121的这种约束而做出块请求。或者，RM 121可以适于知道时序和/或带宽可用性约束，诸如可以由CM 122或客户端设备110内的其它模块向RM 121提供，以及因此RM 121可以操作为基于这种约束来做出块请求。

实施例的RM 121适于与多个不同的CM配置的操作。此外，一些实施例的RM 121可以同时与一个以上CM连接，例如以从多个CM请求相同的片段或片段的序列的数据块。每个这样的CM可以例如支持不同的网络接口(例如，第一CM可以具有至设备内置(on-device)的高速缓存的本地接口，第二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可以与支持专有协议的专有服务器相合作来进行操作。

应当明白，虽然已相对于从服务器130请求来自于源文件的数据的CM 122来论述所示出的实施例，但是源文件可以在服务器上获得或者可以本地地存储在客户端设备上，这取决于CM具有的用于存取数据的接口类型。在一些实施例中，包含从匹配的源文件使用FEC编码而生成的修复符号的FEC文件也可以在服务器上获得。在这样的实施例中，可以例如存在针对每个源文件的一个FEC文件，其中每个FEC文件是从源文件使用本领域已知的FEC编码技术来生成的，独立于使用CM来请求数据的特定实施例。

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

在根据实施例的操作中，虽然通常响应于来自RM 121的请求来提供完整数据，但是在一些情形中CM 122可以仍然向RM 121提供部分响应。这种部分响应可以是用于向RM 121提供RM所请求的数据的一部分，而不是所请求的数据的全部(即，在由CM 122提供的一个或多个响应中可以存在数据间隙或洞(hole))。实施例的CM 122操作为尽可能快地向RM 121提供响应(例如，可能包括足够的延迟来聚合响应，以避免在每个响应的时间向RM提供仅几个字节)。例如，虽然所请求的内容块的一些部分尚未被CM 122接收，但是CM 122可以通过接口123的TCP栈向RM 121传递数据。相应地，一旦前述的部分响应是可用的，就可以根据实施例将其提供给RM 121。

在促进前述的部分响应时，实施例的由CM 122向RM 121提供的响应可以包括对返回的数据的字节范围的指示。例如，由CM提供的针对于对片段的字节0-15999的RM请求的响应可以包括字节0-3599、字节4500-7699以及字节9000-14999(即，字节3600-4499、7700-8999和15000-15999的数据在从响应中缺失)，以及因此实施例的来自CM 122的响应被扩充为指示部分响应和/或指示返回的数据的字节范围，其中例如在HTTP响应报头或其等效项中携带字节范围。举个可操作用于指示返回的数据的字节范围的实现方式的进一步示例，实施例的在CM 122与RM 121之间的接口可以包括单独的软件API，其中与实际的数据流分开以信号形式发送“好”和/或“坏”字节范围。另外地或替代地，信令可以是“在流中”执行的，在这个意义上从CM向RM返回的数据包含接收的实际数据、虚设数据和用于指明哪个部分被正确地接收以及哪个部分没有被正确地接收的特殊标记。例如，特殊的比特模式可以被用作标记以促进数据的接收方(例如，在该情况中是RM)解析数据流并提取仅正确接收的数据，而无需使用用于这种信令的另外的接口。相应地，在实施例的RM 121与CM 122之间提供的TA 120的接口123提供了增强的接口(例如，基于HTTP 1.1接口协议的增强的接口)以促进前述的通信。

根据本文的概念，实施例的CM 122可以另外地或替代地向RM 121提供其它有用的信息。例如，CM 122可以向RM 121提供对已下载的聚合数据量的指示，有可能结合用于指示何时进行测量的时间戳。RM 121可以将这种信息用于各种目的，包括决定在RM与多个CM相连接时要向特定的CM发送块请求的哪个部分。举另一个示例，RM 121可以聚合该信息并将其提供给UA 129，以便UA可以使用该信息来确定将来要向RM提供哪些片段请求。例如，在RM 121将信息传递回给UA 129时，其中该信息指示在过去5秒下载速度平均为1Mbps，则UA可以使用该信息来决定下一个片段请求应该是针对按照750Kbps来编码的视频片段，然而如果该信息指示在过去5秒下载速度平均为2Mbps，则UA可以决定下一个片段请求应该是针对按照1.5Mbps来编码的视频片段。相应地，在实施例的UA 129与RM 121之间提供的TA 120的接口124提供了增强的接口(例如，基于HTTP 1.1接口协议的增强的接口)以促进前述的通信。

如先前所提到的，实施例的TA 120适于根据现有的内容传输协议(例如使用在HTTP接口上的TCP)来执行片段请求。相应地，实施例的CM 122适于使用信令根据TCP(例如使用其TCP接收机)来向服务器130提供块请求。然而，现有的TCP实现方式操作为在流中检测到缺失的或重排序的分组时减慢。相应地，本文的实施例的CM 122以及因此的TA 120适于实现扩展传输协议。例如，CM 122可以包括在本文中被称为CM-xTCP的扩展传输协议配置，由此CM 122使用在扩展形式的TCP连接(在本文中被称为xTCP)之上的HTTP。CM 122可以包括适于进行如本文所描述的xTCP操作的TCP接收机(即，xTCP接收机)。xTCP的实施例通过即使在丢失分组时将确认提供回给服务器130，来促进由TA 120向UA 129进行的对片段的增强的传送。也就是说，实施例的xTCP提供了修改的TCP，该修改的TCP绕过如用于对缺失分组的重传的重复ACK之类的这样的行为。根据本文概念的xTCP的实现方式适于实现快速下载，而不会造成网络中的过度拥塞。在操作中，xTCP协议可以立即提供从服务器130接收的所有数据，即便数据不是请求的前缀(即，在响应于其请求而返回给CM的数据中可能存在洞)。前述的xTCP数据分组确认用于避免服务器降低响应于确定数据分组缺失而以其来发送数据分组的速率。

在理解前述的xTCP的操作时，回顾根据现有的TCP来提供的操作是有帮助的。典型的TCP接收机采用关于流式传输内容的数个重要的内部参数，包括NextByteExpected(预期的下一个字节)和LastByteReceived(接收到的最后一个字节)。在图2的内容流200中，这些参数示出为NextByteExpected 210和LastByteReceived 220。在NextByteExpected之前的所有数据被完全接收，并且因此可以由应用读取并在之后由TCP层丢弃。然而，在NextByteExpected与LastByteReceived之间可能存在或不存在缺失的数据(例如，在接收的数据中的缺失的数据或“洞”)。当在数据中存在洞时，如由缺失的数据230所表示的，LastByteReceived的值将大于NextByteExpected的值，在这两个字节偏移之间的数据必须由TCP层进行缓存并且不能由应用读取。接收窗(RWND)的左边缘也不能比NextByteExpected提前得更远。

在现有的TCP实现方式中，接收机将仅提供数据接收确认(ACK)直到NextByteExpected。之后如果接收到在NextByteExpected与LastByteReceived之间具有缺失数据的乱序分组，该缺失数据不包括与NextByteExpected相对应的数据字节(即，在NextByteExpected处起始的缺失数据仍存在洞)，则接收机将发出与NextByteExpected相对应的重复ACK。发送方(例如，内容服务器)将把这种重复ACK解读为网络中拥塞的迹象，并且通过借助减小拥塞窗而减慢发送速率来进行反应，其中拥塞窗是确定可以在任何时间待解决(outstanding)的字节的数量的因素。例如，内容服务器可以在接收到预先确定的数量(例如3个)的重复ACK之后将拥塞窗减小一半(a factor of two)，从而减慢TCP的发送速率。拥塞窗仅与往返时间(RTT)(针对对数据的请求的响应所需要的时间)成比例增长。例如，在没有检测到进一步重复ACK的情况下，内容服务器可以每RTT将拥塞窗增加一个分组。因此，TCP的发送速率通常很慢地增加，尤其是在经历大的RTT的情况下。

本文的实施例的由CM 122进行的xTCP的实现方式以如下方式改变TCP的操作：分组丢失或在某些场景中的分组丢失将不导致减慢服务器130的发送速率。在根据实施例的操作中，xTCP通过即使当从服务器130至客户端设备110的传输中丢失分组时也将确认提供回给服务器130，来促进由TA 120向UA 129进行的对片段的增强的传送。此外，实施例可以实现适于促进如本文所描述的xTCP操作的请求发送技术。例如，为了确保及时发送块请求，TA 120可以操作为禁用Nagle(纳格)算法(例如，如通常可以实现为典型的TCP接收机的部分)，否则Nagle算法可能在发出请求时(例如，在RTT的量级)引入额外的延迟。这可以根据实施例通过CM 122设定TCP_NODELAY(TCP_无延迟)套接字选项来完成。本文实施例所实现的对请求发送技术的进一步调整可以包括使针对块的请求的大小变小(例如，小于一个最大区段大小(MSS)，因此其适合放入到一个分组中)并且在一个send()(发送())系统调用中发送块请求，例如以降低由于在数个分组中发送块请求而造成部分块请求丢失的风险。

根据许多内容传输协议(例如TCP)，上行链路仅发送相对少量的数据，因此可能难以获得对未获得分组的快速重传。相应地，可操作用于减轻上行链路丢失的技术可以实现为根据实施例来促进由TA 120进行的对片段的增强的传送。例如，当在一个分组中发送每个块请求，并且TA 120在连接上管道输送两个请求时，如果两个管道输送的块请求中的第一块请求丢失，则向TA 120提供单个重复ACK。接收到这种重复ACK通常不足以触发重传，并且因此通常将不重新发送第一块请求直到在发生重传超时之后为止，这会是相当长的时间。针对第一块请求的响应将同样被显著地延迟。因此，用于上行链路丢失减轻的技术由根据本文的实施例的TA 120来实现。

在实现上行链路丢失减轻技术时，应当明白，一些内容传输协议实现方式(例如，TCP)具有用于发送少量数据的流(诸如前面提到的上行链路)的算法。在Linux中，例如，在存在少量的正使用的(in-flight)数据的情形中，“精简的流”优化提供了在单个重复ACK(例如，而不是3个重复ACK)之后进行重传。本文中实现xTCP操作的实施例可以相对于用于请求块的控制流来实现这种特征，可能与其它特征或技术(例如，如下文所描述的)相结合，以便减轻在xTCP内容传输加速时的上行链路丢失的影响。

实施例可以适于在每个块请求之后添加协议数据单元(例如，TCP区段)，其目的在于当丢失请求区段时触发重复ACK。在实现这种技术时，应当明白，HTTP GET请求具有不变的前缀“GET”，由此TA 120可以适于首先推测性地发送该前缀，并且随后在稍后的时间(例如当实际存在要发送的请求时)发送请求的剩余部分。TA 120可以随后针对下一个请求再次发送推测性的“GET”。在丢失了请求的相关部分的情况下，将由服务器130接收的“GET”部分触发DUP ACK，提示TA 120重传丢失的块请求。类似地，可以以相同的方式重传推测性的前缀。通过实现该技术，可以避免最坏情况的延迟(例如，由于超时引起的重传)，但由于每个请求使用更多分组而以有点高的重传次数为代价。

图3的梯形图(表示UA 129、RM 121、CM 122与服务器130之间的交互的序列图300)以及图4的流程图(表示由RM 121进行的处理的流程400)和图5的流程图(表示由CM 122进行的处理的流程500)根据本文的概念示出了该操作。

UA 129可以例如发出对与流式传输内容会话相关联的内容片段的请求(例如，图3的片段请求301)。由UA 129发出的片段请求可以使用标准通信协议(例如，TCP)或根据本文概念的扩展通信协议(例如，xTCP)。例如，如将通过下文的论述明白的，实施例的RM 121操作为向UA 129提供完整的片段响应，从而在不要求修改传统的UA的情况下促进TA 120的增强的操作，以便得到传输加速器的益处。

应当明白，虽然为了简单起见，图3-图5中所示出的示例示出了单个片段和单个块请求/响应，但是可以执行多个这种请求和响应，无论是并行地和/或串行地。例如，UA 129可以在任何特定的时间点具有与RM 121待决的多个片段请求。此外，RM 121可以具有针对UA 129所请求的一个或多个片段的、与CM 122待决的多个块请求，并且类似地，CM 122可以在任何特定的时间点具有与服务器130待决的多个块请求。

RM 121可以将片段请求分成多个块请求，该多个块请求可以作为下一个块请求串行和/或并行地发给CM 122(例如，图3的块请求302和图4的框401)，例如使用标准通信协议(例如，TCP)或根据本文概念的扩展通信协议(例如，xTCP)。根据实施例，块请求(例如块请求302)可以包括针对文件或文件的字节范围的HTTP请求。

响应于已从RM 121接收到块请求，CM 122可以向服务器130发出针对流式传输内容的内容数据的下一个块的请求(图3的块请求303)(图5的框501)。在CM 122与RM 121之间提供的信令可以包括除了块请求准备信令以外的信息或替代块请求准备信令的信息，例如块大小信令。实施例的CM 122关于发给服务器130的块请求来采用扩展通信协议(例如，xTCP)。应当明白，虽然这种扩展通信协议的操作可以控制服务器130的行为，但是根据本文的实施例，服务器130可以仍然包括标准的传统服务器，该标准的传统服务器并不专门适于进行根据扩展通信协议的操作。然而，如将根据以下论述更好地明白的，根据扩展通信协议来适应实施例的CM 122的操作。

CM 122可以接收(图5的框502)包括所请求的内容数据、或其某部分(例如，如图2的内容流200)的多个数据分组(例如，图3的分组304)。如果内容流不包括任何洞或缺失的数据(例如，在图5的框503处没有检测到迟到的或乱序的数据)，则CM 122可以根据典型的通信协议(例如，TCP)操作向服务器130发出适当的一个或多个ACK(例如，图3的ACK 305)(图5的框504)，并且将数据分组组装成所请求的块以便提供给RM 121(图5的框505)。

然而，在根据扩展通信协议(例如，xTCP)的CM 122的操作中，该CM可以向服务器130发出ACK直到所接收的最后一个字节(例如，图2的LastByteReceived 220)为止，而不管是否存在缺失的数据(例如，图2的缺失的数据230)，从而防止服务器130减小拥塞窗的操作，即使在服务器130可根据传统通信协议(例如，典型的TCP)技术来操作的情况下。相应地，如果内容流包括洞或缺失的数据(例如，在图5的框503处检测到迟到的或乱序的数据)，则CM 122可以向服务器130发出针对LastByteReceived 220的适当的一个或多个ACK(例如，图3的ACK 302和图5的框506)。例如，CM 122可以操作为将所接收的数据(可选地包括如下文所描述的虚设数据)传递给其xTCP接收机，或者以其它方式由CM控制为触发xTCP接收机向内容服务器发送接收确认，就像缺失的数据已到达CM处。因此，缺失的分组将不会使发送方(例如，传统的TCP发送方)减慢，因为服务器130可以在无间隙的情况下连续地接收ACK，尽管在内容流中存在缺失的数据。

实施例的CM 122可以采用用于确定何时要向发送方提供一个或多个ACK(如果已检测到缺失的数据的话)的逻辑单元，例如以提供适于避免网络拥塞的操作。例如，当反复地检测到缺失的数据时(例如，在指定的时间段内的预先确定的数量的缺失的分组，预先确定的数量的连续缺失的数据分组，等等)，CM 122可以操作为向服务器130发送一个或多个重复ACK，以便提供控制来避免网络拥塞。当在CM 122与服务器130之间使用TCP连接，并且服务器130实现典型的TCP行为，以在存在缺失的或重排序的分组时减慢对数据分组的传输的情况下，CM 122的xTCP接收机可以操作为发送多个已知的重复ACK，以调用由服务器130对数据传输的速率的降低(例如，拥塞窗的减小)。另外地或替代地，实施例的CM 122可以操作为抑制向服务器130发送一个或多个ACK，以便提供控制来避免网络拥塞(例如，CM可以操作为抑制多个已知的ACK以调用由服务器对数据传输的速率的降低)。

另外地或替代地，当CM 122检测到网络拥塞时并且在减慢发送速率将是有益的情况下，CM 122可以发送重复ACK来减慢(例如，不一定响应于缺失的数据，但通常作为速率控制机制)数据传输。例如，即使当不存在缺失的数据时，CM 122可以发送重复ACK，这将以信号形式通知服务器130减小发送方拥塞窗并且因此减慢发送速率，其代价是CM 122潜在地从服务器130接收一些小部分数据两次。举另一个示例，CM 122可以发送针对缺失的数据中的一些数据的重复ACK，但不一定针对所有缺失的数据，以信号形式通知未被CM 122接收的数据的至少一部分的丢失，与此同时以信号形式向服务器130通知减小发送方拥塞窗并因此减慢发送速率，并且还从服务器130接收在先前的传输中丢失的缺失数据的部分数据。

如可以通过前述内容明白的，CM 122的逻辑单元提供了用于网络拥塞避免的客户端侧控制。即使在服务器130包括尚不适于实现本文的扩展通信协议的功能的传统内容服务器的情况下，也可以提供这种客户端侧控制。

此外，响应于检测到缺失的数据，本文实施例的CM 122的扩展通信协议接收机可以调整接收窗以促进接收数据和/或避免网络拥塞。例如，当CM 122的扩展通信协议接收机发现缺失的分组和/或RTT变化时，CM 122可以不仅操作为发出ACK直到LastByteReceived为止(如上文所描述的)，而且还可以操作为调整接收窗大小以控制网络中的拥塞。可以根据以下的方案来实现接收窗的缩放：连续地接收数据分组而没有缺失数据将会增加接收窗(例如，增加到预先确定的最大接收窗大小)，然而检测到更多缺失的分组将会使CM 122的扩展通信协议接收机缩小接收窗(例如，缩小到预先确定的最小接收窗大小)。根据实施例来实现的接收窗缩放可以另外地或替代地考虑RTT，例如以在RTT是相对长的情况下实现有点大的接收窗缩放，而在RTT是相对短的情况下实现有点小的接收窗缩放。根据实施例的接收窗缩放操作可以因此在不会在网络中引入显著的拥塞的情况下，使用接收窗来将发送方行为控制在适当的积极性(aggressiveness)水平。

前述的对接收窗大小的调整可以根据实施例来实现而无需改变接收缓冲区大小。也就是说，接收窗缩放可以实现为一种用于向发送方(例如，服务器130)通知接收窗调整，并因此控制发送方行为的技术。因此，实施例的CM 122的扩展通信协议接收机可以操作为向服务器130发送经调整的接收窗大小而无需改变接收缓冲区大小。

所示出的实施例的CM 122向RM 121提供所接收的数据直到LastByteReceived 220为止(图3的块数据306和图5的框507)。虽然RM 121可以操作为使用数据分析技术、带外信令(例如，由CM 122设定的外部寄存器或标记)等来在由CM 122提供的块内检测缺失的数据，但是实施例操作为在CM 122与RM 121之间的通信中提供用于指示缺失数据的范围的数据(例如，起始字节偏移和字节数量)。例如，在RM 121与CM 122之间的通信接口使用标准通信协议的情况下，RM 121的逻辑单元可以适于识别具有响应于块请求而提供的不完整数据的块，例如通过分析块数据自身、报头数据、由CM 122设定的寄存器或标记等。在RM 121与CM 122之间的通信接口使用扩展通信协议的情况下，可以提供关于具有响应于块请求而返回的不完整数据的块的信令，如下文进一步论述的。

当向RM 121提供具有缺失数据(即，前述的洞)的块数据306时，CM 122可以操作为利用虚设数据(例如，零)来填充洞，以便向RM 121的通信协议栈提供看似是完整的数据。例如，CM 122的xTCP接收机可以操作为：在CM向RM 121传递(具有虚设数据的)所接收的数据之前，利用该虚设数据来填充缺失的数据。前述的关于缺失数据的范围的信息可以由RM 121用于稍后补全数据以及防止数据在不完整时被提供给UA 129。也就是说，RM 121的逻辑单元可以识别出CM 122所提供的数据是不完整的，例如通过参考关于缺失数据的范围的信息，并且因此抑制将该数据提供给UA 129直到已接收到请求的片段的所有数据为止。在根据实施例的操作中，CM 122可以利用关于缺失数据的范围的信息来控制xTCP接收机将具有虚设数据的所接收的数据传递给RM 121。

RM 121接收由CM 122响应于块请求而提供的块数据(例如，块数据306)(图4的框402)，以便处理该块数据以恢复由UA 129请求的片段。被提供成块数据306的内容块可以例如包括HTTP可寻址的文件或文件的字节范围。所示出的实施例的RM 121操作为确定CM 122所提供的块数据是否是缺失的数据(框403)。如果块数据不包括洞或缺失的数据，则RM 121可以行进至确定是否已接收到针对特定片段的所有块(图4的框404)；在已接收到所有块的情况下，行进至组装片段并将片段提供给UA 129(框405)，以及在尚未接收到片段的所有块的情况下，行进至发出针对片段的下一个块请求(框401)。然而，如果块数据包括洞或缺失的数据，则RM 121可以操作为使用数据分析技术、带外信令、在CM 122与RM 121之间的通信中用于指示缺失数据的范围的数据(例如，起始字节偏移和字节数量)等来在由CM 122提供的块内检测缺失的数据。在检测到块数据中的缺失数据时，所示出的实施例的RM 121抑制向UA 129提供该数据直到已接收到请求的片段的所有数据为止，并且因此行进到在向UA 129提供包括块数据的片段之前实现用于补全或填充缺失的数据的操作(框406)。

例如，RM 121可以操作为等待某个时间段以便使迟到的数据由CM 122接收并随后提供给RM 121。另外地或替代地，RM 121可以操作为向CM 122提供针对缺失数据的重传的请求(例如，缺失数据请求307)。在根据实施例的操作中，针对缺失数据的重传的请求将在已发出在网络上的块请求之后进行(潜在地进行管道输送)。相应地，如本文中由块请求所提供的内容块的大小可以相对很小(例如，在16千字节至128千字节的范围中)，以控制在任何特定时间多少数据将是待解决的，以及可以多快地供应针对重传的请求。

实施例可以实现一种关于前述的用于对缺失数据的重传的请求的优先级化技术。例如，RM 121可以向CM 122提供信令，无论是在请求内还是以其它方式与其相关联(例如，带外信令)，以使得CM 122在一个或多个块请求(例如，低优先级请求，诸如初始块请求、与低优先级或低质量的服务流相关联的块请求)已由CM 122处理之前向服务器130发送请求。

在根据实施例的操作中，由RM 121提供的缺失数据请求可以包括针对缺失数据的特定字节范围的请求。另外地或替代地，缺失数据请求可以包括针对纠错编码(例如，FEC)数据(诸如可以由用于提供所接收的分组(例如，分组304)的内容的不同表示来提供)的请求。根据实施例，可以请求纠错编码数据而不是原始请求的、数据的非纠错编码表示，以便有助于发起请求而无需等待关于缺失数据的字节范围的信息(例如，避免额外的用于请求缺失数据字节范围信息的RTT)。这种实现方式可以在实况流式传输情形中尤其有利，其中在对内容的创建与客户端设备对内容的使用之间预期非常短的时间延迟(例如，1秒)。

应当明白，根据本文的实施例，可以单独或结合非纠错编码数据来请求纠错编码数据。在结合非纠错编码数据来请求纠错编码数据的情况下，实施例可以操作为一旦接收到响应于针对数据恢复的请求的足够数据(无论是纠错编码数据、非纠错编码数据、还是其组合)就恢复缺失的数据。可以请求适合于恢复缺失的数据的纠错编码数据的量(无论是结合已接收的数据和/或如还可以由RM 121请求的缺失数据的一部分)，以便一旦由RM 121接收到足够的数据量就促进恢复缺失的数据。例如，RM 121可以操作为：基于接收的数据和/或重新请求的数据(其未进行纠错编码)，来确定针对用于获得缺失的数据的请求的纠错编码数据的量。

响应于已从RM 121接收到缺失数据请求，CM 122可以向服务器130发出针对适当内容的对应请求(例如，缺失数据请求308)。正如前述的块请求一样，实施例的CM 122关于向服务器130发出的缺失数据请求采用诸如xTCP、标准TCP等的通信协议。CM 122可以接收包括所请求的缺失数据或其某个部分的一个或多个数据分组(例如，分组309)。CM 122可以向服务器130发出适当的一个或多个ACK(例如，ACK 310)(如上文所讨论的)，并且向RM 121提供数据(例如，如缺失的数据311)。

已执行了用于补全或填充缺失的数据的操作(框406)，图4中所示出的实施例的RM 121行进至确定数据是否完整(框407)。如果数据是不完整的(例如，数据中的洞仍未被填充)，根据所示出的实施例的处理返回至执行用于补全或填充缺失的数据的进一步操作(框406)。例如，RM 121可以发出进一步的缺失数据请求。然而，如果确定数据是完整的，则根据所示出的实施例的处理行进至确定是否已接收到针对特定片段的所有块(框404)。在已接收到针对片段的所有块(或者当请求FEC时，已通过块请求接收到足够数据)的情况下，RM 121可以行进至组装片段(框405)并将片段提供给UA 129(例如，如片段312)。此外，在根据实施例的操作中，一旦足够的数据/块已到达并且可以从头开始构建响应的连续部分，RM就能够开始组装片段(例如，在框405)。实施例的RM可以操作为：一旦存在足够的从响应的开始连续的重构的数据(即，数据中无洞)，就向UA提供部分响应。如可以通过前述内容明白的，RM 121可以因此操作为：及时地聚合来自多个响应的数据，并且一旦足够的数据已到达以恢复UA所请求的片段、或其连续部分，就将完整的片段响应或者在一些实施例中部分片段响应提供给UA 129。相应地，可以根据需要发出针对流式传输内容的另一个片段的下一个块请求(框401)。

虽然前述的示例性操作提供了扩展传输协议CM操作(例如，xTCP操作)，但是实施例可以选择性地实现这种操作。在根据实施例的操作中，某些字节或请求可以被指定用于捕获而不使用扩展传输协议，例如以便使用标准TCP操作来获得。例如，可以选择某些字节(例如，传统上在扩展传输协议实现之前的用于建立流的流的初始帧、用于确保可靠接收的流式传输清单信息，等等)来进行传输而无需实现TA 120的扩展传输协议。CM 122可以例如被配置为使其行为在传统TCP操作与xTCP操作之间进行交替，例如其中对于RM 121所请求的每个块中的第一数量(SB)个字节，由CM 122实现的xTCP接收机操作在传统TCP模式中并且之后通过xTCP来操作在积极模式中。可以实现积极的行为直到完成块请求为止。参数值SB可以具有默认值0(例如，没有保守模式)，并且可以被由RM 121针对每个块请求提供的值来覆写。可以定义特殊的情况，例如其中SB等于“-1”，以指示：通过传统TCP，完全可靠的传输行为是预期的。通过前述内容，应当明白，扩展传输协议操作的这种选择性实现方式可以是相对于使用TA 120来传输的多个内容流中的一个或多个内容流和/或相对于使用TA 120来传输的内容流的一个或多个部分。

在CM 122的扩展传输协议接收机适于在检测到缺失的数据时总是发出ACK的情况下，在根据实施例的操作中，服务器130可以不因丢失的分组而减慢内容流的发送速率。同样，实施例的CM 122可以不减慢发送ACK，并且可以继续提前接收窗。

然而，本文实施例的扩展传输协议配置的操作的目的是在不会造成网络中的过度拥塞的情况下实现流式传输内容的快速下载。相应地，扩展传输协议接收机操作的积极性可以针对网络状况等来调谐，例如基于缺失分组的数量和/或所估计的RTT。实现这种扩展传输协议配置的实施例可以利用速率适配机制来适应UA 129，诸如自适应流式传输客户端中的应用层速率请求逻辑单元。另外地或替代地，根据本文的实施例，可以利用速率适配机制来适应CM 122。

在提供可操作用于提供相对于传输速率和/或网络拥塞的客户端侧控制的速率适配机制时，实施例的CM 122可以适于实现扩展传输协议接收机(例如，xTCP接收机)配置，该xTCP接收机配置在检测到缺失的数据时并不总是发出ACK。例如，CM 122可以实现逻辑单元来确定网络状况或其它因素是否指示应当减慢服务器130对数据的发送(例如，以避免或缓解网络拥塞)，从而提供了由接收机提供数据发送速率控制的实施例。在这种实施例中，xTCP接收机操作可以利用对TCP发送方的行为(例如，对接收重复ACK的反应)的了解来提供适当的信令(例如，选择性地提供重复ACK)以用于控制内容流发送速率。可以基于缺失分组的数量、所估计的RTT等来调谐这种xTCP接收机的积极性。

另外地或替代地，在CM 122的扩展传输协议接收机适于提供数据发送速率控制的情况下，当扩展传输协议接收机发现缺失的分组和/或RTT变化时，CM 122可以操作为发出ACK直到所接收的最后一个字节(例如，LastByteReceived 220)为止，同时调整接收窗大小以控制网络中的拥塞(例如，减小接收窗大小，使得在网络中较少请求的数据是待解决的)。可以根据公式来完成接收窗缩放，例如将接收窗大小基于估计的拥塞窗大小，该估计的拥塞窗大小将由传统TCP、RTT等来生成。在操作中，可以响应于连续地接收不具有缺失数据的数据分组来增大接收窗，然而还可以响应于检测到较多的缺失分组(例如，在预先确定的时间窗内)来减小接收窗。相应地，接收窗可以用于在不会在网络中引入显著的拥塞的情况下，按照适当的积极性水平来控制发送方行为。虽然接收缓冲区大小的变化可以实现为与接收窗调整相关联，但是根据本文的实施例而实现的接收窗调整可以不采用接收缓冲区大小的变化，而是操作为向发送方通知接收窗调整。为此目的，CM 122的扩展传输协议接收机可以向服务器130发送经调整的接收窗大小以实现期望的控制，而无需实现接收缓冲区大小的对应变化。

虽然上文所描述的TA 120的实施例适于使用扩展传输协议(例如，示例性实施例的xTCP)来提供对期望内容的片段或片段序列的增强的传送，但是可以由根据本文概念的传输加速器使用其它实现方式和/或技术来提供对内容的增强的传送。例如，TA 120的实施例可以包括：可以提供未修改的传输协议CM配置(例如，CM-yTCP)，其中CM使用在具有未修改的语义的TCP(在本文中被称为yTCP)之上的HTTP。在实施例的yTCP配置中，TCP的通过有线(over-the-wire)协议保持未修改，虽然CM适于窥探乱序的所接收的数据流并向RM传送乱序的所接收的数据流，并且继而RM可以向UA传送乱序的所接收的区段(如果UA被装备为处理乱序的数据传送的话)。通过CM窥探TCP栈的缓冲区并向RM传送TCP栈的缓冲区，其中TCP栈的缓冲区包括根据实施例的yTCP操作来乱序地发送的数据，如果仅丢失一区段，该区段将以一延迟到达RM，同时跟在其后的乱序的区段及时到达RM，则当这些乱序的区段到达RM时，可以从RM向UA传递这些区段。虽然这种实现yTCP的实施例可能自身经受普通的TCP拥塞控制，但是yTCP的实现方式不太可能扩大(inflate)网络拥塞以及因此自身的分组丢失概率。相应地，CM-yTCP配置可以用于(通过快速地向RM和/或UA提供乱序接收的数据，而不是等待在乱序接收的数据之前的缺失数据的到达)减小由于偶尔的分组丢失所引起的停滞概率而不会增加整体的接收速率。

在实施例的yTCP的实现方式中，CM 122的yTCP接收机适于窥探区段并向RM 121和UA 129传送区段，其中接收机已乱序接收这些区段，并且因此这些区段未被正常地乱序传送给UA 129。应当明白，在未修改的TCP操作中，如果发生分组丢失，则客户端通常不接收除了丢失的区段以外的任何数据，除非并直到该丢失的区段由发送方重传并由客户端接收。接收到的具有延迟的数据量会因此相当大。例如，如果按照2M比特/秒的速率接收数据并且RTT是200ms，则将在接收了近似40KB的乱序数据之后接收到重传的区段。该数据的丢失将导致传送具有延迟的该40KB的数据(例如，在前述的示例中，与单个延迟的区段相比，大约20倍的数据被延迟)。此外，在实践中，由于排队延迟，RTT通常将增长至秒的量级，并且因此单个分组丢失会使连接停滞非常长的时间。通过CM 122窥探包括所有接收的区段的TCP接收缓冲区并向RM 121传送这些区段(无论其是按顺序还是乱序接收的)而获得的信息可以用于实现用于减轻分组丢失的一个或多个技术。

可能与一个或多个其它技术相结合的yTCP操作的实现方式可以用于减轻前述的问题。例如，RM 121可以操作为针对每个片段请求来请求一些FEC数据。在操作中，RM 121可以假定可由RM处理的错误概率(例如，1％)并且请求FEC数据的量，该FEC数据的量有助于实现高的纠正概率(如果没有丢失较多数据的话)。另外地或替代地，RM 121可以根据历史信息来估计错误概率(例如，基于yTCP操作看出TCP传送中的洞来确定错误概率)。这种FEC数据可以用于恢复缺失的数据而不会不可接受地增加带宽使用。这种CM-yTCP可以有助于减少延迟的数据的量以及请求和发送的FEC数据的量两者。

虽然详细示出和描述了选定的方面，当时将明白的是，在不脱离如所附权利要求书所限定的、本公开内容的精神和范围的情况下，可在其中进行各种替换和更改。