管理经过分类的网络流

摘要

本发明的一些实施例涉及对网络流进行分类并且基于其对应的类别来调节流的行为。用于管理流的一种技术涉及对应用进行分析，获得关于应用的特征的指示，以及使用这些特征来推断出应用的流可以被指派到的类别。另一种技术涉及在网络的边缘处部署信标节点。信标节点向流管理器通知网络条件，比如关于网络边界或区段的等待时间。用于促进流的管理的另一个实施例涉及用于UDP应用的预订服务。UDP应用可以预订服务，所述服务可以由寄放应用的操作系统提供。事件被公布到任何预订所述服务的UDP应用，以便向UDP应用通知联网条件中的改变。UDP应用又可以对其内部传送控制逻辑进行适配。

权利要求

1.一种由包括存储装置、处理硬件和网络接口的单个计算机执行的方法，所述方法包括：

执行安装在所述计算机上的应用，所述应用包括安装在所述计算机上的可执行文件和存储在所述计算机上的配置设定，所述应用具有由所述计算机的操作系统管理的相应网络流；

分别自动地确定所述应用的第一特征，以及/或者分别自动地确定所述应用的第二特征，其中所述确定由在所述计算机上执行的应用建档器来执行，其中自动地确定所述第一特征包括所述应用建档器解析所述可执行文件和/或所述配置设定，其中自动地确定所述第二特征包括所述应用建档器监测所述应用的执行，并且其中第一特征和/或第二特征针对相应的所述应用中的每个应用被确定；

访问所述存储装置中的映射，所述映射包括预定义的应用特征和网络流类别的指示，所述网络流类别是由所述计算机的所述操作系统实施的，所述映射指示所述预定义的应用特征中的哪些预定义的应用特征与所述网络流类别中的哪些网络流类别相关联，其中所述映射在确定所述第一特征和/或所述第二特征之前被存储，并且其中所述预定义的应用特征包括所述第一特征和/或所述第二特征中的至少一些特征；

针对所述应用中的每个应用，确定由所述应用建档器确定的相应的所述第一特征和/或所述第二特征中的哪些特征与所述映射中的所述预定义的应用特征中的哪些预定义的应用特征匹配，以及针对所述应用中的每个应用，基于所述映射指示哪个网络流类别与相应地匹配的所述预定义的应用特征相关联来选择网络流类别；

存储指示针对相应的所述应用选择了所述网络流类别中的哪些网络流类别的应用分类信息；以及由所述计算机的所述操作系统调节通过所述网络接口对所述流的分组的传输，其中根据所述应用分类信息指示针对对应的所述应用选择了哪个网络流类别来执行每个流的所述调节。

2.根据权利要求1的方法，其中，通过以下来执行所述调节：针对与给定网络流类别相关联的给定网络流，比较所述给定网络流的带宽和/或等待时间性能的测量与所述给定网络流类别的对应的带宽和/或延迟等待时间规范。

3.根据权利要求1的方法，其中，所述第一特征包括由所述应用建档器确定为由所述应用参考的所述操作系统的组件。

4.根据权利要求1的方法，其中，所述第二特征包括在所述应用的执行期间或者作为所述应用的执行的结果而出现的所述应用的特征。

5.根据权利要求1的方法，其中，所述映射的所述预定义的应用特征具有相应的权重，所述权重被用于确定所述网络流类别中的哪个网络流类别与应用的所识别的特征最佳匹配。

6.根据权利要求1的方法，其中，自动地确定所述第一特征和/或所述第二特征是响应于根据所述分类信息确定应用尚未与所述映射中包括的任何网络流类别相关联而针对所述应用被执行的。

7.根据权利要求6的方法，还包括使用由所述应用建档器确定的所述应用的特征来自动地为所述应用选择网络流类别，以及将所述分类信息更新为指示所述应用与为其选择的所述网络流类别之间的关联。

8.根据权利要求7的方法，还包括存储所述应用的流基于所述应用与所选择的所述网络流类别之间的所指示的关联而具有所述网络流类别的指示。

9.一种计算设备，包括：

存储信息的存储硬件，以便当所述计算设备正在操作时允许处理器执行操作系统；

网络接口；

所述处理器，所述处理器当所述计算设备正在操作时与存储器耦合以便执行所述操作系统；以及所述操作系统，所述操作系统在执行时包括流管理器，所述流管理器管理在网络与安装在所述计算设备上并且由所述操作系统执行的应用之间提供传输控制协议(TCP)分组的网络流，所述流管理器实施预定义的流类别集合，其中基于所述流类别与所述流之间的关联，每个网络流与所述流类别中的一个流类别相关联；

所述存储硬件存储被配置为通过以下来形成流类别与应用的网络流之间的关联的指令：

执行应用建档代码，所述应用建档代码(i)通过解析所述应用的配置设定和/或可执行文件来确定所述应用的第一应用特征，以及/或者(ii)通过监测所述应用的执行来确定所述应用的第二应用特征；

访问包括预定义的应用特征和所述流类别之间的关联的映射，所述映射表明哪些预定义的应用特征与哪些流类别相关联，其中所述映射存在于形成所述流类别与所述网络流之间的所述关联之前；

通过将所述映射中的预定义的应用特征与所述应用的所述第一应用特征和/或所述第二应用特征匹配来形成所述流类别与所述应用的所述网络流之间的所述关联，以及基于所述映射具有相匹配的所述预定义的应用特征和所述流类别之间的关联来选择所述流类别；

存储所述流类别与所述网络流之间的所述关联；以及

由所述操作系统调节通过所述网络接口对所述网络流的传输，其中基于所述流类别与所述网络流之间的所存储的关联来执行所述调节。

10.根据权利要求9的计算设备，其中，所述流管理器提供事件公布服务，所述事件公布服务响应于确定所述计算设备的网络条件已发生改变而提供对向其预订的应用的更新，其中所述网络条件的指示被所述流管理器用于调节所述网络流的行为。

11.根据权利要求9的计算设备，还包括所述操作系统的功率管理模块，其根据与所述网络流相关联的所述流类别来控制无线电装置的供电。

12.根据权利要求9的计算设备，其中，所述操作系统根据分别与所述网络流相关联的所述流类别而在所述网络流中引发延迟，所述引发包括人为地延迟传输控制协议(TCP)确认以及/或者延长接收确认阈值以避免TCP重传，所述接收确认阈值包括重传请求被发出之前的时间段。

