CN107211022A

CN107211022A - 利用服务器装置的改进的客户端驱动资源推送

Info

Publication number: CN107211022A
Application number: CN201680007911.4A
Authority: CN
Inventors: 弗兰克·德诺奥; 优恩·法博莱特; 赫夫·鲁伦; 弗雷德里克·梅兹; 内尔·奥德拉奥果
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2015-01-28
Filing date: 2016-01-15
Publication date: 2017-09-26
Anticipated expiration: 2036-01-15
Also published as: CN107211022B; GB2534617A; GB2538832B; JP2018509679A; GB2534849A; GB2538832A; US20180013845A1; WO2016120089A1; EP3251322B1; GB201602333D0; KR20170106426A; US10348846B2; US20170230442A1; KR102007105B1; GB201501437D0; JP6686029B2; GB201509094D0; EP3251322A1

Abstract

本发明涉及经由HTTP通信网络的数据传输、例如数据流传输。一种用于在服务器和客户端之间传输数据的方法，所述方法在所述服务器处包括以下步骤：从所述客户端接收用以获得第一数据的HTTP请求，其中所述HTTP请求包括使得能够在所述服务器上识别所述第一数据的第一数据识别信息，并且包括包含与推送第二数据有关的指示的一个或多个附加头部字段；检索所述第一数据并将所述第一数据发送至所述客户端；以及向所述客户端发送确认数据，其中所述确认数据代表与推送所述第二数据有关的指示。

Description

利用服务器装置的改进的客户端驱动资源推送

技术领域

本发明涉及经由HTTP(代表超文本传输协议)通信网络的数据传输(例如，数据流传输)，并且更精确地涉及利用服务器装置的客户端驱动的资源推送。

背景技术

在经由HTTP的通信(诸如DASH(经由HTTP的动态自适应流传输(Dynamic AdaptiveStreaming over HTTP)的首字母缩略词)媒体内容流传输)中，可以由客户端装置向服务器装置请求大量数据。为此，客户端装置通常发送HTTP请求，其中这些HTTP请求各自包括由方法(例如，“GET(获得)”)和统一资源标识符即URI形成的请求行，从而可能地连同HTTP请求中的一个或多个附加头部(例如，提供利用URI所标识资源内的字节范围的Range(范围)头部)一起识别并定位服务器装置上的所请求数据。

研发了服务器Push(推送)特征，以使得服务器装置可以自发地推送客户端装置尚未请求的数据。这是用于减少web资源加载时间的有用特征。

在HTTP/2(其还使得可以在一个现有连接内交换多个请求/应答(即，具有多个流))中引入了服务器Push特征，从而使得服务器装置能够将未经请求的web资源表现发送至客户端装置。诸如网页等的web资源通常包含向其它资源的链接，而这些其它资源自身可能包含指向其它资源的链接。为了完全显示网页，客户端装置通常需要检索所有链接和子链接的资源。特别是在诸如移动网络等的高延迟网络上，该递增式发现可能导致网页的缓慢显示。

在接收到针对给定网页的请求的情况下，服务器装置能够确定需要哪些其它资源用于所请求的资源的完整处理。通过同时发送所请求的资源和所链接的资源，服务器装置使得能够缩短网页的加载时间。因而，使用推送特征，服务器装置可以在该服务器被请求了给定资源时发送附加资源表现。

在DASH的背景下(例如，在本申请人的以WO 2015/004276公开的申请中)也建议了数据的推送。

该公开旨在特别是在基于DASH的通信的背景下增强数据流传输，以优化用户体验。这是因为，在传统的机制中，客户端装置和服务器装置可能并不知晓所承诺的数据是否将在期望时间被发送和接收：客户端装置可能并不知晓将于何时按何顺序发送视频片段。此外，服务器装置所推送或通报的所承诺的数据可能与客户端装置的需求(该需求可能随时间的经过而演变)不匹配，由此导致特别是服务器端的资源浪费。因而，公开WO 2015/004276建议在服务器装置和客户端装置之间共享推送策略。

该共享有助于客户端装置预先知晓将要推送哪些数据，然后准备取消这些推送以避免浪费网络带宽。

然而，该公开中所提出的机制要求服务器装置具有DASH的专业知识，特别是能够在基于XML的DASH“媒体呈现描述”文件(MPD)上应用推送策略，以根据推送策略来确定要推送哪些数据或资源。

值得注意的是，MPD文件按媒体片段描述媒体内容的构造。在服务器装置和客户端装置之间交换MPD文件，从而向客户端装置提供使得客户端装置能够控制媒体内容的传递(即，单独请求各媒体片段)的信息。

发明内容

在该背景下，本发明提供一种用于在服务器装置和客户端装置之间传输数据的方法，所述方法在所述服务器装置处包括以下步骤：

从所述客户端装置接收用以获得第一数据的HTTP请求，其中所述HTTP请求包括使得能够在所述服务器装置上识别所述第一数据的第一数据识别信息，并且包括包含与推送第二数据有关的指示的一个或多个附加头部字段；

检索所述第一数据并将所述第一数据发送至所述客户端装置；

向所述客户端装置发送确认数据，其中所述确认数据代表与推送第二数据有关的所述指示；以及

仅使用所述一个或多个附加头部字段并且可能地使用所述第一数据识别信息，来确定使得能够在所述服务器装置上识别所述第二数据的第二数据识别信息。

因此，本发明的方法使得客户端装置可以考虑到服务器装置所应用的推送策略来变更其行为。

在实施例中，所述方法还包括以下步骤：

将用以通报所述第二数据的推送的推送承诺消息发送至所述客户端装置、以及/或者将所述第二数据推送至所述客户端装置。

在实施例中，所述确认数据代表用于推送所述第二数据的指示。

在实施例中，所述确认数据表示响应于所述HTTP请求将不发送第二数据。

在实施例中，与推送所述第二数据有关的指示包括包含与推送所述第二数据有关的至少两个不同指示的列表。

在实施例中，所述确认数据包括与推送所述第二数据有关的至少两个不同指示其中之一，其中使用与推送所述第二数据有关的至少两个不同指示其中之一来识别要推送至所述客户端装置的所述第二数据。

在实施例中，与推送所述第二数据有关的指示与所述第二数据的数据类型相关联，其中所述数据类型包括描述数据类型或内容数据类型，所述第二数据属于内容数据或描述数据。

在实施例中，与推送所述第二数据有关的指示涉及推送媒体呈现描述更新。

在实施例中，所述确认数据包含与推送所述第二数据有关的指示，其中所述确认数据内的与推送所述第二数据有关的指示不同于所述HTTP请求内的与推送所述第二数据有关的指示。

在实施例中，与推送所述第二数据有关的指示包括至少一个唯一标识符，其中所述至少一个唯一标识符代表用于推送所述第二数据的指令和要推送的所述第二数据的标识，或者代表用于不推送所述第二数据的指令。

在实施例中，所述唯一标识符是在中央储存库中定义的。

在实施例中，所述唯一标识符是根据至少一个参数所设置的。

根据本发明的另一目的，提供一种用于在服务器装置和客户端装置之间传输数据的方法，所述方法在所述客户端装置处包括以下步骤：

识别要从所述服务器装置获得的数据；

生成用以从所识别出的数据获得第一数据的HTTP请求，其中所述HTTP请求包括使得能够在所述服务器装置上识别所述第一数据的第一数据识别信息，并且包括一个或多个附加头部字段，其中所述子部分信息包含针对所述服务器装置的用以推送第二数据或者不推送所述第二数据的指示；

将所述HTTP请求发送至所述服务器装置以获得所述第一数据，并且驱动所述服务器装置以推送所述第二数据或者不推送所述第二数据；以及

响应于发送所述HTTP请求，从所述服务器装置接收确认数据，其中所述确认数据代表与推送所述第二数据有关的指示，

其中，所述一个或多个附加头部字段仅基于所述一个或多个附加头部字段并且可能地基于所述第一数据识别信息，来定义使得能够从所述服务器装置上的所识别出的数据中识别所述第二数据的第二数据识别信息。

在实施例中，所述确认数据包括与推送所述第二数据有关的至少两个不同指示其中之一，其中所述服务器装置使用与推送所述第二数据有关的至少两个不同指示其中之一来识别要推送至所述客户端装置的所述第二数据。

在实施例中，与推送所述第二数据有关的指示涉及推送描述数据更新。

在实施例中，所述唯一标识符是在中央储存库中定义的。

根据本发明的另一方面，提供一种用于在服务器装置和客户端装置之间传输数据的方法，所述方法在所述服务器装置处包括以下步骤：

从所述客户端装置接收用以获得第一数据的HTTP请求，其中所述HTTP请求包括使得能够在所述服务器装置上识别所述第一数据的第一数据识别信息，并且包括一个或多个附加头部字段；

检索所述第一数据并将所述第一数据发送至所述客户端装置；以及

根据所述一个或多个附加字段内所包含的与推送第二数据有关的指示，来向所述客户端装置推送所述第二数据或者不向所述客户端装置推送所述第二数据。

因此，本发明的方法提高了服务器装置的用以将有用数据推送至客户端装置的能力。

在实施例中，所述唯一标识符是在中央储存库中定义的。

根据本发明的另一方面，一种用于在服务器装置和客户端装置之间传输数据的方法，所述方法在所述客户端装置处包括以下步骤：

识别要从所述服务器装置获得的数据；

生成用以从所识别出的数据获得第一数据的HTTP请求，其中所述HTTP请求包括使得能够在所述服务器装置上识别所述第一数据的第一数据识别信息，并且包括一个或多个附加头部字段，其中所述子部分信息包含针对所述服务器装置的用以推送第二数据或者不推送所述第二数据的指示；以及

将所述HTTP请求发送至所述服务器装置以获得所述第一数据，并且驱动所述服务器装置以推送所述第二数据或者不推送所述第二数据。

在实施例中，所述唯一标识符是在中央储存库中定义的。

根据本发明的另一目的，提供一种用于利用客户端装置来从服务器装置接收数据的方法，所述方法在所述客户端装置处包括以下步骤：

发送用以获得第一数据的HTTP请求，其中所述HTTP请求包括使得能够在所述服务器装置上识别所述第一数据的第一数据识别信息，并且包括一个或多个附加头部字段；

在所述客户端装置不想所述服务器装置推送任何不同于所述第一数据的第二数据的情况下，在所述一个或多个附加头部字段至少之一中插入如下的信息项，其中所述信息项表示所述客户端装置不想所述服务器装置响应于所述HTTP请求而发送任何第二数据；以及

将所述HTTP请求发送至所述服务器装置。

因此，本发明的方法防止将从服务器装置推送的无用数据传输至客户端装置。

在实施例中，表示所述客户端装置不想所述服务器装置推送任何第二数据的信息项包括至少一个唯一标识符，其中所述至少一个唯一标识符代表用于不推送所述第二数据的指令。

在实施例中，所述唯一标识符是在中央储存库中定义的。

根据本发明的另一方面，提供一种用于从服务器装置向客户端装置发送数据的方法，所述方法在所述服务器装置处包括以下步骤：

响应于所述HTTP请求，将表示所述服务器装置将不推送任何不同于所述第一数据的第二数据的信息项发送至所述客户端装置。

在实施例中，表示所述服务器装置将不推送任何第二数据的信息项包括至少一个唯一标识符，其中所述至少一个唯一标识符代表用于不推送所述第二数据的指令。

在实施例中，所述唯一标识符是在中央储存库中定义的。

根据本发明的另一方面，提供一种用于利用客户端装置来从服务器装置接收数据的方法，所述方法在所述客户端装置处包括以下步骤：

在所述客户端装置不想所述服务器装置推送任何不同于所述第一数据的第二数据的情况下，在所述一个或多个附加头部字段至少之一中插入如下的信息项，其中所述信息项表示所述客户端装置不想所述服务器装置响应于所述HTTP请求而发送任何第二数据；

将所述HTTP请求发送至所述服务器装置；

响应于发送所述HTTP请求，从所述服务器装置接收确认数据，其中所述确认数据包括表示所述服务器装置将不推送任何不同于所述第一数据的第二数据的信息项。

在实施例中，所述唯一标识符是在中央储存库中定义的。

根据本发明的另一目的，提供一种用于从服务器装置向客户端装置发送数据的犯法，所述方法在所述服务器装置处包括以下步骤：

从所述客户端装置接收用以获得第一数据的HTTP请求，其中所述HTTP请求包括使得能够在所述服务器装置上识别所述第一数据的第一数据识别信息，并且包括包含如下的信息项的一个或多个附加报头字段，其中所述信息项表示所述客户端装置不想所述服务器装置响应于所述HTTP请求而推送任何第二数据；

在实施例中，所述唯一标识符是在中央储存库中定义的。

在实施例中，所述一个或多个附加头部字段是一个或多个可选头部字段。

在实施例中，所述第一数据识别信息和所述第二数据识别信息分别包括第一统一资源标识符即第一URI和第二统一资源标识符即第二URI。

在实施例中，所述一个或多个可选头部字段包括用以根据所述HTTP请求的内容来生成所述第二URI的至少一个构建规则。

在实施例中，所述一个或多个可选头部字段包括变化部分信息和替代信息，其中所述变化部分信息识别参考URI中的至少一个变化子部分，以及所述替代信息包括用以替换在所述参考URI中识别出的变化子部分以定义所述第二URI的至少一个替代值。

在实施例中，所述参考URI包括所接收到的HTTP请求中所包括的第一URI。

在实施例中，所述变化部分信息使用所述替代信息中所包括的各个替代值来识别所述参考URI中的供替代的两个或更多个子部分。

在实施例中，所述变化部分信息使各个优先级级别与所述参考URI中的两个或更多个子部分各自相关联，以根据各个优先级级别来连续地考虑所述两个或更多个子部分的替代值。

在实施例中，所述附加头部字段以显式方式包括所述第二URI。

在实施例中，所述第一数据识别信息包括识别所述服务器装置上的主资源的第一统一资源标识符即第一URI，并且包括将所述子资源的子部分定义为所述第一数据的子部分信息；以及

所述可选头部字段包括用以替换所述第一数据识别信息中的所述子部分信息以定义所述第二数据识别信息的替代子部分信息。

在实施例中，所述子部分信息包括所述主资源内的字节的范围值。

在实施例中，所述第一数据和所述第二数据分别是利用所述第一数据识别信息和所述第二数据识别信息在DASH清单呈现描述中识别出的媒体片段或媒体内容子部分。

根据本发明的另一目的，提供一种用于在服务器装置和客户端装置之间传输数据的方法，所述方法在所述服务器装置处包括以下步骤：

从所述客户端装置接收用以获得第一数据的HTTP请求，其中所述HTTP请求包括使得能够在所述服务器装置上识别所述第一数据的第一数据识别信息，并且包括使得能够识别第二数据的一个或多个可选头部字段；

在所述可选头部字段存在于所述HTTP请求中的情况下，

仅使用所述可选头部字段并且可能地使用所述第一数据识别信息(即，仅使用所述HTTP请求的内容)，来确定使得能够所述服务器装置上识别所述第二数据的第二数据识别信息；以及

将用以通报所述第二数据的推送的推送承诺消息发送至所述客户端装置、以及/或者将所述第二数据发送至所述客户端装置。

从客户端的角度，本发明提供一种用于在服务器装置和客户端装置之间传输数据的方法，所述方法在所述客户端装置处包括以下步骤：

识别要从所述服务器装置获得的数据；

生成用以从所识别出的数据获得第一数据的HTTP请求，其中所述HTTP请求包括使得能够在所述服务器装置上识别所述第一数据的第一数据识别信息，并且包括一个或多个可选头部字段，其中所述一个或多个可选头部字段仅基于可选头部字段并且可能地基于所述第一数据识别信息(即，仅基于所述HTTP请求的内容)，来定义使得能够从所述服务器装置上的所识别出的数据中识别第二数据的第二数据识别信息；

将所述HTTP请求发送至所述服务器装置以获得所述第一数据，并且驱动所述服务器装置以推送所述第二数据。

相关地，本发明提供一种服务器装置，用于与客户端装置交换数据，所述服务器装置包括至少一个微处理器，所述至少一个微处理器被配置为执行以下步骤：

在所述可选头部字段存在于所述HTTP请求中的情况下，

