用于在传输层中以信号形式发送请求加速的系统和方法

摘要

公开了适于通过使用用户代理(UA)信令来提供传输加速器操作的系统和方法。在根据实施例的操作中，传输加速器(TA)分析内容请求以确定内容请求是否包括要提供传输加速功能的指示。如果存在这样的指示，则TA进一步该分析内容请求以确定是否将提供传输加速功能。

说明书

相关申请的交叉引用

本申请要求于2014年9月30日提交的题为“SYSTEMS AND METHODS FOR USERAGENT SIGNALING REQUEST ACCELERATION BY TRANSPORT ACCELERATOR”的共同待决的美国临时专利申请号62/057,412的优先权，以及于2015年2月6日提交的题为“SYSTEMS ANDMETHODS FOR USER AGENT SIGNALING REQUEST ACCELERATION BY TRANSPORTACCELERATOR”的美国实用专利申请序列号14/616,233的优先权，其全部内容通过引用明确地并入本文。

背景技术

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

当前，许多类型的应用依赖于HTTP以用于上述内容传递。在许多这样的应用中，HTTP传输的性能对于用户对应用的体验来说是至关重要的。例如，直播(live)的流式传输具有可能阻碍视频流式传输客户端的性能的若干约束。两个约束特别突出。首先，媒体片段随着时间推移一个接一个地变得可用。该约束防止客户端连续下载大部分数据，但这反过来影响下载速率估计的准确性。由于大多数流式传输客户端以“请求-下载-估计”的循环来操作，所以当下载估计不准确时，内容下载通常不能很好地执行。第二，当观看直播的事件流时，用户通常不想遭受来自实际直播事件时间线的长延迟。这样的行为防止流式传输客户端建立大的缓冲器，但其反过来可能导致更多的重新缓冲。

如果流式传输客户端在传输控制协议(TCP)上操作(例如，与大多数基于HTTP的动态自适应流式传输(DASH)客户端一样)，则前述严格的直播事件时间线与典型的TCP行为矛盾，所述典型的TCP行为是当存在丢失或重新排序的分组时其变慢。内置的TCP拥塞控制机制加剧了直播流期间的重新缓冲效果，而直播事件的观众更有可能愿意跳过重新缓冲并跳到最新的事件时间线。

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

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

已经开发了用于使用对传输加速器的实现来关于对内容的传递提供加速的各种技术。这样的传输加速器实现可以例如操作以提供对数据的高速缓存、对数据请求的处理和/或对数据请求的响应等，以努力促进数据到客户端设备的加速传递。尽管在一些或甚至许多情况下提供数据到客户端设备的加快传递，但是在一些情况下，许多传输加速器实现仍然导致不期望的操作。例如，传输加速器的操作可能导致增加的网络拥塞、与通信协议或其一部分的不兼容性等。

传输加速器可以例如在系统框架(例如，由ANDROID移动设备操作系统提供的STAGEFRIGHT媒体播放器架构)中实现，以促进关于数个应用的传输加速操作。例如，操作系统(OS)可以提供系统框架，并由此例如通过使用应用编程接口(API)来提供诸如HTTP层事务、网络层事务、媒体回放引擎等某些较低级别功能以供应用使用。可以利用通常可用于在OS上操作的潜在大量应用的这种框架来类似地使得诸如传输加速器的请求和数据传递加速等功能类似地可用于利用框架服务的应用。

然而，一些应用可能不使用这种系统框架的功能。例如，某些应用可以实现它们自己的诸如HTTP层事务、网络事务、媒体回放等较低级功能，以便优化用于应用的操作的那些功能。例如，相对高的网络影响应用(例如，NETFLIX和YOUTUBE客户端)可以放弃(forego)对系统提供的框架(例如，STAGEFRIGHT)的使用，并且反过来实现它们自己的较低级别功能。因此，尽管需要更复杂的应用软件配置，但是这样的应用可以通过使用特别适于由特定应用使用的较低级别功能而受益于改进的或甚至更可预测的性能。

发明内容

根据本文的实施例，提供了一种用于传输加速请求通信的方法。所述方法包括：通过传输加速器(TA)经由所述TA的第一请求加速端口从第一用户代理(UA)接收内容请求，其中，所述内容请求包括对将通过内容服务器传递到所述UA的内容数据的请求。该方法还包括：分析所述内容请求以确定所述内容请求是否包括指示将关于所述内容请求提供传输加速功能的信令；以及至少部分地基于确定所述内容请求包括指示将提供传输加速功能的信令来执行关于所述内容请求的传输加速操作，其中，所述传输加速操作包括将所述内容请求细分(subdivide)为多个对内容的请求，以及通过所述TA控制从所述内容服务器请求所述内容，以向所述TA提供对所请求的内容数据的加速传递。

根据本文的另外实施例，提供了一种用于传输加速请求通信的装置。该装置包括用于传输加速器(TA)经由所述TA的第一请求加速端口从第一用户代理(UA)接收内容请求的单元，其中，所述内容请求包括对将通过内容服务器传递到所述UA的内容数据的请求。该装置还包括：用于分析所述内容请求以确定所述内容请求是否包括指示将关于所述内容请求提供传输加速功能的信令的单元；以及用于至少部分地基于确定所述内容请求包括指示将提供传输加速功能的信令来执行关于所述内容请求的传输加速操作的单元，其中，所述传输加速操作包括将所述内容请求细分为多个对内容的请求，以及通过所述TA控制从所述内容服务器请求所述内容，以向所述TA提供对所请求的内容数据的加速传递。

根据本文的另外实施例，提供了一种存储用于传输加速请求通信的计算机可执行代码的计算机可读介质，其中，所述计算机可读介质包括其上记录有程序代码的有形计算机可读介质。所述程序代码包括：用于通过传输加速器(TA)经由所述TA的第一请求加速端口从第一用户代理(UA)接收内容请求的程序代码，其中，所述内容请求包括对将通过内容服务器传递到所述UA的内容数据的请求。所述程序代码还包括：用于分析所述内容请求以确定所述内容请求是否包括指示将关于所述内容请求提供传输加速功能的信令的程序代码；以及用于至少部分地基于确定所述内容请求包括指示将提供传输加速功能的信令来执行关于所述内容请求的传输加速操作的程序代码，其中，所述传输加速操作包括将所述内容请求细分为多个对内容的请求，以及通过所述TA控制从所述内容服务器请求所述内容，以向所述TA提供对所请求的内容数据的加速传递。

根据本文的另外实施例，提供了一种用于传输加速请求通信的装置。该装置包括至少一个处理器和耦合到所述至少一个处理器的存储器。所述至少一个处理器被配置为：通过传输加速器(TA)经由所述TA的第一请求加速端口从第一用户代理(UA)接收内容请求，其中，所述内容请求包括对将通过内容服务器传递到所述UA的内容数据的请求。所述至少一个处理器还被配置为：分析所述内容请求以确定所述内容请求是否包括指示将关于所述内容请求提供传输加速功能的信令；以及至少部分地基于确定所述内容请求包括指示将提供传输加速功能的信令来执行关于所述内容请求的传输加速操作，其中，所述传输加速操作包括将所述内容请求细分为对内容的多个请求，以及通过所述TA控制从所述内容服务器请求所述内容，以向所述TA提供对所请求的内容数据的加速传递。

附图说明

图1显示了根据本公开内容的实施例的适于传输加速器操作的系统。

图2A显示了根据本公开内容的实施例，示出传输加速器控制逻辑单元的操作以提供传输加速器操作的高级流程图。

图2B显示了根据本公开内容的实施例，示出用于选择性地调用传输加速器逻辑单元的功能的操作的高级流程图。

具体实施方式

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

在本说明书中，术语“应用”还可以包括具有可执行内容的文件，例如：目标代码、脚本、字节代码、标记语言文件和补丁。另外，本文中所提及的“应用”还可以包括本质上不可执行的文件，例如可能需要被打开的文档或需要被访问的其它数据文件。

如本说明书中所使用的，术语“内容”可以包括具有视频、音频、视频和音频的组合的数据或者在一个或多个质量水平的其它数据，所述质量水平由比特率、分辨率或其它因素来确定。内容还可以包括可执行内容，例如：目标代码、脚本、字节代码、标记语言文件和补丁。另外，“内容”还可以包括本质上不可执行的文件，例如可能需要被打开的文档或需要被访问的其它数据文件。

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