13.根据权利要求9的计算设备，其中，所述网络流与所述流类别之间的所述关联基于指示哪些应用与所述流类别中的哪些流类别相关联的应用类别关联信息。

14.一种存储信息的计算机可读存储设备，所述信息被配置为允许计算设备执行过程，所述过程包括：存储安装在计算设备上的应用，所述应用包括由存储硬件存储的可执行文件和配置设定；

针对每个应用，通过执行应用建档器来自动地确定相应的第一应用特征和/或第二应用特征，所述应用建档器(i)通过解析相应地对应的所述应用的所述可执行文件和/或对应的所述配置设定来确定所述第一应用特征，以及/或者(ii)通过监测相应地对应的所述应用的执行来确定所述第二应用特征，其中第一应用特征和/或第二应用特征针对相应的所述应用中的每个应用被确定；

访问特征类别映射，所述特征类别映射由所述存储硬件在自动地针对每个相应的应用确定所述第一应用特征和/或所述第二应用特征之前存储，所述特征类别映射包括预定义的应用特征的第一指示以及网络应用类别的第二指示，其中所述特征类别映射指示所述应用特征中的哪些应用特征与所述网络应用类别中的哪些网络应用类别相关联，并且其中所述预定义的应用特征包括所述第一应用特征和/或所述第二应用特征中的至少一些应用特征；

针对所述应用中的每个应用，确定相应地对应的所述第一应用特征和/或所述第二应用特征中的哪些应用特征对应于所述特征类别映射的所述预定义的应用特征中的哪些预定义的应用特征；

针对所述应用中的每个应用，选择所述特征类别映射指示与被确定对应于相应地对应的所述应用的所述第一应用特征和/或所述第二应用特征的所述预定义的应用特征相关联的网络应用类别；

存储分别指示针对所述应用选择了所述网络应用类别中的哪些网络应用类别的应用分类信息；以及由所述计算设备的操作系统调节通过所述网络接口对所述应用的流的分组的传输，其中根据所述应用分类信息指示针对相应地对应的所述应用选择了哪个网络应用类别来执行每个流的所述调节。

15.根据权利要求14的计算机可读存储设备，其中，所述第一应用特征和/或所述应用第二特征包括与所述应用相关联的过程名称、链接到所述应用的库、所述应用的后台执行状态、与所述应用相关联的端口号、由所述应用使用的协议和/或所述应用的应用编程接口(API)调用。

16.根据权利要求14的计算机可读存储设备，所述过程还包括分别根据所述预定义的应用特征的权重来针对应用计算得分。

17.根据权利要求14的计算机可读存储设备，其中，所述调节在所述计算设备不对所述流执行服务质量标记的情况下被执行。

18.根据权利要求14的计算机可读存储设备，所述过程还包括分别存储所述网络应用类别的网络性能参数，以及根据所述应用分类信息指示与应用相关联的所述网络应用类别的所述性能参数来针对所述应用的流执行所述调节。

说明书

管理经过分类的网络流

背景技术

[0001] 当计算设备上的多个应用共享该计算设备上或外部的相同的有限网络资源时，多种技术已被用来尝试平衡这些应用的联网需求。计算机用户和应用通常优选的是消费网络资源的各个应用当中的特定折中和优先级排序。但是在实践中，用于共享网络访问的现有技术常常并没有最优地实现这些优选项和优先级。举例来说，设备的用户可能优选的是所述用户的设备上的IP语音（VoIP）具有低网络等待时间，并且所述设备上的web浏览迅速且响应灵敏。用户还可能优选的是，例如云端同步和操作系统更新之类的后台大批量网络传输对于设备网络资源的消费允许令人满意的前台性能并且保持合理的进展。

[0002] 除了常常无法令人满意地共享网络访问之外，现有的访问共享技术常常不便于软件开发者访问或实施。举例来说，虽然服务质量（QoS）设施可能是有帮助的，但是所述设施常常是不可用的或者不是以均匀的方式实施的。大多数QoS技术在应用层以下发生，因此可能无法由应用可靠地操纵。大多数QoS方法（例如差分服务）取决于两个端点之间的网络的行为和支持。这样的支持可能不是在所有网络路径上都存在。在便利性方面，网络共享行为也是在应用内实施的，但是这通常需要复杂的网络编程，并且在应用之间没有或者只有很少的直接协调。不同的应用实施其自身的网络共享逻辑的做法不仅是重复性的，而且各个应用的不同资源共享行为还可能发生冲突。

[0003] 虽然存在由操作系统实施来允许应用实施特定类型的网络消费行为的例如LEDBAT（低额外延迟后台传输）之类的协议，但是用以利用此类协议的编码可能会增加开发应用的成本和开销，并且可能使得开发者较不可能使用此类协议。此外，例如LEDBAT之类的广泛部署的低优先级TCP（传输控制协议）机制存在缺点，并且常常无法提供理想的用户体验（对于其他实例参见互联网工程任务组意见请求6297）。LEDBAT协议例如仅限制TCP发送窗口并且对接收流没有影响，然而大多数客户端侧因特网通信量是流入的。即使当例如LEDBAT之类的机制可用并且不需要复杂的开发者编码时，操作系统或网络堆栈仍然可能无法确定某一应用应当使用此类机制。换句话说，关于网络资源冲突的用户和应用意图难以被推断出来，并且应用很少规定其网络优先级。设备的网络资源共享也不是按照在各个竞争应用当中都是一致的方式来实施的，并且可能会发生例如“迟到者（latecomer）”现象之类的问题（例如参见意见请求6817第4.4节）。

[0004] 后面将讨论与实施和利用经过分类的网络流有关的技术。

发明内容

[0005] 包括下面的发明内容部分仅仅是为了介绍在后面的具体实施方式部分中所讨论的一些概念。本发明内容部分并不是全面性的，并且不意图界定由所附权利要求书阐述的所要求保护的主题内容的范围。