仅使用所述可选头部字段并且可能地使用所述第一数据识别信息，来确定使得能够所述服务器装置上识别所述第二数据的第二数据识别信息；以及

此外，本发明提供一种客户端装置，用于与服务器装置交换数据，所述客户端装置包括至少一个微处理器，所述至少一个微处理器被配置为执行以下步骤：

识别要从所述服务器装置获得的数据；

生成用以从所识别出的数据获得第一数据的HTTP请求，其中所述HTTP请求包括使得能够在所述服务器装置上识别所述第一数据的第一数据识别信息，并且包括一个或多个可选头部字段，其中所述一个或多个可选头部字段仅基于可选头部字段并且可能地基于所述第一数据识别信息，来定义使得能够从所述服务器装置上的所识别出的数据中识别第二数据的第二数据识别信息；

在HTTP/2中，推送承诺消息在相应数据的实际推送之前。其它协议(特别是如WebSocket或SPDY(代表SPeeDY)那样的双向协议)可以在无需先前的推送通报的情况下直接推送第二数据。

由于本发明，客户端装置在使向后兼容性成为可能的同时，高效地控制利用服务器装置的推送机制。这减少了推送数据和客户端的需求之间的不匹配。这是因为使用传统HTTP请求的可选头部字段定义了客户端装置想要被推送的第二数据(资源或资源的一部分)。此外，向后兼容性来自于以下事实：如果服务器装置是传统型、即不支持可选头部字段，则该服务器装置仍可以在无处理错误的情况下，以传统方式处理HTTP请求。

对于理解可选头部字段但不支持推送特征的服务器，在该服务器不是内容服务器而是中继服务器的情况下，该服务器可以使用来自可选头部字段的信息来预取资源。

另外，本发明使得可以依赖于低技能服务器、例如不具有DASH知识的服务器。这是因为，要推送的第二数据的识别不需要处理MPD文件等。根据本发明，仅使用可选头部字段并且可能地使用第一数据识别信息来进行这种识别。

因而，本发明的实施例提供包括客户端驱动的服务器推送方法的、用于服务器引导的流传输的轻量级机制。可以在DASH网络的背景下实现实施例。

本发明的实施例符合现有的HTTP/2特征。这些特征可以有利地用于实现本发明的实施例。

网络性能大体上提高了。

在从属权利要求中定义了方法和装置的可选特征。以下针对方法来说明这些可选特征中的一些可选特征。然而，这些可选特征还可以适用于相应的装置。

在一个实施例中，第一数据识别信息和第二数据识别信息分别包括第一统一资源标识符即第一URI和第二统一资源标识符即第二URI。

在特定实施例中，一个或多个可选头部字段包括用以根据HTTP请求的内容来生成第二URI的至少一个构建规则。换句话说，可选头部字段使用该构建规则来以隐式方式定义第二URI。如从以上所推断出的，构建规则仅使用可选头部字段并且可能地使用第一URI，以获得第二URI。

例如，一个或多个可选头部字段包括变化部分信息和替代信息，其中该变化部分信息识别参考URI中的至少一个变化子部分，以及该替代信息包括用以替换在参考URI中识别出的变化子部分以定义第二URI的至少一个替代值。

根据特定特征，参考URI包括所接收到的HTTP请求中所包括的第一URI。换句话说，构建规则(替代处理)适用于第一URI、即所请求的第一数据的URI。这意味着(可能是通用的)构建规则根据所请求的第一数据、但仅使用HTTP请求的内容，来推断要推送的第二数据。

根据另一特定特征，变化部分信息使用替代信息中所包括的各个替代值来识别参考URI中的供替代的两个或更多个子部分。因而，可以根据第一URI生成复杂的第二URI。

根据又一特定特征，变化部分信息使各个优先级级别与参考URI中的两个或更多个子部分各自相关联，以根据各个优先级级别来连续地考虑两个或更多个子部分的替代值。由于该规定，因此客户端装置对第二URI进行排序，并由此驱动服务器装置推送第二数据的顺序。

在一些实施例中，可选头部字段以显式方式包括第二URI。这是为了与使用例如构建规则的第二URI的隐式定义相对比。

在其它实施例中，第一数据识别信息包括表示服务器上的主资源的第一统一资源标识符即第一URI，并且包括将该主资源的子部分定义为第一数据的子部分信息；以及

可选头部字段包括用以替换第一数据识别信息中的子部分信息以定义第二数据识别信息的替代子部分信息。

子部分信息的示例是DASH中所使用的Range参数。在该示例中，子部分信息包括主资源内的字节的范围值。

根据实施例，第一数据和第二数据分别是利用第一数据识别信息和第二数据识别信息在DASH清单呈现描述中所识别出的媒体片段或媒体内容更新。注意，尽管DASH中的URI通常标识整个媒体片段，但DASH Range参数的使用使得可以识别媒体内容/片段子部分。

与已知的现有技术相比，还需要帮助客户端装置驱动或引导服务器推送特征。在这种情况下，本发明还提供一种用于在服务器装置和客户端装置之间传输数据的方法，所述方法在所述服务器装置处包括以下步骤：

从所述客户端装置接收用以获得第一数据的超文本传输协议请求即HTTP请求，其中所述HTTP请求包括包含一个或多个过滤参数的第一可选头部字段；

在所述第一可选头部字段存在于所述HTTP请求中的情况下，

使用从所述HTTP请求获得的主资源来识别一组数据；

使用所述一个或多个过滤参数来过滤所识别出的一组数据中的各数据，以获得第二数据的列表；以及

将所述第二数据推送至所述客户端装置。

利用包括推送承诺特征的协议，所述方法还包括：在推送所述第二数据之前，将用以通报所述第二数据的推送的推送承诺消息发送至所述客户端装置。

生成用于获得第一数据的超文本传输协议请求即HTTP请求，其中所述HTTP请求包括包含一个或多个过滤参数的第一可选头部字段；

将所述HTTP请求发送至所述服务器装置以获得所述第一数据，并且驱动所述服务器装置，以根据所述一个或多个过滤参数来推送在从所述HTTP请求推断出的主资源中所引用的第二数据。

所述一个或多个过滤参数：

-定义资源类型，所述资源类型包括来自应用程序类型、文本类型、图像类型、视频类型、音频类型中的一个或多个类型；或者

-使用经由HTTP的动态自适应流传输媒体呈现描述即DASH媒体呈现描述中的元素的标识符来识别数据的一个或多个组；或者

-是使用识别所述主资源的子部分的时间范围在所述第一可选头部字段中所定义的。

此外，可以接收到推送承诺消息。

在所述第一可选头部字段存在于所述HTTP请求中的情况下，

使用从所述HTTP请求获得的主资源来识别一组数据；

将所述第二数据推送至所述客户端装置。

所述一个或多个过滤参数：