如本说明书中所使用的，术语“流式传输内容”是指可以根据一个或多个标准从服务器设备发送并在用户设备处接收的内容，所述一个或多个标准使得能够实现对内容的实时传送或在一段时间上对内容的传送。流式传输内容标准的示例包括支持去交织的(或多个)信道的标准和不支持去交织的(或多个)信道的标准。

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

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

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

图1显示了根据本文的概念适配以通过通信网络提供对内容的传输的系统100的实施例，所述内容例如可以包括音频数据、视频数据、图像数据、文件数据等。因此，客户端设备110被显示为经由网络150与服务器130通信，根据本公开内容的概念，服务器130可以由此将存储在数据库140中的各种内容传送给客户端设备110。应当理解，尽管在图1中仅表示了单个客户端设备和单个服务器和数据库，但系统100可以包括任意或所有这样的设备中的多个。例如，服务器130可以包括服务器群中的服务器，在服务器群中，多个服务器可以集中地布置和/或以分布式配置来布置，以提供高水平的内容传送需求。或者，服务器130可以与传输加速器(TA)120共同位于一设备上(例如，直接通过I/O元件113而不是通过网络150连接到TA 120)，例如当一些或全部内容驻留于数据库140(高速缓存)(其共同位于该设备上并且通过服务器130被提供给TA 120)时。同样，用户可以拥有多个客户端设备和/或多个用户可以各自拥有一个或多个客户端设备，所述客户端设备中的任意一个或全部适用于根据本文概念的内容传送。

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

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

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

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

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

应当理解，虽然关于图1中所示的客户端设备110的实施例显示了UA的两个实例，但系统100的客户端设备可以包括任何数量的UA。例如，特定客户端设备配置可以包括单个UA，而另一客户端设备配置可以包括多个UA(即，两个或更多个)。

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

在提供前述增强的片段传递功能时，本文的实施例中的TA 120包括如本文所描述的架构组件和协议。例如，图1所示的实施例中的TA 120包括请求管理器(RM)121和一个或多个连接管理器(CM)122，其协作以提供各种增强的片段传递功能。RM 121可以操作为接收和响应来自UA 129a和129b的片段请求，细分所请求的片段以提供多个相应的较小数据请求(本文称为“块请求”，其中所请求的数据包括“块”)，以及将块请求引导至CM 122。因此，CM 122可以与RM 121对接(interface)以接收块请求，在网络150上发送对应于那些块请求的请求(例如，HTTP请求)，接收对其块请求的响应，并且将响应传送回RM 121，其中，由UA请求的片段由RM 121从接收的块解析并提供给请求UA。实施例中的CM 122的功能操作为决定何时请求由RM 121做出的块请求中的数据。

应当理解，所示实施例中的客户端设备110被显示为实现多接口架构，例如可以用于提供对一个或多个通信会话的同时多端口通信支持、关于通信会话的通信端口恢复等。具体地，TA 120被示为包括CM 122a-122d。相应地，I/O元件113被示为包括可操作用于有助于数据通信的多个接口，所述多个接口被显示为接口161a-161d。RM 121同样可以适于与多个不同的CM配置一起操作和/或与多于一个CM同时对接，例如以从CM 122a-122d中的两个或更多个CM请求相同片段或片段序列的数据块。每个这样的CM可以例如支持不同的网络接口(例如，第一CM可以具有至设备上高速缓存的本地接口，第二CM可以使用至3G网络接口的HTTP/TCP连接，第三CM可以使用至4G/LTE网络接口的HTTP/TCP连接，第四CM可以使用至WiFi网络接口的HTTP/TCP连接等)。相应地，I/O元件113的接口可以包括可根据数个通信协议操作的各种配置。例如，接口161a-161d可以分别提供至3G网络、4G/LTE网络、不同的4G/LTE网络和WiFi通信的接口，其中TA 120使用例如传输协议(例如HTTP/TCP、HTTP/xTCP、或使用用户数据报协议(UDP)构建的协议)来在这些接口上传送数据。每个这样的接口可以可操作用于提供用于实现通信会话(例如经由相关联的通信链路)的一个或多个通信端口，所述通信链路例如显示为将I/O元件113的接口与网络150的组件进行链接的连接151a-151d。

应当理解，根据本文的实施例使用的接口的数量和配置不限于所示出的。例如，根据传输加速器的实施例，可以使用更少或更多的接口。另外，一个或多个这样的接口可以提供除了通过所示的网络链路(例如，连接151a-151d)之外的数据通信和/或与除了网络组件(例如，服务器130)之外的设备的数据通信。

除了形成应用、操作系统、文件、电子文档、内容等的上述代码段，存储器112还可以包括或以其它方式提供由客户端设备110的功能块使用的各种寄存器、缓冲器和存储单元。例如，存储器112可以包括播出(play-out)缓冲器，所述播出缓冲器例如可以提供用于排存(spooling)来自服务器130的流式传输的片段中的数据并由客户端设备110回放的先入先出(FIFO)存储器。

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

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

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

应当理解，根据本文的实施例使用的接口的数量和配置不限于图1中所示出的。例如，根据传输加速器的实施例，可以使用更少或更多的接口。此外，一个或多个这样的接口可以提供除了通过所显示的网络链路(例如，连接151和152)之外的数据通信，和/或与除了网络组件(例如，服务器130)之外的设备的数据通信。

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

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

网络150可以是无线网络、有线网络、广域网(WAN)、局域网(LAN)或适用于如本文所述的对内容的传送的任何其它网络。网络150可以例如包括3G网络、4G/LTE网络、WiFi网络等以及其组合。此外，尽管被示出为单个网络云，但是应当理解，如根据实施例所使用的网络150可以包括不同的或单独的网络，其中的任何或全部网络可以包括相同或不同的网络技术，以提供客户端设备110和服务器130之间的通信。在实施例中，网络150可以包括互联网的至少一部分。客户端设备110可以通过双向连接(例如由网络连接151表示)连接到网络150。或者，客户端设备110可以经由单向连接来连接，所述单向连接例如由启用多媒体广播多媒体系统(MBMS)的网络提供的连接(例如，连接151、152，并且网络150可以包括MBMS网络，服务器130可以包括广播多播服务中心(BS-MC)服务器)。连接可以是有线连接或者可以是无线连接。在实施例中，连接151可以包括无线连接，例如蜂窝3G连接(例如，由接口161a提供的连接151a)、蜂窝4G连接(例如，分别由接口161b和161c提供的连接151b和151c)、无线保真(WiFi)连接(例如，由接口161d提供的连接151d)、蓝牙连接或另一无线连接。服务器130可以在双向连接(例如由连接152表示)上连接到网络150。服务器130可以在单向连接(例如，使用如在3GPP TS.26.346或ATSC 3.0网络中描述的协议和服务的MBMS网络)上连接到网络150。连接可以是有线连接或者可以是无线连接。

图1所示的实施例中的客户端设备110系统包括TA 120，其可操作用于提供对由UA请求的期望内容的片段或片段序列的增强的传递，所述UA例如UA 129a和129b中的任一个或两者。例如，如上所讨论的，所示实施例的TA 120包括RM和CM功能，其协作以提供可操作用于促进向客户端设备110的UA加快传递数据的各种增强的片段传递功能。然而，传统上提供的传输加速功能可能不可用于UA的所有配置或所有情况。因此，本文的实施例适于促进由各种UA对传输加速器操作的请求。例如，在UA向TA提供关于期望关于特定内容或特定内容请求的传输加速的信令的情况下，TA可以检测该信令并响应于此来提供传输加速功能。然而，由于并非所有内容请求都可以受益于传输加速器操作，因此实施例响应于各种UA的这种请求来选择性地实现传输加速器操作(例如，由此选择性地绕过(bypass)传输加速器操作的一个或多个功能，或者传输加速器操作的一个或多个功能不基于特定准则)。例如，尽管检测到来自UA的信令，所述信令请求关于特定内容或特定内容期望传输加速，但是TA可以操作为确定传输加速功能的实现是否实际上是响应于以信号形式发送的请求而实现的。

为了帮助理解本文的概念，UA 129a和129b包括具有可由或不由根据实施例适配的TA 120提供的不同配置的UA。如从下面的讨论将理解的，UA 129包括尽管不利用系统框架127的资源或功能但仍适于利用TA 120的功能的应用或其它用户代理。相比之下，UA129b包括利用系统框架127的功能的应用或其它用户代理，并且通过该交互，还可以被提供TA 120的功能。