[0006] 这里所描述的实施例涉及对网络流进行分类，以及基于网络流的对应类别对网络流的行为进行调节。用于管理流的一种技术涉及对应用进行分析，获得关于应用的特征的指示，以及使用这些特征来推断出应用的流可以被指派到的类别。另一种技术涉及在网络的边缘处部署信标节点。信标节点向流管理器通知网络条件，比如关于网络边界或区段的等待时间。用于促进流的管理的另一个实施例涉及用于UDP应用的预订服务。UDP应用可以预订服务，所述服务可以由寄放应用的操作系统提供。事件被公布到任何预订所述服务的UDP应用，以便向UDP应用通知联网条件中的改变。UDP应用又可以对其内部传送控制逻辑进行适配。

[0007] 在其他实施例中，操作系统实施网络流的类别。应用将其网络流指派到各个类别。操作系统又根据流的类别对流进行调节。随着条件改变，通过根据流被指派到的类别对流进行调节可以使得网络资源可用或者可以更加充分地利用网络资源。通过对更低优先级类别中的流进行限制，对于更高优先级类别中的流可以使得网络资源可能快速地或者占先地可用。

[0008] 后面将参照结合附图考虑的详细描述来解释许多伴随的特征。

附图说明

[0009] 通过根据附图阅读后面的详细描述将会更好地理解本发明的描述，其中相同的附图标记被用来在伴随的描述中标示相同的部件。

[0010] 图1示出了用于自动地或隐含地对应用或流进行分类的安排。

[0011] 图2示出了简档-类别映射和应用-类别映射的实例。

[0012] 图3示出了利用简档-类别映射和应用-类别映射来选择流类别的处理。

[0013] 图4示出了可以提供网络信息的信标节点，所述网络信息可由流管理器使用来帮助依据流的类别对流进行调节。

[0014] 图5示出了用于帮助用户数据报协议（UDP）应用改进其网络行为的一个实施例。

[0015] 图6示出了一个实施例，其中TCP发送和接收窗口尺寸由流管理器使用来根据流的类别对流进行调节。

[0016] 图7示出了具有实施网络堆栈的操作系统的计算设备。

[0017] 图8示出了使用应用编程接口（API）的应用的处理。

[0018] 图9示出了流分类模型的一个实例。

[0019] 图10示出了具有对应的网络性能类属的示例性流。

[0020] 图11示出了分类模型的另一个实例。

[0021] 图12示出了流管理器的详细视图。

[0022] 图13示出了流管理器可以用来对流进行处理的示例性处理。

[0023] 图14示出了流分类模型的另一个实例。

[0024] 图15示出了用于统一流管理的一个实施例的处理。

[0025] 图16示出了计算设备的附加细节。

具体实施方式

[0026] 管理经过分类的流

[0027] 后面的标题为“网络流分类模型及其实现方式”的章节描述用于对网络流进行分类并且相应地调节网络资源的使用的技术。标题为“管理经过分类的流”的本章节描述用于管理经过分类的流的有关方法。本章节将开始于解释当应用没有明确地对其流进行分类时如何可以隐含地对所述应用的流进行分类。接下来将讨论一种使用网络边缘信号来改进网络资源分配的技术。随后将讨论各种其他技术，其中包括如何为UDP（用户数据报协议）应用提供通知服务，如何使用发送和接收窗口来帮助对流进行调节，以及其他技术。

[0028] 后面的标题为“网络流分类模型及其实现方式”的章节描述如何可以由应用明确地对用于载送网络通信量的流进行分类，这例如是通过使用由操作系统提供的应用编程接口（API）。虽然使得应用明确地对其网络流进行分类的方法对于把应用的优选项与操作系统的网络资源管理相匹配是有效的，但是这种明确分类方法可能并不总是实际的。举例来说，如果没有shim函数库或其他变通方法，则已经在没有利用流分类设施的情况下被编码和编译的应用或程序很可能需要被重新编写、重新编译、重新测试以及重新分发。出于许多原因，对应用进行修改可能是不可能或不实际的。

[0029] 图1示出了用于自动地或隐含地对应用或流进行分类的安排。运行在计算设备上的应用100通常使用计算设备（参见图16）或其操作系统的各种资源。应用的这些特质特别可以由应用建档器102使用来尝试为所述应用确定默认流分类。对于这一解释，应用100表示可以在计算设备上运行的任意代码或软件。应用100可以具有对于操作系统是可观察的各种静态和动态特征。举例来说，应用100可以发出应用编程接口（API）调用104，以便调用或链接库106，访问系统或应用配置设定108，与操作系统服务110进行交互，与网络堆栈112进行交互等等。

[0030] 应用建档器102可以具有静态分析器114和/或动态运行时间分析器116。这些组件当中的任一个或全部两个可以被用来确定哪些API调用104是由应用100发出的。可以通过异常分支（hook）、事件侦听器或者其他运行时间拦截来识别运行时间API调用104，并且通知运行时间分析器116。还可以通过由静态分析器114实施的静态分析来识别API调用104，这或者是恰好在执行应用之前、在安装应用时、在周期性的维护规程期间等等。静态分析可以涉及识别所链接到的库106（可能在应用清单文件中或者在可执行文件的特殊节段中标识）、对于已知操作系统文件的相关性、解析配置文件或设定等等。

[0031] 还可以由应用建档器102收集应用100的其他特征。举例来说，应用建档器102可以确定：应用被配置成作为后台还是前台进程运行，这例如是基于某一终端是否与所述应用相关联；应用是否访问在其寄主计算设备上可用的多媒体硬件（从而暗示流送类别）；流入到应用中的内容的类型（例如包括多媒体超链接或内容的超文本标记语言（HTML）代码）、与操作系统的多媒体调度器的配准、与流相关联的网络端口或协议等等。关于应用100可确定的任何信息都可以充当关于什么网络分类（如果存在的话）对于所述应用将是适当的提示。在一个实施例中，远程网络服务可以能够提供分类。举例来说，应用建档器102可以把应用的标识符发送到所述服务，并且作为响应接收到基于从受到管理的软件分发服务（也就是在线软件“商店（store）”）获得的关于所述应用的元数据而提供的分类。在任何情况下，所收集到的应用特征118由应用建档器102接收，并且被用来尝试为应用100确定类别。

[0032] 在一个实施例中，应用建档器102可以实施一种算法以便确定将与应用100相关联的最有可能的网络流类别。应用建档器102可以具有把应用特征映射到一个预定义类别集合的简档-类别映射120的集合。也就是说，简档-类别映射120可以表明哪些特征对应于哪些类别。图2示出了简档-类别映射120和应用-类别映射122的一个实例。在该例中，对于不同的流类别为应用特征指派权重。应用建档器102还可以保持应用-类别映射122以便跟踪哪些应用与哪些流类别相关联。将参照图3来讨论全部这两种映射。

