CN105493449A - 速率控制 - Google Patents

Abstract

提供了一种控制通过网络以其在接收器处接收内容数据的速率的方法，其中接收器引起要在接收器处接收的实时通信事件数据的第一串流，以及要在接收器处接收的内容数据的第二串流，该方法包括以下步骤：基于实时通信事件数据动态地测量网络的网络条件；以及基于动态测量的网络条件限制以其在接收器处接收内容数据的速率。

Description

速率控制

背景技术

一些通信系统允许诸如个人计算机或移动设备之类的设备的用户通过诸如因特网之类的基于分组的计算机网络进行语音或视频呼叫。这样的通信系统包括通过互联网协议（VoIP）系统的语音或视频。这些系统对用户是有益的，因为它们通常具有比常规固定线路或移动蜂窝网络明显更低的成本。这可能特别地是针对长距离通信的情况。为了使用VoIP系统，用户在其设备上安装和执行客户端软件。客户端软件设立VoIP连接以及提供诸如注册和验证之类的其它功能。除语音通信之外，客户端还可以设立用于诸如即时消息传递（“IM”）、SMS消息传递、文件传输和语音邮件之类的其它通信媒体的连接。

在音频/视频的实时通信期间，内容的下载和上载可以发生在呼叫期间。例如，服务提供商可以选择将内容（例如广告）分发给用户，或者用户可以共享诸如照片、屏幕截图和文件之类的内容。内容的分发典型地基于超文本传输协议（HTTP）或超文本传输协议安全（HTTPS）应用协议，其中传输控制协议（TCP）作为默认底层输运协议。

发明内容

内容数据（依照TCP输运）可以通过网络传送到接收器，而同时通信事件数据也在接收器与一个或多个另外的设备之间的通信事件期间通过网络传送到接收器。

发明人已经认识到，TCP内容数据在以下意义上本质上是相当进取的：其保持增加发送速率直到网络节点处的缓冲器变满并且发生丢失。该行为引入分组丢失和高延迟抖动，其引起并发音频/视频呼叫的质量中的明显降级。

提供了一种控制在接收器处通过网络以其接收内容数据的速率的方法，其中接收器已经引起要在接收器处接收的实时通信事件数据的第一串流，以及要在接收器处接收的内容数据的第二串流，该方法包括以下步骤：基于实时通信事件数据动态地测量网络的网络条件；以及基于动态测量的网络条件而限制在接收器处以其接收内容数据的速率。

提供本发明内容来以简化形式引入以下在具体实施方式中进一步描述的概念的选择。本发明内容不意图标识所要求保护的主题的关键特征或必要特征，也不意图用于限制所要求保护的主题的范围。

附图说明

为了更好地理解本发明并且为了示出本发明可以如何付诸实践，现在将通过示例的方式对以下各图做出参照，其中：

图1示出通信系统的示意性图示；

图2是用户设备的示意性框图；

图3是协议栈的示意性框图；

图4是示例架构的功能图；

图5是图示了算法模式切换机制的流程图；以及

图6是另一示例架构的功能图。

具体实施方式

以下描述的本发明的实施例实现了在通信事件（即音频/视频呼叫）期间所经历的端对端队列延迟/分组丢失与网络的带宽利用之间的权衡。也就是说，当网络的带宽利用将降低某个百分比（例如降低20%）时，通信事件中的端对端队列延迟/分组丢失将被最小化，因而避免实时通信事件中的质量（即音频/视频呼叫质量）的降级。

现在将仅通过示例的方式描述实施例。

图1示出通信系统100，包括与第一用户设备104相关联的第一用户102（“用户A”）和与第二用户设备110相关联的第二用户108（“用户B”）。在其它实施例中，通信系统100可以包括任何数目的用户及相关联的用户设备。用户设备104和110可以通过通信系统100中的网络106通信，从而允许用户102和108通过网络106与彼此通信。用户102和108之间的通信由图1中的虚线表示。网络106可以包括用于在端点之间中继数据的一个或多个路由节点107。图1示出通信系统100，包括由服务提供商操作以将内容（即广告）分发给通信系统的一个或多个用户的广告服务器。在用户102与108之间的通信事件期间，用户可以共享诸如照片、屏幕截图和文件之类的内容。内容从广告服务器以及在用户102和108之间的分发由图1中的粗线表示。

图1中所示的通信系统100是基于分组的通信系统，但是可以使用其它类型的通信系统。网络106可以例如是互联网。用户设备104和110中的每一个可以例如是移动电话、平板电脑、膝上型电脑、个人计算机（“PC”）（包括例如Windows®、Mac OS®和Linux® PC）、游戏设备、电视、个人数字助理（“PDA”）、或者能够连接到网络106的其它嵌入式设备。用户设备104布置成从用户设备104的用户102接收信息并且向其输出信息。用户设备104包括诸如显示器和扬声器之类的输出构件。用户设备104还包括输入构件，诸如小键盘、触摸屏、用于接收音频信号的麦克风和/或用于捕获视频信号的图像的相机。用户设备104连接到网络106。

用户设备104执行由与通信系统100相关联的软件提供商所提供的通信客户端的实例。通信客户端是在用户设备104中的本地处理器上执行的软件程序。客户端施行用户设备104处所要求的处理以便使用户设备104通过通信系统100传送和接收数据。

用户设备110对应于用户设备104并且在本地处理器上执行与用户设备104处所执行的通信客户端对应的通信客户端。用户设备110处的客户端以与用户设备104处的客户端施行允许用户102通过网络106通信所要求的处理相同的方式来施行允许用户108通过网络106通信所要求的处理。用户设备104和110是通信系统100中的端点。图1为了清楚起见而仅示出两个用户（102和108）和两个用户设备（104和110），但是多得多的用户和用户设备可以包括在通信系统100中，并且可以使用在相应用户设备上执行的相应通信客户端通过通信系统100通信。