具体地，UA 129b适于经由系统框架127传输对内容的请求，其中系统框架127提供某些低级别功能以供各种UA(例如，通过链路128c供UA 129b)使用。例如，系统框架127可以包括由ANDROID移动设备操作系统提供的STAGEFRIGHT媒体播放器架构，其经由公布的API向UA提供记录的功能(例如，HTTP层事务、网络层事务、媒体回放引擎等)。因此，实施例中的TA 120可以适于与系统框架127互操作并且提供传输加速功能以供实现系统框架127API的应用来使用。例如，系统框架127可以经由链路128d与TA 120交互，以向TA 120提供由UA129b做出的用于传输加速操作的内容请求。例如，TA 120可以提供与链路128d相关联的“总是加速”端口，由此经由链路128d接收的内容请求被知晓是通过系统框架127提供的，并因此经受根据本文描述的概念的传输加速操作。

然而，UA 129a可以适于实现其自己的低级别功能或服务(例如，HTTP层事务、网络事务、媒体回放等)，例如以优化用于UA 129a的操作的那些功能，否则所述低级别功能或服务可以通过系统框架127来获得。例如，UA 129a可以包括相对高的网络影响应用(例如，NETFLIX或YOUTUBE客户端)，其不是利用系统框架127，而是实现其自己的HTTP层、网络层、媒体回放引擎等。因此，UA 129a可以操作为经由链路128a与由I/O元件113提供的一个或多个端口直接交互，以与服务器130通信，从而绕过由TA 120提供的传输加速器功能。

尽管UA 129a可以适于自身提供也可通过系统框架127获得的某些功能，但是UA129a仍然可以受益于其它功能(例如TA 120的传输加速功能)的可用性和实现。例如，在UA的开发者的专业领域之外，传输加速功能的实现可能是复杂的，或者否则不存在直接包括在UA 129a内的理想机会。因此，尽管存在UA 129a可能不使自身利用系统框架127的功能这一现实，但是期望向UA 129a提供对本文实施例中的TA 120的传输加速功能的访问。

图1中所示的实施例中的UA 129a适于促进以下操作：其中，TA 120的传输加速器功能是关于由UA做出的内容请求来实现的。例如，UA 129a可以适于经由链路128b与TA 120交互，以向TA 120提供由UA 129a做出的对传输加速操作的内容请求。实施例中的UA 129a适于例如通过将内容请求直接引导到I/O元件113的端口从而绕过TA 120的传输加速功能，或通过将内容请求引导到TA 120的端口以调用TA 120的传输加速功能，来选择性地实现传输加速。例如，TA 120可以提供与链路128b相关联的“选择性加速”端口，由此UA 129a可以将期望被提供传输加速功能的请求经由链路128b引导到TA 120选择性加速端口。经由链路128b接收的内容请求因此经受根据本文所描述的概念的传输加速操作。应当理解，对UA进行修改以使得其根据本文的概念对传输加速功能的使用可以是相对小的。例如，可以向UA提供以下逻辑：用于确定是否关于特定操作、内容等期望传输加速的逻辑，和/或用于将适当的请求引导到传输加速器端口(例如，TA 120的实施例中的选择性加速端口)以关于由UA做出的请求提供传输加速服务的逻辑。

根据前述，在根据实施例的操作中，UA 129a适于将期望传输加速功能的内容请求引导到与TA 120相关联的端口(例如，经由链路128b)。例如，UA 129a的逻辑可以确定所请求的内容包括期望传输加速操作的大文件、特定类型的媒体、流媒体内容等(例如，已知或预期提供下载性能改进)。因此，UA 129a可以操作以经由链路128b选择性地将与其相关联的内容请求引导到TA 120。根据实施例，其它内容请求(例如对相对小的文件的内容请求，对针对其的传输加速是不切实际的或通常不导致改进的性能等的特定类型的媒体的内容请求)可以经由链路128a被引导到I/O元件113的端口，从而绕过TA 120。

为了有助于根据本文的实施例的传输加速操作，所做出的到TA 120的选择性加速端口的内容请求包括以下信令，所述信令指示请求接收传输加速操作是期望的，以提供在促进传输加速操作中有用的信息等等。例如，实施例中的UA 129a可以操作为将报头信息(例如，在本文中，对传输加速器操作来说唯一的HTTP报头)与内容请求包括在一起，其指示内容请求被提供传输加速器功能的请求。这样的报头信息可以另外包括用于以期望的或最佳的方式向UA提供对内容的传递的数据，例如优先级信息、定时信息、调度信息、比特率信息、文件大小信息等。

在根据实施例的操作中，关于在TA 120的选择性加速端口处接收到的内容请求的默认行为不是提供传输加速功能，而是替代地在没有加速处理的情况下传递那些请求(例如，将该内容请求提供给I/O元件113的端口)。这种默认行为有助于以下UA，所述UA不想利用系统框架127并且也不希望加速特定请求，其在不具有特殊报头的情况下向TA 120的选择性加速端口发送请求，并因此绕过针对该请求的传输加速操作。如果例如在UA 129a向TA120发送的内容请求中不存在指示内容请求将被加速的特殊报头，则内容请求将不会被实施例中的TA 120加速。因此，UA可以使用信令，例如可以使用前述特殊报头来提供的信令，以指示内容请求将被提供传输加速功能，以及提供传输加速器可以在分割该请求并调度该请求时使用的另外的元信息。在将内容请求转发到内容服务器之前，该信令(例如，特殊报头)可以由实施例中的传输加速器从内容请求中移除。该信令可以以多种合适方式中的任一种被包括在内容请求中，例如，信令可以是HTTP请求的特殊报头、可以被包括作为HTTP请求的报头中的字段值、可以被包括在HTTP请求的URI或URL的查询字符串中的一个或多个参数中、和/或可以被包括作为内容请求的任何其它合适的特征。

前述信令可以是双向的，例如以包括从TA 120到UA 129a的关于所请求的传输加速器功能的实现的信令。例如，实施例中的TA 120可以操作为在对UA 129a的一个或多个响应中包括报头(例如，在本文中对传输加速器操作来说唯一的HTTP报头)，所述报头用于指示内容请求是否已经被加速，用于提供关于所提供的加速的细节的信息(例如，以有助于UA的兼容操作或优化操作)等。

在实现上述传输加速器信令时，本文中的实施例可以适于提供如本文所述的携带信息的UA/TA特殊请求报头(本文中称为“QC-STA报头”)。因为实施例的QC-STA报头仅与UA-TA连接相关，所以可以在由根据本文的实施例的传输加速器转发该内容请求之前移除该QC-STA报头。当然，QC-STA报头或其它信令可以被配置为使得其可以被忽略，并且因此其移除可以是可选的。具有将实施例中的QC-STA报头包括在其中的HTTP请求报头的示例是“连接：关闭，QC-STA”。根据本文概念的QC-STA报头可以包括具有分隔符的键(key)-值对的列表(例如，在HTTP报头中常用的分隔符“；”)。每个键值对可以例如以格式“key＝value”来提供。实施例中的QC-STA报头的一般形式可以包括“QC-STA：key1＝value1；key2＝value2；...；keyN＝valueN；”，其中报头令牌字符串本身以分隔符“；”结束。在根据实施例的操作中，如果QC-STA报头不存在于内容请求中，则内容请求将不被传输加速器加速。

包括在QC-STA报头中的键可以提供各种不同类型的信息。例如，关于QC-STA报头使用的键可以包括但不限于fileType、priority、streamingBitRate、streamingPlaybackBuffer和requestExpirationTime。键中的特定键可以包括另外的数据或具有与其相关联的另外数据。例如，根据实施例，可以为所有fileType提供approxFileSize信息。然而，应当理解，在实施例的QC-STA报头中不需要存在任何键。也就是说，UA可以发送具有其中没有令牌的QC-STA报头的内容请求，以便使用默认参数/设置来发起传输加速功能。然而，对于到本文实施例中的TA 120的选择性加速端口的内容请求，可以根据需要或适当地使用所有上述键。

下面的表1提供了可以关于本文实施例中的QC-STA报头使用的键、值的类型、和键的可能值的示例。

通过将前述键进一步解释为可以根据本文的QC-STA报头的实施例来使用，“fileType”键可以包括关于内容请求所涉及的特定类型的文件的信息。该信息可以由传输加速器用来确定传输加速器功能的实现是实际的还是有利于与例如内容请求相关联地使用。另外地或替代地，这种信息可以由传输加速器用于确定如何实现加速的一个或多个方面(例如，确定块大小、比特率、误差校正等)。

