网络装备和用于递送数据分组的方法

技术领域

本公开一般涉及用于将多媒体内容从网络装备传递到客户端设备的数据分组序列的递送。

背景技术

本部分旨在向读者介绍可能与下面描述和/或要求保护的本公开的各个方面相关的技术的各个方面。相信该讨论有助于向读者提供背景信息，以便于更好地理解本公开的各个方面。因此，应当理解，这些陈述应就此而论来阅读，而不是作为对现有技术的承认。

TCP(传输控制协议)是被设计为通过因特网协议(IP)发送数据分组的网络通信协议。它为因特网上使用的几乎所有应用提供了可靠的递送，包括Web应用、文件传输协议应用、安全外壳应用、对等文件共享、甚至流媒体应用。

虽然TCP是以精确而不是及时递送为目标设计的，但是它已经主要用于视频流，特别是采用HTTP自适应流(HAS)。

特别地，HTTP自适应视频流技术被各种利益相关者推动以允许在因特网中提供顶级视听递送。这样的技术允许客户端设备接收小的连续片段(几秒长)形式的视频，即所谓的块(chunk)。每个片段通过HTTP协议被请求，并且可以以不同的变型(所谓的表示，其针对自适应流协议)存在，允许客户端设备在任何时间选择匹配网络和设备约束的适当比特率。

在视频流中，由于HTTP是无状态协议，因此客户端设备通过控制视频适配来扮演中心角色。它允许部署传统HTTP服务器和缓存而不是专门的流装备。基于HTTP的递送防止NAT(网络地址转换)和防火墙遍历问题。

作为可靠的流递送服务，TCP协议保证所有接收到的字节将与发送的字节相同并且处于正确的顺序。当发送数据分组(在TCP术语中称为片段)时，将所传送的数据放入重传队列中，并且触发与数据分组相关联的定时器。当在定时器结束之前没有接收到对片段的确认时，发生重传，即，由客户端设备重传该片段直到其确认，或者直到(长)超时期满(在该情况下，认为连接断开并且将被关闭)。

然而，当所递送的数据具有实时约束时(在视频流传输中的情况下)，这种行为可能是不适当的。实际上，当超过在目的地应用上处理和渲染(rendering)的时间时，视频片段没有理由再被递送。

本公开是考虑到前述内容而设计的。

发明内容

根据一个或多个实施例，提供了一种网络装备，其被配置为通过网络与设备通信以递送包括初始有效载荷的数据分组，

所述网络装备包括一个或多个处理器，所述一个或多个处理器被配置用于：

-获得要被递送到所述设备的所述数据分组的所述初始有效载荷的到期时间，

-将属于根据数据分组确认而移动的滑动窗口的数据分组递送到所述设备，

-当到达属于所述滑动窗口的数据分组的初始有效载荷的到期时间而没有从所述设备接收到相应确认时，重新发送具有与要通过所述滑动窗口传送的至少一个下一数据分组的初始有效载荷相对应的新的有效载荷的所述数据分组。

根据一个或多个实施例，提供了一种在网络装备处实现的方法，所述网络装备被配置为通过网络与设备通信以递送包括初始有效载荷的数据分组，所述方法包括：

-获得要被递送到所述设备的所述数据分组的所述初始有效载荷的到期时间，

-将属于根据数据分组确认而移动的滑动窗口的数据分组递送到所述设备，

-当到达属于所述滑动窗口的数据分组的初始有效载荷的到期时间而没有从所述设备接收到相应确认时，重新发送具有与要通过所述滑动窗口传送的至少一个下一数据分组的初始有效载荷相对应的新的有效载荷的所述数据分组。

根据一个或多个实施例，提供了一种设备，被配置为通过网络与网络装备通信以接收包括初始有效载荷的数据分组，

所述设备包括一个或多个处理器，所述一个或多个处理器被配置用于：

-从网络装备接收属于根据数据分组确认而移动的滑动窗口的数据分组，

-当到达属于所述滑动窗口的数据分组的初始有效载荷的到期时间而所述设备没有发送相应确认时，接收具有与要通过所述滑动窗口传送的至少一个下一数据分组的初始有效载荷相对应的新的有效载荷的所述数据分组。

根据一个或多个实施例，提供了一种在设备处实现的方法，所述设备被配置为通过网络与网络装备通信以接收包括初始有效载荷的数据分组，

所述方法包括：

-从网络装备接收属于根据数据分组确认而移动的滑动窗口的数据分组，

-当到达属于所述滑动窗口的数据分组的初始有效载荷的到期时间而所述设备没有发送相应确认时，接收具有与要通过所述滑动窗口传送的至少一个下一数据分组的初始有效载荷相对应的新的有效载荷的所述数据分组。