图2图示了在其上执行通信客户端实例206以用于通过通信系统100通信的用户设备104的详细视图。用户设备104包括中央处理单元（“CPU”）或“处理模块”202，连接到它的有：输出设备，诸如可以实现为触摸屏的显示器208、以及用于输出音频信号的扬声器（或“扩音器”）210；输入设备，诸如用于接收音频信号的麦克风212、用于接收图像数据的相机216以及小键盘218；用于存储数据的存储器214；以及网络接口220，诸如用于与网络106通信的调制解调器。用户设备104可以包括除图2中所示那些之外的其它元件。显示器208、扬声器210、麦克风212、存储器214、相机216、小键盘218和网络接口220可以集成到如图2中所示的用户设备104中。在可替换的用户设备中，显示器208、扬声器210、麦克风212、存储器214、相机216、小键盘218和网络接口220中的一个或多个可以不集成到用户设备104中并且可以经由相应接口连接到CPU 202。这样的接口的一个示例是USB接口。如果用户设备104经由网络接口220到网络106的连接是无线连接，则网络接口220可以包括用于将信号无线地传送到网络106和从网络106无线地接收信号的天线。

图2还图示了在CPU 202上执行的操作系统（“OS”）204。在OS 204的顶部上运行的是通信系统100的客户端实例206的软件。操作系统204管理计算机的硬件资源并且处置经由网络接口220传送到网络106和从网络106传送的数据。客户端206与操作系统204通信并且管理通过通信系统的连接。客户端206具有用于向用户102呈现信息和从用户104接收信息的客户端用户接口。以此方式，客户端206施行允许用户102通过通信系统100通信所要求的处理。

如本领域技术人员将熟悉的，用户设备通过其可以通过诸如因特网之类的网络通信的基本机制可以被视为协议栈（体现在运行于每一个用户设备上的软件中）。取决于通信类型而存在数个不同的协议栈，但是在图3中作为代表示出一个。

在该栈300中，最低层是负责通过RF链路在设备102和110之间运送位的链路层301。链路层301负责以调制到载波频率上的（典型地经编码的）位的形式运送RF业务量。

互联网层303是负责即时分组路由的分组协议。本领域技术人员将理解到，数据分组包括报头部分和有效载荷。报头包括目的地用户设备的互联网络地址（例如IP地址），并且有效载荷包括通信客户端应用期望传送的实际用户数据。当路由节点接收到分组时，其IP层软件检验IP地址并且确定将分组路由到的下一相邻路由节点（或者最终用户终端设备，如果目的地设备相邻的话）。

输运层305添加缠绕在IP报头顶部上的附加报头信息以提供诸如端口编号、拥塞控制和分组接收的确认之类的服务。输运层305可以例如根据传输控制协议（TCP）或用户数据报协议（UDP）处置通信。

TCP服务通过传送器和接收器二者创建被称为套接口（socket）的端点而获得。每一个套接口具有套接口号码（地址），其包括主机的IP地址和在被称为端口的该主机本地的16位数字。对于要获得的TCP服务而言，连接必须建立在传送设备上的套接口与接收设备上的套接口之间。每一个TCP套接口具有在其从操作于上部应用层307上的应用读取之前队列化所接收的数据（通过网络106接收的数据）的TCP接收缓冲器，以及在将其发送到栈300中的较低层以用于通过网络106传送之前队列化数据的TCP发送缓冲器。

最终，应用层307涉及要包括在分组有效载荷中的用户信息，例如语音或视频呼叫的音频或视频内容，或者用于IM消息的用户文本。在应用层307上操作的客户端应用自由地在有效载荷中包括它希望的任何内容，如对于所讨论的应用适当的那样。

在应用层307上操作的应用布置成从TCP接收缓冲器读取所接收的数据，并且将数据发送到TCP发送缓冲器以用于通过网络106传送。

在本发明的实施例中，网络106的条件通过通信客户端206动态地测量并且这些网络条件用于确定和限制TCP交叉业务量（即HTTP/HTTPS交叉业务量）的速率，使得可以避免并发实时通信事件（即语音/视频呼叫）的降级。术语“TCP交叉业务量”在本文中用于指使用TCP作为底层输运协议而传送到接收器的任何数据，而同时通信事件数据传送到接收器。

用于实现本发明的示例架构400的功能图在图4中示出。在该功能图中，在用户设备104上执行的通信客户端206处置与用户设备110（未在图4中示出）的通信事件。应用层过程402布置成在用户设备104与用户设备110之间的通信事件期间经由代理404向用户设备110传送数据和/或从网络节点112（即远程服务器或任何其它类型的数据中心）或用户设备110接收数据。

通信客户端206典型地托管定制浏览器以便支持各种基于HTTP/HTTPS的web服务。应用层过程402可以是由通信客户端206托管的定制浏览器。定制浏览器402是由通信客户端206提供的用户接口并且可以用于向用户102呈现信息和从用户102接收信息。例如，定制浏览器402可以用于在用户设备104与用户设备110之间的通信事件期间显示从网络节点112所接收的内容（即广告）和显示从用户设备110所接收的内容（即照片、屏幕截图和文件）。定制浏览器能够使用由定制浏览器或操作系统（例如Microsoft® Windows®系统中的Wininet API）提供的应用编程接口（API）来使用HTTP/HTTPS协议发送请求。

应用层过程402可以可替换地为运行在用户设备104上的web浏览器（例如Microsoft的Internet Explorer® web浏览器）。web浏览器能够使用由用户设备104的web浏览器或操作系统（例如Wininet API）提供的应用编程接口（API）来使用HTTP/HTTPS协议发送请求。

应用层过程402可以可替换地为在用户设备104上执行的另一应用（除通信客户端206之外）。该另一应用能够使用由用户设备104的操作系统（例如Wininet API）提供的应用编程接口（API）来使用HTTP/HTTPS协议发送请求。