“requestPriority”键可以提供关于UA内的给定内容请求的优先级的信息。在根据实施例的操作中，存在优先级到底层或较低级别通信层的一致映射。例如，实施例可以操作以将该优先级信息传递到低级别网络库(例如，CHROMIUM)，以便建立与由UA做出的内容请求一致的块请求优先级。另外地或替代地，实施例可以在传输加速器内实现调度算法，所述调度算法根据随内容请求一起提供的优先级信息来调度内容请求的块请求。

“streamingBitRate”键可以提供指示客户端期望播放或处理所请求的数据的速率的信息。因此，根据实施例来指定流速率可以促进传输加速器操作为向竞争请求流分配适当的带宽份额，这导致向满足所指示的播放或数据处理速率的UA的数据传递。

“streamingPlaybackBuffer”键可以指示UA的当前回放缓冲器的长度。实施例的streamingPlaybackBuffer键可以由传输加速器用于确定如何实现加速的一个或多个方面(例如，确定块大小、比特率、纠错等)。例如，回放缓冲器的大小可以由TA 120用来确定要在不久的将来下载的数据量(例如，要发出的块请求的大小和数量)。

“requestExpirationTime”键可以指示内容请求将被完成的时间。目标时间可以例如以秒为单位给出，这是因为可以允许具有分数秒的Unix纪元。在根据实施例的操作中，时间戳可以关于所讨论的设备的系统时间，其中，用于该实现的系统时间不需要是正确的，以允许准确的到期时间(例如，其中TA 120和UA 129a使用相同的时钟，实际的到期将在期望的时间点发生)。在到达到期时间时，实施例的传输加速器可以操作以取消内容请求(例如，此后接收的任何内容数据可能是不可用的或不期望的，因为其不合时宜)。

“approxFileSize”键可以指示正在请求的资源的近似文件大小。例如，这种信息可以由传输加速器用来选择要发出的适当数量的块请求(例如，在知晓精确的文件大小之前)。作为根据实施例的使用近似文件大小信息的示例，如果块大小是C，则TA 120的RM 121可以在接收第一响应之前发出max(floor(approxFileSize/C)，1)个块请求，以实际确定文件大小并发出进一步的请求。

“preferredNetworkInterface”键可以指示在特定网络接口(例如，WiFi)上发送请求的偏好。例如，由于蜂窝数据计划约束，对WiFi网络接口的使用(当可用时)可能优于蜂窝接口。可以例如通过UA到知道可操作的接口的连接管理器的访问来促进这种对优选网络接口的选择。

“fastStartSize”键可以由UA用来指示期望提供对所请求内容的传递的快速启动。作为响应，传输加速器可以使用其最大努力来满足该请求，例如使用多个接口来下载该初始量的内容，并且随后切换到正常的取回操作，这例如从使用多个接口切换到使用一个接口，以提取所请求的内容的剩余部分。

“useHTTPS”键可以由UA用来指示传输加速器将使用安全通信路径(例如，如HTTPS协议所提供的)来发送该内容请求。

使用键、值的类型和键的可能值的前述示例，具有键及其值的示例性QC-STA报头可以表现为：

QC-STA：fileType＝“streaming”；priority＝1；streamingBitRate＝7500；streamingPlaybackBuffer＝10000；approxFileSize＝300000；

preferredNetworkInterface＝“WiFi”；fastStartSize＝1000；

应当理解，上述提供了可以根据本文实施例实现的信令的示例，并因此，特定实现可以实现信令以提供根据本文的概念的各种不同信息。

作为可以根据实施例来使用的信令的另一示例，下面的表2中阐述的键、值的类型和键的可能值可以关于根据本文中的概念的QC-STA报头来使用。

通过对可以根据本文的QC-STA报头的实施例来使用的前述键的进一步说明，“uniqueUAinstanceID”键可以促进UA在若干连接上向传输加速器做出请求的操作。例如，uniqueUAinstanceID键可以提供先验信息，使得传输加速器可以知道哪些连接属于哪个UA。这样的信息可以由实施例的中TA 120使用以给予传输加速器在UA之间公平的能力。

以某种方式对实施例的“uniqueUAinstanceID”键进行选择，使得其是唯一的。例如，UA可以创建128位随机数并使用该随机数的十六进制符号作为其唯一ID。或者，实施例可以定义用于创建唯一ID的约定，所述约定保证所述唯一ID的唯一性。例如，该唯一ID可以是过程PID及其开始时间的组合，由此，这样的组合通常在任何给定主机上的所有过程中是唯一的。

实施例中的“UAP优先级”键是建立针对UA的优先级。根据实施例实现的可能优先级值的集合被保持在故意低的数量(例如，从0到7的值的范围的8个不同设置)，例如以有助于跨越不同UA的对优先级值的一致使用。根据一些实施例，优先级键的较高值指示较高优先级。在操作中，较高优先级UA的请求可以具有优惠对待，而无论给予各个流的优先级值如何。根据此处的实施例，在相同UA的流上而不是跨越UA来比较各个流的优先级值。例如，一个UA可以操作以将其所有内容请求保持在默认值2^31，而另一个(例如，直播流式传输客户端)可以具有随时间推移潜在地使用所有2^32个可能值的精细方案，这不应该由于在根据实施例的操作中分配优先级的不同方式而导致一个UA主导另一个UA。然而，在一些实施例中，例如，如果UA具有用于分配优先级值的类似算法和/或UA已经被设计为一起工作，则可以在跨越多个UA的流上比较各个流的优先级值。

虽然预期许多UA可能不改变其默认优先级(例如，UAPriority＝3)，但是各种流仍可以利用不同的优先级。例如，非交互式软件更新过程可能通过向自身分配较低的优先级(例如，UAPriority＝0)来移出潜在地运行流式传输客户端的方式。

在根据实施例的操作中，UA可以通过在新的内容请求中提供新值来更新与其相关联的优先级。其中UA可以操作以更新其优先级的应用的一个示例是具有非常大的缓冲器的视频流式传输客户端(例如，可操作用于提前下载整个电影的GOOGLE PLAY)。当缓冲器为低时，UA可以指示高优先级，例如以增加可用的缓冲数据，但是一旦缓冲器水平达到某个门限(例如，若干分钟的缓冲数据)，则降低优先级。如果缓冲器变低，则UA可以再次增加其优先级。然而，应当理解，这样的优先级更新会引入竞争条件的风险。为了避免竞争条件，实施例中的UA可以在其已经接收到对先前内容请求的至少部分响应(其在此处更新了其请求优先级)之后更新其优先级。

“uniqueStreamID”键可以提供内容请求所属于的流的标识。具有相同唯一流ID的内容请求可以被认为属于相同流，并且因此可以根据实施例在键之间共享一个或多个属性。在根据实施例的操作中，流ID仅需要在做出内容请求的UA内是唯一的(例如，传输加速器可以通过其ID和与其相关联的UA ID来标识流)。

根据实施例，具有显式流标识符有助于UA针对单个流而使用到传输加速器的若干连接，其中该传输加速器可能仍然知道该连接的什么集合形成该流。这种配置在各种情况下可能是有用的。例如，在UA包括DASH客户端的情况下，可以针对音频和视频实现单独的流。如果UA使用网络库(例如，CHROMIUM堆栈)，则从UA到传输加速器的连接可能不忠实地表示流(例如，任何连接上的任何内容请求可能属于两个流中的任一个)。因此，根据本文的概念操作的DASH客户端可以用流标识符来标记其内容请求，从而使得传输加速器能够针对不同流来正确地区分块请求的优先级。

“streamPriority”键可以为流提供优先级值(例如，在0到2^32-1的范围内)。UA和传输加速器可以关于较小的优先级值集合来使用与上面描述的算法类似的算法，所述算法具有较大范围的流优先级。在根据实施例的操作中，关于相同UA的流，传输加速器在处理来自具有较低优先级的流的内容请求之前处理来自具有较高优先级的流的内容请求。streamPriority值可以针对做出内容请求的流而保留在原位置，直到其在后续内容请求中被更新。当streamPriority值被更新时，可以认为其是针对整个流来改变的，而不是针对在优先级改变之前已经发出的流的内容请求而改变的。

“streamBitRate”键可以指示针对做出内容请求的流应当假定的比特率(例如，以Kbps为单位)。这样的比特率信息可以由传输加速器用来实现令人满意的带宽共享策略，例如在不会在另一UA处缺乏数据传输的情况下有助于在UA处促进期望的性能。在根据实施例的操作中，对于给定流，streamBitRate可以保持设置，直到在针对同一流的后续内容请求中被替换为新值。可以使用预定比特率值(例如，-1)来清除由实施例的streamBitRate键提供的比特率“提示”。