根据一个或多个实施例，提供了一种计算机程序产品，其是可从通信网络下载的计算机程序产品和被记录在非暂时性计算机可读介质上的计算机程序产品中的至少一者，所述非暂时性计算机可读介质由计算机中的至少一者可读并且由处理器可运行，所述计算机程序产品包括用于执行要在网络装备处实现的方法的程序代码指令，所述网络装备被配置为通过网络与设备通信以递送包括初始有效载荷的数据分组，

所述方法包括：

-获得要被递送到所述设备的所述数据分组的所述初始有效载荷的到期时间，

-将属于根据数据分组确认而移动的滑动窗口的数据分组递送到所述设备，

-当到达属于所述滑动窗口的数据分组的初始有效载荷的到期时间而没有从所述设备接收到相应确认时，重新发送具有与要通过所述滑动窗口传送的至少一个下一数据分组的初始有效载荷相对应的新的有效载荷的所述数据分组。

根据一个或多个实施例，提供了一种计算机可读的非暂时性程序存储设备，其有形地体现可由计算机运行的指令程序，以执行要在网络装备处实现的方法，所述网络装备被配置为通过网络与设备通信以递送包括初始有效载荷的数据分组，

所述方法包括：

-获得要被递送到所述设备的所述数据分组的所述初始有效载荷的到期时间，

-将属于根据数据分组确认而移动的滑动窗口的数据分组递送到所述设备，

-当到达属于所述滑动窗口的数据分组的初始有效载荷的到期时间而没有从所述设备接收到相应确认时，重新发送具有与要通过所述滑动窗口传送的至少一个下一数据分组的初始有效载荷相对应的新的有效载荷的所述数据分组。

根据一个或多个实施例的方法可以在可编程装置上的软件中实现。它们可以单独地以硬件或软件或其组合来实现。

由一个或多个实施例的元素实现的一些过程可以是计算机实现的。因此，这样的元素可以采取完全硬件实施例、完全软件实施例(包括固件、驻留软件、微代码等)或组合软件和硬件方面的实施例的形式，其可以全部在本文中一般地被称为“电路”、“模块”或“系统”。此外，这样的元素可以采取在任何有形表达介质中体现的计算机程序产品的形式，该有形表达介质具有在该介质中体现的计算机可用程序代码。

由于元素可以以软件实现，因此实施例的一些方面可以被实现为计算机可读代码，用于在任何适当的载体介质上提供给可编程装置。有形载体介质可以包括存储介质，例如软盘、CD-ROM、硬盘驱动器、磁带设备或固态存储器设备等。

一个或多个实施例因此提供了一种计算机可读程序，其包括计算机可运行指令以使得计算机能够执行上述方法。

下面阐述与所公开的实施例的范围相当的某些方面。应当理解，这些方面仅被呈现以向读者提供一个或多个实施例可能采取的某些形式的简要概述，并且这些方面不旨在限制本公开的范围。实际上，本公开可以涵盖可能未在下面阐述的各种方面。

附图说明

通过以下实施例和运行示例，将更好地理解和说明本公开，但本公开不以任何方式限制，参考附图，其中：

-图1是示例性客户端-服务器架构的示意图，其中可以实现一些实施例；

-图2是图1的示例性客户端设备的框图，其中可以实现一些实施例；

-图3是图1的服务器的框图，其中可以实现一些实施例；

-图4示出了根据TCP协议的用于客户端设备和服务器之间的连接建立的示例性片段序列；

-图5示出了通过TCP连接在服务器和客户端设备之间交换的示例性片段序列，每个片段被正确地接收和确认；

-图6示出了通过TCP连接在服务器和客户端设备之间交换的示例性片段序列，其中一个片段未被客户端设备确认；

-图7描绘了被操作以用于在服务器和客户端设备之间传送片段序列的滑动窗口的演变；

-图8示出了当实现滑动窗口机制时从服务器向客户端设备递送片段序列，每个片段由客户端设备接收和确认；

-图9示出了与图8中所示的片段相同的片段递送，其中一个片段未被客户端设备确认；

-图10是根据一些实施例的用于将片段序列从服务器递送到客户端设备的示例性方法的流程图；

-图11描绘了根据一些实施例的与序列片段的初始有效载荷相关联的到期时间；

-图12示出了根据一些实施例的包括TCP片段的示例性IP数据报；

-图13示出了根据一些实施例的当实现滑动窗口机制时从图1的服务器到客户端设备的片段序列的传输；

-图14示出了根据一些实施例的图13的序列的接收片段的有效载荷；

-图15示出了图14的接收片段的重新排序的有效载荷。

在可能的情况下，在所有附图中使用相同的附图标记来表示相同或相似的部件。

具体实施方式