发明人已经认识到，由于实际分组发送和到达信息不可用于应用层（应用过程402在其上操作的层）并且API不向应用过程402提供速率限制选项，所以对于应用过程402而言难以施行带宽估计和将速率限制应用于底层标准TCP连接。

架构400包括代理404，其为在用户设备104的本地处理器上执行的软件程序并且充当代理服务器。如本领域技术人员所公知的，代理服务器使用在客户端/服务器连接之间，并且充当“客户端”与“服务器”之间的中介。代理服务器就像是服务器那样接受来自客户端的请求，然后将它们转发（可能地修改它们）到实际服务器，该服务器将代理看作客户端。服务器响应回代理，其将答复转发回到客户端。代理可以实现为通信客户端软件206的功能性的部分。可替换地，代理可以是布置成与通信客户端软件206通信和交互的分离软件程序。

代理404包括速率控制器模块406。通信客户端206将所监视的网络条件信息动态地供应到速率控制器模块406。速率控制器模块406使用速率控制算法来确定对下行链路（从网络节点112发送到用户设备104的TCP数据或者从用户设备110发送到用户设备104的TCP数据）或上行链路（从用户设备104发送到用户设备110的TCP数据）中的数据流的适当速率限制。

代理404可以是HTTP/HTTPS代理，在该情况下，速率控制器模块406使用速率控制算法来确定对HTTP/HTTPS数据流的适当速率限制。

应用层过程402可以在编程上设定成使用HTTP/HTTPS代理404。如图4中所示，来自应用层过程402的HTTP/HTTPS请求将被转发到代理404。代理404将设立与网络节点112（或用户设备110）的TCP连接，从网络节点112（或用户设备110）下载数据，并且将所下载的TCP数据供应到应用层过程402以用于显示给用户设备104的用户。例如，如果应用层过程402是在用户设备104上运行的web浏览器，如果用户102允许它，则web浏览器可以在编程上设定成使用代理404，因此穿过web浏览器的所有HTTP/HTTPS处于速率控制器模块406的控制之下，速率控制器模块406的操作在下文更详细地描述。

在使用TCP代理的情况下，在TCP级别处而不是HTTP/HTTPS级别处应用该机制。

为了避免音频/视频通信质量中的降级，TCP交叉业务量的速率通过速率控制器模块406使用速率控制算法来控制。速率控制算法被配置成探索和检测可用带宽，并且根据改变的网络条件动态地确定对TCP交叉业务量的适当速率限制阈值。

在应用层过程402从网络节点112或用户设备110下载内容的情况下，对下行链路中的数据流的适当速率限制实现在传送的接收客户端侧处，即在用户设备104处。这是由于网络节点112由第三方（不是提供通信客户端206的服务提供商）操作，并且因此网络节点112不处于用户设备104处的任何功能性的控制之下。由于TCP协议的性质，通过控制输运层305处的TCP接收缓冲器的大小以及在应用层307上操作的应用层过程402以其从TCP接收缓冲器读取数据的速度，控制网络节点112/用户设备110侧处的TCP交叉业务量的发送速率。这是由于TCP协议的操作所致。TCP是滑动窗口协议。滑动窗口协议中的窗口大小指定可以在发送器必须暂停并且等待接收器确认它们之前发送的数据量。

在TCP中，可以在发送器必须暂停并且等待确认之前的任何时间处发送的数据字节数目由两个因素限制：接收器的TCP接收缓冲器的大小，以及发送器的TCP发送缓冲器的大小。接收器的TCP接收缓冲器的大小是重要的，因为发送器不能发送比接收器所具有的缓冲空间更多的字节；否则数据丢失。发送器的TCP发送缓冲器的大小是重要的，因为发送器不能重复利用其自身的缓冲器空间直到接收器已经确认TCP发送缓冲器中的字节，以防网络丢失数据并且字节必须重新发送。发送器知晓接收器的剩余缓冲器大小，因为接收器将该值通告（advertise）为答复给发送器的每一个确认中的TCP窗口大小。发送器总是知晓其自身的TCP发送缓冲器大小。但是基于其TCP接收缓冲器中的未使用空间，以及发送器自身的TCP发送缓冲器大小，由发送器使用的有效窗口大小实际上是由接收器通告的TCP窗口大小的最小值。

因而，用户设备104的接收窗口大小（空闲TCP接收缓冲器大小）被馈送回到发送器（即网络节点112或用户设备110），并且发送器选择所报告的接收窗口大小（从用户设备104馈送回）和发送器自身的TCP发送缓冲器大小中的最小者作为有效窗口大小。

在用户设备104将内容上载到用户设备110的情况下，对上行链路中的数据流的适当速率限制通过直接控制用户设备104的TCP发送缓冲器大小和在应用层307上操作的应用（即应用层过程402）以其向TCP发送缓冲器发送TCP数据的速度来实现。

因而，在上载和下载情况二者中，TCP交叉业务量的速率通过确定适当的套接口接收/发送缓冲器大小和以其从适当的TCP缓冲器读取TCP数据或者以其向适当的TCP缓冲器供应TCP数据的速率来控制。

现在描述由速率控制器模块406执行的速率控制算法。首先参照其中在用户设备104与用户设备110之间的通信事件期间向用户设备104下载内容的场景来描述速率控制算法的描述。内容可以从网络节点112或用户设备110下载。

在该场景中，执行速率控制算法以确定适当的TCP套接口读取速度（tcp_rate_limit）和TCP接收缓冲器大小。

在用户设备104与用户设备110之间的通信事件期间，通信客户端206基于通信事件（即语音/视频呼叫）的测量来动态地监视网络条件。特别地，通信客户端206测量端对端队列延迟（由发送器传送的分组到达接收器所花费的时间）和在网络106之上所经历的分组丢失。用于测量这些网络条件的技术对于本领域技术人员而言是公知的并且因此在本文不做详细讨论。