“streamPlaybackBuffer”键可以指示当前在流中的重放缓冲器的量(例如，以毫秒为单位)。实施例中的streamPlaybackBuffer键可以由传输加速器用于确定如何实现加速的一个或多个方面(例如，确定块大小、比特率、纠错等)。例如，当streamPlaybackBuffer很大时，传输加速器可以请求更大尺寸块中的数据以减少上行链路业务和服务器负载。对于小的streamPlaybackBuffer，传输加速器可以选择不请求更大尺寸块中的数据，因为这增加了在这种情况下的排头阻塞(head-of-line blocking)的风险(例如，延迟的块可能导致流被中断)。一些传输加速器实现可以将X的streamPlaybackBuffer值视为与将requestSoftExpirationTime设置为X+T的请求大致相同，其中T是请求由UA接收的时间。

“requestExpirationTime”键可以提供内容请求将到期的时间，并且因此提供UA不再有兴趣接收对内容请求的任何响应的时间。当内容请求到期并且不能及时完成时，实施例中的传输加速器可以例如关闭到UA的连接。

“requestSoftExpirationTime”键可以提供软到期时间，传输加速器通过该到期时间来尝试接收对内容请求的响应。在根据实施例的操作中，如果错过了requestSoftExpirationTime最后期限，则传输加速器可能例如不导致内容请求被丢弃。例如，内容可以继续由传输加速器提取，由此，除了传输加速器可能已经实现其最大努力以在requestSoftExpirationTime到期之前获得所请求的内容，一切都如同不存在与内容请求相关联的到期时间。在根据实施例的操作中，传输加速器可以利用这种软到期时间来决定适当的请求策略。例如，如果传输加速器可能请求FEC修复数据，则传输加速器可以操作以针对即将软到期的内容请求来请求大量的FEC数据，这是因为如果分组丢失发生的话(其延迟单个组块请求)这些内容请求否则将容易错过最后期限。然而，对于将来远没有软到期的其它内容请求，传输加速器可以操作以针对那些内容请求来请求较少的FEC数据或不请求FEC数据，因为在那些情况下，数据重传可以足够快地起作用，从而避免将带宽用于不必要的FEC开销。根据实施例使用的特定软到期时间可以随请求先决条件而改变，如下面进一步讨论的。

实施例中的requestSoftExpirationTime键的软到期时间可以另外地或替代地关于各种其它算法来使用：例如，传输加速器可以取消并重新发出看似被卡住的块请求。因此，当相关内容请求的软到期时间很快时，传输加速器可以积极地采用这种取消和重新发布块请求，而如果到期时间在远的将来，则可能更宽松。

“requestUniqueID”键可以提供内容请求的唯一标识。可以例如将这样的请求ID选择为在所讨论的UA内并且不仅仅在一个UA流内是唯一的(例如，不是跨越UA)。可以根据实施例来提供唯一ID，以使UA能够参考其稍后发布的特定内容请求，以例如关于下面讨论的requestPrerequisites键来使用。

“requestPrerequisites”键可以提供作为特定内容请求的先决条件的请求ID的分隔列表。例如，requestPrerequsites键可以包括作为正被发出的内容请求的先决条件的请求ID的逗号分隔列表。在视频流式传输应用中，例如，对片段B(其不以I帧开始，并且不能独立解码，但只能利用前面的片段A解码)的请求可以使得对片断A的请求是对片段B的请求的先决条件，从而向传输加速器指示在片段B之前需要片段A。使用这种请求先决条件的另一示例是可扩展高效视频编码(SHEVC)视频流式传输应用，其中对基本层的请求可以是对第一增强层的请求的先决条件，等等。

应当理解，可以根据本文中的实施例来将先决信息用于多个目的。例如，如以上示例中所示，可以利用先决信息来传输流内的各个内容请求的优选排序。例如，客户端可以实现类似HTTP的对请求的顺序处理，这可以通过使每个请求取决于其前者来实现。使用诸如流优先级等其它信息可能不能实现相同的目的，因为这样的其它信息可能不与单个内容请求相关(例如，流优先级对整个流而不是单个请求起作用)。DASH客户端可以例如想要具有视频请求的流。如果客户端使用不支持HTTP流水线的HTTP库，但是客户端本身发出在时间上重叠的请求，则传输加速器可以在不同的TCP连接上接收对不同流的请求。根据本文的实施例提供的请求先决条件可以用于通知传输加速器如何将这些请求相对于彼此进行排序，从而避免需要缓冲和重新排序客户端中的潜在无界的数据量。用于解决这个问题的替代技术可以除了流优先级和UA优先级之外还提供请求优先级，由此，对于该应用来说，请求依赖性将不是必需的。

可以利用实施例中的先决信息的另一个目的是提供给传输加速器关于如果不能满足一个或多个硬或软到期时间时如何进行动作的信息。在根据实施例的操作中，硬到期的行为可以不同于软到期的行为。

如果请求A是请求B(直接地或间接地)的先决条件，并且请求A经受硬到期，则根据实施例，即使请求B具有较晚的到期时间(或根本没有到期时间)，请求A的硬到期时间的到期会使得请求B的到期时间也到期。可以实现上述关系，这是因为如果达到请求A的硬到期时间并且请求A不可用，则请求A将永远不可用。由于在该示例中将永远不可用的请求A是请求B的先决条件，则即使请求B在某个将来点可用，其也将是无用的。

上述情况可能发生的示例是关于SHEVC直播视频播放器。SHEVC解码器可以在规定时间(例如，其接收下一秒的视频数据的每秒)接收下一个视频片断(例如具有数个增强层的基本层)，以便在其后200ms播放。因此，给予播放器的数据是基本层和数个增强层。然而，存在一个约束，即每秒最多具有与在前一次将视频数据发送到解码器时使用的增强层一样多的增强层。对此进行重复，直到下一个完整刷新段到来，在该完整刷新段到来的点处再次可以给解码器任意数量的层(例如，每第5个段可以是这样的刷新)。流式传输模块可以请求基本层B1，并且在第1.2秒播放增强层E1，并且因此将硬到期时间设置为1。然后，流模块可以请求基本层B2和增强层E2，在2.2秒播放，并因此这些的硬到期时间设置为2.0。请求依赖性可以用于向传输加速器传达E2在没有E1的情况下是无用的，并且如果没有及时接收到E1，则传输加速器不应获取E2。这可以根据本文中的实施例通过取决于E1标记E2来实现(应当理解，在发出对E2的请求时，可能不知道E1是否将成功)。

这样的请求依赖性不仅对于硬到期有用，如前述示例所示，而且还与软到期相结合使用。作为关于软到期的请求依赖性的效用的示例，UA可能已经发出了两个请求A和B，其中请求A在请求B的软到期时间之前具有软到期时间。其中请求B取决于请求A，如果传输加速器未能通过请求A的软到期时间来下载请求A，则其仍然可以尝试与请求B一起完成请求A(例如，通过请求B的软到期时间，因为只有那时其才满足请求B的软到期截止日期)。更一般地说，用于实施例的传输加速器内的请求A的实际有效软到期时间可以是请求A的标记软到期时间及其直接和间接相关请求(例如，上述示例中的请求B)的标记软到期时间中的最小值。

为了进一步说明关于软到期的请求依赖性的使用，再次考虑SHEVC视频客户端。在时间1，UA可以播放段1、或者仅基本层B1、或者基本层和增强层的组合B1+E1。因此，可以发出对B1的请求，其具有软到期时间1，以及发出对E1的另一请求，其也在时间1软到期，并且B1声明为E1的先决条件。在时间2，UA可以播放段2、或者仅基本层B2、或者基本层和增强层的组合B2+E2。因此，可以发出对B2的请求，其具有软到期时间2，以及发出对E2的另一个请求，其也具有软到期时间2，B2声明为具有B1作为先决条件，而E2声明为具有B2和E1两者作为先决条件的E2(例如，在该示例中，E2需要B2和E1两者以便可以播放)。当在时间1接收到B1而不是E1时，播放器可以在不具有增强层E1的时间1播放基本层B1。因此，实施例中的传输加速器可以尝试通过时间2来下载E1、B2和E2的全部，因为所有的有效软到期时间现在是2。如果传输加速器成功地下载E1、B2和E2的全部，则播放器可能能够在时间2播放B2+E2的组合，因为正确解码这些层的所有先决条件都是可用的。