以下描述示出了一些实施例。因此，将理解，本领域技术人员将能够设计各种布置，尽管未在本文中明确描述或示出，但是这些布置体现实施例的一些方面并且被包括在其范围内。

本文所述的所有示例和条件语言旨在用于教育目的以帮助读者理解实施例，并且应被解释为不限于此类具体所述的示例和条件。

此外，本文中叙述实施例的所有陈述及其特定示例旨在涵盖其结构和功能等效物两者。另外，这些等同物旨在包括当前已知的等同物以及将来开发的等同物，即，所开发的执行相同功能的任何元素，而不管结构如何。

因此，例如，本领域技术人员将理解，本文呈现的框图表示体现实施例的一些方面的说明性电路的概念视图。类似地，将理解，任何流程图、流图、状态转移图、伪代码等表示可基本上在计算机可读介质中表示并因此由计算机或处理器运行的各种过程，而不管是否明确示出了这样的计算机或处理器。

可以通过使用专用硬件以及能够与适当软件相关联地运行软件的硬件来提供图中所示的各种元素的功能。当由处理器提供时，功能可以由单个专用处理器、单个共享处理器或多个单独的处理器提供，其中一些可以被共享。此外，术语“处理器”或“控制器”的明确使用不应被解释为排他性地指代能够运行软件的硬件，并且可以隐含地包括但不限于数字信号处理器(DSP)硬件、用于存储软件的只读存储器(ROM)、随机存取存储器(RAM)和非易失性存储装置。

在其权利要求中，被表达为用于执行指定功能的装置(means)和/或模块的任何元素旨在包括执行该功能的任何方式，包括例如：a)执行该功能的电路元素的组合；或者b)任何形式的软件，因此包括固件、微代码等，与用于运行该软件以执行该功能的适当电路组合。因此，认为可以提供那些功能的任何装置都等效于本文所示的那些装置。

另外，应理解，本发明的图式和描述已被简化以说明与清楚理解本实施例相关的元素，同时出于清楚的目的而消除在典型数字多媒体内容递送方法、设备和系统中发现的许多其它元素。然而，因为这些元素在本领域中是公知的，所以在此不提供对这些元素的详细讨论。本文的实施例涉及本领域技术人员已知的所有这样的变化和修改。

描述了关于通过递送网络将多媒体内容(诸如视频)递送到客户端设备的流环境(诸如自适应流技术)的实施例。当然应该理解，这些实施例的实现不限于流环境。

如图1的示例性实施例所示，包括第一网络10(例如家庭网络、企业网络)和第二网络20(例如诸如因特网的宽带网络)的客户端-服务器网络架构包含与网关200和诸如内容服务器(在图1中，表示了三个服务器)的网络装备300通信的客户端设备100。第一网络10例如通过网关200连接到第二网络20。

客户端设备100(例如，通过网络10(作为家庭网络或企业网络)连接到网关200的流客户端设备)希望通过宽带网络20连接到服务器300(例如，HTTP服务器)，以便发起用于从因特网20检索多媒体内容的流会话。一旦与客户端设备100建立连接，服务器300就应请求，使用流协议通过例如一个或多个TCP/IP连接，将片段流式传输(stream)到客户端设备100。根据TCP术语，数据分组被称为片段。

如图2的示例所示，在一个实施例中，第一网络10的客户端设备100可以至少包含：

-(一个或多个)接口101，用于到网络10或到另外的网络(未示出)的连接(有线和/或无线，例如Wi-Fi、以太网等)；

-通信电路102，实现用于与一个或多个服务器300通信的协议栈。特别地，通信电路102包括TCP/IP栈。当然，它可以是使客户端设备100能够与服务器300通信的任何其它类型的网络和/或通信装置；

-流控制器103，其沿流会话从一个或多个服务器300(尤其是相应的片段)接收多媒体内容。特别地，在自适应流的情况下，流控制器103可以例如以更好地匹配网络约束和其自身约束的比特率连续地选择片段；

-视频播放器104，适于解码和渲染通过流会话接收的多媒体内容。应当理解，在一变型中，流控制器103和视频播放器104可以组合以形成单个实体；

-一个或多个处理器105，用于运行存储在客户端设备100的存储器中的应用和程序；

-一个或多个存储组件106(例如，易失性或非易失性存储器，包括RAM、SRAM、DRAM、ROM、可编程ROM(PROM)、闪存、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)等)，用于存储信息和指令代码。特别地，易失性存储器例如可以在从服务器300接收的片段被传输到视频播放器104之前对这些片段进行缓冲；

-内部总线107(硬件和/或软件实现)，连接各种模块和本领域技术人员公知的用于执行通用客户端设备功能的所有装置。