如图4中所示，将延迟和分组丢失信息供应到执行速率控制算法的速率控制器模块406。速率控制算法还监视在TCP内容的下载期间在用户设备104的TCP接收缓冲器处以其接收TCP内容数据的速率，该所观察到的接收速率（avg_receving_rate）通过TCP内容数据的样本之上的移动平均来计算。要指出的是，所观察到的接收速率（avg_receving_rate）可以低于TCP套接口读取速度（tcp_rate_limit），如果TCP套接口读取速度高于瓶颈中的可用带宽并且实际平均数据到达速率低于TCP套接口读取速度（tcp_rate_limit）的话。然而，所观察到的接收速率（avg_receving_rate）不能高于TCP套接口读取速度（tcp_rate_limit）。如果来自较低层（互联网层303）的实际分组到达速率高于TCP套接口读取速度（tcp_rate_limit），则TCP接收缓冲器将变满，并且接收窗口（空闲TCP接收缓冲器大小）将变得更小。

速率控制算法还通过调节参数max_bandwidth来追踪网络106的最大可行带宽。用于max_bandwidth的值可以被初始化为预确定的值并且然后被相应地调节。用于max_bandwidth的值使用加权平均等式来更新：

max_bandwidth=[权重*avg_receiving_rate]+[(1-权重)*max_bandwidth]

其中权重是0与1之间的数值并且根据诸如端对端队列延迟和分组丢失之类的各种网络条件而自适应。

例如，如果所观察到的接收速率（avg_receving_rate）大于当前的max_bandwidth，则max_bandwidth将使用加权平均等式来更新。

如果所观察到的接收速率（avg_receving_rate）小于当前的max_bandwidth，并且端对端队列延迟小于某个阈值（例如60ms）并且分组丢失也小于某个阈值（即存在可忽略量的分组丢失），则max_bandwidth将不更新。

然而，如果所观察到的接收速率（avg_receving_rate）小于当前的max_bandwidth，并且端对端队列延迟高于某个阈值（例如100ms）和/或分组丢失在指示观察到严重分组丢失的某个阈值（例如多于5-10%）以上，则max_bandwidth将根据加权平均等式来更新，即使是所观察到的接收速率（avg_receving_rate）小于当前的max_bandwidth。

如上文指示的，在加权平均等式中使用的权重可以是端对端队列延迟的函数，例如当所观察到的接收速率（avg_receving_rate）小于当前的max_bandwidth，并且端对端队列延迟高于某个阈值时，置于当前的avg_receiving_rate上的权重将对应于增加某个阈值以上的端对端队列延迟而增加。类似地，在加权平均等式中使用的权重可以是所观察到的分组丢失的函数，例如当所观察到的接收速率（avg_receving_rate）小于当前的max_bandwidth，并且所观察到的分组丢失高于某个阈值时，置于当前的avg_receiving_rate上的权重将对应于增加某个阈值以上的分组丢失而增加。

如果所观察到的接收速率（avg_receving_rate）小于TCP套接口读取速度（tcp_rate_limit）并且队列延迟和丢失速率二者在相应的阈值以上，则max_bandwidth也将使用以上的加权平均等式来更新。

而且，如果网络106的带宽明显利用不足，例如网络106可能处于闲置状态或者发送器可能不具有足够的数据来发送，则在更新max_bandwidth时需要谨慎注意。所观察到的接收速率（avg_receving_rate）与max_bandwidth相比的比率在检测这样的情况中发挥作用。如果该比率在某个阈值以下，则网络106的带宽明显利用不足的几率将更高。在这样的场景中，防止max_bandwidth的更新或者使avg_receiving_rate上的权重为非常低的预确定值。

根据不同的队列延迟、丢失速率条件，基于所观察到的接收速率（avg_receiving_rate）的加权平均、max_bandwidth的某个百分比（例如大约80%）和当前的tcp_rate_limit来计算TCP套接口读取速度（tcp_rate_limit）。TCP套接口读取速度（tcp_rate_limit）可以基于以下等式计算：

tcp_rate_limit = [weight_l * { weight_2 * 百分比 * max_bandwidth + (1 -weight_2 ) * avg_receiving_rate)}] + [(1 - weight_l ) * tcp_rate_limit]

通过设定max_bandwidth的该百分比，用于TCP交叉业务量的网络106的可用带宽的利用不足的量得以控制。该百分比可以是队列延迟的函数。例如，当所测量的队列延迟减小时，百分比可以增加以使得能够更为充分地利用带宽。

如果队列延迟相当低，具有零或可忽略的丢失速率，这意味着网络106的带宽非常利用不足，则速率控制算法将还尝试有意地使所计算的tcp_rate_limit增加某个百分比。百分比可以在开始阶段处较高以允许较快的速率适配速度。增加的百分比还可以根据队列延迟和丢失水平而自适应。

TCP套接口读取速度（tcp_rate_limit）通过在每一次应用层过程402尝试从TCP接收套接口读取以从TCP接收缓冲器检索TCP内容数据时控制参数read_interval_limit和read_block_limit来控制。

参数read_interval_limit是从TCP接收套接口读取（即从TCP接收套接口的TCP接收缓冲器读取）的应用层过程402的分离实例之间所准许的最大时间间隔。参数read_block_limit是响应于读取TCP接收套接口的呼叫而准许应用层过程402从TCP接收套接口（即TCP接收套接口的TCP接收缓冲器）读取的最大数据量（以字节计）。这些参数之间的关系如下：

TCP套接口读取速度，

TCP套接口读取间隔read_interval_limit是读取粒度和代码执行频率之间的权衡。如果read_interval_limit低于20ms，则read_block_limit将增加某些字节。如果read_interval_limit大于100ms，则read_block_limit将相应地减小。