软到期时间的示例与硬到期时间的先前示例之间的差异在于，在硬到期示例中，假定解码器不能“赶上”回放时间(例如，播放器只能利用它及时接收到的任何层)。另一方面，在软到期示例中，假设在请求的软到期时间之后接收的该请求，其仍然可以用于解码相关请求(例如，即使在播放本身没有及时接收到E1，只要E1和E2在E2的播出时间不久前接收到，则E1就可以用于解码E2)。

应当理解，上面表2中所示的示例性信令以几种方式不同于表1的信令。一个显着的区别是在表2的信令中明确地提供了流的概念。许多属性与流相关而不是与单独的请求相关，并因此可以基于每个流来设置所述属性。例如，相对于单个短的请求，可能难以准确地设置比特率，但是相对于请求的流来执行可能更容易并且更有意义。

在针对表2的信令来提供的另一差异中，内容请求可以“柔和地”到期，由此到期时间不使内容请求无效。已经将可选的请求依赖性信息添加作为表2的信令中的另一个差异。这样的依赖性信息可以例如对于视频流式传输应用是有用的。

根据实施例，与表1中的示例性信令相比，以下键可以由表2的示例中提供的信令中的不同键替换或替代：streamingBitrate(由streamBitrate替代)和streamingPlaybackBuffer(由streamPlaybackBuffer)。表1的示例性信令的requestPriority键可以由实施例的表2中的示例性信令的streamPriority键替换或者另外使用。

尽管已经参考由UA向传输加速器提供的信令来描述了前述信令示例，但是关于本文中的实施例的传输加速器功能实现的信令包括从传输加速器到UA的信令。例如，实施例的TA 120可以在到UA 129a的一个或多个响应中包括指示根据本文的概念的各种信令的特殊响应报头(本文被称为“QC-STA响应报头”)。QC-STA响应报头的形式可以与内容请求的QC-STA报头的形式相同，如上所述。

下面的表3提供了可以关于本文的实施例的QC-STA响应报头使用的键、值的类型和键的可能值的示例。

作为可以根据本文的QC-STA响应报头的实施例使用的前述键的进一步说明，“requestAccelerated”键可以指示内容请求是否正在加速。UA可以利用这样的信息来“学习”哪些请求可以或可以不导致加速，以针对所请求的数据的加速/非加速传递来调整一个或多个属性以用于适当或优化的操作。

“requestEstimatedReceiveRate”键可以指示可以向做出了内容请求的服务器实现的速率的估计(例如，当请求足够大量的数据时)。例如，自适应流式传输客户端可以利用该信息来决定要选择用于回放的好的表示。在根据实施例的操作中，传输加速器可以基于其过去在该服务器上能够实现的速率的历史来计算对这种接收速率的估计。另外地或替代地，传输加速器可以使用在正在使用的网络接口上可实现的速率的估计。因此，可以根据具有关于可实现速率的历史信息的实施例来获得这样的估计。

“numberOfSupportedPriorities”键可以用于指示传输加速器支持的不同优先级值的数量。这种信息可以由UA用于调整分配给其内容请求的优先级以落入由传输加速器支持的范围内，从而确保关于每个这样的内容请求的适当的相对优先级处理。

“usedHTTPS”键可以用于指示传输加速器是否关于内容请求成功地建立了到内容服务器的安全链路。例如，UA可以选择向I/O元件113的端口发送内容请求，而不是向TA 120的选择性加速端口发送内容请求，其中传输加速器报告其在建立安全通信中没有成功，例如尝试直接通过I/O元件113建立安全通信。

已经提供了可以在UA和传输加速器之间提供的各种信令的示例，所述信令用于根据本文的概念提供对由UA请求的期望内容的片段或片段的序列的增强传递，关于对根据本文实施例的这种信令的示例性使用的进一步细节在下面描述。然而，应当理解，所提供的示例不是根据本文的概念对这种信令的利用的穷举。

在利用诸如由前述的streamingBitRate和/或streamBitRate键提供的比特率信息时，TA 120的调度算法可以适于调度块请求以允许公平地共享不同的比特率流(例如，400Kbps的流可以接收大约是100Kbps流的4倍的块请求)。因此，这样的调度算法可以限制给定流的比特率，从而给予较低优先级流以获得一些带宽的机会。

诸如由requestExpirationTime和requestSoftExpirationTime键提供的上述到期时间信息可以由实施例中的TA 120使用以根据以下算法中的一个或多个来调度块请求。传输加速器块请求限制算法可以例如在低延迟直播流式传输情形中使用。根据实施例来利用这种算法的背后的思想是，如果已知内容请求在某个时间Te到期，则可能有利的是在Te之前的短时间内停止针对该内容请求发布新的块请求，这是因为对块请求的响应太接近Te从而不太可能由时间Te返回。对这种算法的实现的效果是传输加速器然后可以在到期时间之前不久继续处理其它内容请求，从而导致较少浪费针对将要到期的内容请求的块请求。

这样的传输加速器块请求限制算法可以根据以下表达：

令T为当前时间；

令Te是正在考虑的UA请求的到期时间；

令Tstart是从发出块请求到接收到响应开始(这是对包括排队延迟的往返时间(RTT)的估计)的平均时间；

令Tend是从块请求发出时间直到块响应完成的平均时间(可以测量Tstart和Tend，例如使用RM 121内的指数加权移动平均(EWMA)估计器)；

令cs和ce是配置常数；

如果T+cs*Tstart+ce*Tend>＝Te，则不对给定的UA内容请求发出任何进一步的块请求。

在前述示例中，cs和ce通常可以被选择为使得：cs，ce>＝0并且cs+ce＝1。针对cs和ce的一些可能的选择在下面的表4中阐述。

在前述传输加速器块请求限制算法的变型中，F(t)是块请求将花费t或更少的时间来完成的概率。因此，F(0)＝F(负值)＝0，F(无穷大)＝1，F单调增加。虽然F通常可能是未知的，但是可以进行对F的参数估计或非参数估计。对传输加速器块请求限制算法上的变型可以根据以下表达：

令T为当前时间；

令Te是正在考虑的UA请求的到期时间；

令pthresh为配置常数；

如果F(Te-T)<pthresh，则不针对给定的UA请求发出任何进一步的块请求。

前述pthresh配置常数可以被选择为在0和1之间的某个合适的值，并且取决于如何估计F，极限值0和1也可以是有意义的。

在操作中，上述示例中给出的传输加速器块请求限制算法将继续发送针对内容请求的块请求，直到内容请求将要到期。当信道速率近似为已知时，根据本文实施例可操作的传输加速器可以早得多地断定内容请求将在其硬到期时间之前不成功，并因此通过不请求针对其的任何(或另外的)块请求来不浪费带宽。因此，这样的传输加速器实施例可以实现用于放弃不能满足硬到期时间期限的请求的算法。基于请求硬到期的这种算法可以用下式表示：

令Te为所考虑的请求的到期时间；

令S是所考虑的请求的大小(如果大小不知道，则可以使用估计)；

令V是已经针对所考虑的请求而请求的字节数；

令ca为可配置常数(例如ca＝1)；

令R是对下载速率的估计(用于所考虑的内容请求)；

令Tstart是对从块请求发出时间到响应开始进入的时间的估计(这可以与上述示例性算法中的Tstart相同)；

令d：＝Te-(T+Tstart)；

如果ca*d*R<S-V，则不发出针对所考虑的内容请求的块请求。针对ca的一些可能的选择在下面的表5中阐述。由于放弃请求通常是不期望的，因此ca>＝1的选择通常将是有利的。

速率R可以随时间改变。然而，如果上述算法阻止在给定时间点发出块请求，则其可能不会在稍后的时间阻止它。

实施例可以实现与软到期时间相关联的FEC算法，例如由requestSoftExpirationTime键提供的那些。例如，如果针对内容请求的FEC数据可用，则当软到期时间很快时，实施例可以操作以更积极地请求FEC数据。这样的算法可以调整到底层信道条件(例如，当错误概率低时，即使即将到期，也可以请求很少的开销)。

可以根据实施例提供(例如通过streamPriority键)的不同流优先级的数量可以相当大(例如，2^32)。这样的大量优先级对于一些应用可能是有用的，例如以允许每个内容请求以不同的优先级来发送。为了在这种情况下不耗尽可用优先级值的集合，可以将大量不同的优先级值传送到传输加速器。另外，如果传输加速器要使用HTTP/2.0作为后端，则可以使客户端能够使用HTTP/2.0支持的完整的优先级集合。因此，本文中的实施例实现将优先级映射提供到较小集合中的算法，从而适应这种大的不同优先级的使用以及促进互操作性。由于各种技术原因，传输加速器的一些实现可能不内部地支持所有可能的优先级值(例如，2^32)。在这种情况下，可以提供优先级映射算法以将值映射到内部支持的优先级的较小集合。尽管存在可以进行这种优先级映射的许多方式，但是下面提供了示例性实施例。应当理解，尽管以下示例可能看起来很复杂，但是其优于可以实现的其它映射技术，如从下面的讨论将更好地理解的。