[0033] 图3示出了利用简档-类别映射120和应用-类别映射122来选择流类别的处理。在步骤180处，应用建档器102接收对目标应用或其流进行分类的请求。所述请求可以通过任何类型的事件发起，比如应用开始执行、应用被安装、后台维护进程的迭代、应用与流的交互、通信量开始在所述流上流动、形成流或者发起用于流的网络连接、确定网络资源受到足够约束或者其他事件。所述请求可以由管理网络流的流管理器例如在重新校准所管理的流时发起。在一个实施例中，只有被确定为不使用流分类API的应用被隐含地分类。

[0034] 在步骤180处，参照应用-类别映射122以确定目标应用是否已经与特定类别相关联，随后在步骤182处，该类别被用作目标应用的流的默认类别。也就是说，目标应用的流将由流管理器根据如在应用-类别映射122中所表明的已经与目标应用相关联的类别进行管理（特别是关于本地网络资源消费的调节）。

[0035] 如果在步骤180处确定目标应用尚未与流类别相关联，则实施附加的步骤以便隐含地对目标应用进行分类。在步骤184处，如前面所描述的那样收集应用特征。在步骤186处，咨询简档-类别映射120以识别出其中的作为目标应用的特征的任何特征。举例来说，如果目标应用使用TCP（传输控制协议）端口8080，则可以使用简档-类别映射的第一行。在一个实施例中，对于可以从分类模型当中选择的每一个潜在的类别保持一个累积分数（running score）。随着在简档-类别映射中对目标应用的特征进行匹配，将相应的权重添加到相应的类别分数。当目标应用的所有特征都已被处理时，在步骤190处选择具有最高所得分数的类别作为对应于目标应用的默认类别。具有最高分数的类别被认为是与目标应用的行为或性能优选项最佳地匹配的类别。换句话说，各个类别的分数表明目标应用的特征与由操作系统提供的各种流类别的简档的配合良好程度。可以使用除了评分之外的其他方法。举例来说，可以使用优先级排序特征的系统（例如“对于库Z的使用总是类别C”），可以使用评分与布尔逻辑规则的组合等等。不管一项或更多项目标应用特征或特质如何被映射到类别，对于应用所选择的默认类别都可以在步骤192处被存储在应用-类别映射122中。下一次处理目标应用时，应用-类别映射122将使得应用建档器102再次使用相同的默认类别。

[0036] 可以使用其他方法来进行隐含的应用或流分类。举例来说，可以由操作系统保持一个用户设定列表，并且用户界面可以允许用户把类别与特定应用相关联。在另一个实施例中，可以跟踪并且分析应用的网络行为，以便确定应用应当具有的类别。例如可以把通信样式（例如突发性、长持续时间）匹配到特定类别。在另一个实施例中，如果隐含的类别-应用关联被存储并且重复使用，则可以在经过一段时间之后重新评估或删除这样的关联。此外，如果先前经过分类的应用开始对于流分类使用明确的API，则可以去除或撤消与类别的任何先前的隐含关联。

[0037] 图4示出了可以提供网络信息的信标节点220，所述网络信息可由流管理器使用来依据流的类别对流进行调节。正如在前面提到的有关专利申请中所讨论的那样，流管理器可以被实施在操作系统中以便调节各个流对于本地寄主的网络资源的消费。信标节点220可以被视为扩展本地操作系统关于网络的可见性。

[0038] 在一个实施例中，可能有帮助的是使得流管理器具有关于本地网络条件的信息，并且特别是连接的“最后一英里（last mile）”。换句话说，通过基于边缘网络信息对流进行节制，流管理器能够以改进的效率或结果对流以及流之间的争用进行调节。在该实施例中，网络（例如由大型实体运营的第一网络222）可以在第一网络222处具有信标节点220。信标节点220可以被实施成运行在边界网关上或者驻留在网络边缘附近的服务器上的新的进程，作为网络边缘附近的专用服务器机器等等。信标节点220可以记录网络条件并且把这些条件报告回到收集服务224。具体来说，可以观察并且报告第一网络222内的节点之间的等待时间，以及去到第一网络222外部的节点的等待时间。在一个实施例中，可以对已知的外部节点进行轮询，以便估计由于与外部网络上的节点的通信所导致的增加的等待时间。此外，等待时间信息可以表明第一网络222的不同边缘处的不同等待时间。还可能有帮助的是帮助识别哪些通信量正在跨越因特网。非因特网通信量可能具有低等待时间，因特网通信量则可能具有高等待时间。

[0039] 边缘提供的等待时间信息可以通过多种方式由本地流管理器使用来对流进行调节。本地流管理器可以从收集服务224获得等待时间信息，并且使用该等待时间信息对流进行调节。具体来说，当新的流被发起时，可以获得基线网络等待时间（或其他属性）。边缘相关的等待时间信息可以被用来把初始流基线设定到促进更好的流管理的数值。等待时间信息还可以被用于设定拥塞窗口或者发送和接收窗口的初始或当前尺寸。为了阐明如何可以在LEDBAT之类的协议中使用边缘相关的等待时间信息，考虑LEDBAT协议例如取决于全局基础等待时间或者经过网络的最小可能等待时间。LEDBAT协议不会混合各个流之间的信息；所有的流都基于基础等待时间受到管理。边缘等待时间信息可以被用来区分行经不同网络或网关的流，这是因为各个流可能具有显著不同的基础等待时间。通过为流提供已知的端点和网关（比如行经本地机器的因特网服务提供商的因特网服务器），边缘提供的等待时间信息可以帮助进行所述区分。

[0040] 图5示出了用于帮助UDP应用改进其网络行为的一个实施例。使用UDP协议的应用常常实施其自身的传送控制，比如分组序列化、重传以及检错。在一些实现方式中，把UDP流作为经过分类的流进行管理可能并不实际。但是应用常常具有通信量调节逻辑，所述通信量调节逻辑可以受益于被通知与网络性能和网络资源使用有关的条件。可以为计算设备250提供事件公布服务252。事件公布服务252可以是可用于应用254的操作系统服务，所述应用可以通过适当的API调用来预订公布服务。