如上文描述的，除确定适当的TCP套接口读取速度（tcp_rate_limit）之外，还执行速率控制算法以确定适当的TCP接收缓冲器大小（TCPRCVBUFSIZE）。TCP接收缓冲器的大小可以使用TCP设定函数“setsockopt”来控制。

TCP接收缓冲器大小确定最大可能的TCP窗口大小。TCP窗口大小将影响数据发送突发性，因为其是发送器可以发送出而没有从接收器接收到确认的数据量。高TCP接收缓冲器大小将创建高延迟尖峰，其对于实时呼叫质量是有害的。另一方面，过低的缓冲器大小设定可能使可能的TCP发送速率受限，因为TCP发送速率大致等于TCP窗口大小除以平均往返时间（RTT）。因而，本领域技术人员将清楚的是，要求TCP接收缓冲器大小的适当选择。速率控制算法通过最初将TCP接收缓冲器大小设定为相对低（例如4096字节）并且然后基于所确定的TCP套接口读取速度tcp_rate_limit而逐步增加TCP接收缓冲器大小来实现这一点。TCP接收缓冲器大小随tcp_rate_limit线性地缩放。也就是说，当tcp_rate_limit增加时，TCP接收缓冲器大小将相应地增加，并且当tcp_rate_limit减小时，TCP接收缓冲器大小将相应地减小。缓冲器大小的改变的粒度可以设定成例如1024字节。

如果所观察到的接收速率（avg_receiving_rate）持续低于tcp_rate_limit而同时队列延迟保持相当低，则速率控制算法确定TCP接收缓冲器大小可能设定不足（under-set）并且在该情况下以预确定的量逐步增加TCP接收缓冲器大小。

尽管已经在上文参照其中在用户设备104与用户设备110之间的通信事件期间向用户设备104下载内容的场景而描述了速率控制算法，但是将领会到，速率控制算法还能够控制在用户设备104与用户设备110之间的通信事件期间从用户设备104向用户设备110上载TCP交叉业务量的速率。针对上行链路方向而不是下行链路方向动态地测量网络条件（端对端队列延迟和分组丢失）。速率控制算法基于通信事件（即语音/视频呼叫）的测量而接收动态监视的网络条件以便确定适当的TCP套接口发送缓冲器大小以及内容数据以其（从操作于上部应用层307上的应用过程402）供应到TCP发送缓冲器的速率。

如果用户设备104侧处的通信客户端206将这些测量反馈到如图4中所示的代理404，则将提供端对端队列延迟和分组丢失的更精确的估计。在端对端队列延迟和分组丢失向代理404的这种反馈不可用的情况下，上行链路方向上的队列延迟可以通过代理404近似地估计。代理404打开TCP套接口并且将从应用层过程402所接收的数据写入到TCP发送缓冲器。由于上行链路通常是瓶颈，所以如果上行链路拥塞，则数据队列将在TCP接收缓冲器处累积。代理404然后可以基于队列化在TCP发送缓冲器中的数据的观察来估计端对端队列延迟。分组丢失速率可以不在发送缓冲器处估计。上行链路速率控制的可接受性能可能通过使用这种方法实现，甚至是在没有分组丢失速率信息可用于代理404的情况下，然而相比于通信客户端206测量并且向代理404报告端对端队列延迟和分组丢失时的场景而言，上行链路速率控制的性能可能稍微受损。

在以上描述的示例中，更为方便的是在接收客户端侧处（即在用户设备104处）施行速率控制，因为网络节点112属于第三方提供商并且在射程外。然而，本发明的实施例不限于仅在接收侧处的实现并且也可以应用于网络节点处（如果网络节点由提供通信客户端206的相同软件提供商控制的话）。也就是说，网络节点112可以通过确定适当的TCP套接口发送缓冲器大小（在网络节点112处）和以其向TCP发送缓冲器供应内容数据的速率（在网络节点112处）来施行速率控制以限制到用户设备104的TCP数据的上载速率。在该实现中，通信客户端可以通过网络106向网络节点112提供动态测量的网络条件（端对端队列延迟和分组丢失）。

在端对端队列延迟和分组丢失向网络节点112的这种反馈不可用的情况下，端对端队列延迟可以在网络节点112处的TCP发送缓冲器处近似地估计，然而分组丢失速率不能在网络节点112处估计。通过确定适当的TCP套接口发送缓冲器大小和以其向TCP发送缓冲器供应内容数据的速率来限制向用户设备104的TCP数据的上载速率的速率控制可能仍在该情况中使用仅估计的端对端队列延迟来施行。可能实现速率控制的可接受性能，甚至是在没有分组丢失速率信息可用于网络节点的情况下（即使用仅估计的端对端队列延迟），然而速率控制的性能可能稍微受损。

虽然图4示出代理404中的速率控制器模块406的实现，但是速率控制器模块406可以实现为通信客户端206的功能性的部分。在这些实施例中，通过速率控制算法的执行所确定的缓冲器大小和速率限制信息可以从通信客户端206供应到代理，其具有使得代理能够接收适当的缓冲器大小和速率限制信息并且相应地设定适当的缓冲器大小和速率限制的速率限制能力。

对于在不具有对TCP套接口的访问的应用层307上操作的应用过程402而言，要求HTTP/HTTPS代理或TCP代理的使用。例如，如上文所述，应用层过程402可以是由通信客户端206托管的嵌入式浏览器，嵌入式浏览器不具有对TCP套接口的访问，因此要求代理以使得能够访问较低协议层。

图4示出代理404的使用，然而本文公开的实施例不限于这样的代理的使用。例如，应用层过程402可以具有直接打开TCP套接口以便下载或上载TCP内容的能力。在这样的实施例中，不使用代理并且将速率控制器模块406实现为通信客户端206的功能性的部分。将领会到，具有访问TCP套接口的能力的应用层过程402可以仍使用代理404以便下载或上载TCP内容（尽管不要求使用代理）。