作为示例，客户端设备100是便携式媒体设备、移动电话、平板电脑或膝上型电脑、头戴式设备、电视机、机顶盒等。自然地，客户端设备100可以不包括完整的视频播放器，而仅包括一些子元素，诸如用于解复用和解码媒体内容的子元素，并且可以依赖于外部装置来向终端用户显示解码的内容。

此外，在实施例中，网关200可以是例如数字用户线(DSL)网关，其通过DSL技术提供到本地网络10的因特网宽带接入。当然，网关可以是任何类型的宽带网关，例如电缆、光纤或无线。

如图3的示例所示，网络装备300可以至少包括：

-到第二网络20的连接接口301；

-通信电路302，用于将数据递送到一个或几个进行请求的设备100。特别地，通信电路302可以包括本领域公知的TCP/IP栈。当然，它可以是使网络装备300能够与客户端设备100通信的任何其它类型的网络和/或通信装置；

-流控制器303，被配置为在流会话期间将多媒体内容递送给一个或多几个客户端设备100；

-一个或多个存储组件304，例如易失性或非易失性存储器，包括RAM、SRAM、DRAM、ROM、可编程ROM(PROM)、闪存、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)等)，用于存储信息和指令代码；

-一个或多个处理器305，用于运行存储在网络装备300的非易失性存储器中的应用和程序；

-内部总线306，用于连接各种模块和本领域技术人员公知的用于执行通用网络装备功能的所有装置。

在图4的示例中，在TCP连接建立期间交换的片段的序列的时间线如下：

-客户端设备100发送SYN片段，该SYN片段指定客户端设备100想要连接到的服务器300的端口号和客户端设备的初始序列号(所谓的ISN，在该示例中设置为x)；

-服务器300以其自己的包含服务器的初始序列号(在该示例中被设置为y)的SYN片段来响应。服务器300还利用包括客户端设备的ISN加一的ACK来确认客户端的SYN片段。SYN片段消耗一个序列号；

-客户端设备100通过发送包括服务器的ISN加一的ACK片段来确认由服务器300递送的SYN片段。

客户端100和服务器300维护它们自己的32位序列号(随机初始化的)，用于跟踪它们已经发送的数据量。该序列号被嵌入在每个传送的片段上，并且由相对主机确认为确认号，以通知发送主机传输的数据被成功接收。序列号在每个传送字节递增一。

每个TCP片段包括TCP报头(header)，该TCP报头指定与其有效载荷(所谓的数据块或数据片段)的第一个字节相关联的序列号(下文中记为SN)。片段还携带确认号，该确认号是要在相反方向上递送的下一个期望的数据八位字节的序列号。

在下文中，为了清楚起见，假设x＝0且y＝0，使得当建立连接时，分别与客户端设备100和服务器300相关联的序列号SN1和SN2等于1(即，SN1＝1且SN2＝1)。

此外，图5示出了沿着TCP连接在服务器300和客户端100之间交换的示例性片段序列，每个片段被正确地接收并且用ACK片段确认。根据TCP协议，ACK片段是累积的，即它们确认接收方(在该示例中，客户端100)已经正确地接收到所有字节，直到ACK中涉及的确认序列号减一。

图6的示例还描绘了由服务器300发送的一个片段(具有等于2049的相关联的序列号的片段)没有到达客户端设备100的情况。根据RFC 5681，当无序片段到达时，接收方(即，客户端100)发送立即复制的ACK片段(即，用于确认先前接收的片段的相同ACK)。该复制的ACK片段用于通知发送方(即服务器300)片段被无序接收以及期望哪个序列号。

在图6中，服务器300在不知道有什么问题的情况下，发送属于下文定义的滑动窗口的片段。客户端100接收序列号不连续的片段(即，SN＝3073的片段)，并且然后生成复制的ACK片段(包括确认第一个接收到的片段的序列号1025)。当服务器300已经接收到序列号等于1025的三个复制的ACK片段时，它重传该序列号之后的片段。根据TCP范例，当片段未被确认时，发送方将尝试重传它。

应当注意，ACK片段的复制不是管理片段丢失及其后续重传(例如，也可以实现超时)的唯一方式。

除了通信路径上可用带宽的限制之外，单个TCP连接的最大可实现吞吐量由称为滑动窗口协议的流控制来确定，允许发送方在停止并等待确认之前传送多个片段。

TCP滑动窗口协议依赖于两个不同的变量：

-拥塞窗口(cwnd)，其限制TCP在接收到ACK片段之前可以传送到网络中的数据量；

-接收方窗口(rwnd)，用于通知目的端可以接收的数据量。

发送方最多可以传送拥塞窗口和被通告的接收方窗口中的最小值。