[0041] 事件公布服务252可以实施处理256。处理256可以涉及接收关于网络资源条件的信号。实际上，流管理器257可以使用来对流进行管理的任何类型的信息都可以潜在地被传递到事件公布服务以供公布。在一个实施例中，事件公布服务252可以从网络堆栈253收集网络性能信息，并且关于网络条件何时发生了值得通知预订所述服务的应用254的改变作出其自身的确定。在另一个实施例中，流管理器257可以周期性地推送出关于计算设备250的当前等待时间和带宽性能的更新。

[0042] 随后，应用254可以使得定制逻辑258应对来自事件公布服务的通知。举例来说，在预订了事件公布服务之后，应用可以接收事件。所述事件可以通过某种形式的处理间通信来传达，并且可以仅表明网络条件发生了改变并且需要进行重新校准。所述事件还可以具有关于网络条件的具体信息，比如当前带宽或等待时间性能、当前拥塞程度、推荐窗口尺寸等等。接收应用随后将调用定制代码以用于重新校准其网络行为。举例来说，如果事件表明一个或更多流类别的性能过低或性能过高，则应用可以相应地决定增加或减少其当前通信量吞吐量，暂停通信，或者作出被设计成改进其自身行为或者帮助允许流管理器257更好地对流进行管理的其他调节。在应用实施其自身的传输类型特征的情况下，比如发送窗口、接收窗口、拥塞窗口等等，所述应用可以响应于所公布的事件调节这些特征。

[0043] 图6示出了一个实施例，其中TCP发送和接收窗口尺寸由流管理器使用来根据流的类别对流进行调节。前面提到的专利申请讨论了根据网络流的类别对网络流进行调节的流管理器。用于进行流调节的一种机制时修改与TCP流相关联的TCP发送和接收窗口270、272的尺寸。当计算设备250正通过网络276与远程设备278进行通信时，TCP连接的全部两端都可以具有发送和接收窗口。但是接收窗口尚未被接收设备使用来调节本地网络资源（特别是等待时间）。通常来说，一些低延迟额外带宽（LEDBAT）实现方式假设远程节点也在实施LEDBAT或者等效的带宽/等待时间调节方案。因此，这些实现方式通常仅使用拥塞窗口来调节通信量；每一侧都假设另一侧将尽到其调节通信量的责任。当（例如具有更高优先级等待时间的第二类别中的）其他流需要更高的响应度时，通过在计算设备250处调节本地发送和接收窗口270、272的尺寸为流管理器256给出对于回退（例如第一类别中的）一些流的更多控制。

[0044] 具体来说，在管理流时，流管理器256可以实施接收关于网络资源要求或本地条件改变的指示的处理280。举例来说，所述流可以是高优先级等待时间类别，并且流管理器256可以确定该流正处于或逼近等待时间要求或阈值。为了确保对应于所述流的类别的等待时间优先级或等待时间底限得以保持，流管理器随后根据其他流的类别调节其他流的发送和接收窗口272、274全部二者。这样可以允许流管理器256快速地节制那些其他流（特别是低优先级类别中的流），并且允许高优先级等待时间类别中的流以低等待时间快速操作。在一个实施例中，可以根据关于延迟的信息确定发送和接收窗口272、272的尺寸。举例来说，可以利用TCP时间标记测量单向延迟。应当提到的是，还可以对拥塞窗口274的尺寸进行操纵以便根据流的类别对流进行调节。还应当提到的是，流管理器256不需要直接管理窗口。流管理器256可以与网络堆栈进行通信并且向网络堆栈通知窗口尺寸应当是多少，并且随后网络堆栈实施这些尺寸。

[0045] 可以如下实施一种用于窗口操纵的算法。首先，一个流与其流类别的等待时间目标相距越远，就可以越加快速地重新确定该流的窗口尺寸。举例来说，如果一个流的类别以100ms以下的等待时间为目标并且当前测量的等待时间是400ms，则快速地降低其他流（可能通过类别进行了优先级排序）的窗口尺寸。如果当前测量的等待时间是150ms，则逐渐地减小窗口尺寸。换句话说，窗口尺寸修改的速率可以是当前等待时间与流的目标等待时间之间的差异的函数。一种更简单的重新确定尺寸的方法（例如把窗口尺寸改变静态的数量）可能导致过冲目标等待时间的极端波动。

[0046] 其次，并不撤销先前广告的窗口尺寸。远程发送方被允许完全使用先前所广告的任何窗口尺寸，但是可以限制将来的窗口尺寸广告。这样可以帮助避免与不遵从先前广告的改变的远程发送方的任何兼容性问题。

[0047] 第三，可以保持硬性最小窗口尺寸。在某些情形中，这出于几个原因可能是相关的。首先，如果TCP流的窗口尺寸变为低于2MSS（最大节段尺寸），则TCP流可能会遇到延迟的ACK以及后续的增加的等待时间。此外，可以实施最小吞吐量逻辑以避免流的连接的任一端由于低吞吐量而断开。举例来说，如果吞吐量有几分钟是极低的，则即使正在发生向前的进展，一些HTTP（超文本传输协议）服务器仍将断开HTTP会话。这部分地是为了避免通过保持资源被利用而实现的服务拒绝。为了实现该最小吞吐量，可以使用试探法以保持吞吐量的移动平均值，并且当吞吐量低于规定的最小吞吐量时可以禁用网络减损（network impairment）。这样可以允许窗口尺寸逐渐地增大而不是立即回复到某些之前的数值。

[0048] 结合在这里以及在前面提到的有关专利申请中所描述的实施例还可以使用其他技术。关于通信量调节，为了帮助释放等待时间容量（从而提高流的响应度），可以通过在发送TCP确认（ACK）之前引入等待时间在低类别流中引发更长的延迟。也就是说，可以刻意延长对应于一些流的ACK延迟，以便改进其他流的响应度（等待时间）。类似地，对于上游通信量可以延长ACK接收阈值，从而在ACK上的超时之前提供更长的等待，并且潜在地避免TCP重传。