现有商用web浏览器产品（例如Google Chrome^TM和Mozilla Firefox®）可以支持通过Google所提供的WebRTC标准的web呼叫服务。也就是说，可以在两个端点之间实现实时通信，其中实时通信穿过相应的WebRTC兼容浏览器。然而，web呼叫质量可能由于其它并发web浏览交叉业务量而严重降级。速率控制机制可以构建到兼容WebRTC浏览器中以使浏览器web呼叫是友好的。要求将实时输运协议（RTP）实现为用于WebRTC的媒体输运协议。RTP本身包括两个部分：RTP数据传输协议和RTP控制协议（RTCP）。端对端队列延迟和分组丢失可以由通过其进行实时通信的WebRTC浏览器来测量，并且被反馈到具有构建到其中的速率控制机制的另一WebRTC浏览器（通过其进行实时通信）。使用RTCP协议反馈端对端队列延迟和分组丢失。具有内置的速率控制机制的WebRTC浏览器然后可以依照以上描述的实施例施行速率控制。在该情况下，不要求代理，因为web浏览器本身处置HTTP/HTTPS过程。如将清楚的，在该实现中，通信客户端206不处置实时通信。

以上描述的速率控制算法被配置成在第一和第二模式中操作。速率控制算法如上文描述的那样在第一模式中操作以便通过有意地对可用带宽利用不足来降低端对端队列延迟和分组丢失。在第二模式中，将套接口读取速度tcp_rate_limit设定成预确定的值，其足够高以便让底层TCP协议确定实际发送速率，其被确保是TCP友好的。因而在第二模式中，速率控制算法没有控制网络106中的路由器溢出。因此可以看到，当在第一模式中时，算法具有处置TCP交叉业务量的保守方案，并且当在第二模式中时，算法具有处置TCP交叉业务量的更加进取的方案。

速率控制算法被配置成在操作在第一和第二模式中之间切换，现在参照图5中所示的切换过程500描述这一点。

在步骤S502处，速率控制算法开始操作在第一模式中并且启动计时器，自启动计时器开始逝去的时间通过t_timer表示（这在下文更详细地描述）。在步骤S504处，针对预确定的时间段的预确定的比例确定所测量的端对端队列延迟和/或分组丢失是否超出相应阈值（步骤S504处的确定不基于端对端队列延迟和/或分组丢失的单个观察）。如果在步骤S504处确定针对预确定的时间段的预确定的比例所测量的端对端队列延迟和/或分组丢失没有超出相应阈值（即测量没有持续高于相应阈值），则过程500行进回到步骤S502，其中速率控制算法继续在第一模式中操作。步骤S504处的端对端队列延迟阈值可以设定为例如100ms并且步骤S504处的分组丢失阈值可以例如在3-5%的区中。将领会到，这些值仅仅是示例并且可以根据网络类型和观察而改变。

如果在步骤S504处确定针对预确定的时间段的预确定的比例所测量的端对端队列延迟和/或分组丢失超出相应阈值（即测量持续高于相应阈值），则这指示存在由于运行于用户设备104上的其它应用所致的另外TCP交叉业务量（例如视频可能由用户经由web浏览器观看）并且过程500行进到步骤S505，其中将t_timer的值与t_{switch_interval}比较，t_{switch_interval}表示在准许速率控制算法的操作模式中的改变之前必须逝去的时间以防止第一和第二操作模式之间的振荡。t_{switch_interval}的值可以例如设定为至少10-15秒。如果时间段t_{switch_interval}在步骤S505处尚未逝去，则过程500行进回到S504，其中速率控制算法再次检查条件仍成立，以避免对短期丢失/延迟尖峰做出反应。当时间段t_{switch_interval}已经逝去时，过程500行进到步骤S506，其中速率控制算法切换成在第二模式中操作。

当速率控制算法切换成在第二模式中操作时，重置t_timer的值并且重启计时器。

当速率控制算法在第二模式中操作时，针对预确定的时间段的预确定的比例确定（在步骤S508处）所测量的端对端队列延迟是否降至阈值（例如60ms）以下（即端对端队列延迟持续低于延迟阈值）和/或分组丢失是否在预确定的时间段届满之后降至零（步骤S508处的确定不基于端对端队列延迟和/或分组丢失的单个观察）。如果在步骤S508处确定针对预确定的时间段的预确定的比例所测量的端对端队列延迟没有降至相应阈值以下和/或分组丢失在预确定的时间段届满之后没有降至零，则速率控制算法继续在第二模式中操作并且过程500行进到步骤S509。

在步骤S509处，速率控制算法等待直到自进入第二模式起的时间段（t_{temp_switch}）已经在行进到步骤S510之前逝去，其中速率控制算法临时地切换回成在第一模式中操作。由t_{temp_switch}表示的时间段可以例如为20秒。如果时间段t_{temp_switch}在S509处尚未逝去，则过程500行进回到S508，其中速率控制算法检查网络条件是否改变。

在临时切换回到在第一模式中操作之后，速率控制算法然后在步骤S512处确定端对端队列延迟和/或分组丢失是否降至步骤S504处所使用的相应阈值以下。实现回到在第一模式中操作的临时切换，因为当速率控制算法在第二模式中操作时，丢失/延迟中的下降可能不必然被观察到，即使交叉业务量消失，因为速率控制算法将在操作在第二模式中时像TCP那样工作并且因此引入丢失和延迟。

如果端对端队列延迟和/或分组丢失尚未降至用于在步骤S504处所使用的端对端队列延迟和/或分组丢失的相应阈值以下，则过程行进到步骤S514，其中速率控制算法返回至在第二模式中操作。

如果端对端队列延迟和/或分组丢失降至用于在步骤S504处所使用的端对端队列延迟和/或分组丢失的相应阈值以下，则速率控制算法保持在第一操作模式中操作。这通过过程500行进回到步骤S512来表示。