特别地，拥塞窗口由源(例如服务器300)维护，并且确定可以被传送的数据量以避免网络中的拥塞。当与另一网络上的主机建立新连接时(在两个端点之间的路径上具有不同比特率的路由器或链路可能发生拥塞)，拥塞窗口被初始化为一值，该值取决于发送方可以传送的最大片段(如RFC 5681的慢启动策略中所指定的，这样的值通常为4000字节左右)。每次接收到ACK片段，拥塞窗口就增加一片段。当拥塞窗口大小低于某一阈值时，使用慢启动算法，否则使用拥塞避免算法。在拥塞避免期间，拥塞窗口大小每往返时间(RTT)增加大约一个完整大小的片段。拥塞避免继续，直到检测到拥塞为止。

滑动窗口700的示例性演变在图7中描绘。由接收方提供的窗口(rwnd)可以接受4个字节。在时间t1，滑动窗口700覆盖字节4至7(即，发送方已经传送字节1至3，并且接收方已经确认前三个字节的接收)。随着时间的推移，当接收方确认数据时，滑动窗口700移动(到图7中的右侧)。在时间t2，字节4和5被接收，但还没有被接收方确认，使得滑动窗口700的左边缘向右移动(以TCP术语来说，窗口关闭)。当这些字节在接收缓冲器中时，接收方将其窗口大小减小到2字节。一旦字节4和5已经被接收方侧的应用读取，释放TCP接收方缓冲器中的空间，接收方就可以在时间t3宣告4字节的窗口(以TCP术语来说，窗口打开)，即滑动窗口700的右边缘向右移动。

当左边缘到达滑动窗口700的右边缘(称为零窗口)时，发送方停止递送任何数据。

在表示先前关于图5描述的数据传输的片段(数据片段和ACK段)序列的图8的示例中，第一行是由发送方Tx(诸如服务器300)发送或要发送的数据片段900.1至900.9的时间表示。第二行示出了当确认被发送方Tx从接收方Rx(例如，客户端设备100)接收时所定位的确认。所宣告的接收方窗口对应于当前接收方窗口700，并且与在时间t0要传送的片段序列对准。

在图8中，接收的片段的确认950实现了RFC 2018(TCP选择性确认选项)中定义的选择性确认(SACK)方案，以用于在一个TCP数据滑动窗口中丢失了多个片段时提高性能。根据选择性确认方案，接收方可以确认无序接收的片段。然后，接收方可以通知发送方关于已经成功接收的所有片段，因此发送方需要仅重传实际上已经丢失的片段(而不是来自第一个丢失片段的所有片段)。该选择性确认方案以TCP协议中的选项的形式实现，该选项包括由已接收和排队的数据占据的连续序列空间的块的列表。根据TCP术语，SACK是具有SACK选项的ACK，其提供两种类型的信息：

-序列号值，其指示已经接收到直到序列号减一的所有字节(即，ACK)；

-在数据接收方处排队的连续块的第一个字节的序列号，该序列号紧跟在该块的最后一个序列号之后(即，SACK选项)。

为了解释的目的，在图8的示例中考虑所有片段900.1到900.9具有相同的1024字节大小，并且接收方将其窗口700维持在4096字节大小(即对应于四个片段)。接收方窗口(rwnd)大小被嵌入确认片段的TCP报头中，使得接收方传送每个ACK(或SACK)片段，其中窗口大小字段被设置为4096字节。因此，滑动窗口700在每次接收到确认窗口的第一个片段的SACK时向右移动。

应当理解，将接收方窗口大小保持在恒定值意味着在接收方处实现的TCP层中，以相同的速率执行从网络接收片段和将所述接收的片段传输到上层(或应用)。

在图8中，发送方Tx希望把片段1到片段9(900.1到900.9)发送到接收方Rx，该接收方Rx宣告4096字节大小的接收方窗口。在时间t0，发送方Tx将片段1递送到片段4。接收方利用指定所接收的片段的序列号加一的累积ACK来确认这些片段中的每一个的接收(当被接收时)。根据滑动窗口机制，当接收方没有确认片段1时，片段5不能被传送。当在时间t1确认片段1时，滑动窗口700向右移动，允许片段5的发送方Tx进行发送。当正确确认递送的片段时，重复该方案。

图9中所示的示例类似于图8中所示的示例，除了片段3(900.3)没有被接收方Rx确认，片段3从不到达接收方Rx。然后，滑动窗口700在位置3处被阻挡(其中，片段3到6由发送方Tx递送)，并且因此，片段7不能被发送。一旦片段4、5和6(900.4到900.6)已经被发送并且利用具有SACK选项的ACK被确认(950)，来自发送方Tx的数据传输在此被减少到片段3的重传。当由片段1到9(900.1至900.9)的序列定义的数据流专用于实时应用(诸如视频流)时，数据传输可以被阻挡或显著地减少以便尝试递送如果太晚到达则应用将从不使用的片段(在该示例中，片段3)。