[0049] 此外，通过给出一项或更多项分层网络要求的清单，可以支持应用网络使用合约。这方面的实例包括应用通过声明的方式规定一个清单，所述清单对于视频流送应用具有对应于标准清晰度视频层的网络带宽和等待时间要求（或类别）以及对应于高清晰度视频层的带宽和等待时间要求（或类别）的不同集合，以及VOIP（互联网协议语音）呼叫中的不同保真度水平，从而使得中央控制器可以根据发生改变的网络条件（向上和向下）节制经过不同的层。

[0050] 还有可能向宽带提供商给出流优先级提示。如果应用通信量允许更长的延迟，则提供商可以使用所述提示以给出更低的成本，并且反之可以快速跟踪已被适当地标记的通信量。

[0051] 最后，（依据流类别的）网络通信量优先级可以被用于电力管理。更低优先级通信量可以被延迟/丢弃以节省电力。也就是说，通信量可以被调度用于延迟传送，这样可以允许节省电池电力。举例来说，流管理器可以向电力管理模块通知其不需要保持去到特别用于特定流的连接的无线电装置的电力或者开始为所述无线电装置供电。

[0052] 网络流分类模型及其实现方式

[0053] 后面讨论的实施例涉及允许应用将其网络流分类到网络堆栈或操作系统，所述网络堆栈或操作系统又根据网络流的分类在全系统范围内编排设备的网络资源的共享。讨论将开始于系统总览以及解释应用如何可以选择系统将对其网络行为进行调节的方式。接下来将描述网络流分类模型的实例及其实施细节。

[0054] 图7示出了具有实施网络堆栈1104的操作系统1102的计算设备1100。网络堆栈1104可以从任何已知的操作系统联网堆栈导出，并且具有可以从本发明的描述认识到的添加或改变。举例来说，可以利用包装器（wrapper）来修改或增强TCP/IP网络堆栈。通常来说，任何网络协议栈的传输层级的实现方式都将是便利的。在计算设备1100上，多种任意应用
1106当中的任一个可以执行并且通过数据网络1108进行通信。应用1106的一些实例有web浏览器、后台下载器、在线游戏、实时语音或视频通信程序、数据库客户端、媒体流送应用等等。为了与远程设备1109交换数据，应用1106通过数据网络1108进行通信，所述数据网络
1108可以是载送IP（互联网协议）通信量的网络或者其变型。如果存在虚拟化层（例如管理程序）并且应用执行在不同虚拟机上的访客操作系统上，则网络通信可以完全或部分地是计算设备1100本地的。

[0055] 操作系统1102可以包括一个或更多接口驱动程序1110（设备驱动程序），所述驱动程序除了其他已知的功能之外还向/从对应的网络接口1112传递和接收分组。可以假设应用1106执行在用户空间中，并且操作系统1102和这里所描述的联网特征执行在内核空间中。但是并不作此要求。内核模式代码或用户模式代码可以把网络分类指派到其所控制的网络流，并且流管理器1114可以在内核空间或用户空间中执行。在一个实施例中，网络流管理可以通过与已知的TCP/IP网络堆栈交换分组的用户模式包装器来实施。

[0056] 流管理器1114管理并且调节对应于应用1106的网络流1116。网络流1116（后文中称作“流”）是对应于计算设备1100与远程设备1109之间的对应网络连接（例如IP5元组）的操作系统对象。通常来说，每一个流具有FIFO缓冲器和描述符或句柄，所述描述符或句柄由操作系统和该流的应用使用来在该流上实施操作时识别该流。网络堆栈1104可以提供代表流1116实施传输协议的传输层模块（例如TCP模块）。操作系统1102提供应用编程接口（API）1118，应用1106使用所述应用编程接口1118来实施与流有关的操作，比如实例化流对象、设定流参数、发起与流的网络连接、关闭流、获得和设定流的各项属性的数值，比如将要连接到的网络地址、将要使用的远程和本地端口、将要使用的协议、联网参数等等。当按照这里所描述的那样被扩展或修改时，Winsock API、Berkeley套接字API以及其他类似的API都适合用作API 1118。

[0057] 图8示出了应用使用API 1118向网络堆栈1104通知将与指定的流相关联的流类别或类属的处理。在步骤1140处，应用形成或获得流。所述流可以或者可以不具有网络连接。所述流在应用的执行代码中可以作为描述符、句柄、对象等等被参考。应用可以从另一个应用或处理获得流，或者可以作为新的对象发起流。在后一种情况下，可以由应用在使用流形成网络连接之前设定流的各种参数或属性。正如前面所提到的那样，这样的参数例如可以是远程网络地址、本地网络地址（当在计算设备1100上有多个网络接口1112可用时）、本地和远程端口、协议设定等等。

[0058] 在步骤1142处，应用使用API 1118把流类别或类属（后文中称作“类别”）明确地指派到流。应用可以把其他类别指派到该应用的其他流。可以在流的生命周期期间的任何时间实施步骤1142，其中包括在实例化流时，在为流形成网络连接之前，在流被连接并且可能载送通信量之后，当流正在载送通信量时等等。此外，可以在相同的流上重复实施步骤1142，以便改变当前被指派到流的类别，从而正如接下来讨论的那样相应地改变流管理器
1114调节经过所述流的分组流动的方式。

[0059] 在步骤1144处，操作系统（具体来说是流管理器1114）控制网络流的网络资源使用。流管理器1114充当中央协调器，并且编排正由操作系统管理的多个（可能是所有）流的网络行为。流管理器1114可以跟踪各个流的实际网络性能并且调节其行为，特别是关于等待时间和带宽（吞吐量）性能，并且可能还有不同尺寸的时间窗口上的平均吞吐量。流管理器1114还可以接收关于网络条件的信号，这例如是通过分析探测分组的回程时间（RTT），通过接收关于沿着所述流的网络路径的各种设备的队列尺寸的信息等等。应当提到的是，流管理器1114应当能够对于每一个流确定近来的和/或当前的带宽、等待时间或全部二者。在一个实施例中，并非所有的流都具有明确的应用指派的类别。但是流管理器1114也可能管理这些流，这可能是通过将这些流作为具有默认类别来对待。在一个实施例中，流管理器1114不是单独的模块或组件，而是分散在整个操作系统1102和/或网络堆栈1104中的逻辑（这里所使用的术语“流管理器”指代全部两种设计）。换句话说，流管理逻辑的放置并不重要。