将清楚的是，该另外的TCP交叉业务量可能在某个点处消失（即用户停止经由web浏览器观看视频）并且因此存在对于使速率控制算法具有切换回到在第一模式中操作的能力的需要。否则，如果算法保持在第二模式中，即使另外的TCP交叉业务量消失，底层TCP协议也将保持引入延迟和丢失，其将比如果切换回到第一模式的情况更高。

参照回步骤S508，如果在步骤S508处确定针对预确定的时间段的预确定的比例所测量的端对端队列延迟降至相应阈值以下和/或然后分组丢失在预确定的时间段届满之后降至零，则然后这指示网络106的带宽利用不足（即用户停止经由web浏览器观看视频），然后过程500行进到步骤S515，其中将t_timer的值与t_{switch_interval}比较。当自进入第二模式起已经逝去时间段t_{switch_interval}时，过程500行进到步骤S516，其中速率控制算法切换回到在第一模式中操作。

当速率控制算法切换到在第一模式中操作时，重置t_timer的值并且重启计时器。

一旦速率控制算法在步骤S516处切换回到在第一模式中操作，将参数max_bandwidth设定成用于第一模式和之前的第二模式中的max_bandwidth的值的平均。

在步骤S518处，将在速率控制算法操作于第二模式中时所测量的延迟和/或丢失与在速率控制算法操作于第一模式中时所测量的延迟和/或丢失相比较。如果第二和第一模式之间的延迟和/或丢失中的差异超出预确定的延迟和/或丢失量，则过程500行进到步骤S502，其中速率控制算法继续在第一模式中操作。

如果延迟和/或丢失通过切换回到第一模式而变得明显更低，则速率控制算法应当停留在第一模式中。这通过过程500行进回到步骤S502来表示（不重置t_timer的值并且不再次重启计时器，因为这在步骤S516处完成）。

如果延迟和丢失保持类似，即在步骤S518处确定第二和第一模式之间的延迟和/或丢失中的差异没有超出预确定的延迟和/或丢失量，则过程500行进到步骤S519，其中将t_timer的值与t_{switch_interval}比较。如果在步骤S519处时间段t_{switch_interval}尚未逝去，则过程500行进回到S518，其中速率控制算法检查网络条件是否改变。一旦自进入第一模式起已经逝去时间段t_{switch_interval}，过程500行进到步骤S506，其中速率控制算法切换回到在第二模式中操作，其中参数max_bandwidth被设定为用于第一模式中的max_bandwidth的值和之前的第二模式中的所记录值的平均。

如果丢失和延迟中的差异是小的但是所观察到的接收速率（avg_receiving_rate）在第二模式中明显更高，则存在另外的TCP业务量（即由于运行在用户设备104上的其它应用所致）或者网络106具有低质量。

甚至对于低质量网络，该切换机制是有益的，因为max_bandwidth值在每一次切换中重置并且这帮助确定适当的可用带宽。参数max_bandwidth将收敛至正确操作点。在没有图5中所示的状态切换机制500的情况下，速率控制算法可能没有充分地利用低质量网络场景和现有TCP交叉业务量的情况二者中的可用带宽。

现在参照图6描述用于实现本发明的另一示例架构600的功能图。在该功能图中，应用层过程602布置成在用户设备104与用户设备110之间的通信事件期间经由代理604向用户设备110传送数据和/或从网络节点或用户设备110接收数据。

代理604（其可以是HTTP/HTTPS代理或TCP代理）以与上文参照代理404所描述的相同方式起作用。代理604不包括速率控制器模块406，然而的确具有速率限制能力，这将在下文更详细地描述。代理604可以可选地将套接口数据读取/发送信息报告回到通信客户端206。可替换地，代理604可以向通信客户端206报告何时从TCP套接口读取数据和向TCP套接口发送数据。

在图6中示出的通信客户端206包括带宽估计模块606。带宽估计模块606用于动态地测量网络106的网络条件。特别地，带宽估计模块606被配置成估计网络106的总体上行链路/下行链路带宽，并且然后基于所估计的带宽计算用于TCP交叉业务量的带宽上限。该带宽上限是可以用于TCP交叉业务量的总体上行链路/下行链路带宽的分配。例如，如果总体检测到的带宽是1Mbps，客户端可以分配用于通信业务量的400kbps，用于TCP交叉业务量的400kbps的上限，以及作为裕度的200kbps，使得延迟和丢失将最小化。

带宽估计模块606可以被配置成以数个不同的方式估计网络106的带宽。例如，带宽估计模块606可以被配置成通过使用分组对/训练探查或其它现有方案来估计总体上行链路/下行链路带宽。

可替换地，带宽估计模块606可以被配置成通过使用如例如在美国专利号US8,259,570中所描述的技术来估计总体上行链路/下行链路带宽。如果代理604被配置成将套接口数据读取/发送信息报告回到通信客户端206，代理604向带宽估计模块606报告何时从TCP套接口读取字节（下行链路）或向TCP套接口发送字节（上行链路），并且将这些字节作为“侧业务量”并入到带宽估计中。

可替换地，带宽估计模块606可以被配置成通过使用任何已知方法来估计总体上行链路/下行链路带宽并且然后将发送/接收TCP速率添加到它。发送/接收TCP速率可以通过代理404报告给带宽估计模块606。可替换地，发送/接收TCP速率由带宽估计模块606基于代理604报告何时从TCP套接口读取数据和向TCP套接口发送数据来计算。

可替换地，带宽估计模块606可以被配置成通过使用任何已知方法估计总体上行链路/下行链路带宽。我们假定所观察到的接收速率（avg_receving_rate）等于TCP速率限制tcp_rate_limit并且将此添加到估计。该方法具有以下优点：代理604不必报告关于何时从TCP套接口读取数据和向TCP套接口发送数据的任何事情。