在实施例中，为了克服这种情况，例如在用于递送被分割成片段的多媒体内容(例如视频内容和/或音频内容)的流会话期间，在通过网络10与设备100通信的服务器300处实现如图10所示的方法1000。在TCP连接的说明性示例中，每个片段特别地包括TCP报头和TCP数据字段(即，有效载荷)并且携带序列号(数据字节由TCP层根据它们的序列号来递送)。

在步骤1001中，服务器300(例如，由于其(一个或多个)处理器305和/或其流控制器303)获得要被递送到设备的每个数据片段900.1、……、900.9的初始有效载荷的到期时间。通过为传递多媒体内容的数据的每个片段的初始有效载荷实现这样的到期时间，可以防止服务器300使用资源来发送无用数据(即，将永远不会被客户端设备100使用的数据)。

对于要被递送到客户端设备100的每个片段i，服务器300确定客户端侧的解码时间Ti。当要递送的多媒体内容是视频或音频文件时，一系列压缩数据(视频或声音)与相关联的解码时间一起被存储在视频或音频文件中，使得服务器300对多媒体内容的片段暗示知道音频或视频译码。在这种情况下，知道第一个帧(或图片)或音频样本的解码时间，服务器300能够确定所有其他帧或样本的解码时间。在某些文件格式中，例如以时间戳的形式提供帧或音频样本的解码时间。

在实施例中，如图11所示，要被递送的片段(并且更具体地，该片段的第一个样本)的初始有效载荷901的到期时间t

t

其中：

-t

-MTBR定义在客户端侧进行渲染之前的最大时间。在实施例中，MTBR取决于在处理之前的片段在设备处的最大缓冲时间(即，片段在缓冲器中花费的最大时间)和解码时间(即，客户端设备进行的片段的解码开始时间)。该时间是依赖于实现的，并且可以由客户端设备100提供给服务器300。在一个说明性而非限制性的示例中，MTBR等于最大缓冲时间加上解码时间；

-RTT/2是服务器300和客户端设备100之间的片段传输持续时间的评估。

从所确定的片段的初始有效载荷的到期时间t

t

其中SP对应于采样周期(即，在视频的情况下的帧周期；或声音的音频样本)。

应当理解，片段的初始有效载荷的到期时间对应于该片段的要处理的第一个视频帧或第一个音频样本的到期时间。

在步骤1002中，服务器300开始向客户端设备100递送(例如，经由流控制器303和/或通信电路302和/或其(一个或多个)处理器305)属于如上定义的滑动窗口700的片段。新的特定报头902被添加到由服务器300递送的每个片段的有效载荷。特定报头902(例如，布置在有效载荷的开始处)包括片段的有效载荷的长度和片段编号。特定报头的长度字段允许应用层定位下一个片段的位置(这可能是需要的，因为TCP栈知道片段长度，但是不能使其可由上层应用层访问)。片段编号允许在处理之前对数据重新排序。

在步骤1003中，服务器100(例如，经由其流控制器303和/或处理器305)确定到达属于滑动窗口700的片段的初始有效载荷的到期时间而没有从设备100接收到相应确认。

在步骤1004中，当到达属于滑动窗口700的片段的初始有效载荷的到期时间而没有从设备100接收到相应确认时，服务器300重新发送具有与要通过滑动窗口700传送的下一片段的初始有效载荷相对应的新的有效载荷的所述未确认片段。与重新发送的片段相关联的序列号保持不变，仅修改初始有效载荷。

应当注意，要通过滑动窗口传送下一片段不一定是与滑动窗口700相邻的片段(尤其是当所述相邻片段的内容也过时(obsolete)，即到达该片段的初始有效载荷的到期时间时)。此外，在另一实施例中，当有效载荷的长度在片段之间不同时(即，有效载荷的长度对于每个片段不是恒定的且不是相同的)，未确认片段的新的有效载荷可以包括要通过滑动窗口传送的若干下一片段的初始有效载荷(例如，要传送的下一片段的初始有效载荷的长度之和等于未确认片段的初始有效载荷的长度)。在变型中，当下一片段的初始有效载荷超过未确认片段的初始有效载荷时，未确认片段的新的有效载荷可以包括要通过滑动窗口传送的下一片段的初始有效载荷的一部分。

为此，服务器300可以进一步检查替换未确认片段(即，图13的示例中的片段3)的初始有效载荷的新的有效载荷是否过时(即，达到相关联的到期时间)。在新的考虑的有效载荷也到期的情况下，服务器300将考虑下一个片段的初始有效载荷也到期，例如与嵌入所考虑的有效载荷的片段相邻的片段。