[0060] 图9示出了流分类模型1180A的一个实例。图9还示出了把类别指派到流的代码1182的样本。分类模型1180A具有八个类别，其中四个对应于带宽并且四个对应于等待时间。在该示例性分类模型1180A中，两个类别可以被指派到相同的流；一个类别对应于带宽并且一个类别对应于等待时间。如样本代码1182中所见，“高”带宽和“低”等待时间类别被指派到通过“socket_s”表示的流。在其他实施例中，分类模型1180A可以仅具有带宽类别，或者只有等待时间类别，或者具有全部两种性能规格的各个单独的类别，正如图5中所示出的那样。图10示出了具有对应的网络性能类属的示例性流1190。流1190可以具有通过API 
1116指派的标识符和类别1192。在一个实施例中，对应的流的分类是操作系统1102使用来表示所述流的对应数据结构或对象的标志或属性。

[0061] 图11示出了分类模型1180B的另一个实例。分类模型1180B具有六个类别（A到F）：实时类别、响应（交互）类别、流送类别、正常类别、最终（eventual）类别以及不可见类别。该分类模型1180B对于开发者可能是便利的，这是因为各个单独的类别紧密地对应于常见类型的网络消费应用。每一个类别可以具有实施在流管理器1114的逻辑中的网络性能的一种或更多种规格中的对应的性能范围、底限、上限等等。举例来说，各个类别可以被如下实施（带宽以兆比特每秒（MBS）计，等待时间以毫秒（ms）计）：

[0062] 实时：1MBS、200ms；

[0063] 响应：0.1MBS、50ms；

[0064] 流送：3MBS、1500ms；

[0065] 正常：0.2MBS、5000ms；以及

[0066] 最终、不可见：0MBS、0ms。

[0067] 这些数字仅仅是实例；可以使用任何数值，并且一些类别可以不具有带宽和/或等待时间规范。

[0068] 流管理器1114可以具有控制逻辑1200（图6），以便实施关于当需求在各个流之间产生冲突时如何依据其类别实现各个流的性能目标的策略或规则1202。举例来说，规则1202可以规定对于带宽的优先权，从而使得当流送类别流处于或接近其极限时，通过根据其他流的类别对其他流进行节制而使得带宽可用。举例来说，当A类流需要联网资源时，可以首先节制不可见流，随后是最终流，随后是正常流，随后是响应流。各个类别还可以具有对应的权重以便规定将要节制的带宽（或等待时间）的相对部分，从而允许更高优先级类别中的流获得从低优先级流释放的带宽的一大部分以及从中等优先级流释放的带宽的一小部分。在另一个实施例中，根据流的类别对网络资源的使用进行优先级排序或分派。如果响应流需要附加的带宽，可以从能够匀出带宽并且同时保持在其性能规范内的任何流吸取（例如通过节制）带宽，这可能是从最低优先级类别的流开始的。总而言之，可以通过多种算法、规则/策略、性能数值等等根据流的类别对其网络资源消费实施统一管理。

[0069] 根据应用规定的类别对流进行集中式全局管理的一个潜在的益处是可以改进用户的体验。举例来说，假设用户的设备正在通过已被归类为“流送”的网络流运行多媒体流送应用。还假设该用户启动了web浏览器应用，所述web浏览器应用将其HTTP浏览流归类为“响应”并且将其下载流归类为“正常”。当用户请求网页时，由于相应的响应类别流的等待时间优先级高于流送类别流，因此可以暂时节制流送类别流（例如节制50ms）以便允许响应类别流满足其等待时间要求。流送类别流的简短放慢可能不会被用户注意到（由于缓冲），并且网页将会快速地下载。如果用户发起文件下载，则可以从流送类别流“借用”带宽直到达到其带宽底限为止，从而允许正常类别下载流按照最大化其带宽并且不会干扰来自流送类别流的媒体播放的方式继续。

[0070] 图12示出了流管理器1114的详细视图。各个流1190分别具有对应的队列1240，其中分组在被传递经过设备驱动程序以便由相应的网络接口传送之前或者在从设备驱动程序接收到之后被排入队列。控制逻辑1200如前面所描述的那样管理流1190的网络性能。控制逻辑1200可以反复接收关于带宽和等待时间的更新。所述更新可以是来自接口驱动程序1110、网络堆栈1104或者外部来源。这样的更新可以表明多种网络条件和统计信息，比如对于计算设备1100或者对于各个单独的网络接口1112的当前带宽可用性，当前或预期等待时间信息，网络拥塞等等。控制逻辑1200可以使用该信息来调节各个流消费网络资源的方式。

[0071] 图13示出了控制逻辑1200可以用来对流进行调节的示例性处理。在步骤1260处，流管理器1114按照规则的间隔开始在各个活跃的流上进行迭代（本段中的“流”指的是当前迭代的流）。在步骤1262处，获得流的当前性能统计信息。举例来说，获得当前或估计带宽和等待时间。该信息可以从近来的吞吐量进行估计，根据当前通信量统计信息进行预期，基于排入队列的分组的数量、传入分组的速率以及其他已知的技术。流的类别可能会影响其被迭代地评估的频度。

[0072] 在步骤1264处，流管理器1114确定流的类别或类属，并且确定流是否正在（或者预期将会）根据其规定的类属表现性能。在步骤1266处，如果流没有在按照规定的那样表现性能，则流管理器1114实施意图满足该流的类别规范的适配。举例来说，在考虑到其类别的情况下，其他流可以被节制、暂停等等。这可以通过以下措施实现：调节流的发送窗口和/或接收窗口，扩大或缩小流缓冲器，暂停经过某一个流的分组流动等等。应用或其他组件不必对分组加标签，应用也不必使用协议层级的QoS特征。从应用的角度看来，所述流是普通的TCP（或类似的）流。在步骤1268处，对下一个流（如果存在的话）进行处理。

[0073] 关于这里所提到的没有在根据其对应类别的规范表现性能的流，关于性能遵从性的确定或者驱动性能调节的确定应当被理解成不仅仅涵盖相对于寄主机器上的其他连接的性能。如果一个流的网络连接正在经历的单向延迟比所述连接所经历的最低单向延迟高100ms，则例如LEDBAT协议之类的协议认为该流没有在按照规定的那样表现性能。假设LEDBAT连接可能是导致延迟增加的因素，并且通过限制该连接的窗口可以减少正在经过相同的共享网络资源的其他连接的延迟。换句话说，各个流类别的规范可以关于彼此是相对的，关于性能数值是绝对的，或者两种情况的组合。此外，可以提供正式的语言或句法以表达复杂的规范，例如布尔运算符的句法、条件语句等等，并且可能采取基于标记（例如可扩展标记文件）的声明性语言的形式。或者，这样的复杂逻辑可以被“硬编码”到流管理器、网络堆栈等等的编程中。