该方法的示例性例示是请求主HTML网页作为第一数据。然后，可选头部字段可以定义应当推送HTML页中所引用的哪个或哪些类型的子资源。因而，可选头部字段用作过滤参数。例如，可选头部字段可以提供过滤参数“images/*.jpg”来对子资源进行过滤，从而仅推送jpg图像的子集。

利用客户端装置的服务器推送特征的改进控制是通过可选头部字段，通过使用过滤参数以应用于利用请求识别出的数据而获得的。

再次地，使用这种可选头部字段允许服务器端处的向后兼容性。

因而，本发明的实施例提供包括客户端驱动的推送方法的、用于服务器引导的流传输的轻量级机制。可以在DASH网络的背景下实现实施例。

网络性能大体上提高了。

在从属权利要求中定义方法和装置的可选特征。这些可选特征中的一些可选特征在下文针对方法来说明。然而，这些可选特征还可以适用于相应的装置。

在实施例中，主资源是第一数据。这意味着，单独采用HTTP请求就使得服务器装置可以高效地识别要推送的所有第二数据。服务器装置不需要诸如以上论述的现有技术所用的DASH知识等的附加知识。因而可以使用低技能型服务器装置。

在其它实施例中，HTTP请求包括第二可选头部字段，其中该第二可选头部字段定义标识主资源的统一资源标识符即URI。在客户端装置需要首先获得主资源然后分析该主资源、从而识别(并使用可选头部字段定义)用以从主资源中实际选择适当的第二数据的过滤参数的情况下，可以实现这种实施例。实际上，在这种情况下，由于客户端装置尚未访问主资源的内容，因此客户端装置在请求主资源时，不能定义过滤参数。

由于该规定，客户端可以指定服务器上所存储的、可以针对各资源类型定义资源列表的静态配置文件。使用这种静态配置文件需要低技能型服务器来基于资源类型过滤参数识别资源。

在更多的其它实施例中，两个(或更多个)过滤参数分别与两个(或更多个)组的数据并且与两个优先级级别相关联；并且过滤步骤按根据第二数据分别属于的组的优先级级别的顺序来排列这些第二数据，以获得第二数据的有序列表；并且推送步骤根据该有序列表来推送第二数据。在客户端端，这意味着：两个过滤参数分别与两组数据并且与两个优先级级别相关联；并且按根据第二数据分别属于的组的优先级级别的顺序来接收这些第二数据。这样使得客户端装置可以高效地驱动该客户端装置希望接收所推送数据的顺序。

在更多的其它实施例中，各过滤参数定义资源类型；并且资源类型包括来自应用程序类型(例如，javascript)、文本类型(例如，css或html)、图像类型(例如，png或jpg)、视频类型(例如，mp4或webm)、音频类型(例如，mp3或wav)中的一个或多个类型。

该规定特别适用于html或相似交换，诸如用于网页加载等。当然，这些资源类型中的任何资源类型的子分割可以帮助高效地驱动特定内容(例如，图像或者如Javascript功能那样的嵌入功能)的加载。

在更多的其它实施例中，第一可选头部字段中的一个或多个过滤参数使用DASH媒体呈现描述中的元素的标识符来表示一组或多组数据。这些元素可以包括DASH MPD的AdaptationSet(适应集)元素、Presentation(呈现)元素或Segment(片段)元素。在实施例中，利用HTTP请求所请求的第一数据是DASH MPD。当然，在变形例中，可以在上述的第二可选头部字段中指定DASH MPD。

该规定使得客户端装置可以控制利用MPD所定义的媒体内容的一些部分的推送。

在更多的其它实施例中，使用标识主资源的子部分的时间范围(例如，DASH请求中所使用的时间范围)来在第一可选同步字段中定义一个或多个过滤参数。如先前的规定那样，该规定还使得客户端装置可以控制利用服务器装置如何推送使用DASH进行流传输的媒体内容的子部分。

本发明的另一方面涉及一种存储有程序的非暂时性计算机可读介质，其中所述程序在由装置中的微处理器或计算机系统执行的情况下，使所述装置进行如以上所定义的任何方法。

非暂时性计算机可读介质可以具有与上文和下文与方法和装置有关地所陈述的特征和优点类似的特征和优点、特别是提高客户端的针对服务器Push特征的控制并且依赖于低技能型服务器装置的特征和优点。

本发明的又一方面涉及一种装置，其包括被配置为执行如以上所定义的任何方法的各步骤的部件。

本发明的更多其它方面涉及大致如这里参考附图中的图3a或3b或5a或5b或6a或7b或8所述并且在这些图中示出的、用于在服务器装置和客户端装置进行传输资源的方法。

根据本发明的方法的至少一部分可以通过计算机来实现。因此，本发明可以采用完全硬件实施例、(包括固件、常驻软件、微代码等的)完全软件实施例、或者组合这里通常可全部称为“电路”、“模块”或“系统”的软件和硬件方面的实施例的形式。此外，本发明可以采用以介质中嵌入有计算机可用程序代码的表现的任何有形介质中体现的计算机程序产品的形式。

由于本发明可以以软件来实现，因此本发明可以体现为计算机可读代码以提供至可编程设备的任何适当载体介质上。有形载体介质可以包括诸如软盘、CD-ROM、硬盘驱动器、磁带装置或固态存储器装置等的存储介质。瞬态载体介质可以包括诸如电气信号、电子信号、光学信号、声学信号、磁信号或者例如微波或RF信号的电磁信号等的信号。

附图说明

通过以下参考附图针对非限制性典型实施例的说明，本发明的其它特征和优点将变得明显，其中：

图1a使用图表示出互连至诸如网页等的主资源的一组资源；

图1b和1c分别示出在没有使用推送特征的情况下和在使用推送特征的情况下的图1a的主资源的加载；

图1d使用流程图示出实现推送特征时的客户端装置的传统步骤；

图1e使用流程图示出实现推送特征时的服务器装置的传统步骤；

图2示出用以加载网页的HTTP交换；

图3示出根据现有技术的面向DASH的客户端-服务器系统；

图3a示出可以实现本发明的实施例的客户端-服务器系统；

图3b示出可以实现本发明的实施例的面向DASH的客户端-服务器系统；

图4a示出媒体呈现的构建；

图4b示出DASH媒体呈现描述(MPD)文件的构造；

图5a示出例示图3a的系统中的客户端的行为的主要步骤；

图5b示出例示图3b的系统中的面向流传输的客户端的行为的主要步骤；

图6a示出例示图3a或3b的系统中的服务器的行为的主要步骤；

图6b示出根据本发明的推送头部的示例性构造；

图7a示出具有SegmentTemplate(片段模板)的示例性MPD文件；

图7b示出基于图7a的MPD文件的实现本发明的客户端-服务器交换；

图8示出在DASH流传输的背景下的根据本发明的推送头部的示例；

图9是根据实施例的装置的示意例示；

图10示出例示模板URI在多个级别的声明的MPD样本；

图11a～11e示出确认服务器内的推送策略通知的示例；以及

图12a和图12b示出基于唯一标识符来在客户端和服务器之间交换与推送策略有关的信息的示例。

具体实施方式

如以上简要介绍的，本发明涉及经由HTTP通信网络的数据传输。应用示例是诸如DASH等的自适应数据流传输。

HTTP是发送web资源(通常是网页)所使用的协议。HTTP向客户端和服务器表明：

-客户端向服务器发送请求，其中该请求由“request_line”(可选地跟随有不同种类的“头部(header)”)形成。“request_line”通常包含方法(例如，“GET”)以及(可能地利用Range头部等来)标识服务器上的所请求的资源或数据的“Request-URI(请求-URI)”参数；

-服务器利用包含web资源的表现的应答来回复客户端的请求。

请求和应答是包括各个部分(特别是HTTP头部)的消息。HTTP头部包括名称和值。例如，如果考虑“Host:en.wikipedia.org”，则“Host”是头部名称，并且其值是“en.wikipedia.org”。该“Host:en.wikipedia.org”用于表示所查询的资源的主机(例如，描述HTTP的Wikipedia(维基百科)页可在http://en.wikipedia.org/wiki/HTTP处获得)。HTTP头部出现在客户端请求和服务器应答上。

HTTP/2(HTTP的新版本)使得可以经由流来交换请求/应答。针对每个HTTP请求和应答交换在HTTP/2连接内创建流。帧在流内进行交换，以传送请求和应答的内容、伪头部和头部。

HTTP/2定义具有不同含义的有限组帧，诸如以下等：

-HEADERS(头部)：其是针对HTTP头部的发送所提供的

○HTTP/2将头部(在不被处理装置理解的情况下是可选的、即被忽略)与遵循更为严格的规则的伪头部区分开。伪头部与在先前HTTP版本中所定义的用以表示HTTP方法和请求-URI的请求行的映射相对应。在本文中，“HTTP头部”或“头部”意在指定可选头部，而不意在指定以显式方式指定为伪头部的伪头部。

○此外，还在本文中，“Request-URI”是指指定如RFC2616中所定义的Request-URI(即，标识如“请求行”中所使用的服务器上的所请求资源的参数)或者其等同物/向HTTP/2伪头部内的转译。

-DATA(数据)：其是针对HTTP消息内容的发送所提供的

-PUSH_PROMISE(推送承诺)：其是为了通报所推送的内容所提供的

-PRIORITY(优先级)：其是为了设置流的优先级所提供的

-WINDOW_UPDATE(窗更新)：其是为了更新控制流窗的值所提供的

-SETTINGS(设置)：其是为了传送配置参数所提供的

-CONTINUATION(继续)：其是为了继续头部块碎片的序列所提供的

-RST_STREAM(RST流)：其是为了终止或取消流所提供的。

在HTTP/2中，请求然后被转变成第一HEADER帧+一个或多个DATA帧，其中在该一个或多个DATA帧中，如在HTTP/2规范中所述，来自HTTP/1.x的请求行被转译成伪头部字段。

本说明书使用“请求”或“HTTP请求”来指定从客户端向服务器发送的消息，并且使用“应答”或“HTTP应答”来指定从服务器向着客户端的消息。除请求和应答外，还讨论与服务器向客户端发起的消息相对应的通知或服务器通知。该用词符合HTTP/1.x和HTTP/2。

在HTTP/2中引入了利用服务器的推送，以使得服务器能够将未经请求的web资源表现发送至客户端。诸如网页等的web资源通常包含向其它资源的链接，而这些其它资源自身可能包含指向其它资源的链接。为了完全显示网页，客户端通常需要检索所有链接和子链接的资源。特别是在诸如移动网络等的高延迟网络上，该递增式发现可能导致网页的缓慢显示。

在接收到针对给定网页的请求的情况下，服务器可能知晓针对所请求的源的完整处理而需要哪些其它资源。通过同时发送所请求的资源和所链接的资源，服务器使得能够缩短网页的加载时间。因而，使用推送特征，服务器可以在该服务器被请求了给定资源时，发送附加资源表现。

作为链接资源的示例，图1a是服务器所拥有的一组资源及其关系的图表。该组资源交织存在：R₁、R₂、R₃和R₄是需要共同下载以由客户端进行适当处理的资源。另外，定义了子资源A～H。这些子资源与1个、2个或3个资源相关。例如，A链接至R₁，并且C链接至R₁、R₂和R₄。

参考图1e的流程图来说明实现推送特征的服务器的示例操作模式。

在步骤100期间，服务器接收到初始请求。接着，服务器在步骤101期间识别作为应答的一部分的要推送的资源，并且在步骤102期间将PUSH(推送)承诺消息发送至客户端。然后，服务器在步骤102期间开始发送内容应答。PUSH承诺消息例如基于图1a所示的依赖性来标识服务器正计划推送的其它资源。这些消息是为了让客户端预先知晓将发送哪些推送资源而发送的。特别地，这样降低了客户端针对正同时推送或将要推送的资源而发送请求的风险。为了进一步降低该风险，服务器应在发送涉及推送承诺中所描述的资源的应答的任何部分之前，发送推送承诺消息。这样还使得客户端能够在这些客户端不想要这些资源的情况下，请求取消所承诺的资源的推送。接着，服务器在步骤104期间发送应答和所有承诺的资源。该处理在步骤105期间结束。

图1b和1c分别示出在没有使用推送特征的情况下和在使用推送特征的情况下的网页加载。

图1b示出在没有使用服务器PUSH特征的情况下的HTTP交换：客户端请求R₁，接着客户端发现R₂、A、B、C和D并且请求这五者。在接收到这些资源之后，客户端请求R₃、R₄、F和G。最终，客户端请求H子资源和I子资源。因而，必须针对所需的每个资源(资源R₁～R₄和子资源A～I)发送请求。此外，该处理需要四次往返以检索到整组资源。

图1c示出服务器使用推送直接连接的子资源这一特征的HTTP交换。在请求R₁之后，服务器发送R₁并且推送A、B、C和D。客户端识别出R₂并且请求该R₂。服务器发送R₂并且推送F和G。最后，客户端识别出R₃和R₄并且请求这些资源。服务器发送R₃和R₄并且推送H和I。因而，请求的次数限于元素R₁～R₄。元素A～I由服务器基于图1a所示的依赖性“推送”至客户端，由此使得关联的请求变得不必要。该处理需要三次往返以检索整组资源。

因而，如图1b和1c所示，在服务器使用推送特征的情况下，加载资源及其子资源所需的HTTP往返(请求+应答)的次数减少。这是诸如移动网络等的高延迟网络特别关注的。

为了缩短一组资源(通常是网页及其子资源)的加载时间，HTTP/2使得能够并行地交换多个请求和应答优先级。如图2所示，网页可以要求下载如JavaScript、图像等的多个资源。在初始HTTP交换200期间，客户端检索HTML文件。该HTML文件包含指向两个JavaScript文件(JS1,JS2)、两个图像(IMG1,IMG2)、一个CSS文件和一个HTML文件的链接。在交换201期间，客户端针对各文件发送请求。图2的交换201中所给出的顺序基于网页顺序：一发现链接，客户端就发送请求。然后，服务器接收到针对JS1、CSS、IMG1、HTML、IMG2和JS2的请求，并且根据该顺序来处理这些请求。然后，客户端按该顺序检索这些资源。

客户端可能想要具有用于下载Web页描述(HTML文件)中所引用的子资源的适当顺序。在这种情况下，服务器具有该信息、特别是使用该顺序来实现推送特征可能非常有用。

图1d的流程图示出在实现推送特征时客户端侧的处理。

在客户端识别出要从服务器检索的资源的情况下，客户端首先在步骤106期间检查相应数据是否已存在于该客户端的高速缓冲存储器中。在资源已存在于高速缓冲存储器中的情况下(“是”)，在步骤107期间从该高速缓冲存储器检索该资源。高速缓存数据可以是根据先前的请求所检索到的数据或者服务器先前推送的数据。在资源不存在于高速缓冲存储器中的情况下(“否”)，客户端在步骤108期间发送请求并且等待服务器的应答。

在从服务器接收到帧时，客户端在步骤109期间检查该帧与PUSH承诺是否对应。如果数据帧与PUSH承诺相对应(“是”)，则在步骤110期间，客户端处理推送承诺。为此，客户端识别要推送的资源。如果客户端不希望接收资源，则客户端可以向服务器发送错误消息，因而服务器不会推送该资源。否则，客户端存储该推送承诺，直到接收到相应的推送内容为止。使用推送承诺，使得在服务器正推送所承诺的资源的情况下，客户端不会请求该所承诺的资源。

在数据帧与PUSH承诺不对应的情况下(“否”)，在步骤111期间检查该帧是否是与推送数据有关的数据帧。在该帧与推送数据有关的情况下(“是”)，客户端在步骤112期间处理所推送的数据。将所推送的数据存储在客户端高速缓存内。

在该帧不是与推送数据有关的数据帧的情况下，在步骤113期间检查该帧与从服务器接收到的应答是否对应。在帧与来自服务器的应答相对应的情况下(“是”)，在步骤114期间处理该应答(例如，发送至应用程序)。

否则(“否”)，在步骤115期间检查帧是否标识出应答的结束(“是”)。在这种情况下，在步骤116期间终止该处理。否则，处理循环回至步骤109。

因而，似乎客户端接收到应答和所承诺的资源。因此，所承诺的资源通常存储在客户端高速缓存中，同时该应答由诸如显示所检索到的网页的浏览器等的应用程序使用。在客户端应用程序请求所推送的资源其中之一的情况下，从客户端高速缓存立即检索到该资源，而不会引起任何网络延迟。

使用高速缓存控制指令来控制高速缓存中的所推送的资源的存储。高速缓存控制指令还用于进行应答的控制。这些指令特别适用于代理：所推送的或未被推送的任何资源均可仅由代理或仅由客户端来进行存储。

如上所述，客户端可能想要具有用于下载Web页描述(HTML文件)中所引用的子资源的适当顺序，因而应当由服务器驱动推送特征。本发明意图从该方面改善当前情形，例如以向服务器通知客户端在请求第一资源之后可能想要的特定一组(子)资源或(子)资源的一部分。特别地，本发明试图适合客户端识别出(子)资源的智能化为最低限度的服务器、例如不具有用以处理Web页描述等的知识的服务器。

对本发明的这种需求在使用推送特征的情况下，在经由HTTP的HTTP流传输的背景下(例如，在诸如DASH等的自适应HTTP流传输的背景下)增加。

图3示出经由HTTP的媒体流传输的一般原则。针对经由HTTP的自适应流传输的新协议和标准中的大部分协议和标准均基于该原则。这是以下的说明所参考的DASH的情况。

媒体服务器300将数据流传输至客户端310。媒体服务器存储媒体呈现。例如，媒体呈现301包含音频数据和视频数据。音频和视频可以交错存在于同一文件中。以下参考图4a来说明构建媒体呈现的方式。该媒体呈现从时间上分割成可以单独进行寻址并下载的诸如MP4片段等的小的独立且连续的时间片段302a、302b和302c。这些时间片段各自的媒体内容的下载地址(HTTPURL)由服务器向客户端进行设置。音频/视频媒体内容的各时间片段与一个HTTP地址相关联。

媒体服务器还存储描述媒体呈现的内容的清单(manifest)文件文档304(在图7a中示出其示例)，其中该内容包括媒体内容特性(例如，媒体的类型：音频、视频、音频-视频、文本等)、编码格式(例如，比特率、定时信息等)、时间媒体片段的列表和关联的URL。可选地，该文档包含使得可以重建时间媒体片段的显式列表和关联的URL的模板信息。可以使用可扩展标记语言(XML)编写该文档。

将清单文件发送至客户端。在步骤305中接收到清单文件时，向客户端通知媒体内容的时间片段和HTTP地址之间的关联。此外，清单文件向客户端提供与媒体呈现的内容(在本示例中为交错存在的音频/视频)有关的信息。该信息可以包括分辨率、比特率等。

基于所接收到的信息，客户端的HTTP客户端模块311可以发出用于下载清单文件中所描述的媒体内容的时间片段的HTTP请求306。服务器的HTTP应答307传送所请求的时间片段。HTTP客户端模块311从应答中提取时间媒体片段并且将这些时间媒体片段提供至媒体引擎312的输入缓冲器307。最后，可以在步骤308和309期间，分别对媒体片段进行解码并显示。

媒体引擎312与DASH控制引擎313相互作用，以在适当时间发起针对后续时间片段的请求。从清单文件中识别下一片段。发起请求的时间依赖于接收缓冲器307是否为满。DASH控制引擎313控制该缓冲器以防止该缓冲器过载或完全为空。

参考图4a来说明媒体呈现和清单文件的生成。在步骤400和401期间，获取音频数据和视频数据。接着，在402期间对音频数据进行压缩。例如，可以使用MP3标准。此外，在步骤403期间并行地对视频数据进行压缩。可以使用如MPEG4、MPEG/AVC、SVC、HEVC或可扩展HEVC等的视频压缩算法。一旦进行了音频数据和视频数据的压缩，则可利用音频基本流404和视频基本流405。在步骤406期间将这些基本流封装到全局媒体呈现中。例如，可以使用ISO BMFF标准(或该ISO BMFF标准向AVC、SVC、HEVC、HEVC的可扩展延伸等的延伸)来将编码后的音频基本流和视频基本流的内容描述为全局媒体呈现。使用如此获得的封装后的媒体呈现407来在步骤408期间生成XML清单文件409。视频数据401和音频数据400的多个表现可被获取、压缩、封装并描述在媒体呈现407中。

针对图4b所示的MPEG/DASH流传输协议的特定情况，将清单文件称为“媒体呈现描述”(或“MPD”文件)。该文件的根元素是包含适用于所有呈现的属性和如profile或schema那样的DASH信息的MPD元素。将媒体呈现分割成由Period(时间段)元素表示的时间段。MPD文件410包含与各时间段有关的所有数据。通过接收该信息，客户端知晓各段时间的内容。针对各Period 411，定义AdaptationSet元素。

可能的组织是呈现中所包含的各媒体类型具有一个或多个AdaptationSet。与视频有关的AdaptationSet 412包含与在服务器处可利用的编码视频的可能的不同表现有关的信息。在Representation(表现)元素中描述各表现。例如，第一表现可以是以空间分辨率640×480进行编码并且以比特率500kbits/s进行压缩后的视频。第二表现可以是以比特率250kbits/s进行压缩后的同一视频。

如果客户端得知与该视频有关的HTTP地址，则可以利用HTTP请求来下载各视频。通过使用附加描述级别即时间片段来进行各表现的内容和HTTP地址之间的关联。将各视频表现分割成时间片段413(通常为几秒)。各时间片段包括服务器中所存储的经由HTTP地址(URL或具有一个字节范围的URL)可访问的内容。可以使用如下的多个元素来描述MPD文件中的时间片段：SegmentList(片段列表)、SegmentBase(片段基础)或SegmentTemplate。

另外，可利用特定片段即初始化片段。该初始化片段包含(在使用ISOBMFF或其扩展对视频进行了封装的情况下)描述封装后的视频流的MP4初始化信息。例如，该初始化片段帮助客户端实例化与视频有关的解码算法。

在MPD中示出初始化片段和媒体片段的HTTP地址。要注意，在本说明书中，使用“片段”来指定时间碎片(例如：在根据ISO/IEC 14496的第12部分和第15部分对媒体进行封装的情况下为mp4文件中的一个或多个moof+mdat框)或时间片段(例如，以“styp”指示开始的mp4片段)。

在图7a中，示出示例性MPD文件。在所示的MPD文件中描述两个视频表现。第一个视频表现是低分辨率版本(“Representation id＝“h264bl_low””)，而第二个视频表现是更高分辨率版本(“Representation id＝“h264bl_full””)。这两个视频表现都包含在同一AdaptationSet中，并且通过SegmentTemplate URL对来自各表现的各片段进行寻址(“media＝“mp4-live-$RepresentationID$-$Number$.m4s”，其中$RepresentationID$在两个可能的视频表现之间改变，并且$Number$沿着视频中的位置而改变)。

为了清楚，没有表现可能的关联音频流，但可以在另一AdaptationSet中描述各自具有替代版本的这些音频流。

在开始流传输会话时，DASH客户端请求清单文件。一旦接收到清单文件，客户端分析该清单文件，选择适合其环境的AdaptationSet的集合。接着，客户端在各AdaptationSet内选择MPD中符合其带宽、解码和渲染能力的Representation。接着，客户端可以预先构建以针对媒体解码器的初始化信息开始的要请求的片段的列表(在图7a的示例中为SegmentTemplate@initialization URL)。在解码器接收到初始化信息的情况下，这些解码器被初始化，并且客户端在实际开始进行显示之前，请求第一媒体数据并且对最小数据量进行缓冲。

这多个请求/应答可能在流传输会话的启动时引入延迟。其风险是服务提供方注意到他们的客户在没有开始观看视频的情况下离开该服务。常见是将在客户端所进行的针对第一媒体数据块的初始HTTP请求和该媒体数据块实际开始播放的时间之间的这个时间命名为启动延迟。该启动延迟依赖于网络往返时间，而且还依赖于媒体片段的大小：片段越长，启动延迟越长。

另外，在实时流传输中，在客户端请求媒体片段时，该片段在服务器上可能没有就绪。为了减少延迟，缩短片段长度可能是值得的。然而，这样缩短片段长度可能会大大增加请求/应答的数量并且可能会导致极大的网络通信量开销。

为了减少这种通信开销量增加，所提出的方法是在服务器处使用HTTP/2的推送特征，以使得能够仅按照服务器的主动性向客户端推送数据。更一般地，关于HTTP，这种方法(推送特征的使用)使得可以减少HTTP客户端和HTTP服务器之间的往返次数(然后减少延迟)，使得资源可被组织成多个子资源(例如，包含css、jscript、图像等的Web页；包含片段的列表的DASH清单)。

如上所述，在公开WO 2015/004276中已提出了在经由HTTP的DASH流传输的背景下的推送特征的这种使用。

该公开中所提出的机制要求服务器装置具有DASH的专业知识，特别是能够在MPD文件上应用推送策略以根据推送策略来确定要推送哪些数据或资源。

这些机制违背经由HTTP的自适应流传输的一些有用方面。

更精确地，经由HTTP的自适应流传输基于引导流传输这一假设，这是因为客户端通常可以选择用于该目的的最佳版本的多媒体内容。例如，客户端基于其形状因数和屏幕分辨率可以知晓是请求HD还是SD视频。将推送特征用于经由HTTP的自适应流传输应当保持这种行为，从而使得客户端能够针对所推送的数据对服务器进行完全驱动。

另外，如MPEG DASH标准那样的经由HTTP的自适应流传输几乎不需要服务器端的智能：由于客户端所发送的HTTP请求简单，因此简单的HTTP服务器足以服务清单和媒体片段。服务器的这种简单性使得可以在不需要与超出HTTP的标准web使用的服务器资源有关的任何附加成本的情况下，提供大量流传输客户端。特别地，可以使用标准HTTP优化技术经由内容传送网络来管理该大量流传输客户端。将推送特征用于经由HTTP的自适应流传输应当保持该服务器的简单性。

本发明的目的是改善在HTTP的一般背景下的推送特征的使用。本发明特别适用于经由HTTP的流传输和诸如DASH等的经由HTTP的自适应流传输。然而，本发明应优选尽可能多地保持经由HTTP的自适应流传输的现有有用特征。这意味着应当尽可能多地满足以下要求：

-保留客户端控制发送以避免服务器推送潜在无用(对于客户端而言)数据；

-防止在服务器侧使用特定应用程序知识以保持上述的可扩展性优势；

-保留以传统方式请求资源和子资源的方式，以保持将不会实现本发明的旧版客户端和/或服务器之间的互操作性和高速缓存能力。例如，在DASH片段的情况下，这样应避免引入将要求特定操作(例如，请求-URI的转译等)来处理所请求的片段的任何请求格式；

-使服务器侧的处理保持低。

本发明的思想是在请求第一数据或资源的传统HTTP请求中包括如下的可选信息，其中该可选信息向服务器(在可能的情况下使用推送机制)提供提示以确定客户端希望接收的附加资源/数据或资源、或者向服务器提供提示以判断为客户端不希望接收任何附加资源。特别地，这些提示是以附加资源/数据或者资源的确定不使用上下文信息或该请求外部的信息的方式来定义的。HTTP请求可被视为与附加资源/数据或者资源的定义有关的自动描述请求。

以下说明这些提示的示例，并且这些提示的示例包括显示URI/URL或者URI/URL的列表、通过基于自动描述HTTP请求的构建规则的使用的隐式URI/URL、以及资源/数据的过滤规则。

根据本发明的服务器侧方法寻求在服务器装置和客户端装置之间传输数据，并且在服务器装置处包括以下步骤：

从客户端装置接收用以获得第一数据的HTTP请求，其中该HTTP请求包括使得能够识别服务器装置上的第一数据的第一数据识别信息，并且包括使得能够指向第二数据的一个或多个可选头部字段；

检索第一数据并将该第一数据发送至客户端装置；以及

在可选头部字段存在于HTTP请求中的情况下：

仅使用该可选头部字段并且可能地使用第一数据识别信息，来确定使得能够识别服务器装置上的第二数据的第二数据识别信息。即，HTTP请求对于确定第二资源而言是自给自足的，即可自动描述的；以及

将用以通报第二数据的推送的推送承诺消息发送至客户端装置、以及/或者将第二数据推送至客户端装置。

根据特定实施例，将确认数据发送至客户端，以向客户端通知服务器将按照客户端的请求推送第二数据或附加资源，通知服务器将不会推送任何第二数据或附加资源，或者向客户端提供提示以确定服务器可以发送的第二数据或附加资源/数据或者资源。

根据本发明的客户端侧方法尝试在服务器装置和客户端装置之间传输数据，并且在客户端装置处包括以下步骤：

识别从服务器装置要获得的数据；

生成用以从所识别的数据获得第一数据的HTTP请求，其中该HTTP请求包括使得能够识别服务器装置上的第一数据的第一数据识别信息，并且包括一个或多个可选头部字段，其中该一个或多个可选头部字段仅基于可选头部字段并且可能地基于第一数据识别信息(即，仅基于HTTP请求的内容)来定义使得能够从服务器装置上的所识别数据识别第二数据的第二数据识别信息；

将HTTP请求发送至服务器装置以获得第一数据并且驱动服务器装置推送第二数据。

根据特定实施例，客户端在接收到与推送请求有关的确认数据时，变更其策略以获得第二数据或附加资源。

注意，第一数据识别信息通常与HTTP请求的“请求行”的请求-URI形成部分相对应(或其向HTTP/2伪报头的转译)。

本发明所提出的方法满足上述要求的全部或一部分。

首先，本发明的方法使得客户端可以在请求数据的同时向服务器指示一个或多个附加或相关资源。由于客户端将在无需发送针对这些资源的特定请求的情况下接收到这些资源，因此减少了网络通信量和延迟。

此外，本发明的方法使得可以(经由PUSH承诺帧)向客户端通知(基于根据本发明的服务器对可选头部的支持)是客户端将接收附加资源还是客户端必须请求附加资源。因而，保留与现有流传输服务器的向后兼容性，并且应使特征的部署更加容易。

此外，本发明的方法使得服务器可以在不需要容易地识别应用程序专有知识的情况下，容易地识别要推送至客户端的下一资源。因而，服务器侧的处理是有限的，并且可以授权大量客户端向同一服务器进行请求。

图3a示出本发明的实现所用的客户端/服务器系统的通用例示。在下文，无差别地引用“视频”、“媒体”或“内容”以指定资源，其中已知视频是媒体或内容的特定情况。同样，无差别地引用“MPD”或“清单”或“流传输清单”或“HTML页”，以指定要从服务器发送至客户端的媒体资源的描述文件。

本发明的目的在于改善如图3a所示的客户端和服务器之间的HTTP通信(特别是数据流传输)，并且更精确地，目的在于减少资源加载和网络通信量开销所用的这两个时间。

服务器350存储客户端380可以下载的资源。服务器上的资源被分类为引用或包含子资源(352a、352b、352c)的主资源351。

例如，主资源可以是HTML页，并且子资源可以是主资源中所引用的css资源、图像和/或媒体文件、java脚本代码或其它HTML页。可以在静态配置文件355中描述这些资源的访问权限和组织。

客户端380所发出的HTTP请求由HTTP处理器356接收到并进行处理，其中该HTTP处理器356包括请求解析器357，其中该请求解析器357用于将该请求分解成资源标识和头部处理。

本发明考虑推送头部处理器358所进行的一个特定头部处理。如以下所述，推送头部处理器358负责处理在HTTP请求中为可选的一个或多个特定推送头部。如以上简要介绍的，根据一个或多个特定推送头部并且仅使用HTTP请求，服务器能够产生向附加资源的一个或多个引用以推送这些附加资源。

资源管理器360负责检查资源的有/无/新鲜度，并且将所请求的资源提供回至HTTP处理器356。接着，应答生成器359将所提供的这些资源封装在发送至客户端的一个或多个HTTP应答(HTTP/1.x)或(采用HTTP/2的形式的)帧中。

客户端380具有供用户对多个客户端模块所处理的内容进行选择、与该内容相互作用并观看该内容所用的用户接口381。

用户接口381将用户点击转换为针对HTTP客户端382中的请求调度器383所处理的附加内容的请求。针对附加内容的请求可被转变为要下载的资源的列表。HTTP客户端382处理与HTTP服务器350的通信。

HTTP客户端包括请求生成器384，其中该请求生成器384用于构建用以向服务器350请求资源的HTTP请求(HTTP1.x)或帧(HTTP/2)。

根据本发明，HTTP客户端382包含特定模块、即负责在HTTP请求中插入上述的特定(可选)推送头部的推送头部生成器385，其中该推送头部表示在请求调度器383中等待的下一资源，并且/或者表示推送策略、推送对策或推送指令。根据特定实施例，推送头部可以包括推送类型并且可能地包括关联参数。

从服务器接收到的应答或通知由应答解析器386进行处理，其中该应答解析器386提取数据并将这些数据存储在客户端高速缓冲存储器/存储器387中。应答头部中所传送的信息还由HTTP客户端311接收到并进行处理，并且(例如，在DASH应用程序是使用XmlHTTPRequest以javascript代码编写的情况下)可被提供至DASH控制引擎313。

这些数据由渲染引擎388使用，其中该渲染引擎388解析(389)该数据以将这些数据分派至适当的解码模块390。基于该数据，后者将重建数据提供至显示器391以供在用户接口381上进行渲染。

根据本发明，解析模块389能够分析所接收到的数据的内容以识别用户潜在感兴趣的任何附加资源。在这种情况下，解析模块389将这些附加资源添加在请求调度器383中。

在图5a中示出客户端的行为，而在图6a中示出服务器的行为。

参考图5a，在步骤551中，客户端使用HTTP请求(例如，采用HTML的Web页或者流传输清单)来请求主资源。在步骤552中(使用模块389)解析Web页所用的HTML代码，以识别包括Web页的资源。使用解析的结果，客户端识别客户端为了能够渲染整个页而需要下载的资源的列表。这是步骤553，并且将资源的列表存储在调度器383中。

在步骤554中，客户端生成并发送第一HTTP请求以从服务器获得第一识别资源。根据本发明，客户端(模块385)还可以在特定推送头部中表示该客户端想要服务器进行推送的附加/相关资源的列表。这是步骤555。以下提供特定推送头部的句法的示例。

在步骤556中从服务器接收到一个或多个应答时，客户端(模块384)检查(步骤557)是否接收到通报数据的推送的服务器通知(即，PUSH承诺)。在完全接收到第一资源的数据的情况下，可以停止该检查。这是因为，在关闭与所请求的第一资源相对应的流之后，不能发送与由特定推送头部定义的附加/相关资源有关的PUSH承诺。这里需要重申，不支持特定推送头部的服务器将不会发送针对该头部中所定义的附加/相关资源的PUSH承诺，并且将简单地忽略该头部。

如果该检查为否定，则所接收到的数据仅是所请求的第一资源的数据。因而，这些数据在步骤560中由模块384进行处理，并且被提供至渲染引擎288。然后，该处理循环回至步骤555，从而请求在请求调度器383中存储的更多资源(步骤561)。

如果该检查为肯定、这意味着服务器通报该服务器将在特定推送报头中推送客户端所暗示的资源中的一些资源，则客户端更新资源调度器382中的要下载的资源的列表，以将所推送的资源从该列表中撤消。这是步骤558。然后，客户端在进行迭代(步骤561并且循环回至步骤555)、直到在请求调度器382中不存在更多要下载的资源为止之前，处理第一资源的数据(步骤560)和其它附加/相关资源的数据(步骤559)。

现在转向图6a，值得注意的是，服务器350使用专用“推送头部”处理器358来处理客户端380在HTTP请求中所提供的特定推送头部。此外，HTTP处理器356负责解析HTTP请求并且提取该请求中所包含的各种参数，其中这些参数包括所请求的第一资源的URI以及可选的头部。因而，HTTP处理器385经由特定(可选)推送头部的名称识别该特定(可选)推送头部，然后将该特定(可选)推送头部转发至推送头部处理器358以供处理。

在步骤601中，服务器接收并处理来自客户端380的请求以获得主资源(例如，在流传输的背景下的流传输清单)。该主资源由HTTP处理器356进行处理。

接着，在步骤602中，服务器通过发送清单数据来回复。在步骤603中，服务器从客户端接收请求第一资源(通常是清单数据中所引用的第一资源)的新请求。该请求可以是媒体流传输的背景下的媒体片段。

在该请求中，客户端还可能使用特定推送头部指示了该客户端感兴趣的附加或相关资源。因而，在步骤604中，服务器检查这种特定推送头部是否包括在该请求中。

如果这种特定推送头部包括并被填充在该请求中，则服务器将该特定推送头部提供至特定推送头部处理器358。特定推送头部处理器358如以下所述解析推送头部的不同部分，以生成向客户端所指示的附加或相关资源的一个或多个参考。这是步骤605。

可选地，服务器可以具有预先配置的授权文件，其中该授权文件针对服务器具有的资源列表中的各资源声明该服务器是否可以推送该资源。在步骤606中可以遍历该授权文件以使步骤605中所获得的一些引用有效或无效。

服务器向客户端通知仅针对根据授权文件被授权推送的资源的推送通报消息(例如，PUSH PROMISE(推送承诺)帧)。这是步骤607。在HTTP/2中，在与客户端的请求相对应的流上发送PUSH PROMISE帧，其中针对步骤605中所识别的各资源存在一个PUSH PROMISE帧。在步骤607之后是步骤608，其中在该步骤608中，服务器将所请求的第一资源(流传输背景下的第一媒体片段)发送至请求客户端。

如果不存在或不支持特定推送头部(测试604为假)、或者如果针对所识别出的资源没有授权推送(步骤606为假)，则在步骤608中，仅将所请求的第一资源发送回至客户端。

在发送所请求的第一资源之后，服务器关闭相应流并且使用经由推送通报消息(PUSH PROMISE帧)所通报的流(除非被客户端取消)，以推送在步骤605中识别出的附加或相关资源的数据。这是步骤609，其中在该步骤609中，发送可以依赖于发送一个或多个DATA帧。

如上所述，根据特定实施例，将确认数据发送至客户端，以向客户端通知服务器将按照客户端的请求推送第二数据或附加资源，通知服务器将不推送任何第二数据或附加资源，或者向客户端提供提示以确定服务器可以发送的第二数据或附加资源/数据或资源。

因此，如参考610所示，服务器可以将确认数据添加至响应于所接收到的请求而发送的应答，以向客户端通知服务器将按照客户端的请求推送第二数据或附加资源，通知服务器将不推送任何第二数据或附加资源，或者向客户端提供提示以确定服务器可以发送的第二数据或附加资源/数据或资源。通过参考图11a～11e给出这种确认数据的示例。

图3b示出数据流传输(例如，DASH)的背景下的客户端-服务器系统。与图3中的组件相同的组件具有相同的附图标记。

在负责确定要下载的媒体片段的DASH控制引擎313中，添加附加模块，以与HTTP客户端311通信DASH控制引擎313内的请求调度模块所引用的要下载的下一片段的列表。

在HTTP客户端311中利用特定“推送头部”生成器314处理该信息。从要下载的下一片段的列表中，推送头部生成器314负责例如通过将要下载的下一片段的列表映射到特定推送头部的不同部分上，来生成针对特定推送头部的适当句法。

推送头部生成器314所输出的特定推送头部被供给至HTTP客户端311以插入在当前HTTP请求中。

在服务器侧，HTTP处理器320和推送头部处理器321与以上参考图3a所述的HTTP处理器356和推送头部处理器356相同，但是面向流传输和DASH。

图5b示出例示图3b的系统中的面向流传输的客户端的行为的主要步骤。

在步骤501中，客户端310向流传输服务器300请求与所希望的媒体相关联的流传输清单。在接收到流传输清单时，客户端310在步骤502中解析该流传输清单，然后在步骤503中选择视频Representation。

在媒体的流传输期间以迭代方式，客户端选择要向服务器请求的下一片段以供下载。这是步骤504。

接着，步骤505在于识别客户端可能需要的将来片段。该确定包括DASH控制引擎313中的请求调度器预期将来片段：例如，决定请求调度器是不久将切换还是保持于同一Representation级别。

为了预期下一片段的下载，客户端可以识别随后渲染所需的数量“K”个将来片段(K由客户端设置)。

例如，这可以通过以下操作来直接进行：解析MPD中的SegmentList以检索从当前片段起的接下来的K个片段；或者使用MPD中所设置的SegmentTemplate来计算接下来的K个片段的片段数量；或者在通过字节范围对片段进行寻址的情况下、计算来自mp4框的接下来的K个字节范围。

然而，在步骤505的识别处理中可以使用不同的选择标准。

在自适应流传输的背景下，选择标准可以涉及客户端的在Representation之间进行切换时的切换对策。例如，在客户端采用积极型推送对策的情况下，优选K被定义得低(例如，与涵盖小于5秒的多个片段相对应)，以允许更精细的切换粒度。另一方面，在客户端采用保守型对策并且没有过于频繁地进行切换的情况下，K可被设置得更大(例如，设置为涵盖多于10秒的多个片段)。

此外，在自适应流传输的背景下，另一选择标准可以涉及服务器的PUSH PROMISE能力。例如，如果服务器不能在适当时间承诺或发送与客户端所暗示的一样多的片段，则客户端可以考虑到该信息以减小K的值。这样导致每次建议较少的媒体片段以供推送。

此外，在自适应流传输的背景下，另一选择标准可以涉及客户端的预取对策。例如，为了快速寻找的目的，客户端可以在不同时间段的开头选择第一片段。或者，如果视频应用程序提供与视频中的最流行部分有关的信息，则标准可以包括选择与这些最流行部分相对应的第一片段。

另一可能的面向流传输的选择标准可能是由于清单即MPD的分析而产生的。例如，客户端可以建议服务器推送与所选择的Representation相关联的片段。该操作可以利用关联Representation之间的associationId(关联Id)来容易地确定。该建议可以依赖于associationType(关联类型)信息。此外，对于依赖型Representation，可以建议增强层的片段以供推送。

更一般地，在经由HTTP的资源下载(例如，Web页)中(参见图3a和5a)，客户端(Web浏览器、HTML渲染器)可以分析主资源以识别该主资源想要快速下载的该主资源中所引用的子资源。通过解析HTML主资源，客户端例如可以依赖于：

-<link>元素，其具有表示“预取”或“下一个”的“rel”值；

-<link>元素，其表示样式表相关资源以例如选择CSS资源；

-<script>元素，用以选择例如与java脚本代码相对应的子资源；

-如<img>和/或<video>那样的媒体元素。

从在HTML页中潜在声明的这些元素中，客户端可以经由这些元素的“href”属性选择URI的列表。URI的该列表可以放置在一个或多个特定推送头部中，例如针对各资源类型、或者串连在单个头部中作为URI的列表、或者被组织为具有与众所周知的Accept(接受)HTTP头部中的“q”值相似的优先级的列表。

在步骤505中选择并识别K个附加或相关资源之后，客户端生成用以获得步骤504中所识别的下一片段的HTTP请求。这是步骤506。

使用下一片段的URL或具有字节范围的SegmentBase URL来形成HTTP请求(除用以形成请求行的HTTP方法外)。

根据本发明，附加步骤507包括：HTTP客户端311的推送头部处理器314获得DASH控制引擎313在步骤505中所确定的将来片段(即，附加资源)的列表，并且设置特定推送报头以定义这些将来片段。

可以如以下所述实现用以声明客户端想要服务器推送的将来片段的多个方式。

一旦(包括针对下一片段的请求行并且包括用于建议附加片段的推送的特定推送报头的)HTTP请求就绪，仍然在步骤507中，利用HTTP客户端311将该HTTP请求发送至服务器300。

在步骤508中从服务器接收到应答时，客户端检查服务器是否发送表示服务器将主动发送特定推送头部中所定义的附加片段的推送通报通知。该检查是步骤509。

例如，在HTTP/2中，可以利用一个或多个PUSH PROMISE帧来进行推送通报通知(针对每个将来片段存在一个PUSH PROMISE帧)。

如果完全接收到步骤504中选择的所请求的下一片段的数据(相应流由服务器关闭)、并且没有接收到推送通报通知(测试509中为假)，则HTTP客户端311向DASH控制引擎通知要请求的下一片段是紧挨之后的片段。这是步骤510。

否则(测试509中为真)，使用新的HTTP请求要请求的下一片段是紧挨在承诺推送的最后片段之后的片段。在步骤511中进行客户端侧的更新。同时，在步骤512中，HTTP客户端从服务器接收到K个将来片段的数据。

在步骤510和512之后，处理循环回至步骤505，以迭代该处理，直到流传输停止为止。

可选地，客户端310可以在HTTP客户端311中实现要获得的K个将来片段的处理。在这种实现中，这是负责确定要下载的下一片段的HTTP客户端。然后，HTTP客户端311所接收到的所推送数据将针对DASH控制引擎313预先填充客户端高速缓冲存储器(307)，使得在请求下一片段时，DASH应用级别处的所感知延迟减少。

根据特定实施例，客户端在接收到与推送请求有关的确认数据时，处理所接收到的确认数据(步骤513)，例如以变更该客户端的用以获得第二数据或附加资源的对策。通过参考图11a～11e给出处理这种确认数据的示例。

现在转向特定推送头部的句法，作为每个HTTP头部，利用{name,value}对来进行标识，其中利用冒号“:”将名称和值分隔开。

头部名称例如可以是“Push-Request(推送请求)”或者任何其它名称，假设该名称不会与另一现有头部名称冲突。如果头部名称是应用程序专用头部，则该名称可以以应用程序名称(例如，“DASH-Push-Request(DASH推送请求)”或“HTML-Push-Request(HTML推送请求)”)开始，以匹配不同的情况。

在下文，考虑无应用程序相关的前缀的通用头部。

特定推送头部的目的是定义并由此(向服务器)提供一个或多个唯一资源标识符(URI)或定位符(URL)等，从而标识请求第一资源的客户端感兴趣的附加资源或资源的一部分。如本发明所提供的，HTTP请求必须自给自足以确定这些附加资源、即无需利用外部或上下文信息。

可以考虑用以定义附加资源或资源的一部分的各种实施例。

在实施例中，特定推送头部以显式方式包括标识这些附加资源的URI或URL。例如：

<Push-Request:HTTP.//server/path/segment-2.mp4>

在其它实施例中，经由构建规则来表示URI或URL，其中该规则插入特定推送头部中。换句话说，将所关注的附加资源的列表表示为构建规则。特定推送头部的句法可以如图6b所示。

头部650的头部值由利用保留字符(例如，“；”)分隔开的三个不同部分形成。

第一部分652是定义其它两个部分所定义的构建规则必须应用于HTTP请求的哪个部分的“支持(support)”。特别是，这种URI或URL可以是在HTTP请求中设置的请求-URI的全部或一部分。

因而，词语“支持”可以指代初始请求-URI自身，但还可以指代HTTP请求中所存在的另一HTTP头部。

第二部分653定义来自所述支持的提取模式、即支持部分652所引用的URI或URL的变化部分。

例如，可以使用保留字符来以显式方式表示请求-URI等中的变化部分。在变形例中，可以将变化部分表示为指示请求-URI等的要提取并修改的部分的规则表达式。

第二部分653由此包括变化部分信息，并且可以采用URI模板的形式。

在所述支持是另一HTTP头部的情况下，可能不存在要指示的提取模式，或者例如作为880(参见以下)，将整个头部值指示为要替代的模式。

最后部分654可选地包含要应用的一个或多个替代值作为第二部分653所定义的变化部分的替换。

可以使用值的冒号分割(或任何专用分隔符)列表或值的范围或甚至范围的列表来定义替代值。在这种情况下，推送头部处理器321/358应当遍历值的列表或范围，以推导出与替代值一样多的URL。

例如，在合并第一部分和第二部分的情况下，

<Push-Request：HTTp：//server/path/segment-{1}.mp4；{2-5}>

其中，{1}定义变化部分并且{2-5}是替代值。

具有三个不同部分的另一示例如下所述：

<Push-Request：request-URI；segment-{1}.mp4；{2-5}>

其中：“request-URI”是支持，“segment-{1}.mp4”是该支持所定义的具有变化部分{1}的URI的部分，并且{2-5}是替代值。

问题是构建尽可能通用的构建规则。在自适应流传输的背景下提供这种构建的示例性关键方面。

在DASH中提供用以描述媒体片段或媒体内容子部分的各种方式：SegmentTemplate、SegmentBase或SegmentList，其中在Representation、AdaptationSet或Period元素中，一次仅存在这三者中的一个。

SegmentTemplate是用以容易地构建客户端所用的URI模板以向服务器提供与该服务器想要下载的下一片段有关的提示的最便捷方式。这是因为SegmentTemplate清楚地表示清单中所定义的片段URL的哪部分将要根据例如表现的唯一标识符或表现的带宽等而改变。在这种情况下，客户端的K个将来片段的识别不需要与在DASH控制引擎313中可利用的标准模板分辨率处理相比更多的能力。

这是图7a的示例的情况。根据URI模板“mp4-live-$RepresentationID$-$Number$.m4s”，容易定义在相同Representation“h264bl_low”的当前片段N之后指定K个片段的构建规则。

<Push-Request:″mp4-live-h264bl_low-{7}.m4s″；{(N+1)-(N+K)}＞

对于SegmentList方法，客户端可以预处理MPD文件，以识别所列出的片段的URI之间的重复模式，然后推导用以表示片段URL的列表的通用规则。

可选地，MPD分析器可以以离线方式进行工作，并且利用新的元素、属性或描述符注释SegmentList，以提供可以使用的URI模板。这是为了加速客户端侧的处理。作为元素或属性，URI模板可以在SegmentList元素内定义。作为描述符，可以在SegmentList的父元素(例如，Representation元素级别)中定义该描述符。

图10提供使用SegmentList元素来进行片段的描述的MPD样本1000。SegmentList包含SegmentURL元素的列举。在该MPD样本中，在同一AdaptationSet 1001内描述针对同一视频内容的两个替代表现1002、1003。

通过各Representation中的SegmentURL的列表，客户端可以容易地判断为除片段索引外，URL是大致恒定的。

然后，可以将如1005和1006中所提供的示例性URI模板那样的注释添加至父Representation元素(由于针对各Representation存在至多一个SegmentList)。由于(@templateURI属性中的)该注释，因此想要将列表中的一个或多个片段指示为要推送的客户端仅需复制并粘贴特定推送头部中的@templateURI值。

为了进一步简化将URI模板用于客户端，可以检查所获得的@templateURI 1005和1006的哪些部分针对Representation而改变。这是因为，在本示例1000中，在同一AdaptationSet中存在多个Representation。这导致此时在具有多个变量或变化部分的AdaptationSet级别生成另一模板属性(参见1007)。

从一个级别到下一级别，因而可以渐进地推广@templateURI属性。因而，可以对父元素迭代推广处理，直到SegmentURL保持相当相似为止。

关于@templateURI注释1007，可能发生URI模板包含多个变量或变化部分。在这种情况下，由客户端确定必须按何顺序连续地考虑变化部分以供各自的替代值取代。因而，客户端可以使各变化部分与优先级别相关联，以迫使服务器在考虑这些变化部分时遵循预定义的顺序。

可选地，除@templateURI属性外，还可以提供@templateValue属性以表示@templateURI属性的一个或多个变化部分的可能值的范围。可能值的范围是基于MPD、即基于图10的示例中的SegmentURL的列表所确定的。

例如，除注释1005和1006外，还可以利用注释1005和1006各自定义@templateValue属性以定义相同的值范围：@templateValue＝“{1-6}”。

对于在AdaptationSet级别添加的@templateURI，@templateValue属性将取以下值：@templateValue＝“low：hd；{1-6}”，其中“low”和“hd”的字符串列出与表现标识符相对应的第一变量“level”的可能值，并且范围{1-6}列出与片段索引相对应的第二变量“nb”的可能值。

返回如图6b所示的特定推送头部的句法，实施例将以下语法和RFC 6570用在URI模板上，以在描述特定推送头部时表示提取模式653。

可以如下所述定义“推送头部”：

push_request＝″Push-Request：″header_name″；″uri_template^＊(″；″definition)

其中，headername＝″URI″HeaderName

HeaderName(头部名称)与不同HTTP版本的规范中的预定义的头部名称相对应。

uri_template参数是如RFC 6570中所定义的潜在具有扩展名的URI模板。该模板可以包含在大括号之间定义的并且名称是数字的变量或变化部分。例如：/server/video{1}.mp4是具有一个变化参数的uri_template，并且/server/{1}/image{2}.jpg是具有两个变化参数的另一uri_template。

最简单的情况对应于：uri_template等于1，这意味着应利用所声明的定义(即，替代值)替换整个支持。此外，无任何声明变量的uri_template表示应利用uri_template值替换整个支持652。例如，如果support＝“URI”并且uri_template＝“/server/resource2.ext”，则特定推送头部表示利用客户端的所建议的资源的URI是“/server/resource2.ext”，而无需任何进一步的处理。

最后可选的定义参数声明一个或多个替代值。第一个定义与uri_template的第一个变量的替代值相对应，第二个定义与第二个变量相对应，等等。必须存在与uri_template模板(即，提取模式)一样多的定义参数(即，替代值的集合)。

因而，这种“定义”包括值和/或列表和/或范围：

定义＝值|列表|范围

其中：值是用以表示替代值作为字符串的第一可能性；

列表＝值|范围*(“:”值|范围)是用以表示替代值作为冒号分隔的值列表(或值范围)的第二可能性。注意，由于传统上使用冒号字符来分隔同一头部的多个值，因此优先于逗号字符而选择冒号字符以分隔值；

范围＝“{“开始”-“结束”}”是用以表示替代值作为范围的第三可能性。这应被解释为“开始”和“结束”之间的所有值的列表，其中包括了“开始”和“结束”这两者。这仅对于作为整数的值是有可能的。

定义参数内的变量值的格式化是默认的格式化。为了防止针对值范围的任何格式化问题，范围中的值的格式化应遵循开始值和结束值(特别是对于前导零)的格式化。例如，如果将范围指定为“{8-10}”，则所生成的值是“8,9,10”。如果将范围指定为“{08-10}”，则所生成的值是“'08,09,10”。

如以上参考注释1007简要介绍的，特定推送头部可以包括具有两个或更多个变化部分(即，变量)的URI模板。服务器将推送特定推送头部所定义的附加资源的顺序直接依赖于服务器如何连续地考虑(即，扩展)这两个或更多个变化部分。因而，该顺序应当是从特定推送头部推导出的。

假定提供了变量的顺序，用于扩展uri_template规则中的变量的示例性算法如下所述：

1.获得uri_template的列表

-对于第一个变量扩展(根据所提供的顺序为第一个)，使用特定推送头部中所定义的uri_template。

-对于(根据所提供的顺序的)后续变量扩展，使用通过先前变量的扩展而产生的uri_template的列表。

2.利用如下所述所获得的uri_template的列表来替换所获得的列表中的各uri_template：

-针对扩展步骤中所考虑的变量的各值，复制uri_template，并且利用替代值其中之一来替换URI模板内的变量。

这意味着，在URI的(或头部值的)最终列表中，在顺序上为第一个(例如，利用“1”来定义)的变量改变得最慢，并且在顺序上为最后一个(即，利用最大编号来定义)的变量改变得最快。

例如，构建规则<`Push-Request：URI；{1}-{2}；a：b；1：2`>得到以下的有序列表：

-`a-1`

-`a-2`

-`b-1`

-`b-2`

构建规则<`PushRequest：URI；{2}-{1}；a：b；{1-3}`>得到以下的有序列表：

-`a-1`

-`b-1`

-`a-2`

-`b-2`

-`a-3`

-`b-3`

可选地，可以将针对多个变量的处理和替代顺序表示为特定运算符。RFC 6570保留运算符扩展所用的一些字符。在一个实施例中，可以使用“@”字符来表示顺序：运算符的值越大，处理顺序越大。在该替代实施例中，以上两个示例将变为：

构建规则<Push-Request：URI；{foo@1}-{bar@2}；a∶b；1∶2>，其中：“foo”和“bar”是分别按以下顺序利用值“a”和“b”以及“1”和“2”替代的变量名称：

-`a-1`

-`a-2`

-`b-1`

-`b-2`

构建规则<Push-Request：URI；{foo@2}-{bar@1}；a:b；{1-3}>将得到以下的有序列表：

-`a-1`

-`b-1`

-`a-2`

-`b-2`

-`a-3`

-`b-3`

尽管以上示例使用HTTP头部中的一个特定推送头部，但其它实施例可以使用两个或更多个推送头部。

例如，在客户端对不同类型的多个资源感兴趣的情况下、以及/或者在难以提供构建规则的情况下，可以确定使用特定推送头部的多个实例。

作为示例，如果寻求Web页的下载的加速，则客户端可以针对包括Web页的每种子资源生成一个推送头部：针对图像一个、针对样式表一个、针对脚本代码一个、等等。

在这种情形中，各特定推送头部的值表现得像对一些类型的子资源进行过滤的过滤参数。注意，参考子资源的主资源可以是利用HTTP请求以显式方式请求的资源(即，请求-URI的资源)。

具有推送头部的多个实例将得到URI/URL的附加列表，其中各实例定义要推送的单独一组资源。

证明特定推送头部的多个实例的另一情况包括何时客户端想要修改来自初始请求中的不同支持的部分：例如，请求-URI的一部分以及Range头部中的字节范围值；或者何时表示两个不同头部的修改。在这种情形下，客户端可以放置两个(或更多个)特定推送头部：一个用于URI修改并且另一个用于Range修改。然后，处理后的头部得到具有新的URI和关联的新字节范围的组合实例。

要注意，对于基于多个推送头部的多个头部修改，各推送头部处理生成与相应替代值相对应的一组URI/头部：并且资源的最终列表是通过提供所生成的组的所有可能组合、即针对头部的各URI/组的替代值之间的所有可能组合所获得的。

在实施例中，可以将特定推送头部用于uri_template规范的替代。

在uri_template参数表示相对URI的情况下，推送头部处理器不得不考虑相对于原始请求-URI的相对路径以构建绝对URI。

然而，在实施例中，基URI或另一基URI可以是在另一特定头部中指定的或者可被指定为推送-请求头部内的参数。这例如在清单中声明多个BaseURL(基URL)的DASH中可以是有用的。因此，如果客户端希望推送一些资源，则客户端可以使用具有特定推送头部的第一基URL来测试第一服务器，并且如果没有接收到推送承诺，则客户端可以改变下一请求中的BaseURL以测试第二服务器是否支持特定推送头部。

用以表示特定推送头部中的基URI的变化的示例性方式包括在uri_template参数之后设置的附加参数“var_base”。var_base参数声明新的基URI值。

例如，如果HTTP请求的请求行是GET/server1/video/segment-1.mp4，则特定推送请求可以如下所述。

<Push-Request：URI；segment-{1}.mp4；{2-4}；varbase＝/AnotherServer/video/>

该构建规则生成附加资源的以下列表：

http：//AnotherServer/video/segment-2.mp4

http：//AnotherServer/video/segment-3.mp4

http：//AnotherServer/video/segment-4.mp4

可选地，代替使用URI-模板RFC 6570来声明uri_template参数，作为代替可以提供规则表达式。

在处理互操作性目的的实施例中，特定推送头部被分割成两个不同头部：

-用以表示客户端感兴趣的资源的第一个头部。该头部是如上所述的特定推送头部；

-用以向服务器表示客户端接受服务器推送的第二个头部。尽管可以在连接设置时协商该操作，但客户端告知服务器何时客户端可以接受所推送数据以及何时取消推送的风险更高(例如，何时客户端经历未良好建立的频繁切换的视频模式)可以是有用的。

该第二个头部对于不支持推送的(例如，CDN中的)网络中介也将是有用的：这些网络中介仍可以将第一个推送头部解释为用以预取接近网络边缘的一些资源的提示。

本发明的特定推送头部可以帮助流传输客户端改善不同的DASH情形：

-例如，客户端想要预期下一片段的情形；

-或者客户端想在视频中寻求时间偏移的情形；

-或者客户端信任服务器在给定时间段发送后续片段的情形；

-或者客户端尝试预期切换的情形；

-或者客户端对关注资源感兴趣的情形；

-或者客户端请求非多路复用音频-视频片段的情形。在这种情况下，在请求视频片段时，客户端可以表示对相应的音频片段感兴趣。

在另一实施例中，可以将替代值放入另一专用头部(以下的“Push-Values”)中，然后得到以下一组头部(这里，头部名称仅是示例)：

Push-Request：header_name″：″uri_template

Push-Values：definition[^＊(″；″definition)]

利用该另一实施例，以下所述的示例850将被重写为：

GET/server/video/Rep-R1/segment-01.mp4

Push-Request：URI；segment-{1}.mp4；

Push-Values：02：10

此外，以下所述的示例865将变为：

GET/server/video/Rep-R1/segment-01.mp4

Push-Request：URI；Rep-{1}/segment-{2}.mp4

Push-Values：R1：R2；{01-03}

可选地，在推送特定头部中声明一个以上的变量参数的情况下，可以在自身的“Push-Values”头部中声明针对各变量参数的替代值。在这种情况下，“Push-Values”头部应包含变量参数名称，之后是值或者值列表或者值范围。例如：

GET/server/video/Rep-R1/segment-01.mp4

Push-Request：URI；Rep-{var1}/segment-{var2}.mp4

Push-Values：var1＝R1：R2

Push-Values：var2＝{01-03}

可以根据上述重写示例容易地推导出其它示例性重写。

在另一替代例中，可以将图6b上例示的推送特定头部的各部分放入相应的单独头部中；例如(头部名称仅是示例)：

Push-Support：URI

Push-Pattern：segment-{var}.mp4

Push-Values：var＝02：10

现在参考图7a、7b和8来说明使用URI模板的DASH的特定推送头部的示例。

图7a和7b提供在使用DASH标准的经由HTTP的自适应流传输的背景下的本发明的使用示例。图7a是包含SegmentTemplate元素701的示例MPD 700，其中该SegmentTemplate元素701向流传输客户端指示在何处(即，URI)下载各媒体片段。客户端可以根据所希望的或可能的空间分辨率和带宽来在两个替代视频Representation 702和Representation703之间进行选择。

图7b说明在实现本发明的情况下并且在假定客户端和服务器使用HTTP/2来进行通信的情况下的客户端-服务器交换。

客户端750首先在步骤752中经由HTTP GET(HTTP获得)请求向服务器751请求MPD即流传输清单。服务器在步骤753中将用以返回MPD文件的HTTP应答发送至客户端。

在MPD接收时，客户端在步骤754中解析该MPD，从而识别初始化信息以设置其媒体解码器。

接着，在步骤755中，客户端发送另一HTTP GET请求以获得该初始化片段。服务器在HTTP应答中提供所请求的初始化片段文件。这是步骤756。

同时或连续地(步骤757)，客户端根据其偏好/特性来识别适当的Representation。该步骤使得客户端可以识别开始读取视频所需的第一媒体片段、以及(如果没有作出Representation切换决定)为了继续读取视频而要下载的下一片段(通常是在时间上在同一Representation之后的下一媒体片段)。客户端可以使用清单来推导该/这些下一片段的URI。

接着，在步骤758中，客户端向服务器请求第一媒体片段以开始显示视频。

使用本发明，客户端在请求758中插入要下载的下一媒体片段的URI。该插入是在专用HTTP推送头部(例如，请求758中的“Push-Request”头部)中进行的。以下参考图8来提供该特定HTTP头部的值的示例。

响应于请求758，支持本发明并由此理解特定推送头部的服务器可以向客户端通知服务器理解推送头部并且通报其(服务器)将主动向客户端推送数据。这是服务器发送的向客户端提供服务器所发起的流标识符的PUSH PROMISE帧759的目的。

服务器还发送利用GET请求758的流标识符作为流标识符的一个或多个DATA帧760中的所请求的第一片段(GET请求的目的)。

最后，参考在步骤759中所交换的服务器发起的流标识符，服务器经由一个或多个DATA帧761来推送与在请求758的特定头部中表示的媒体片段相对应的数据。

根据特定实施例，服务器确认来自客户端的推送请求，即用于推送所识别的附加资源的请求，用于使用所识别的推送策略、对策或指令的请求，或者用于不推送任何附加资源的请求。可以在推送承诺消息的HTTP头部中发送这种确认。该确认使得DASH应答头部处理器386可以向DASH控制引擎313通知服务器所使用的推送策略。

图11a～11e示出服务器1101和客户端1100之间的推送策略管理的多个示例，其中该推送策略管理使得服务器1101能够确认从客户端1100接收到的推送策略的接收并且向客户端110通知服务器1101将应用或可能应用的推送策略。这些示例基于如MPEG DASH那样的经由HTTP的自适应流传输(基于流传输清单的方法)。

图11a示出客户端1100在针对流传输清单(在DASH的情况下为MPD)的初始请求1102中发送推送策略的指示。如前面所述，该指示可以经由专用HTTP推送头部来传送。

在接收时，服务器1101在步骤1103中处理该请求，即服务器识别要提供至客户端1100的资源(MPD)。然后，服务器1101在步骤1104中利用针对附图标记为1102的初始请求的返回代码来准备应答。因此，如果所请求的资源可用，则返回代码是HTTP代码200。

并行地，服务器1101处理专用HTTP推送头部中所包含的推送策略指示。如果服务器可以理解头部并且如果服务器可以处理所建议的推送策略，则服务器确认客户端所建议的推送策略。这可以通过在附图标记为1104的应答中添加确认数据、例如通过如附图标记为1102的请求中那样添加具有相同策略值的相同专用HTTP推送头部来进行(在这种情况下，推送确认数据与推送策略数据相同)。

这向客户端表示服务器愿意使用所建议的推送策略。

因此，在这种情况下，在确认附图标记为1104的应答中的推送策略之后，服务器开始通报该服务器打算向客户端推送的附加数据。这例如可以通过使用来自HTTP/2的PUSH_PROMISE帧(在DASH的情况下，针对各片段存在一个PUSH_PROMISE帧)来进行。

要注意，服务器在标准的基础上优选在附图标记为1104的应答中包括客户端在附图标记为1102的请求(即，MPD文件)中所请求的数据。

在步骤1105中如此生成的附图标记为1104的HTTP应答被发送回至客户端并由客户端进行处理的情况下，服务器开始准备(步骤1106)用于将所通报的附加数据发送至客户端的数据流(通常，在HTTP/2中，每个所承诺的资源为一个DATA帧，即，在DASH的情况下为片段)。

最后，客户端在处理响应于附图标记为1102的请求而发送的MPD时，在步骤1107期间开始接收媒体呈现所用的第一片段，由此节省网络通信量并且减少发送延迟。

要注意，可选地，可以经由具有例如“OK”那样的简单值的另一专用HTTP推送头部来用信号通知服务器所发送的确认数据。

可以推荐实现本发明的实施例的服务器在支持并应用客户端所建议的推送策略时，确认该推送策略。实际上，该推送策略是客户端容易地决定是否接受服务器所发送的PUSH_PROMISE帧所用的相关信息。

在客户端和服务器之间的该第一次往返之后，客户端例如利用针对在步骤1106和1107期间所推送的片段之后的片段的请求，继续提交请求以继续媒体呈现的流传输(步骤1108)。在该请求内，客户端可以确认客户端正通过在附图标记为1108的请求中添加具有与先前请求相同的推送策略指示的专用HTTP推送头部来维持相同的推送策略。

在服务器端，处理所接收到的请求(步骤1109)导致以下应答，其中该应答确认所请求的资源的可用与否(例如，HTTP状态代码200为OK)，并且确认服务器利用专用HTTP推送头部正应用的推送策略并发送要发送的附加数据和所请求的片段数据的通报(没有示出数据的实际推送，但该实际推送在应答1109之后)。

图11b示出确认推送策略通知的示例，其中根据该推送策略通知，服务器向客户端通知服务器不能实现客户端所建议的推送策略。

在服务器不支持客户端所建议的推送策略指示所依据的情况下，服务器可以简单地忽略该推送策略指示。

然而，服务器向客户端警告服务器将不使用任何推送策略，这可以是有用的。这是客户端为了调度该客户端的将来请求所用的有用信息。客户端确实将不得不逐一请求所有片段。

为此，服务器可以使用表示不进行推送的特定推送指令，例如类型为“不推送(push-none)”或无任何值的推送策略(或者图12b中作为附图标记为1231所登记的推送策略)。

如图所示，第一步骤涉及客户端1100在针对流传输清单(在DASH的情况下为MPD)的初始请求1111中发送推送策略的指示。如前面所述，可以经由专用HTTP推送头部来传送该指示。

在接收时，服务器1101在步骤1112中处理该请求，即服务器识别要提供至客户端1100的资源(MPD)。然后，服务器1101在步骤1113中利用针对附图标记为1102的初始请求的返回代码来准备其应答。因此，如果所请求的资源可用，则返回代码是HTTP代码200。

由于在该示例中假定服务器1101无法实现客户端所建议的推送策略，因此服务器1101向客户端指示服务器将不使用所建议的推送策略。这可以通过使用如图11b所示的表示将不进行推送的特定推送指令(附图标记1113)来进行。

在接收到这种信息时(步骤1114)，客户端1100知晓该客户端将从步骤1115起逐一请求所有的片段。

可选地，客户端可以通过在专用HTTP推送头部中也设置该客户端的请求中的同样的“不推送(no-push)”策略指示(如利用1115所示)，来确认客户端不依赖从服务器推送的任何资源。

然后，服务器1101在步骤1116中处理所接收到的请求，并且在步骤1117中通过确认“不推送”策略并且通过发送与该请求相对应的数据来回复该请求。重复这两个步骤，直到流传输会话结束为止。

可选地，服务器可以使用具有保留信息代码的另一专用HTTP推送头部(例如103，以向客户端通知“不支持推送策略模式”)。

还可选地，客户端可以HTTP Expect头部指示推送策略，然后服务器指示“期望失败”的417代码、或者更清楚为专用于服务器的不支持客户端所希望的推送模式的保留4xx代码。

在另一实施例中，实现本发明的实施例的客户端并不知晓服务器是否支持本发明。如果客户端决定保持完全控制并将“不推送”推送策略发送至服务器，则由于服务器不理解头部，因此服务器没有发送回确认。

在服务器实现本发明但客户端不支持本发明所依据的其它实施例中，没有接收到客户端的请求中的任何专用HTTP推送头部的服务器则可以使用“不推送”策略指示来进行确认，以向客户端警告什么也没有推送(这是因为服务器并不知晓客户端是否支持本发明、或者客户端仅仅忘记指示其偏好)。如此，服务器不会冒发送无用数据的风险。

特别地，可以使用这种特定“不推送”策略的目的，以表示以下：

-客户端对任何推送均不感兴趣；或者

-客户端想要中断针对一些请求的推送。

这样提供与HTTP/2所定义的现有SETTINGS_ENABLE_PUSH设置参数相比更精细的控制，其中客户端可以使用该控制以向服务器指示是否允许服务器推送的使用。该设置参数没有提供与服务器推送有关的任何细粒度协商或控制机制。实际上，客户端和服务器具有这种协商方式可以是有用的。例如，尽管SETTINGS_ENABLE_PUSH设置参数的值使得服务器能够使用服务器推送，但客户端可能想要针对流传输会话内的一些或全部请求禁用服务器推送。例如，该操作在加载嵌入有视频元素的Web页的情况下对于客户端而言可以是有用的。客户端可能对具有关联至要推送的Web页(CSS、图像、JavaScript)的资源而不是媒体片段感兴趣。在这种情况下，将针对整个连接启用推送数据，但对于特定DASH内容，客户端将向媒体服务器表示对不推送数据的偏好。

图11c示出确定推送策略通知的示例，其中根据该推送策略通知，客户端在针对流传输清单的初始请求中建议多个推送策略。换句话说，代替如参考图11a和11b所述建议单一一个推送策略，客户端发送该客户端支持的推送策略的列表。

如图所示，第一步骤涉及客户端1100在针对流传输清单(在DASH的情况下为MPD)的初始请求1119中发送该客户端支持的推送策略的列表。这种列表优选被排序(偏好顺序，图11c中未示出)。

为此，创建专用HTTP推送头部以传送策略的类型和偏好顺序的可选参数。例如，与现有Accept HTTP头部相同，将专用HTTP推送头部定义为“Accept-Push-Policy(接受推送策略)”HTTP头部(参见https://tools.ietf.org/html/rfc7231#section-5.3.2)。

Accept头部允许给定媒体类型具有以下内容：

0*(零个或多个)特定媒体类型参数(例如：charset(字符集))；这例如可以是发出请求的客户端所支持的媒体类型的列表：*.jpg,*.png

0-1“q”参数(用于表示相对权重)

0*扩展参数(如果存在任何扩展参数，则“q”参数作为分隔符是强制性的)。

这将导致专用HTTP推送头部如下：

Accept-Push-Policy：<urn>[’；’<urn-specific-param>^＊]；q＝<N>

其中，在存在一些全局参数的情况下，“q”参数是强制性的。

“q”参数是还使策略参数(在上述表达式中为<urn-specific-param>)(在存在的情况下)与(在上述表达式中利用<urn>表示的)策略类型分隔开的品质因数。

品质因数使得用户或用户代理能够使用大小为0～1的q值来表示针对策略类型和/或策略值的相对偏好程度。默认值是q＝1(更高的品质因数或偏好的品质因数)。

为了例示，客户端可以使用推送头部中的以下通知来要求服务器推送在所请求的一个片段之后连续的接下来的五个片段。

Accept-Push-Po/icy：urn：mpeg：dash：fdh：push-next；5

其中：第一部分URN唯一地标识要使用的推送指令或推送策略的类型。在“：”分隔符之后的第二参数(可选)与该推送策略中要应用的参数相对应。

作为替代，可以使用策略类型和值参数之间的其它分隔符作为HTTP头部值中的分隔符(参见RFC 2616)。

使得客户端能够根据偏好来表示推送策略的有序列表的替代实施例使用“q”参数，例如在实时方案中，在服务器上一些接下来的片段准备就绪时指示服务器推送这些片段(根据图12b中的附图标记1230所登记的标准推送策略)(优选为3个片段，否则为5个片段)，这可被表示为如下：

Accept-Push-Policy：urn：mpeg：dash：fdh：push-next；3，

urn：mpeg：dash：fdh：push-next；5；q＝0.5

作为客户端指示用以允许进行视频(即，来自MPD请求，以推送初始化和第一视频片段)的快速启动(这里，来自可能地还根据图12b中的1230所登记的专有推送策略)的推送策略所依据的另一示例，利用品质级别作为偏好顺序，可以如下所述表示推送策略的有序列表：

Accept-Push-Policy：urn：canon：dash：fdh：push-fast-start；high，

urn：canon：dash：fdh：push-fast-start；mid；q＝0.7

urn：canon：dash：fdh：push-fast-start；low；q＝0.3

或者按针对分辨率的偏好：

Accept-Push-Policy：urn：canon：dash：fdh：push-fast-start；HD，

urn：canon：dash：fdh：push-fast-start；SD；q＝0.7

为了客户端向服务器指示推送各种数据，客户端可以在请求中放置针对q的值相同的两个不同推送策略的指示。这应由服务器解释为响应于该请求而要应用的两个策略。

如果服务器可以应用这两个推送策略，则服务器通过在应答中在专用HTTP推送头部中放置q值相同的这两个推送策略来确认客户端建议。

相反，如果可以应用这两个推送策略中的仅一个，则服务器利用所使用的推送策略作为针对专用HTTP推送头部的值来确认客户端建议。

如果不能应用所建议的两个推送策略，则服务器通过在专用HTTP推送头部中添加不推送策略的标识符(例如，登记值1231或针对该目的而专门定义的任何推送策略类型)，来确认客户端建议。

返回图11c，服务器1101在步骤1120中处理可能涉及快速启动的所接收到的请求1119。

响应于该请求，服务器1101在步骤1121中利用针对初始请求的返回代码准备应答。因此，如果所请求的资源可用，则返回代码是HTTP代码200。

另外，服务器1101通过使用潜在地重新考虑匹配自身的偏好的顺序的相同的Accept-Push-Policy专用HTTP推送头部(在这种情况下，第一个头部是为了通报服务器将推送的下一数据所使用的头部)、或者优选地通过使用仅传送来自服务器将使用的列表的实际推送策略的另一专用HTTP推送头部，来确认客户端1100所建议的推送策略其中之一。

例如，这种专用HTTP推送头部可以是“DASH-PUSH”:urn:canon:dash:fdh:push-fast-start；low(其中，头部的名称(“DASH-PUSH”)是作为示例所给出的)，或者无需提供参数的准确值的仅策略的类型，例如“DASH-PUSH”:urn:canon:dash:fdh:push-fast-start(假设在这种情况下服务器选择要推送的媒体的版本)。

在步骤1122中，客户端1100接收到这种确认数据。

并行地，服务器1101开始准备用于将所通报的附加数据发送至客户端的数据流(步骤1123)，并且发送相应数据。

客户端1100在接收到所推送数据之后(步骤1124)所发送的下一请求可以包括推送策略指示、例如服务器所确认的推送策略指示。

在服务器1101不支持在MPD请求内接收到的任何建议的推送策略(步骤1120)所依据的情况中，服务器1101可以通过将专用HTTP推送头部设置为“不推送”策略(例如，通过图12b中的附图标记为1231的所登记的URN(即，urn:mpeg:dash:fdh:push-none)或者针对该目的而专门定义的任何推送策略类型)，来确认客户端的建议。

图11d示出确认推送策略通知的示例，其中根据该推送策略通知，客户端在针对流传输清单的初始请求中建议“不推送”策略。换句话说，图11d示出客户端想要在开始时保持针对Representation选择的控制所依据的情况。

如图所示，第一步骤涉及客户端1100在针对流传输清单(在DASH的情况下为MPD)的初始请求1131中发送“不推送”策略指示。

因此，初始请求1131清楚地表示客户端不想服务器推送任何内容。为了便于例示，如在图12b的附图标记1230中所登记的，这种“不推送”策略可以如下：urn:mpeg:dash:fdh:push-none。

这种示例与客户端在会话开始时对快速启动不感兴趣所依据的情况相对应，由此防止来自服务器的任何推送(在默认情况下，HTTP/2服务器可能在存在发送与客户端无关的内容的风险的情况下主动进行推送)。

如图11d所示，服务器1101在附图标记为1133的应答中确认该不推送策略。

为了请求片段，客户端分析MPD(步骤1134)以更好地知晓将要询问什么内容，并且作为该分析的结果，向服务器建议一个或多个推送策略(步骤1135)。

作为应答，服务器1101如通过参考图11a或图11c所述确认推送策略，以推送所承诺的数据(未示出)。

当然，可以将针对流传输会话的快速启动的推送策略用于其它目的。例如，客户端在MPD请求时间时指示推送策略(步骤1131)，然后服务器进行肯定确认或否定确认(如参考图11a或图11c所述)，并且最终承诺将第一片段推送至客户端。然后，对于与片段有关的连续请求，客户端可以决定客户端是通过指示所选择的推送策略来信任服务器继续推送、还是客户端通过使用特定“不推送”策略来想要保持针对发送的完全控制。

要注意，无论客户端所指示的推送如何，如果服务器不能处理客户端所建议的任何推送策略以及/或者不能处理相应的特定HTTP头部(例如，图6a的测试604为假)，则服务器不能发送任何种类的确认，因而将仅是忽略来自客户端的提示。

相反，被配置为处理客户端所建议的推送策略(或指令)并决定应用该推送策略的DASH服务器应当通过在应答中使用具有接受参数值(在存在的情况下)的推送策略(或指令)的URN，来确认客户端请求。在客户端指示多个推送策略、并且服务器支持客户端所建议的推送策略列表中的推送策略其中之一的情况下，服务器应通过在专用HTTP推送头部中放入所应用的推送策略的URN来确认该服务器计划使用的推送策略。

可选地，如以下所述并且如图11e所示，服务器还可以以各种方式广告该服务器所实现的替代推送策略的列表。

在服务器不支持客户端所建议的推送策略的情况下，服务器应通过使用“不推送”策略的URL、即urn:mpeg:dash:fdh:push-none，来向客户端进行通知。除确认“不推送”策略外，服务器还可以在另一专用HTTP推送头部中发布该服务器支持的一个推送策略或推送策略列表。为了消除确认应答的歧义，服务器优选使用另一专用HTTP推送头部。根据服务器是发布一个推送策略还是推送策略列表，服务器可以使用在Accept-Push-Policy头部中给出的句法。

要注意，在推送策略被发送至无推送能力的服务器(即，不理解来自客户端的任何推送策略的服务器，例如图6a的测试604为假)的情况下，将不存在任何种类的确认，并且不能用信号向客户端通知任何推送策略的广告。

为了帮助客户端建议推送策略，服务器可以向客户端发送该服务器支持的推送策略的列表。这可以通过多种方式来进行。

为了示例，可以在MPD中创建内容时确定服务器所支持的推送策略的列表，并且将该列表作为一个或多个DASH描述符添加至MPD。这些DASH描述符利用源服务器或内容传递网络中的服务器来提供所支持的推送策略的指示。

这还可以由网络中介(在网络中介知晓DASH的情况下)来进行。

可以利用特定scheme_id_uri属性(例如，“urn:mpeg:dash:fdh:pushDirective”)来标识这种描述符。这种描述符的值属性包含推送策略的类型(例如，“urn:mpeg:dash:fdh:push-next”或“urn:mpeg:dash:fdh:push-none”)。

可选地，其它属性(例如，param)可以包含如要推送的下一片段的数量那样的策略参数。这将被编写为：<SupplementalPropertyscheme_id_uri＝“urn：mpeg：dash：fdh：pushDirective”value＝“urn：mpeg：dash：fdh：push-next”param＝“5”/>。假定scheme_id_uri的值以及值属性由DASH标准或者至少由如1230那样的登记机构来定义。这例如可以是经由scheme_id_uris的DASH、DASH产业论坛、或者具有与客户端和服务器行为有关的关联指南的IANA的DASH，以受益于相应的推送策略。

根据另一示例，可以使用特定HTTP头部字段(例如，“Supported-Push-Policies”)来描述服务器所支持的推送策略。在基本实现中，该头部字段的值是所支持的推送策略的标识符的逗号分隔列表。

这种特定HTTP头部字段例如可以是以下：

Supported-Push-Policies：urn：dash：adobe：k-push，urn：dash：canon：fast-start

在更丰富的实现中，针对各策略所支持的参数值可被描述为“，”分隔列表或范围。

这种特定HTTP头部字段例如(使用“；”作为策略类型和其参数之间的分隔符)可以是以下：

Supported-Push-Policies：urn：dash：adobe：k-push；0-100，urn：dash：canon：fast-start；low：medium

服务器还可以通过针对各策略添加“q”参数来表示针对各策略的偏好。

这种特定HTTP头部字段例如可以是以下：

Supported-Push-Policies：urn：dash：adobe：k-push；0-100；q＝0.4，urn：dash：canon：fast-start；low：medium；q＝0.9

在应用代码中，例如在Web页中，HTML meta标签可以列出客户端为了改善传输而可以使用的一些策略。

这种HTML meta标签例如可以是以下：

其中：在名称属性中所允许的新的“dash：fdh：pushDirective”值可被登记到现有扩展列表中：https://wiki.whatwq.org/wiki/MetaExtensions。这种登记使得能够向Web客户端通知应用程序服务器已想到了用以优化媒体传送的对策，其中媒体例如作为<video>元素嵌入在Web页中。要放在内容属性中的值可以是图12b中的附图标记为1230的登记值其中之一。

图8提供针对利用DASH的自适应流传输的情况的推送头部的各种示例。媒体(视频)可用作两个不同的表现R1 810和R2 820，其中这两个表现R1 810和R2 820都包含时间对齐的视频片段811和821。

第一示例830例示客户端的针对表现R1的第一片段的请求。该请求还经由推送头部“Push-Request”表示客户端对作为将来片段的片段编号2感兴趣。为此，推送特定头部表示服务器不得不修改请求(利用头部的第一参数集“UIR”指示的)URI的花括号模式、即请求-URI中的字符串“01”，其中值设置在最后参数中(在示例830中为“02”)。替代方案可以是经由如Push-Request:URI；-$\d\+$,-$％02d:\1+1$那样的规则表达式来指示替代规则。

第二示例840例示客户端的针对表现R1的第一片段的请求。该请求还经由推送头部“Push-Request”表示客户端对作为将来片段的片段编号02、03、04和05感兴趣。为了紧凑和简单的目的，这里将将来片段的该列表表示为范围。再次地，在初始请求-URI中，不得不利用所提供的范围中所设置的值来迭代地替换花括号之间的模式，从而构建四个URL的相应列表。

第三示例850例示客户端的针对表现R1的第一片段的请求。该请求还经由推送头部“Push-Request”表示客户端对作为将来片段的片段编号02和10感兴趣。对片段编号感兴趣可以允许客户端快速浏览视频。然后，给出替代值作为利用冒号分隔的值的列表。在客户端将对多个片段(编号02～04和10～13)感兴趣的情况下，可以如下所述经由范围列表来用信号通知这些片段：

Push-Request:URI；segment-{1}.mp4；{02-04}:{10-13}

第四示例860例示客户端的针对表现R1的第一片段的请求。该请求还经由推送头部“Push-Request”表示客户端对作为将来片段的在Representation R2中的片段编号01感兴趣。在Representation R2是基础版本R1的增强版本的情况下，这对于可扩展视频而言可以是有用的。该示例例示用以代入请求-URI中的(花括号之间的)两个模式的存在所表示的请求-URI中的多个模式的变形。

第五示例865例示客户端的针对表现R1的第一片段的请求。该请求还经由推送头部“Push-Request”表示客户端对作为将来片段的以下内容感兴趣：首先是RepresentationR2中的片段编号01，然后是Representation R1和Representation R2这两者中的片段02，最后是Representation“R1”和“R2”这两者中的片段03，其各自表示替代顺序。在该示例中，首先考虑具有第一组值“R1”和“R2”的表现标识符，然后考虑具有范围01～03(包括端点)的值的片段索引。

要注意，对于遍历多个参数(两个表现各自上的片段01～03)的特殊情况，提供两次表现R1中的第一片段(一次作为所请求的第一片段-参见请求-URI；并且一次作为所推送数据)。因此，服务器可以过滤所获得的URL的列表以删除与初始请求-URI相对应的URL。

第六示例870和第七示例880例示在通过MPD中的字节范围发送媒体片段的情况下的头部使用，其中媒体片段被描述为包含提供片段的字节范围的SegmentURL的SegmentBase元素。

示例870例示客户端的针对表现R1的第一字节的Range请求。该请求还经由推送头部“Push-Request”表示客户端对作为资源的将来部分的、“Rep-R1.mp4”文件中的始于2001且结束于3000字节偏移的字节范围感兴趣。

第七示例880例示客户端的针对表现R1的第一字节的Range请求。该请求还经由推送头部“Push-Request”表示客户端对作为资源的将来部分的字节范围(“Rep-R1.mp4”文件中的首先为2001～3000(包括3000)然后为3001～4000(包括4000))的列表感兴趣。

图8的第八且最后示例890例示客户端的针对初始化片段的请求。该请求还经由推送头部“Push-Request”表示客户端对作为将来片段的给定片段感兴趣：这里提供显式且绝对的URI，而不需要模式识别或替代值。

上述说明主要集中于可能地经由构建规则来定义要推送的特定资源的特定推送头部。

在服务器包含将资源类型映射至资源文件夹的静态配置文件的一些实施例中，客户端可以使用特定推送头部来过滤该客户端感兴趣的资源。这种过滤例如可以在上述的步骤606期间发生。

在客户端在特定推送头部中指示除特定资源以外的一类资源或者至少用以识别这些特定资源的规则的情况下，该过滤方法可以是有用的。

如参考图12a和12b所示，存在替代例，例如使用唯一标识符(例如，URN)来明确地指定推送策略或推送指令。

图12a示出客户端1200在针对流传输清单(在DASH的情况下为MPD)的初始请求1201中发送推送策略的指示，其中该指示是与推送策略相关联的唯一标识符。如前面所述，可以经由专用HTTP推送头部来传送该指示。

在接收时，服务器1210在步骤1203中处理该请求，即服务器识别要提供至客户端1200的资源(MPD)。然后，服务器1210利用针对初始请求的返回代码来准备应答。因此，如果所请求的资源可用，则返回代码是HTTP代码200。

并行地，服务器1210根据专用HTTP推送头部中所包含的唯一标识符来识别所建议的推送策略。如果服务器可以理解头部并且如果服务器可以处理所建议的推送策略，则服务器确认客户端所建议的推送策略。这可以通过在将唯一标识符添加在应答1204中来进行。

这向客户端指示服务器愿意使用所建议的推送策略。

与推送策略相关联的唯一标识符可以是在中央注册表(例如，图12b所示的中央注册表1230)中定义的。URM使得能够唯一地识别推送策略(或指令)。在推送策略(或指令)需要参数的情况下，必须在从上述注册表所链接的规范中定义这些参数，使得清楚地指定推送策略。

如果没有定义中央注册表，则专用HTTP推送头部可以传送推送策略的类型(例如，要推送的片段的数量、应推送片段的持续时间或用于推送MPD更新的指示)。

为了例示，在专用HTTP推送头部可以传送的推送策略的类型可以是以下(在该示例中，“Push-Request”是专用HTTP推送头部的名称)：

Push-Request：push-next

Push-Request：push-time

Push-Request：fast-start

Push-Request：mpd-update

可选地，专用HTTP推送头部可以传送推送策略的类型和所建议的推送策略的参数(例如，片段数量和要推送的持续时间(以秒为单位))。因此，在专用HTTP推送头部可以传送的推送策略的类型以及关联参数可以是以下(这里使用“；”作为策略类型和参数之间的分隔符)：

Push-Request：push-next；5

Push-Request：push-time；2

Push-Request：fast-start；2

Push-Request：mpd-update；patch

Push-Request：push-next；

更一般地，专用HTTP推送头部可被表示为：

Push-Request：URN^＊[‘；’<urn-specific-params>]

最后一个示例是具体的，并且目的在于指示服务器保持从给定片段起推送所有的后续片段(即，从客户端向服务器驱动模式的一种切换)。

要注意，对于与几个可能值相关联的一些策略类型，例如将类型+参数登记为一个URN可以是有利的：

urn:mpeg:dash：fdh:2015：push-next-^＊

或者

urn:mpeg:dash：fdh:2015：push-time-2。

根据特定实施例，向客户端给予用以清楚地表达客户端在要推送的数据方面的意愿的选项，以根据要推送的数据的类型来建议推送策略。因此，如图12b的中央注册表1230所示，客户端可以定义与片段有关的推送策略的集合和与MPD更新有关的推送策略的另一集合。

这些实施例可被证明具有特定MPD更新推送策略是有用的，这是为了客户端授权更新处理。实际上，建议并确认推送MPD更新使得可以避免在媒体片段中添加特殊元数据框来表示MPD有效日期(在更新MPD时，该操作通常由服务器来进行)。

例如，在流传输会话期间的某个时间点所确认的针对MPD更新的推送策略将向客户端通知服务器正承诺推送MPD更新。

此外，具有不同种类的MPD更新推送策略可以允许向客户端通知服务器是重新发送整个MPD(例如，具有URN：urn:mpeg:dash:fdh:push-mpd-full)还是重新发送仅补丁(urn:mpeg:dash:fdh:push-mpd-patch)。可选地，可以定义针对MPD更新的仅一个推送策略，其中整个或补丁模式变为参数。

图11a～11e示出使用这两种推送策略。如参考图11a～11e所述，客户端通过请求MPD而开始。同时，客户端可以表示对MPD更新和片段这两者的推送感兴趣或者仅对这两种数据其中之一感兴趣。同样，在准备针对片段的请求时，客户端可以表示对MPD更新和片段这两者感兴趣或者仅对这两种数据其中之一感兴趣。

实际上，在针对片段的请求中应允许MPD特有策略的使用，以在任意时间表示针对MPD更新的愿望。同样，在请求MPD时使用片段相关推送策略使得客户端能够具有快速启动流传输会话。

要注意，为了例示，涉及流传输应用的给定示例基于HTTP/2协议，但还可以使用诸如WebSocket(网络套接字)等的其它双向协议。特别地，如下所述，在针对WebSocket的绑定时，可以替换专用HTTP推送头部：

-URL：表示所请求的资源的URL。相应的JSON参数是“url”。

-PushDirective(推送指令)：表示客户端所选择的PushDirective的URN并且具有JSON名称“PushDirective”。

-可选的pushParams(推送参数)，其表示pushDirective特有的并且由pushDirective定义的值。

同样，确认机制可以将JSON参数用在一些专用WebSocket帧中。

例如，服务器可以将数据托管在不同的文件中。然后，假定“path”是服务器上的用以到达主资源的路径，“path/image”将包含图像资源，“path/code”将包含代码(例如，javascript代码)，“path/style”将包含css资源，等等。在这种情况下，在客户端在特定推送头部中表示该客户端想要在Web页中声明的所有种类的图像(image/*)或者给定类型的所有图像(image/*.jpg)的情况下，服务器上的配置文件则应针对任何资源目录列出可以推送的图像的列表。

Web页可以是在请求的请求-URI中所请求的数据。在变形例中，可以使用请求中的另一可选头部来识别Web页。

根据过滤方法，本发明提供一种用于在服务器装置和客户端装置之间传输数据的方法，所述方法在所述服务器装置处包括以下步骤：

在所述第一可选头部字段存在于所述HTTP请求中的情况下，

使用从所述HTTP请求获得的主资源来识别一组数据；

将所述第二数据推送至所述客户端装置.

生成用于获得第一数据的超文本传输协议请求即HTTP请求，其中所述HTTP请求包括包含一个或多个过滤参数的第一可选头部字段；以及

将所述HTTP请求发送至所述服务器装置以获得所述第一数据，并且驱动所述服务器装置，以根据所述一个或多个过滤参数来推送在从所述HTTP请求推断出的主资源中所引用的第二数据.

现在说明作为过滤方法的推送特定头部的使用的一些示例。

第一示例涉及在客户端想要根据要推送的子资源的类型(例如，根据加载jss和ess然后根据html和img)向服务器指示这些子资源的优先列表的情况下的网页加载。被称为主资源的网页是在请求的request-URI中所定义的所请求网页。可以如下所述定义特定推送头部：

Push-Request：appication/javascript；q＝1，text/css；q＝0.8，text/html；q＝0.7，image/png；q＝0.6，image/^＊；q＝0.4

这是针对服务器的表示客户端想要根据类型(例如，MIME类型、内容类型、格式类型或编解码类型)而要推送的一组资源(例如，在主资源中声明的子资源)的指示。

这里，以与表示客户端的相对偏好程度的Accept头部的“q”参数相同的方式，通过使用“q”参数来向各资源类型设置优先级级别。注意，q＝0使得可以排除某些资源类型被服务器推送。

在该示例中，优先级“q”使得可以定义服务器不得不推送子资源的客户端偏好顺序或版本(例如，根据偏好分辨率)。结果，服务器不得不对子资源进行过滤以提供推送所用的数据的有序列表。

第二示例涉及在网页不是请求的request-URI中所定义的所请求数据的情况下的针对网页的图像加载。在这种情形下，特定推送头部的支持部分以显式方式表示HTTP“Referer”头部。这是针对服务器的客户端所希望的附加资源是在Referer头部的值中所指示的主资源的子资源的指示。可选地，以下的头部利用针对采用.png image格式的图像的优先级，来驱动在“Referer”HTTP头部中所指示的网页的所有图像的加载。

Push-Request：Referer；image/png；q＝0.6，image/^＊；q＝0.4

Referer：the_url_to-web-page

第三示例涉及DASH流传输，并且更特别地涉及MPD加载和快速启动。推送头部可以如下所述，其中MPD是在请求的request-URI中所定义的所请求数据：

Push-Request：video/mp4；q＝1.video/webm；q＝0.4

这表示来自客户端的用以从具有“video/mp4”MME类型的媒体片段、而不是具有“video/webm”MME类型的片段开始的偏好。等同示例可被编写为如下：

Push-Request：URI；video.{1}；{video/^＊.mp4；q＝1，video/webm；q＝0.4}

在上述示例中，基于主资源的URI、即MPD，服务器可以推导要推送至客户端的采用mp4格式的所有视频片段。利用该通配符替代值，由服务器例如基于针对给定清单或来自MPD分析的静态配置信息来确定要推送的片段列表。

更一般地，例如在下载一段javascript代码或CSS子资源的客户端在Web页中声明并向服务器指示该客户端还想要从相同请求获得在javascript代码中和在CSS子资源中分别引用的子资源的情况下，这可以是有用的。

第四示例涉及视频流传输，并且更特别地涉及寻求字节范围。如果在HTTP请求中使用SegmentBase URL和字节范围来请求媒体内容子部分，则同一请求中的以下推送头部使得可以驱动字节范围[1400-4000]的推送，然后驱动优先级较低的字节范围[4000-6000]：

Push-Request：Range；{1}；[1400-4000]；q＝1：[4000-6000]；q＝0.8

第五示例针对DASH应用将要推送的一组资源描述为与主资源即清单有关。这通过具有值“Referer”的特定推送头部的支持部分来指示。模式部分表示一组视频资源，并且通配符替代值表示基于视频片段的类型(这里为mp4)的过滤规则：

Push-Request：Referer；video.{1}；video/^＊.mp4

Referer：the_url_to-MPD

这样使得客户端能够在特定推送头部中使用通配符值。

Referer头部是可选的，但在智能服务器(知晓MPD)的情况下，其值可以帮助服务器过滤客户端所指示的片段的集合(或者更一般为(子)资源)。

图9是根据实施例的装置的示意例示。该装置可以是服务器、客户端或代理。该装置包括RAM存储器902，其中该RAM存储器902可用作被配置为实现根据实施例的方法的控制单元901的工作存储器。例如，控制单元可被配置为执行从ROM存储器9303加载的计算机程序的指令。该程序也可以是从硬盘驱动器906加载的。

该装置还包括可以是单个网络接口的网络接口904、或者包括一组网络接口(例如，多个无线接口、或者多种有线或无线接口)。该装置可以包括用于向用户显示信息并且用于接收来自用户的输入的用户接口905。

该装置还可以包括用于相对于外部装置进行数据的接收和/或发送的输入/输出模块907。

尽管已经在附图和前述说明中详细例示并说明了本发明，但这些例示和说明应被视为说明性或例示性而非限制性的，其中本发明不限于所公开的实施例。本领域技术人员在根据针对附图、公开内容和所附权利要求书的研究实践要求保护的发明时，可以理解并实现所公开的实施例的其它变形例。

这些变形例特别是可以通过组合如在背景技术部分和/或所附权利要求书中所陈述的实施例而推导出的。

在权利要求书中，词语“包括”并未排除其它要素或步骤，并且不定冠词“a”或“an”并未排除多个。单个处理器或其它单元可以实现权利要求所记载的多个项的功能。在相互不同的从属权利要求中记载不同特征这一事实并不表示无法有利地利用这些特征的组合。权利要求书中的任何附图标记不应被解释为限制本发明的范围。

Claims

1.一种用于在服务器装置和客户端装置之间传输数据的方法，所述方法在所述服务器装置处包括以下步骤：

从所述客户端装置接收用以获得第一数据的超文本传输协议请求即HTTP请求，其中所述HTTP请求包括使得能够在所述服务器装置上识别所述第一数据的第一数据识别信息，并且包括包含与推送第二数据有关的指示的一个或多个附加头部字段；

2.根据权利要求1所述的方法，其中，还包括以下步骤：

3.根据权利要求1所述的方法，其中，所述确认数据代表用于推送所述第二数据的指示。

4.根据权利要求1所述的方法，其中，与推送第二数据有关的所述指示包括包含与推送第二数据有关的至少两个不同指示的列表。

5.根据权利要求4所述的方法，其中，所述确认数据包括与推送第二数据有关的所述至少两个不同指示其中之一，其中与推送第二数据有关的所述至少两个不同指示其中之一用来识别要推送至所述客户端装置的所述第二数据。

6.根据权利要求1所述的方法，其中，与推送第二数据有关的所述指示与所述第二数据的数据类型相关联，其中所述数据类型包括描述数据类型或内容数据类型，所述第二数据属于内容数据或属于描述数据。

7.根据权利要求1所述的方法，其中，所述确认数据包含与推送第二数据有关的指示，其中所述确认数据内的与推送第二数据有关的指示不同于所述HTTP请求内的与推送第二数据有关的指示。

8.根据权利要求1所述的方法，其中，与推送第二数据有关的所述指示包括至少一个唯一标识符，其中所述至少一个唯一标识符代表用于推送所述第二数据的指令和要推送的所述第二数据的标识，或者代表用于不推送所述第二数据的指令。

9.根据权利要求1所述的方法，其中，所述一个或多个附加头部字段是一个或多个可选头部字段。

10.根据权利要求1所述的方法，其中，所述第一数据识别信息和所述第二数据识别信息分别包括第一统一资源标识符即第一URI和第二统一资源标识符即第二URI。

11.根据权利要求10所述的方法，其中，所述一个或多个可选头部字段包括用以根据所述HTTP请求的内容来生成所述第二URI的至少一个构建规则。

12.根据权利要求10所述的方法，其中，所述一个或多个可选头部字段包括变化部分信息和替代信息，其中所述变化部分信息识别参考URI中的至少一个变化子部分，以及所述替代信息包括用以替换在所述参考URI中识别出的变化子部分以定义所述第二URI的至少一个替代值。

13.根据权利要求11所述的方法，其中，所述第一数据识别信息包括标识所述服务器装置上的主资源的第一统一资源标识符即第一URI，并且包括将所述主资源的子部分定义为所述第一数据的子部分信息，以及

14.根据权利要求13所述的方法，其中，所述子部分信息包括所述主资源内的字节的范围值。

15.根据权利要求10所述的方法，其中，所述一个或多个可选头部字段包括变化部分信息和替代信息，其中所述变化部分信息识别参考URI中的至少一个变化子部分，以及所述替代信息包括用以替换在所述参考URI中识别出的变化子部分以定义所述第二URI的至少一个替代值。

16.根据权利要求15所述的方法，其中，所述变化部分信息使用所述替代信息中所包括的各个替代值来识别所述参考URI中的供替代的两个或更多个子部分。

17.一种用于在服务器装置和客户端装置之间传输数据的方法，所述方法在所述客户端装置处包括以下步骤：

识别要从所述服务器装置获得的数据；

生成用以从所识别出的数据获得第一数据的超文本传输协议请求即HTTP请求，其中所述HTTP请求包括使得能够在所述服务器装置上识别所述第一数据的第一数据识别信息，并且包括一个或多个附加头部字段，其中所述一个或多个附加头部字段包含针对所述服务器装置的用以推送第二数据或者不推送所述第二数据的指示；

18.一种用于利用客户端装置来从服务器装置接收数据的方法，所述方法在所述客户端装置处包括以下步骤：

发送用以获得第一数据的超文本传输协议请求即HTTP请求，其中所述HTTP请求包括使得能够在所述服务器装置上识别所述第一数据的第一数据识别信息，并且包括一个或多个附加头部字段；

将所述HTTP请求发送至所述服务器装置。

19.一种用于从服务器装置向客户端装置发送数据的方法，所述方法在所述服务器装置处包括以下步骤：

从所述客户端装置接收用以获得第一数据的超文本传输协议请求即HTTP请求，其中所述HTTP请求包括使得能够在所述服务器装置上识别所述第一数据的第一数据识别信息，并且包括一个或多个附加头部字段；

20.根据权利要求19所述的方法，其中，表示所述服务器装置将不推送任何第二数据的信息项包括至少一个唯一标识符，其中所述至少一个唯一标识符代表用于不推送所述第二数据的指令。

21.根据权利要求18所述的方法，其中，还包括以下步骤：响应于发送所述HTTP请求，从所述服务器装置接收确认数据，其中所述确认数据包括表示所述服务器装置将不推送任何不同于所述第一数据的第二数据的信息项。

22.根据权利要求19所述的方法，其中，还包括以下步骤：

23.根据权利要求19所述的方法，其中，表示所述服务器装置将不推送任何第二数据的信息项包括至少一个唯一标识符，其中所述至少一个唯一标识符代表用于不推送所述第二数据的指令。

24.根据权利要求19所述的方法，其中，表示所述客户端装置不想所述服务器装置推送任何第二数据的信息项包括至少一个唯一标识符，其中所述至少一个唯一标识符代表用于不推送所述第二数据的指令。

25.一种用于在服务器装置和客户端装置之间传输数据的方法，所述方法在所述服务器装置处包括以下步骤：

在所述第一可选头部字段存在于所述HTTP请求中的情况下，

使用从所述HTTP请求获得的主资源来识别一组数据；

将所述第二数据推送至所述客户端装置，

其中，所述一个或多个过滤参数：

26.一种用于在服务器装置和客户端装置之间传输数据的方法，所述方法在所述客户端装置处包括以下步骤：

将所述HTTP请求发送至所述服务器装置以获得所述第一数据，并且驱动所述服务器装置，以根据所述一个或多个过滤参数来推送在从所述HTTP请求推断出的主资源中所引用的第二数据；

其中，所述一个或多个过滤参数：

27.一种可编程设备所用的计算机程序产品，所述计算机程序产品包括指令，所述指令用于在程序被所述可编程设备加载并执行的情况下，实现根据权利要求1、17、18、19、25和26中任一项所述的方法的各步骤。

28.一种计算机可读存储介质，用于存储计算机程序的指令，所述指令用于实现根据权利要求1、17、18、19、25和26中任一项所述的方法。

29.一种装置，其包括被配置为执行根据权利要求1、17、18、19、25和26中任一项所述的方法的各步骤的部件。