如图12所示，TCP提供在经由IP网络通信的主机上运行的应用之间的字节流的可靠、有序和错误校验的递送，一旦已经接收到嵌入新的有效载荷的未确认片段，TCP层就以片段顺序向上层递送滑动窗口700的片段，因为这些片段被看作连续的数据系列。由于有效载荷的添加的特定报头，将通知上层在处理之前需要对未确认片段重新排序。

此外，还没有通过滑动窗口700递送的用于传递多媒体内容的片段序列的后续片段也将使其初始有效载荷以序列顺序被传输到前一片段(还未被传送)。它们的初始有效载荷将进一步被例如以序列顺序被传送的下一个相邻片段的有效载荷所替换。然而，初始有效载荷被替换的片段的序列号保持不变。

在图13的示例中，类似于图9的示例，除了方法1000现在在服务器300处实现之外，由于缺少设备100对服务器300发送的片段3(与序列号3072相关联)的确认，所以滑动窗口700在位置3处被阻挡。在滑动窗口700的位置3，片段3至6可以由服务器300传送到设备100。在片段3的初始有效载荷的到期时间，片段4至6(900.4至900.6)已经被传送，并且由设备100利用包括SACK选项的ACK消息来确认。片段7(900.7)不能由服务器300发送，因为它在滑动窗口700之外，但是它将是要通过滑动窗口700传送的下一片段(一旦在位置4中偏移)。

没有接收到确认片段3(900.3)的ACK消息(SN＝2049)，这阻止了服务器300将滑动窗口700更新到位置4。当服务器300通过具有SACK选项(SN＝3073到SN＝4097)的ACK(具有SN＝2049)接收到对片段4的确认时，由于片段3的确认丢失，它不能将滑动窗口700更新到位置5。在接收到具有用于确认片段5的SACK选项(SN＝3073到SN＝5121)的ACK(SN＝2049)和具有用于确认片段6的SACK选项(SN＝3073到SN＝6145)的ACK(SN＝2049)时，发生相同的行为。

然而，由于方法1000，片段7(900.7)的初始有效载荷可以利用片段3(900.3)传送，而不是片段3的初始有效载荷现在已过时。这对于客户端100的TCP层是透明的，因为它不处理片段内的数据。现在将片段7看作片段3，即编号在2049和3072之间的1024字节的片段。修改后的片段3的TCP报头保持不变(除了校验和)，仅改变其初始有效载荷。

当客户端设备100最终接收到具有片段7的初始有效载荷的片段3时，其利用ACK消息进行确认，该ACK消息指定与下一期望字节(即，片段7的初始有效载荷的与SN＝6145相对应的第一字节，其已经利用片段3而被传送)相关联的序列号。在接收到这种ACK时，服务器将TCP窗口700更新到位置7。

由于片段3的初始有效载荷与片段7的初始有效载荷的改变，服务器300通过替换片段的初始有效载荷来继续通过滑动窗口700递送片段。例如，片段8的初始有效载荷(如果未期满)利用片段7而被发送，在片段7中标识的序列号保持不变(即SN＝6145)。类似地，片段9的初始有效载荷(如果未期满)利用片段8而被发送，在片段8中标识的序列号未改变(即SN＝7169)。

在要被传输到进行传输的序列顺序中的前一片段的片段的初始有效载荷也过时的情况下，可以考虑序列顺序中的下一片段的初始有效载荷。

图14示出了由设备100的TCP层递送到上层的接收的片段3到6的有效载荷。如图所示，根据它们相应的片段的序列号来递送有效载荷，以便在片段4到6的初始有效载荷之前递送由片段3传送的片段7的初始有效载荷。然后，上层使用所添加的特定报头的片段编号来以正确顺序对数据重新排序，如图15所示。

上述方法的实现可以允许例如在流会话期间通过避免过时数据的不必要重传来改进带宽使用，同时保持支持数据递送的网络协议(诸如TCP)的可靠性。然后，网络资源被用于递送将被客户端设备真正使用的数据而不是无用数据。此外，它可以允许在面对网络中的分组丢失和/或延迟时减少等待时间，并且减少TCP发射机中的缓冲大小。这种实现仍然符合TCP协议。

虽然已经利用TCP连接的实现方式描述了上述实施例，但是还可以使用其他适当的网络协议。

还应当理解，从应用的角度来看，为了实现方法1000，应用将通知服务器300它确实支持无序数据。

更一般地，在实施例中，被配置为通过网络与设备通信以递送包括初始有效载荷的数据分组的网络装备包括一个或多个处理器，所述一个或多个处理器被配置用于：

-获得要被递送到所述设备的所述数据分组的所述初始有效载荷的到期时间，