然后将用于TCP交叉业务量的所计算的带宽上限供应到代理604。代理604然后通过依照从通信客户端206所接收的带宽上限确定适当的套接口接收/发送缓冲器大小和以其从适当的TCP缓冲器读取TCP数据或向适当的TCP缓冲器供应TCP数据的速率来控制TCP交叉业务量的上行链路/下行链路速率。

图6示出代理604的使用，然而本文公开的实施例不限于这样的代理的使用。例如，如果应用层过程602具有对TCP套接口的直接控制，则不要求代理604。

一般地，本文描述的任何功能（例如图4和6中所示的功能模块）可以使用软件、固件、硬件（例如固定逻辑电路）或这些实现的组合来实现。在图4-6中分离地示出的模块和步骤可以或者可以不实现为分离的模块或步骤。如本文所使用的术语“模块”、“功能性”、“组件”和“逻辑”一般表示软件、固件、硬件或其组合。在软件实现的情况下，模块、功能性或逻辑表示当在处理器（例如一个或多个CPU）上执行时施行指定任务的程序代码。程序代码可以存储在一个或多个计算机可读存储器设备中。本文描述的技术的特征是独立于平台的，这意味着技术可以实现在具有各种处理器的各种商用计算平台上。例如，用户设备还可以包括使得用户设备的硬件施行操作（例如处理器功能块等）的实体（例如软件）。例如，用户设备可以包括可以被配置成维护指令的计算机可读介质，该指令使得用户设备并且更具体地用户设备的操作系统和相关联的硬件施行操作。因而，指令的作用是配置操作系统和相关联的硬件以施行操作并且以此方式导致操作系统和相关联的硬件的变换以施行功能。指令可以由计算机可读介质通过各种不同配置而提供给用户设备。

计算机可读介质的一个这样的配置是信号承载介质并且因而被配置成诸如经由网络向计算设备传送指令（例如作为载波）。计算机可读介质还可以被配置为计算机可读存储介质并且因而不是信号承载介质。计算机可读存储介质的示例包括随机存取存储器（RAM）、只读存储器（ROM）、光盘、闪速存储器、硬盘存储器、以及可以使用磁性、光学和其它技术来存储指令和其它数据的其它存储器设备。

尽管已经以具体到结构特征和/或方法动作的语言描述了主题，但是要理解到，在随附权利要求中限定的主题不必限于上文描述的具体特征或动作。而是，上文描述的具体特征和动作是作为实现权利要求的示例形式而公开的。

已经在上文描述了其中通过确定适当的套接口接收/发送缓冲器大小和以其从适当的TCP缓冲器读取TCP数据或向适当的TCP缓冲器供应TCP数据的速率来控制TCP交叉业务量的速率的实施例。TCP交叉业务量的速率可以通过仅限制以其从适当的TCP缓冲器读取TCP数据或向适当的TCP缓冲器供应TCP数据的速率来控制。然而，通过附加地控制接收/发送缓冲器大小，业务量速率将更平滑得多，具有较少突发速率和队列延迟尖峰，从而提供并发音频/视频呼叫中的改进的质量。

Claims (10)

1.一种控制通过网络以其在接收器处接收内容数据的速率的方法，其中接收器引起要在接收器处接收的实时通信事件数据的第一串流，以及要在接收器处接收的内容数据的第二串流，方法包括以下步骤：

基于实时通信事件数据动态地测量网络的网络条件；以及

基于动态测量的网络条件限制以其在接收器处接收内容数据的速率。

2.权利要求1的方法，其中所述步骤在接收器处执行并且所述速率是下载速率，其中所接收的内容数据在接收器处的缓冲器中队列化，并且下载速率通过接收器限制可以以其从缓冲器读取内容数据的速率来限制。

3.权利要求2的方法，其中下载速率通过接收器控制被配置成队列化所述内容数据分组的缓冲器的大小来限制。

4.权利要求1的方法，其中基于实时通信事件数据动态地测量网络的网络条件的步骤在所述接收器处执行，并且基于动态测量的网络条件限制以其在接收器处接收内容数据的速率的步骤在网络节点处执行，其中网络的动态测量的网络条件由接收器报告给网络节点。

5.权利要求1的方法，其中所述步骤在网络节点处执行。

6.权利要求1的方法，其中所述步骤在传送器处执行，并且所述速率是上载速率，其中内容数据在传送到所述接收器之前在传送器处的缓冲器中队列化，并且上载速率通过传送器限制可以以其向缓冲器发送内容数据的速率来限制。

7.权利要求6的方法，其中上载速率通过传送器控制被配置成队列化所述内容数据分组的缓冲器的大小来限制。

8.任何前述权利要求的方法，其中依照输运控制协议通过网络输运内容数据，并且所述基于动态测量的网络条件限制以其在接收器处接收内容数据的速率通过在第一操作模式中操作的速率控制算法的执行而施行，所述速率控制算法被配置成取决于动态测量的网络条件而在所述第一操作模式与第二操作模式之间切换，其中速率控制算法使得输运控制协议能够确定以其在接收器处接收内容数据的速率而同时在第二操作模式中操作。

9.权利要求1的方法，其中方法包括：

通过估计网络的带宽来动态地测量网络的网络条件；以及

基于所估计的带宽限制以其在接收器处接收内容数据的速率。

10.一种被配置成控制通过网络以其在接收器处接收内容数据的速率的计算机程序产品，其中接收器引起要在接收器处接收的实时通信事件数据的第一串流以及要在接收器处接收的内容数据的第二串流，计算机程序产品体现在计算机可读存储介质上并且被配置成以便当在接收器的处理器上执行时：

基于实时通信事件数据动态地测量网络的网络条件；以及

基于动态测量的网络条件而使得以其在接收器处接收内容数据的速率被限制。