在传输加速器支持从0、...、N-1的N个不同的内部优先级的情况下，以下算法提供针对给定32位优先级P的内部优先级的映射：

大多数客户端不需要2^32个不同的优先级，并因此可能利用仅M个不同优先级的非常小的集合。在这种情况下，客户端可以具有可能的请求优先级0，...，M-1。为了针对范围0，...，M-1中的给定优先级clientInternalPriority来计算2^32位精度优先级P'，可以使用以下算法：

前述优先级映射技术不仅提供互操作性，而且提供优于其它可能的优先级映射技术的优点。例如，上述示例性实施例的优先级映射可以保证只要传输加速器支持至少与应用所需的一样多的不同优先级(即，只要N>＝M)，则不同的客户端优先级映射到不同的传输加速器优先级，其中正确保留优先级顺序。注意，该优先级映射在客户端不知道传输加速器的内部值N、传输加速器也不知道客户端的值M的情况下工作。此外，如果客户端使用另一种方式来指派优先级(例如，通过使用指派P'＝floor(clientInternalPriority*2^32/M))，只要所选择的指派将值扩展到2^32范围，责根据示例性实施例的优先级映射将仍然相对良好地工作。

从上述可以理解，可以在UA和TA之间实现以下信令：所述信令用于请求关于特定内容、特定内容请求等的传输加速器操作。在根据一些实施例的操作中，TA可以检测到存在这种指示对传输加速功能的需求的信令，并因此提供传输加速功能。然而，应当理解，虽然根据本文的实施例，尽管根据本文实施例，信令可以用于促进关于对TA作出的内容请求的传输加速操作的信令，但是本文实施例可以操作以选择性地提供关于这样的内容请求的传输加速操作。也就是说，尽管关于特定内容或特定内容请求，期望检测来自请求传输加速的UA的信令，但是实施例中的TA可操作以确定对传输加速功能的实现是否实际上是响应于以信号形式发送的请求而实现的。例如，发送到选择性加速端口的内容请求可以服从传输加速器的另一组规则，以便确定内容请求是否将被加速。

请求分派器(例如可以由TA控制125的逻辑实现的)可以操作以分析内容请求或其各方面(例如，解析请求URI、报头字段、以及内容请求和/或响应消息的其它元素)，以便生成用于确定何时加速或绕过对内容请求的加速的一个或多个规则。这样的规则可以例如提供针对某些关键词/短语模式的存在的检查。在根据实施例的操作中，使用这样的规则来提供排除列表，由此，排除列表包括黑名单规则的集合(例如，涉及对HTTP版本、消息方法、请求的文件后缀、报头、以及(服务器、资源)元组等的一系列检查)，当满足该黑名单规则的集合时，其导致确定内容请求将不被加速。

根据前述，图1中所示的实施例包括根据本文的概念适配的TA控制125，以提供关于通信会话的选择性传输加速器操作。如上所述，TA控制125可以被实现为诸如可以存储在存储器112中的计算机可读代码段，当其由处理器(例如处理器111)执行时，提供可如本文所述来操作的逻辑电路。TA控制125可以包括一个或多个功能块，例如所示实施例中的分析/控制逻辑126，其可操作以提供用于如本文所述的操作的必要功能。应当理解，尽管被示为设置在客户端设备110内，但是实施例可以采用对TA控制功能的不同配置。例如，TA控制125的一些部分可以设置在客户端设备110外部，例如，分析/控制逻辑126布置在服务器130处和/或与客户端设备110通信的另一基于处理器的系统处，而另一部分布置在客户端设备110处。类似地，TA控制125或其一部分也可以布置在客户端设备110内，而不是如图示实施例中所显示的。例如，TA控制125或其某一部分(例如，分析/控制逻辑126)可以布置在实施例中的TA 120内。

实施例中的TA控制125操作以区分要提供传输加速的消息和不提供传输加速的消息，从而提供选择性传输加速器操作。例如，如上所讨论的，TA 120可以操作以将片段请求细分为块请求(例如，将HTTP请求分解成在适当时间发送到服务器的较小请求)，以有助于传输加速。然而，使用这种较小的块请求可能不能在所有情况下提供期望的操作。将请求分解成较小请求并且提供那些较小请求的操作具有与其相关联的开销。在一些情况下，例如在存储所请求的内容的文件本身很小的情况下，增加的开销可能导致对数据的传输未被加速。类似地，在请求之间存在特定依赖性的情况下，例如在存在是针对期望稍后被下载的内容的先决条件的小文件的情况下，进行细分请求的操作可以针对该相互依赖的内容来分割请求，使得临界时间在依赖图中丢失，并且由于尝试的加速，内容被更慢地重新组装(例如，所得到的网页被呈现)。作为另一示例，块请求可以使用字节范围请求来做出，而服务器可能不支持字节范围请求(例如，忽略请求中不支持的字节范围信息并且响应于每个块请求返回完整文件)。这种情况可能导致增加的网络拥塞，同时不能提供传输加速。

因此，TA控制125的逻辑可操作以分析对TA 120的选择性加速端口做出的内容请求(例如，包括QC-STA报头的那些内容请求，从而指示UA希望具有内容请求加速)。例如，分析/控制逻辑126可以从内容请求获得一个或多个加速选择属性或与内容请求相关联的一个或多个加速选择属性，并且确定TA 120是否要提供关于特定消息或通信会话的传输加速。分析/控制逻辑126此后可以例如经由TA控制125向TA 120提供信令(和/或与其相关联的路由块)，以使得由TA 120基于上述确定针对该消息或通信会话的请求来提供传输加速操作或不提供传输加速操作。在任一情况下，TA120可以在将请求或其一部分(例如，块)传递到服务器130之前，操作以剥离传输加速信令的内容请求(例如，前述QC-STA报头)。另外，TA 120可以操作以向UA 129a提供信令以指示加速确定的状态和/或提供关于其操作的信息。

图2A中的流程图显示了根据本文的实施例的流程200，所述流程200示出了TA控制125操作以提供选择性传输加速器操作。在所示实施例的框201处，分析对TA 120的选择性加速端口做出的内容请求，以确定是否存在指示该请求是要接收传输加速操作的信令。例如，分析/控制逻辑126可以操作以分析与内容请求包括在一起的报头信息(例如，对本文的传输加速器操作来说唯一的HTTP报头)，所述报头信息指示将向内容请求提供传输加速器功能。用于指示请求是要接收传输加速操作的信令可以以多种合适方式中的任何一种被包括在内容请求中，例如，根据本文实施例，信令可以是HTTP请求的特殊报头、可以被包括为HTTP请求的报头中的字段值、可以被包括在HTTP请求的URI或URL的查询串中的一个或多个参数中、和/或可以被包括为内容请求中的任何其它适当的特征。如果不存在信令以指示期望关于内容请求的传输加速，则根据所示实施例的过程进行到框202，在此处，在不具有由TA120提供的加速操作的情况下(尽管已经被提供给TA 120的选择性加速端口)将请求传递到服务器130。

然而，如果存在信令以指示关于内容请求的传输加速，则可以或可以不根据实施例来提供传输加速处理。因此，在这种情况下，根据所示实施例的处理进行到框203，在此处，TA控制125的逻辑获得一个或多个加速选择属性，以用于选择性地实现TA 120的一个或多个功能。例如，TA控制125的逻辑可以从请求(例如，片段和/或块体请求)本身获得一个或多个加速选择属性。加速选择属性可以包括用户代理对来自内容服务器的内容的请求的属性、内容服务器的属性等。

在从请求获得一个或多个加速选择属性时，TA控制125的逻辑可以操作以分析请求、关于请求所使用的通信协议、请求内的数据等的各个方面，以识别关于加速选择属性的信息。例如，TA控制逻辑可以操作以分析诸如URI、用户代理字段、字节范围或内容长度字段等信息，以识别对于识别加速选择属性有用的信息。在根据实施例的操作中，TA控制逻辑可以分析该请求以确定该请求的协议类型(例如，HTTPS、HTTP1.0、HTTP2.0等)、与请求相关联的通信会话的属性(例如，spdy_enabled、qulc_enabled、upstream_proxy_configured等)、所做出的请求的类型(例如，HTTP GET、PUT、POST、TRACE、OPTIONS等)、该请求内的报头信息(例如，具有多个范围呈现的字节范围报头、授权报头呈现等)等等。在根据实施例的操作中，用户代理字段可以用特殊值填充，以便识别可加速的业务。另外或替代地，TA控制125的逻辑可以操作以分析在上述信令中提供或与其相关联的信息。例如，根据本文的实施例，可以分析由QC-STA报头中提供的一个或多个上述键(诸如fileType、priority、streamingBitRate、streamingPlaybackBuffer和requestExpirationTime)所提供的信息，以用于加速选择。

在获得了一个或多个加速选择属性之后，根据所示实施例的流程200的操作进行到框204，在此处，TA控制125的逻辑控制基于由所述TA控制逻辑获得的所述一个或多个加速选择属性的对TA 120的功能的选择性调用(例如，选择性地调用传输加速操作)。在TA控制125的逻辑的控制下，对TA 120的功能的选择性调用可以操作以使得传输加速器的逻辑使用上述功能从内容服务器获得内容，或者使得传输加速器的逻辑从绕过上述功能的内容服务器获得内容。例如，TA 120(特别是其中的RM 121)可以操作以提供将用户代理对内容的请求细分为多个块请求(其用于从内容服务器请求内容的块)，以用于向客户端设备提供对内容的加速传递。可以在TA控制125的逻辑的控制下，基于加速选择属性来选择性地调用(举例来说，绕过或不绕过RM 120和/或TA 120的其它逻辑，所述绕过是例如通过受控地绕过RM 120和/或TA 120的其它逻辑来绕过的)用于传输加速的这种请求“组块”功能。

由TA控制逻辑对加速选择属性进行分析，以用于根据实施例来确定是否要调用传输加速器的功能，可以采用一些一般规则和/或假设。例如，在根据本文实施例的操作中，向在TA 120的选择性加速端口中接收的内容请求应用一组或多组排除列表规则，以便确定内容请求是否应当被加速。实施例可以例如实现多组排除列表规则，所述多组排除列表规则例如可以包括黑名单服务器列表(例如，排除列表126a)和请求属性排除列表(例如，排除列表126b)。

根据本文的实施例使用的黑名单服务器列表可以包括由于一个原因或另一个原因已经被确定为请求加速是不实际的或不可能的服务器的列表。例如，UA 129a可以向已经被确定为不与TA 120进行的传输加速操作兼容并因此包括在排除列表126a中的黑名单服务器列表上的特定服务器提供内容请求。因此，在流程200的框204处分析/控制逻辑126的操作可以确定不向该请求提供传输加速功能。在下面的表6中提供了黑名单服务器列表的示例。

应当理解，这样的黑名单服务器列表可以提供关于特定资源(例如，由表6的“资源”列指定的)的黑名单。因此，到以其它方式被列入黑名单的服务器的、针对其它资源的请求仍然可能不会被拒绝传输加速功能，这是因为服务器已经被列入的是关于不同资源的黑名单服务器列表。根据实施例，其它信息(例如表6中的“定时器值”(下面解释))可以按照需要或期望而被包括在黑名单服务器列表中。

根据本文实施例使用的请求属性排除列表可以包括内容请求的各种属性或与内容请求相关联的各种属性，根据所述属性，可以做出关于实现对内容请求的传输加速的确定。下面的表7提供了可以根据本文的实施例使用的请求属性排除列表(例如，排除列表126b)的示例。该示例性表格标识请求的特定协议类型、与请求相关联的通信会话的属性、所做出的请求的类型、以及请求内的报头信息，如果存在与请求的关联，则将该请求从传输加速操作中排除(例如，传输加速功能被绕过)。

本文的排除列表中的特定条目可以通过数种技术来确定。例如，可以针对先前已知为不兼容或以其它方式不适合传输加速操作的某些资源来做出某些条目(例如，通过后缀、路径或区域的内容文件，通过识别信息的用户代理，通过识别信息或路径的内容服务器等)。另外地或替代地，可以监测内容传输(例如，监视传输加速器操作、网络拥塞、用户代理操作、用户体验度量等)，以经验性地确定传输加速操作的兼容性或适用性。另外，可以例如基于对请求的响应，随时间推移来学习针对排除列表中的条目的资源。例如，TA控制125的学习逻辑可以操作以例如基于对字节范围请求的支持/不支持、导致禁止或范围不可满足的响应的请求等，利用关于特定内容服务器和/或其它资源的信息来填充排除列表和/或包括列表中的任一个或二者。TA控制125的学习逻辑的实施例可以操作(可能结合用以提供该请求的监测操作)以分析由内容服务器提供的响应代码，来学习哪些响应代码指示内容服务器兼容性或传输加速操作的适合性。

图2B中的流程图示出了根据框204的实施例的TA控制125的操作，以基于一个或多个排除列表(例如，黑名单服务器列表和请求属性排除列表)提供对传输加速器逻辑的功能的选择性调用。在所示实施例的框221处，关于内容请求应用排除列表(例如，排除列表126a和/或排除列表126b)。在根据实施例的操作中，可以分层地应用多个排除列表。例如，服务器排除列表可以相对容易地实现，并且需要很少的处理能力来确定内容请求是否指向黑名单内容服务器。因此，这种排除列表可以应用于较高的层次(例如，在可能需要更多处理能力来实现的请求属性排除列表之前)。作为对本文的排除列表的分层实现的另一示例，例如为了便于操作，可以逐列地(例如，从左到右)应用排除列表(例如，可以包括上面所示的表7的排除列表)以实现分层地来排除规则。例如，字符串搜索通常比属性匹配更慢和/或利用更多的计算资源，因此诸如“spdy_enabled”之类的属性搜索可以在任何字符串匹配之前执行以提供改进的性能和/或降低资源利用率，其中，在根据实施例应用排除规则时早发现一匹配。在框222处，确定是否满足任何排除规则(例如，请求被引导到的内容服务器或加速选择属性与排除列表中的条目匹配)。

如果满足排除条件中的任何一个，则根据所示实施例的处理进行到框224，在此处，绕过传输加速功能。例如，TA控制125的逻辑可以操作以控制TA 120的路由块，以使得该请求绕过传输加速功能，优选地剥离关于来自其的传输加速操作任何信令(例如，前述QC-STA报头)。TA 120可以在确定不实现传输加速功能时或之后，向UA提供关于不实现传输加速的信令(例如，使用上述QC-STA响应报头)。

然而，如果不满足排除条件，则根据所示实施例的处理进行到框223。在所示实施例的框223处，实现关于该请求的传输加速功能。例如，TA控制125的逻辑可以操作以控制TA120的路由块，以使得请求被提供传输加速功能，优选地剥离关于来自其的传输加速操作的任何信令(例如，前述QC-STA报头)。在来自UA的信令中提供的信息，诸如由一个或多个上述信令键提供的信息(例如，包括在前述QC-STA报头中)，可以由传输加速器用于实现适合于UA操作的传输加速功能。TA 120可以在实现传输加速功能时和/或与之相关联时，向UA提供关于传输加速的启动和/或操作的信令(例如，使用上述QC-STA响应报头)。

在确定内容服务器不支持传输加速操作(例如，当任何前述示例性条件已经失败时)时，根据实施例的操作可操作以将内容服务器动态地添加到排除列表(例如，将{服务器，资源}元组添加到排除列表，所述{服务器，资源}元组例如(主机名，文件扩展)元组)，所述排除列表例如排除列表126a。此后，如上所述，可以基于这些内容服务器包括在排除列表中，来选择性地实现关于这样的内容服务器的传输加速功能。

因为指示支持传输加速的条件可以逐资源地改变，因此实施例可以操作为将被确定为不支持传输加速操作的特定内容服务器临时包括在排除列表中。例如，当根据上述将内容服务器添加到排除列表时，实施例还可以在排除列表中注明针对该条目的时间戳或定时器值(例如，上面的表6中的“定时器值”)。在根据实施例的操作中，在特定元组在排除列表上的时间期间，对该内容服务器的请求将不被加速(即，将绕过传输加速功能)。然而，一旦排除列表定时器到期，对内容服务器的请求可以被加速(例如，取决于对其应用的传输加速控制分析)。

虽然已经详细地示出和描述了所选择的方面，但是应当理解，在不脱离由以下权利要求所限定的本发明的精神和范围的情况下，可以在其中进行各种替换和更改。