-将属于根据数据分组确认而移动的滑动窗口的数据分组递送到所述设备，

-当到达属于所述滑动窗口的数据分组的初始有效载荷的到期时间而没有从所述设备接收到相应确认时，重新发送具有与要通过所述滑动窗口传送的至少一个下一数据分组的初始有效载荷相对应的新的有效载荷的所述数据分组。

在另一实施例中，一种在网络装备处实现的方法，所述网络装备被配置为通过网络与设备通信，以递送包括初始有效载荷的数据分组，所述方法包括：

-获得要被递送到所述设备的所述数据分组的所述初始有效载荷的到期时间，

-将属于根据数据分组确认而移动的滑动窗口的数据分组递送到所述设备，

-当到达属于所述滑动窗口的数据分组的初始有效载荷的到期时间而没有从所述设备接收到相应确认时，重新发送具有与要通过所述滑动窗口传送的至少一个下一数据分组的初始有效载荷相对应的新的有效载荷的所述数据分组。

在实施例中，所述重新发送的数据分组的新的有效载荷的到期时间尚未达到。

在实施例中，当至少一个数据分组已经利用新的有效载荷而被重新发送时，将尚未通过滑动窗口传送的后续分组的初始有效载荷被传输至一个或多个先前分组以进行递送。

在实施例中，每个数据分组与序列号相关联，与所述重新发送的数据分组相关联的序列号保持不变。

在实施例中，当TCP协议被实现以用于传送数据分组时，除了校验和之外，重新发送的数据分组的TCP报头保持不变。

在实施例中，数据分组的初始有效载荷的到期时间对应于该数据分组的要被处理的第一个视频帧或第一个音频样本的到期时间。

在实施例中，其中数据分组的初始有效载荷的到期时间取决于渲染之前的最大时间和数据分组从网络装备到设备的传输时间。

在实施例中，其中数据分组的渲染之前的最大时间取决于数据分组在设备处的处理之前的最大缓冲时间和解码时间。

在实施例中，特定报头被添加到每个数据分组的初始有效载荷。

在实施例中，数据分组的特定报头包括数据分组的初始有效载荷的长度和分组编号。

在说明书、权利要求书和附图中公开的参考可以独立地或以任何适当的组合提供。在适当的情况下，特征可以以硬件、软件或两者的组合来实现。

本文对“一个实施例”或“实施例”的参考意味着结合实施例描述的特定特征、结构或特性可包括在所描述的方法和设备的至少一个实现中。在说明书中的各个地方出现的短语“在一个实施例中”不必都指相同的实施例，也不是必须与其它实施例互斥的单独的或替代的实施例。

权利要求中出现的参考标记仅作为说明，并且不应对权利要求的范围具有限制作用。

尽管本文仅描述了本公开的某些实施例，但是本领域的任何技术人员将理解，本公开的其他修改、变化和可能性是可能的。因此，这些修改、变化和可能性被认为落入本公开的精神和范围内，并因此形成如本文所述和/或例示的本公开的一部分。

附图中的流程图和/或框图示出了根据本公开的各种实施例的系统、方法和计算机程序产品的可能实现的配置、操作和功能。在这点上，流程图或框图中的每个框可以表示模块、片段或代码的部分，其包括用于实现指定的(一个或多个)逻辑功能的一个或多个可运行指令。还应当注意，在一些替代实现中，框中所标注的功能可以不按图中所标注的顺序发生。例如，连续示出的两个框实际上可以基本上同时运行，或者这些框有时可以以相反的顺序运行，或者这些框可以以替代的顺序运行，这取决于所涉及的功能。还将注意，框图和/或流程图图示的每个框以及框图和/或流程图图示中的框的组合可以由执行指定功能或动作的基于专用硬件的系统或专用硬件和计算机指令的组合来实现。虽然没有明确地描述，但是可以以任何组合或子组合来采用本实施例。

此外，应当理解，例如在“A/B”、“A和/或B”以及“A和B中的至少一者”的情况下，使用以下“/”、“和/或”以及“……中的至少一者”中的任何一个旨在涵盖仅对第一列出的选项(A)的选择、或仅对第二列出的选项(B)的选择、或对两个选项(A和B)的选择。作为进一步的示例，在“A、B和/或C”和“A、B和C中的至少一者”的情况下，这样的措词旨在涵盖仅选择第一列出的选项(A)，或者仅选择第二列出的选项(B)，或者仅选择第三列出的选项(C)，或者仅选择第一和第二列出的选项(A和B)，或者仅选择第一和第三列出的选项(A和C)，或者仅选择第二和第三列出的选项(B和C)，或者选择所有三个选项(A和B和C)。这可以扩展到所列的许多项，这对于本领域和相关领域的普通技术人员来说是清楚的。