[0074] 图14示出了流分类模型1180C的另一个实例。每一个类属具有等待时间分量和带宽分量。各个类属可以沿着任一种规格重叠。在该例中，流的分类把带宽和等待时间全部二者的性能目标指派到流。如果假设一个类别（例如E类）意图在相应的流上施加对应于实时或快速响应的等待时间规范（也就是说网络通信量将响应于用户请求开始以最小视在延迟流动），则流管理器逻辑可以使用本地操作系统的各种网络影响机制来“回退”或向下调节其他流，比如D类流（或者所有其他的流，或者所有其他活跃的流等等）。也就是说，当被归类为对于等待时间敏感的新连接或新通信量开始时，可以立即在本地减损低优先级连接。举例来说，如果由用户发起的web浏览器将要请求web对象，则可以占先地减损后台文件传输，从而使得即将到来的浏览器通信量以清空的网络开始。先前的方法常常依赖于根据竞争通信量作出的服务质量决定，这对于新通信量通常并不是立即有帮助的。类似的方法可以被用于带宽性能或者各种网络性能特性的组合。应当提到的是，可以通过以下措施实现本地通信量减损：暂停从应用到其网络连接的数据流动，暂停缓冲分组的传送，调节联网窗口尺寸，暂停或降级应对流通信量的线程，或者通过调节可能会潜在地影响流的网络资源消费的流的其他操作参数。

[0075] 图15示出了对应于统一流管理的一个实施例的处理。在该实施例中，流管理器1114可以如下实施网络资源的重新分配。在步骤1280处，根据目标流的类别确定目标流需要附加的网络资源，例如带宽或等待时间或全部二者。对于一个解释性实例，将假设分类模型1180C的A类流需要附加的带宽。在步骤1282处，对于每一个流类别采集聚合统计信息。在步骤1284处，按照适合于类别的顺序对这些聚合统计信息进行评估，并且在步骤1286处按照需要对其进行调节。首先对根据网络需求的最低优先级类别的流进行评估，也就是E类。
如果E类流的聚合带宽作为一个整体具有额外的带宽，则对E类流进行节制以便提供附加的带宽。如果E类流所给出的带宽不足，则对下一个优先级类别（C类）的聚合统计信息进行评估。也就是说，如果对E类流的节制没有释放出足够的带宽，则对C类流的聚合带宽进行评估，并且按照需要对该类别中的流进行节制。如果C类和E类流都无法在满足其类别要求的同时让出足够的带宽，则可以把较低优先级类别的流（E类）压到其类别的带宽目标以下，以便帮助满足具有更高优先级的A类流的带宽要求。

[0076] 如果前面的实例中的流需要改进的等待时间以替代或补充附加的带宽，则实施类似的处理，但是对于每一个类别的聚合统计信息的评估以及对于其中的流的任何调节都是按照取决于各个类别的等待时间特质的顺序来实施的。

[0077] 虽然本发明的描述可能在一些地方提到分配或重新分配网络资源，但是资源的“分配”是使用多种（前面描述的）网络影响机制当中的任一种以尝试满足各个流类别的规范的副作用的概念性表征。此外，基于流类别所采取的优先级排序或流调节措施可以不一定涉及相应的流的网络资源消费的立即增加或减少。举例来说，当LEDBAT判定低优先级连接需要被“限制”时，（可以被修改以提供流类别的）例如LEDBAT协议之类的协议可以不一定损害低优先级连接的带宽或等待时间。举例来说，减小连接的发送窗口的尺寸对于其吞吐量或等待时间可能没有直接影响；出于许多可能的原因，所述连接后来可能会获得更好的吞吐量或等待时间。

[0078] 图16示出了可以在其上实施前面所描述的实施例的通用计算设备1100的附加细节。计算设备1100可以具有显示器1300以及存储装置1302和处理硬件1304，所述处理硬件1304可以是以下各项当中的任何一项或更多项的组合：中央处理单元、图形处理单元、模拟到数字转换器、总线芯片、现场可编程门阵列（FPGA）、专用集成电路（ASIC）、专用标准产品（ASSP）或者复杂可编程逻辑设备（CPLD）等等。存储装置1302可以是磁性存储装置、静态存储器、易失性存储器等等的任意组合。这里所使用的术语“存储装置”的含义不是指信号或能量本身，而是指物理装置（包括例如磁性存储介质、光学存储介质、静态存储器设备等物理介质，而不包括信号本身）。计算设备1100的各个硬件元件可以按照计算领域内众所周知的方式进行协作。此外，输入设备1306可以与计算设备1100集成在一起或者与计算设备
1100进行通信。计算设备1100可以具有任何外形，或者可以被使用在任何类型的封装设备中。计算设备1100可以采取以下形式：例如智能电话之类的手持式设备、平板计算机、游戏设备、服务器、机架安放或背板安放的板上计算机、芯片上系统或者其他形式。通常来说，计算设备1100将是分立的网络节点或设备。

[0079] 前面所讨论的实施例和特征可以通过存储在易失性或非易失性计算机或设备可读装置中的信息的形式来实现，此类信息能够配置计算设备1100实施这里所描述的实施例。这些装置可以包括例如光学存储装置（例如紧致盘只读存储器（CD-ROM））、磁性介质、全息存储装置、闪速只读存储器（ROM）之类的装置或者用于存储数字信息的其他设备。所存储的信息可以采取机器可执行指令（例如已编译的可执行二进制代码）、源代码、字节代码或者可以被用来允许或配置计算设备实施这里所描述的实施例的其他信息的形式。此外还认为这方面至少包括易失性存储器，比如在实施一个实施例的软件的执行期间存储例如中央处理单元（CPU）指令之类的信息的随机存取存储器（RAM）和/或虚拟存储器，以及存储允许加载和执行程序或可执行程序的信息的非易失性设备。