CN113726677B - 一种网络拥塞控制方法及设备 - Google Patents

Abstract

本申请实施例提供一种网络拥塞控制方法及设备。在本申请实施例中，采用硬件时间来记录单次通信往返中目标数据包和其对应的确收数据包各自所经历的发送时间和接收时间，这样，可根据各个硬件时间计算网络时延，并基于网络时延感知网络拥塞及调整本端的网络速率。本申请实施例中，基于硬件时间计算网络时延，可有效提高网络时延的准确性，从而根据网络时延来更加准确地感知网络拥塞，而且还可根据网络时延调整本端的网络速率，从而实现更加精准的拥塞控制。

Description

一种网络拥塞控制方法及设备

技术领域

本申请涉及网络技术领域，尤其涉及一种网络拥塞控制方法及设备。

背景技术

近些年，用户对数据中心和云计算服务的需求快速增长，并提出了更高的性能要求。其中，网络对数据中心、云计算服务的性能有着重要影响，网络拥塞会严重影响数据中心、云计算服务的性能。

目前常用的拥塞控制方案有基于丢包的CUBIC（立方）方案、基于网络打标的DCQCN（data center quantized congestion notificatio，量化拥塞通知）方案等，但是，这些拥塞控制方案对网络拥塞的感知准确性不足，导致拥塞控制的效果不佳。

发明内容

本申请的多个方面提供一种网络拥塞控制方法及设备，用以更加准确地感知网络拥塞，从而有效控制网络拥塞。

本申请实施例提供一种网络拥塞控制方法，包括：

接收对端针对本端发送的目标数据包而返回的确收数据包，所述确收数据包中包含的对端发送时间和所述目标数据包的被接收时间记录，采用硬件时间；

获取本端接收所述确收数据包时的硬件时间，作为所述确收数据包对应的本端接收时间；

获取本端发送所述目标数据包时的硬件时间，作为所述目标数据包的发送时间记录；

根据所述确收数据包对应的本端接收时间和对端发送时间以及所述目标数据包的发送时间记录和被接收时间记录，计算本端与对端之间的网络时延；

基于所述网络时延，调整本端的网络速率，以对后续数据包进行拥塞控制。

本申请实施例还提供一种网络拥塞控制方法，包括：

在本端与对端之间的网络时延大于指定的时延阈值的情况下，获取本端最近一次延时发包操作所对应的实际发包时延；

若所述最近一次延时发包操作的发生时间与当前时间之间的时间间隔小于所述实际发包时延，则以窗口规格不小于本端支持的最大传输单元为目标，调整本端的拥塞窗口；

按照调整后的拥塞窗口，确定本端的网络速率，以对本端进行拥塞控制；

其中，所述延时发包操作是在本端的历史拥塞窗口的窗口规格小于所述最大传输单元的情况下被触发的。

本申请实施例还提供一种网络时延确定方法，包括：

接收对端针对本端发送的目标数据包而返回的确收数据包，所述确收数据包中包含的对端发送时间和所述目标数据包的被接收时间记录，采用硬件时间；

获取本端接收所述确收数据包时的硬件时间，作为所述确收数据包对应的本端接收时间；

获取本端发送所述目标数据包时的硬件时间，作为所述目标数据包的发送时间记录；

根据所述确收数据包对应的本端接收时间和对端发送时间以及所述目标数据包的发送时间记录和被接收时间记录，计算本端与对端之间的网络时延。

本申请实施例还提供一种通信端，包括存储器、处理器和通信组件；

所述存储器用于存储一条或多条计算机指令；

所述处理器与所述存储器和所述通信组件耦合，用于执行所述一条或多条计算机指令，以用于：

通过所述通信组件接收对端针对本端发送的目标数据包而返回的确收数据包，所述确收数据包中包含的对端发送时间和所述目标数据包的被接收时间记录，采用硬件时间；

获取本端接收所述确收数据包时的硬件时间，作为所述确收数据包对应的本端接收时间；

获取本端发送所述目标数据包时的硬件时间，作为所述目标数据包的发送时间记录；

根据所述确收数据包对应的本端接收时间和对端发送时间以及所述目标数据包的发送时间记录和被接收时间记录，计算本端与对端之间的网络时延；

基于所述网络时延，调整本端的网络速率，以对后续数据包进行拥塞控制。

本申请实施例还提供一种通信端，包括存储器、处理器和通信组件；

所述存储器用于存储一条或多条计算机指令；

所述处理器与所述存储器和所述通信组件耦合，用于执行所述一条或多条计算机指令，以用于：

在本端与对端之间的网络时延大于指定的时延阈值的情况下，获取本端最近一次延时发包操作所对应的实际发包时延；

若所述最近一次延时发包操作的发生时间与当前时间之间的时间间隔小于所述实际发包时延，则以窗口规格不小于本端支持的最大传输单元为目标，调整本端的拥塞窗口；

按照调整后的拥塞窗口，确定本端的网络速率，以对本端进行拥塞控制；

其中，所述延时发包操作是在本端的历史拥塞窗口的窗口规格小于所述最大传输单元的情况下被触发的。

本申请实施例还提供一种通信端，包括存储器、处理器和通信组件；

所述存储器用于存储一条或多条计算机指令；

所述处理器与所述存储器和所述通信组件耦合，用于执行所述一条或多条计算机指令，以用于：

通过所述通信组件接收接收对端针对本端发送的目标数据包而返回的确收数据包，所述确收数据包中包含的对端发送时间和所述目标数据包的被接收时间记录，采用硬件时间；

获取本端接收所述确收数据包时的硬件时间，作为所述确收数据包对应的本端接收时间；

获取本端发送所述目标数据包时的硬件时间，作为所述目标数据包的发送时间记录；

根据所述确收数据包对应的本端接收时间和对端发送时间以及所述目标数据包的发送时间记录和被接收时间记录，计算本端与对端之间的网络时延。

本申请实施例还提供一种存储介质，存储计算机指令的计算机可读存储介质，当所述计算机指令被一个或多个处理器执行时，致使所述一个或多个处理器执行前述的网络拥塞控制方法或网络时延确定方法。

在本申请实施例中，采用硬件时间来记录单次通信往返中目标数据包和其对应的确收数据包各自所经历的发送时间和接收时间，这样，可根据各个硬件时间计算网络时延，并基于网络时延感知网络拥塞及调整本端的网络速率。本申请实施例中，基于硬件时间计算网络时延，可有效提高网络时延的准确性，从而根据网络时延来更加准确地感知网络拥塞，而且还可根据网络时延调整本端的网络速率，从而实现更加精准的拥塞控制。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请一示例性实施例提供的通信系统的结构示意图；

图2为本申请一示例性实施例提供的一种确收数据包中时间戳的示意图；

图3为本申请另一示例性实施例提供的一种网络拥塞控制方法的流程示意图；

图4为本申请另一示例性实施例提供的一种基于调整后的拥塞窗口进行网络速率控制过程的逻辑示意图；

图5为本申请另一示例性实施例提供的一种拥塞窗口调整过程的逻辑示意图；

图6为本申请另一示例性实施例提供的另一种网络拥塞控制方法的流程示意图；

图7为本申请又一示例性实施例提供的一种网络时延的确定方法的流程示意图；

图8为本申请又一示例性实施例提供的一种通信端的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

目前，目前常用的拥塞控制方案对网络拥塞的感知准确性不足，导致拥塞控制的效果不佳。为此，本申请的一些实施例中：采用硬件时间来记录单次通信往返中目标数据包和其对应的确收数据包各自所经历的发送时间和接收时间，这样，可根据各个硬件时间计算网络时延，并基于网络时延感知网络拥塞及调整本端的网络速率。本申请实施例中，基于硬件时间计算网络时延，可有效提高网络时延的准确性，从而根据网络时延来更加准确地感知网络拥塞，而且还可根据网络时延调整本端的网络速率，从而实现更加精准的拥塞控制。

以下结合附图，详细说明本申请各实施例提供的技术方案。

图1为本申请一示例性实施例提供的通信系统的结构示意图。如图1所示，该系统包括：第一通信端10和第二通信端20，第一通信端10和第二通信端20上均部署有本实施例所提高的网络拥塞控制装置，其中，本实施例提供的网络拥塞控制装置可实现为软件和/硬件的结合。本实施例提供的网络拥塞控制装置可取代第一通信端10和第二通信端20上原本部署在网卡等通信设备中的网络拥塞控制功能，当然，也可额外部署在第一通信端10和第二通信端20上原有的网络拥塞控制功能之外，这种情况下，可直接弃用原有的网络拥塞控制功能即可。

本实施例提供的网络拥塞控制方案可应用在各种需要进行网络拥塞控制的场景中，例如，对数据中心内部进行网络拥塞控制等，当然，这仅是示例性的，本实施例对应用场景不做限定。在不同的应用场景中，图1中的第一通信端10和第二通信端20的物理实现形式可能不完全相同。例如，在数据中心的场景中，第一通信端10和第二通信端20可以是数据中心包含的服务器。本实施例中对第一通信端10和第二通信端20的物理形式不做限定，在此不再穷举。

值得说明的是，图1是从单次通信往返的层面示出了通信系统中的成员设备，但是应当理解的是，在应用场景中，可以包含无数的通信端，本案为了便于描述，从任意两个通信端进行的单次通信往返过程来对本实施例提供的网络拥塞控制方案进行说明。其中，通信往返是指从发送端发送数据开始，到发送端收到来自接收端的确认结束。图1中示出了一种示例性的通信往返过程：第一通信端10向第二通信端20发送目标数据包；之后，第二通信端20向第一通信端10返回针对目标数据包的确收数据包。值得说明的是，这里的确收数据包并不限于专门的确收响应ACK，在实际应用中，第二通信端20在收到目标数据包后向第一通信端10所返回的携带针对目标数据包的ACK信息的数据包即可作为这里的确收数据包，而对确收数据包中负载的其它数据内容不做限定。

其中，确收数据包中至少包含对端发送时间和目标数据包的被接收时间记录。对端发送时间用于表征第二通信端20发送该确收数据包的时间；目标数据包的被接收时间记录用于表征第二通信端20接收到目标数据包的时间。重要的是，确收数据包中包含的这几种时间均采用硬件时间。本实施例中，第一通信端10和第二通信端20通常是利用通信硬件来收/发数据包的，因此，本实施例中的硬件时间可理解为通信硬件自身维护的时间信息，区别于系统/软件时间。其中，通信硬件可包括但不限于网卡设备等。这样，本实施例中，第一通信端10可从确收数据包中读取确收数据包对应的对端发送时间和目标数据包的被接收时间记录。

第一通信端10还可获取本端接收确收数据包时的硬件时间，作为确收数据包对应的本端接收时间；获取本端发送目标数据包时的硬件时间，作为目标数据包的发送时间记录。其中，本端接收时间用于表征第一通信端10收到该确收数据包的时间；目标数据包的发送时间记录用于表征第一通信端10向第二通信端20发送目标数据包的时间。

承接图1中的示例性通信往返过程：第一通信端10可在向第二通信端20发送目标数据包过程中，利用自身的通信硬件将目标数据包经过通信硬件时的硬件时间作为目标数据包的发送时间记录写入目标数据包中。第二通信端20在接收到目标数据包的情况下，可记录接收到目标数据包时的硬件时间作为目标数据包的被接收时间记录，在一可选的实现方式中，第二通信端20可为目标数据包维护本地状态信息，并将前述目标数据包的发送时间记录和目标数据的被接收时间记录记录到目标数据包对应的本地状态信息中。基于此，第二通信端20还可在向第一通信端10发送针对目标数据包的确收数据包的过程中，从目标数据包的本地状态信息中读取目标数据包的发送时间记录和目标数据包的被接收时间记录，并写入确收数据包中；还可利用自身的通信硬件将确收数据包经过通信硬件时的硬件时间作为确收数据包的本端发送时间写入确收数据包中。此后，第一通信端10接收确收数据包，并可在接收到确收数据包的情况下，利用通信硬件将当前硬件时间写入确收数据包，作为本端接收时间，至此，确收数据包中包含了四种硬件时间：本端接收时间、对端发送时间、目标数据包的发送时间记录和目标数据包的被接收时间记录。这样，本实施例中，第一通信端10可从确收数据包中获取确收数据包的本端接收时间和目标数据包对应的本端发送时间记录。而且，本实施例中，第一通信端10和第二通信端20均可利用自身的通信硬件将收/发数据包时的硬件时间写入到数据包中，而无需额外的软件开销，这可有利于网络性能的提升。

在一实际应用中，可以时间戳的形式将上述的四种硬件时间写入确收数据包中。图2为本申请一示例性实施例提供的一种确收数据包中时间戳的示意图。参考图2，确收数据包中可包含4个时间戳，其中，时间戳1用于承载目标数据包的发送时间记录，由第二通信端20写入；时间戳2用于承载目标数据包的被接收时间记录，由第二通信端20写入；时间戳3用于承载确收数据包的对端发送时间，由第二通信端20写入；时间戳4用于承载确收数据包的本端接收时间，由第一通信端10写入。另外，第一通信端10也可为确收数据包维护本地状态信息，并从确收数据包中读取时间戳3和时间戳4分别作为确收数据包的发送时间记录和确收数据包的被接收时间记录，并记录到确收数据包的本地状态信息中，以供第一通信端10在向第二通信端20发送下一个数据包过程中，将这两个硬件时间分别写入下一个数据包的时间戳1和时间戳2，进而支持下一次通信往返过程中的网络时间计算。同样，本实施例中的目标数据包也可能作为其上一数据包的确收数据包，因此，目标数据包中除携带前述的通过第一通信端10的通信硬件时的硬件时间外，还可包含其它3种硬件时间，可将目标数据包作为一个确收数据包而适配前述的确收数据包中4种硬件时间的写入过程，在此不再赘述。

其中，本实施例中，除了可通过利用硬件设备直接将硬件时间写入数据包中的方式来获取相关的硬件时间外，还可采用其它实现方式来获取到硬件时间。例如，利用硬件设备在收

/发数据包时，向数据包之外的其它对象（如本地文件等）来写入硬件时间，从而获取到相关的硬件时间。当然，对于需要对端提供的硬件时间，还是需要由对端写入到确收数据包中，以保证本端拥有足够的数据基础来计算网络时延。

这样，除了上述的将目标数据包和确收数据包各自的收/发时间携带在确收数据包中之外，本实施例中，第一通信端10和第二通信端20均可为目标数据包和确收数据包维护本地状态信息，并将本端发生的硬件时间记录在相应的本地状态信息中，而无需再从数据包中获取本端发生的硬件时间。例如，对于第一通信端10来说，可将目标数据包的本端发送时间记录写入目标数据包的本地状态信息中；将确收数据包的本端接收时间写入确收数据包的本地状态信息中，对于这两个时间，第一通信端10无需再从确收数据包中获取，而是可直接记录在本地状态信息中，而对端也无需再将这两个时间写入确收数据包。当然，考虑到第二通信端20也需要从自身的角度计算其与第一通信端10之间的网络时延，第一通信端10可将这两个时间写入到合适的数据包中，以提供给第二通信端20作为计算网络时延的基础。

还是以图1中示例性的通信往返过程为例，第一通信端10可根据上述的本端接收时间、对端发送时间、目标数据包的发送时间记录和目标数据包的被接收时间记录，计算本端与第二通信端20之间的网络时延。其中，本端接收时间可由第一通信端10的通信硬件在接收到确收数据包时而写入到确收数据包中，当然，也可不写入而通过上述提及的其它方式获取到该硬件时间。在一种可选的实现方案中：第一通信端10可计算对端发送时间与目标数据包的被接收时间记录之间的差值，作为对端处理时间；计算本端接收时间与目标数据包的发送时间记录之间的差值，作为本端等待时间；将本端等待时间与对端处理时间之间的差值，作为本端与对端之间的网络时延。该实现方案可表征为如下表达式：

网络时延=（本端接收时间-目标数据包的发送时间记录）-（对端发送时间-目标数据包的被接收时间记录）。

由于网络时延的计算基础均为硬件时间，可有效提高网络时延的准确性，而且，这些硬件时间均可由通信硬件直接写入到确收数据包中，避免了额外的软件开销，有利于网络性能提升。

在此基础上，参考图1，第一通信端10可基于网络时延，调整本端的网络速率，以对后续数据包进行拥塞控制。本实施例中的拥塞控制思路可以是：在发生网络拥塞时，网络中的通信端通过控制自身的网络速率来降低数据发送量，从而改善网络拥塞。例如，在数据中心场景中，数据中心中的服务器之间通过交换机来进行网络通信，也既是各个通信端（服务器）将数据发送至交换机后，再由交换机转发至其指定的对端（其它服务器），对此，本实施例中，可在数据中心包含的各个服务器上部署本实施例提供的网络拥塞控制装置，从而支持各个服务器控制自身的网络速率，在发生网络拥塞时，减少向交换机发起的数据量，进而缓解交换机处的网络拥塞。

另外，本实施例中，网络中的数据包中均可携带本实施例中提到的4种硬件时间，以标识通信往返过程中数据包的收/发时间，从而贯穿起连续的若干通信往返过程，这样，第一通信端10和第二通信端20均可作为通信往返的起点，第一通信端10可作为通信起点（也即对应于图1中发出目标数据包），计算其与第二通信端20之间的网络时延；第二通信端20也可作为通信起点（也即对应于图1中发出目标数据包），来计算其与第一通信端10之间的网络时延，从而第一通信端10和第二通信端20可按照各自计算出的网络时延各自完成自身的拥塞控制。

据此，本申请实施例中，可采用硬件时间来记录单次通信往返中目标数据包和其对应的确收数据包各自所经历的发送时间和接收时间，并将这些硬件时间写入确收数据包中，这样，可根据确收数据包中携带的各个硬件时间计算网络时延，并基于网络时延感知网络拥塞及调整本端的网络速率。本申请实施例中，基于硬件时间计算网络时延，可有效提高网络时延的准确性，从而根据网络时延来更加准确地感知网络拥塞，而且还可根据网络时延调整本端的网络速率，从而实现更加精准的拥塞控制。

在上述或下述实施例中，第一通信端10可基于其与第二通信端20之间的网络时延，调整自身的拥塞窗口的窗口规格，以调整本端的网络速率。其中，拥塞窗口是网络拥塞控制领域中的常规术语，在此不再进行解释。另外，调整拥塞窗口的窗口规格的具体方案将在后续实施例中进行说明，本实施例中，将以调整后的拥塞窗口作为阐述的起点。

本实施例中，可为第一通信端10配置两种控速模式：一种是基于发送窗口的控速模式；另一种是基于延时发包的控速模式。

基于此，对第一通信端10来说，在调整后的拥塞窗口的窗口规格大于或等于最大传输单元的情况下，采用前述的基于发送窗口的控速模式来控制本端的网络速率。在该控速模式下，可将调整后的拥塞窗口直接赋值给发送窗口，并按发送窗口进行确收数据包之后的下一数据包的发送操作。其中，发送窗口也是网络拥塞控制领域中的常规术语，在此也不再进行解释。另外，最大传输单元可以是第一通信端10支持传输的最大数据包的大小，例如，在数据中心场景中，第一通信端10和交换机之间可约定最大传输单元。

本实施例中，第一通信端10可在调整后的拥塞窗口的窗口规格小于最大传输单元的情况下，采用前述的基于延时发包的控速模式来控制本端的网络速率。在该控速模式下，可将发送窗口赋值为最大传输单元；并将调整后的拥塞窗口转换为延时发包操作对应的理论发包时延；按照理论发包时延和发送窗口对后续数据包执行延时发包操作，以控制本端的网络速率。在一可选实现方案中：理论发包时延=最大传输单元/（拥塞窗口*网络带宽）。另外，实际应用中，可在第一通信端10中部署定时器以用于支持延时发包操作。基于定时器，第一通信端10可按照理论发包时延配置定时器的触发时间，第一通信端10可在接收到确收数据包之后需要发送下一个数据包时，启动定时器，而定时器则可在启动后等待理论发包时延到达后，发出提醒，第一通信端10可按照提醒发出该下一个数据包，从而实现对该下一个数据包的延时发包操作。可以理解的，在基于延时发包的控速模式下，是将拥塞窗口转换为理论发包时延，以保证最大传输单元的正常通行。

本实施例中，对第一通信端10来说，在确定出发送窗口的窗口规格后，可采用慢启动等控速算法来计算出本端的网络速率，本实施例对基于发送窗口可应用的控速算法不做限定，也不再对算法的具体过程进行详解。

据此，本实施例中，可支持基于发送窗口和基于延时发包的两种控速模式，从而可根据调整后的拥塞窗口的窗口规格选择合适的控速模式，这样，对本端的网络速率的调控粒度更细致，能够实现更加精准的拥塞控制。

在上述或下述实施例中，第一通信端10可按照其与第二通信端20之间的网络时延，调整本端的拥塞窗口，进而实现前述实施例中的控速方案。本实施例中，可采用多种实现方式来执行调整拥塞窗口的操作。例如，一些常规的实现方式可以是：网络时延大于指定的时延阈值时，则对本端的拥塞窗口执行降窗处理；而在网络时延小于指定的时延阈值时，则对本端的拥塞窗口执行增窗处理。

但是，发明人在研究过程中发现，这些常规实现方式的拥塞窗口调整效果存在不足，尤其是降窗处理的情况下，经常出现过度降窗的问题，导致第一通信端10发生过度控速，浪费网络传输时间。

为此，本实施例中，第一通信端10可在网络时延大于指定的时延阈值的情况下，获取本端最近一次延时发包操作所对应的实际发包时延；若最近一次延时发包操作的发生时间与当前时间之间的时间间隔小于实际发包时延，则以窗口规格不小于本端支持的最大传输单元为目标，调整本端的拥塞窗口；按照调整后的拥塞窗口，确定本端的网络速率，以对后续数据包进行拥塞控制；其中，参考前文中的实施例，延时发包操作是在本端的历史拥塞窗口的窗口规格小于最大传输单元的情况下被触发的。应当理解的是，最近一次延时发包操作可能发生在确收数据包之前的第N个数据包的发送过程中，其中，N可以是任意正整数，也即是第一通信端10在发送该第N个数据包是的拥塞窗口小于最大传输单元所以触发了延时发包操作，该第N个数据包和前述的确收数据包之间的那些数据包则采用的是基于发送窗口的控速模式，也即是，在那些数据包发送期间第一通信端10的拥塞窗口均未低于最大传输单元。

其中，本实施例中的实际发包时延是指最近一次延时发包操作过程中实际的发包等待时长。这里会存在两种情况：一种是基于延时发包的控速模式（例如前述的定时器）正常的情况，这种情况下，实际发包时延通常等于理论发包时延；另一种是基于延时发包的控速模式（例如前述的定时器）异常的情况，这种情况下，实际发包时延通常远大于理论发包时延，例如，定时器过忙的情况下，会造成定时器无法按照理论发包时延来发出发包提醒，从而导致实际发包时延很长，理论发包时延为5微秒时，实际发包时延可能是100毫秒。实际应用中，若基于延时发包的控速模式存在异常，实际发包时延与理论发包时延之间的差距通常是指数级别甚至更高，差距非常大。

这样，本实施例中，在调整拥塞窗口的过程中，增加基于实际发包时延的时间判断，可在基于延时发包的控速模式存在异常的情况下，在相当长的一段时间内尽量避免调用基于延时发包的控速模式（承接上文示例，也即是可尽量避免调用定时器）。这是由于，基于延时发包的控速模式存在异常的情况下，实际发包时延将比较长，这样，在最近一次延时发包操作之后的相当长一段时间内，上述的判断结果均会是“最近一次延时发包操作的发生时间与当前时间之间的时间间隔小于实际发包时延”，这样，在相当长的一段时间内，第一通信端10的拥塞窗口将不会被调整到最大传输单元以下，从而可避免调起基于延时发包的控速模式。

本实施例中，在以窗口规格不小于本端支持的最大传输单元为目标，调整本端的拥塞窗口的过程中：第一通信端10可按照预置的乘性降窗逻辑计算对本端当前的拥塞窗口进行乘性降窗后的窗口规格；若计算出的窗口规格小于或等于最大传输单元，则将拥塞窗口赋值为最大传输单元，以获得调整后的拥塞窗口；若计算出的窗口规格大于最大传输单元，则对当前的拥塞窗口执行乘性降窗处理，以获得调整后的拥塞窗口。其中，乘性降窗逻辑可采用本领域中的常规逻辑，在此不再展开详述。这样，本实施例中，可提供两种拥塞窗口的降窗幅度：一种是乘性降窗；另一种是降至最大传输单元（小于乘性降窗的降窗幅度）。基于此，可根据现有的拥塞窗口的窗口规格选择合适的降窗幅度，而乘性降窗的频率也可得到合理地控制。

本实施例中，若最近一次延时发包操作的发生时间与当前时间之间的时间间隔大于实际发包时延，则说明基于延时发包的控速模式正常或者基于延时发包的控速模式异常情况下第一通信端10已经很长一段时间未调用基于延时发包的控速模式，因此，这种判断结果下，可允许对拥塞窗口进行乘性降窗处理，以获得调整后的拥塞窗口。也即是，这种判断结果下，可允许对拥塞窗口进行正常降窗。应当理解的是，这种情况下，乘性降窗处理可能导致第一通信端10的拥塞窗口降至最大传输单元以下，从而触发基于延时发包的控速模式，但这种情况下的基于延时发包的控速模式处于正常状态或者即便处于异常状态但也已经很长时间未被调用，也即有可能异常状态早已缓解，因此，基于延时发包的控速模式可正常支持拥塞控制。

另外，本实施例中，在拥塞窗口的调整过程中，除了可进行如上的基于实际发包时延的判断逻辑之外，还可在此之前判断降窗间隔是否大于网络时延，如果是，则执行前述的基于实际发包时延的判断逻辑；而如果否，则可禁止本次对拥塞窗口的调整，以保证在网络时延内最多进行一次降窗处理。

本实施例中，若网络时延小于指定的时延阈值，则第一通信端10可对拥塞窗口执行增窗操作。本实施例中，可提供乘性增窗模式和加性增窗模式，基于此，若现有的拥塞窗口的窗口规格小于慢启动阈值，则可采用乘性增窗模式；而若现有的拥塞窗口的窗口规格大于慢启动阈值，则可采用加性增窗模式。其中，慢启动阈值为本领域中的常规术语，在此不再进行解释，而乘性增窗和加性增窗也可采用本领域中的常规处理逻辑，在此也不再展开详述。

据此，本实施例中，可根据网络时延来确定对现有拥塞窗口的调整策略，而且，在确定对现有拥塞窗口执行降窗处理的情况下，可基于最近一次延时发包操作对应的实际发包时延来及时发现基于延时发包的控速模式是否存在异常，从而更加合理地控制乘性降窗操作的频率，以及合理确定对现有拥塞窗口的降窗幅度，这可有效保证拥塞窗口调整方案的健壮性，进而减少发生异常的基于延时发包的控速模式对拥塞控制效果的影响。

图3为本申请另一示例性实施例提供的一种网络拥塞控制方法的流程示意图。参考图3，该方法可包括：

步骤300、接收对端针对本端发送的目标数据包而返回的确收数据包，确收数据包中包含的对端发送时间和目标数据包的被接收时间记录，采用硬件时间；

步骤301、获取本端接收确收数据包时的硬件时间，作为确收数据包对应的本端接收时间；

步骤302、获取本端发送目标数据包时的硬件时间，作为目标数据包的发送时间记录

步骤303、根据确收数据包对应的本端接收时间和对端发送时间以及目标数据包的发送时间记录和被接收时间记录，计算本端与对端之间的网络时延；

步骤304、基于网络时延，调整本端的网络速率，以对后续数据包进行拥塞控制。

本实施例提供的网络拥塞控制方法可应用于图1所示通信系统中的任意通信端。通信端中可装配有通信硬件，例如网卡等。基于此，在一可选实施例中，步骤301可包括：在接收到确收数据包的情况下，利用通信硬件将当前硬件时间写入确收数据包，作为本端接收时间。

在一可选实施例中，确收数据包中的其它硬件时间的写入方案可以是：

在向对端发送目标数据包过程中，利用通信硬件将目标数据包经过通信硬件时的硬件时间写入目标数据包中，以供对端将硬件时间作为目标数据包的发送时间记录而写入确收数据包中；

其中，由对端将接收到目标数据包时的硬件时间写入确收数据包中作为目标数据包的被接收时间记录；将发送确收数据包时的硬件时间写入确收数据包中作为对端发送时间。

在一可选实施例中，计算本端与对端之间的网络时延的方案，可以是：

计算对端发送时间与目标数据包的被接收时间记录之间的差值，作为对端处理时间；

计算本端接收时间与目标数据包的发送时间记录之间的差值，作为本端等待时间；

将本端等待时间与对端处理时间之间的差值，作为本端与对端之间的网络时延。

图4为本申请另一示例性实施例提供的一种基于调整后的拥塞窗口进行网络速率控制过程的逻辑示意图。其中，调整后的拥塞窗口的产生方案将在后文中详述。参考图4，在基于调整后的拥塞窗口进行网络速率控制过程中，可包括：

步骤401，判断调整后的拥塞窗口是否小于最大传输单元。是则执行步骤402，也即采用基于延时发包的控速模式，否则执行步骤405，也即采用基于发送窗口的控速模式。

步骤402：将调整后的拥塞窗口转换为延时发包操作对应的理论发包时延，并可记录到拥塞窗口的本地状态。可选地，理论发包时延 = 最大传输单元 / （拥塞窗口 * 网络带宽）。

步骤403：按照理论发包时延和发送窗口对后续数据包执行延时发包操作，以控制本端的网络速率。在一可选实现方案中：可在本端中部署定时器以用于支持延时发包操作。基于定时器，可按照理论发包时延配置定时器的触发时间。并可将发送窗口赋值为最大传输单元。

步骤404：在接收到确收数据包之后需要发送下一个数据包时，启动定时器，而定时器则可在启动后等待理论发包时延到达后，发出提醒，这样，本端可按照提醒发出该下一个数据包，从而实现对该下一个数据包的延时发包操作。可以理解的，在基于延时发包的控速模式下，是将拥塞窗口转换为理论发包时延，以保证最大传输单元的正常通行。还可记录定时器的实际触发时间，从而获得实际发包时延。

步骤405：使用调整后的拥塞窗口给发送窗口赋值。

步骤406：根据发送窗口（及理论发包时延）控制本端的网络速率。

在一可选实现方式中，调整拥塞窗口的过程，可包括：

在网络时延大于指定的时延阈值的情况下，获取本端最近一次延时发包操作所对应的实际发包时延；

若最近一次延时发包操作的发生时间与当前时间之间的时间间隔小于实际发包时延，则以窗口规格不小于本端支持的最大传输单元为目标，调整本端的拥塞窗口；

按照调整后的拥塞窗口，确定本端的网络速率，以对后续数据包进行拥塞控制；

其中，延时发包操作是在本端的历史拥塞窗口的窗口规格小于最大传输单元的情况下被触发的。

图5为本申请另一示例性实施例提供的一种拥塞窗口调整过程的逻辑示意图。参考图5，上述调整拥塞窗口的过程，可具体包括：

步骤501：计算延时阈值，本实施例对延时阈值的计算方式不做限定，例如可以根据网络跳步数、端到端时延的测量值、当前流的个数等来计算延时阈值。

步骤502：判断网络时延是否大于目标时延，是则执行步骤503，否则执行步骤509。

步骤503：判断降窗间隔是否大于网络时延，是则执行步骤504。降窗间隔可以是指上次降窗时刻到当前时刻之间的时间间隔；否则可禁止本次的拥塞窗口调整工作。

步骤504：判断最近一次延时发包操作的发生时间与当前时间之间的时间间隔是否大于最近一次延时发包操作对应的实际发包时延，是则执行步骤506，否则执行步骤505。

步骤505：按照预置的乘性降窗逻辑计算对本端当前的拥塞窗口进行乘性降窗后的窗口规格；若计算出的窗口规格小于或等于最大传输单元，则执行步骤507，否则执行步骤506。

步骤506：窗口乘性降低。

步骤507：使用最大传输单元给拥塞窗口赋值。

步骤508：使用拥塞窗口给慢启动阈值赋值。

步骤509：判断现有的拥塞窗口是否小于慢启动阈值，是则执行步骤510，否则执行步骤511。

步骤510：窗口乘性增长。

步骤511：窗口加性增长。

值得说明的是，上述关于网络拥塞控制方法的各实施例中的技术细节，可参考前述的系统实施例中关于第一通信端的相关描述，为节省篇幅，在此不再赘述，但这不应造成本申请保护范围的损失。

图6为本申请另一示例性实施例提供的另一种网络拥塞控制方法的流程示意图。参考图6，该方法可包括：

步骤600、在本端与对端之间的网络时延大于指定的时延阈值的情况下，获取本端最近一次延时发包操作所对应的实际发包时延；

步骤601、若最近一次延时发包操作的发生时间与当前时间之间的时间间隔小于实际发包时延，则以窗口规格不小于本端支持的最大传输单元为目标，调整本端的拥塞窗口；

步骤602、按照调整后的拥塞窗口，确定本端的网络速率，以对本端进行拥塞控制；

其中，延时发包操作是在本端的历史拥塞窗口的窗口规格小于最大传输单元的情况下被触发的。

本实施例提供的网络拥塞控制方法与图3相关的网络拥塞控制方法相比，区别在于，本实施例中的网络拥塞控制方法涉及到的网络时延并不局限于按照图3相关实施例中提供的网络时延计算方式来获得。本实施例中，还可采用其它计算方式来确定网络时延，例如，传统的按照系统时间来计算网络时延的方式等。

本实施例提供的网络拥塞控制方法，可根据网络时延来确定对现有拥塞窗口的调整策略，而且，在确定对现有拥塞窗口执行降窗处理的情况下，可基于最近一次延时发包操作对应的实际发包时延来及时发现基于延时发包的控速模式是否存在异常，从而更加合理地控制乘性降窗操作的频率，以及合理确定对现有拥塞窗口的降窗幅度，这可有效保证拥塞窗口调整方案的健壮性，进而减少发生异常的基于延时发包的控速模式对拥塞控制效果的影响。

在一可选实施例中，步骤以窗口规格不小于本端支持的最大传输单元为目标，调整本端的拥塞窗口，可包括：

按照预置的乘性降窗逻辑计算对本端当前的拥塞窗口进行乘性降窗后的窗口规格；

若计算出的窗口规格小于或等于最大传输单元，则将拥塞窗口赋值为最大传输单元，以获得调整后的拥塞窗口；

若计算出的窗口规格大于最大传输单元，则对当前的拥塞窗口执行乘性降窗处理，以获得调整后的拥塞窗口。

在一可选实施例中，该方法还可包括：

若最近一次延时发包操作的发生时间与当前时间之间的时间间隔大于实际发包时延，则对本端当前的拥塞窗口执行乘性降窗处理，以获得调整后的拥塞窗口。

在一可选实施例中，步骤按照调整后的拥塞窗口，确定本端的网络速率，可包括：

若调整后的拥塞窗口的窗口规格大于最大传输单元，则将本端的发送窗口赋值为调整后的拥塞窗口；基于发送窗口控制本端的网络速率；

若调整后的拥塞窗口的窗口规格小于最大传输单元，则将本端的发送窗口赋值为最大传输单元，并将调整后的拥塞窗口转换为延时发包操作对应的理论发包时延；按照理论发包时延和发送窗口对后续数据包执行延时发包操作，以控制本端的网络速率；

其中，采用定时器实施延时发包操作，且在定时器存在异常的情况下，实际发包时延大于理论发包时延。

值得说明的是，上述关于网络拥塞控制方法的各实施例中的技术细节，可参考前述的系统实施例中关于第一通信端的相关描述以及图3相关实施例中的相关描述，为节省篇幅，在此不再赘述，但这不应造成本申请保护范围的损失。

图7为本申请又一示例性实施例提供的一种网络时延的确定方法的流程示意图。参考图7，该方法可包括：

步骤700、接收对端针对本端发送的目标数据包而返回的确收数据包，确收数据包中包含的对端发送时间和目标数据包的被接收时间记录，采用硬件时间；

步骤701、获取本端接收确收数据包时的硬件时间，作为确收数据包对应的本端接收时间；

步骤702、获取本端发送目标数据包时的硬件时间，作为目标数据包的发送时间记录；

步骤703、根据确收数据包对应的本端接收时间和对端发送时间以及目标数据包的发送时间记录和被接收时间记录，计算本端与对端之间的网络时延。

本实施例提供的网络时延的确定方法，可采用硬件时间来记录单次通信往返中目标数据包和其对应的确收数据包各自所经历的发送时间和接收时间，并将这些硬件时间写入确收数据包中，这样，可根据确收数据包中携带的各个硬件时间计算网络时延。本实施例中，基于硬件时间计算网络时延，可有效提高网络时延的准确性。与前述实施例相比，本实施例中计算获得的网络时延并不局限用于网络拥塞控制这一种场景，本实施例获得的网络时延还可用于其它场景，例如，故障监测等。

在一可选实施例中，步骤701可包括：

在接收到确收数据包的情况下，利用本端的通信硬件将当前硬件时间写入确收数据包，作为本端接收时间。

在一可选实施例中，该方法还可包括：

在向对端发送目标数据包过程中，利用通信硬件将目标数据包经过通信硬件时的硬件时间写入目标数据包中，以供对端将硬件时间作为目标数据包的发送时间记录而写入确收数据包中；

其中，由对端将接收到目标数据包时的硬件时间写入确收数据包中作为目标数据包的被接收时间记录；将发送确收数据包时的硬件时间写入确收数据包中作为对端发送时间。

在一可选实施例中，步骤计算本端与对端之间的网络时延，可包括：

计算对端发送时间与目标数据包的被接收时间记录之间的差值，作为对端处理时间；

计算本端接收时间与目标数据包的发送时间记录之间的差值，作为本端等待时间；

将本端等待时间与对端处理时间之间的差值，作为本端与对端之间的网络时延。

值得说明的是，上述关于网络时延确定方法的各实施例中的技术细节，可参考前述的系统实施例中关于第一通信端计算网络时延过程的相关描述，为节省篇幅，在此不再赘述，但这不应造成本申请保护范围的损失。

需要说明的是，在上述实施例及附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如501、502等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的应用端、消息等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

图8为本申请又一示例性实施例提供的一种通信端的结构示意图。如图8所示，该计通信端包括：存储器80、处理器81以及通信硬件82。

处理器81，与存储器80及通信硬件82耦合，用于执行存储器80中的计算机程序，以用于：

通过通信硬件82接收对端针对本端发送的目标数据包而返回的确收数据包，确收数据包中包含的对端发送时间和目标数据包的被接收时间记录，采用硬件时间；

获取本端接收确收数据包时的硬件时间，作为确收数据包对应的本端接收时间；

获取本端发送目标数据包时的硬件时间，作为目标数据包的发送时间记录；

根据确收数据包对应的本端接收时间和对端发送时间以及、目标数据包的发送时间记录和被接收时间记录，计算本端与对端之间的网络时延；

基于网络时延，调整本端的网络速率，以对后续数据包进行拥塞控制。

在一可选实施例中，处理器81具体可用于：

在接收到确收数据包的情况下，利用通信硬件将当前硬件时间写入确收数据包，作为本端接收时间。

在一可选实施例中，处理器81还可用于：

在向对端发送目标数据包过程中，利用通信硬件将目标数据包经过通信硬件时的硬件时间写入目标数据包中，以供对端将硬件时间作为目标数据包的发送时间记录而写入确收数据包中；

其中，由对端将接收到目标数据包时的硬件时间写入确收数据包中作为目标数据包的被接收时间记录；将发送确收数据包时的硬件时间写入确收数据包中作为对端发送时间。

在一可选实施例中，处理器81在计算本端与对端之间的网络时延过程中，可用于：

计算对端发送时间与目标数据包的被接收时间记录之间的差值，作为对端处理时间；

计算本端接收时间与目标数据包的发送时间记录之间的差值，作为本端等待时间；

将本端等待时间与对端处理时间之间的差值，作为本端与对端之间的网络时延。

在一可选实施例中，处理器81在基于网络时延，调整本端的网络速率，以对后续数据包进行拥塞控制过程中，可用于：

在网络时延大于指定的时延阈值的情况下，获取本端最近一次延时发包操作所对应的实际发包时延；

若最近一次延时发包操作的发生时间与当前时间之间的时间间隔小于实际发包时延，则以窗口规格不小于本端支持的最大传输单元为目标，调整本端的拥塞窗口；

按照调整后的拥塞窗口，确定本端的网络速率，以对后续数据包进行拥塞控制；

其中，延时发包操作是在本端的历史拥塞窗口的窗口规格小于最大传输单元的情况下被触发的。

在一可选实施例中，处理器81在以窗口规格不小于本端支持的最大传输单元为目标，调整本端的拥塞窗口过程中，可用于：

按照预置的乘性降窗逻辑计算对本端当前的拥塞窗口进行乘性降窗后的窗口规格；

若计算出的窗口规格小于或等于最大传输单元，则将拥塞窗口赋值为最大传输单元，以获得调整后的拥塞窗口；

若计算出的窗口规格大于最大传输单元，则对当前的拥塞窗口执行乘性降窗处理，以获得调整后的拥塞窗口。

在一可选实施例中，处理器81还可用于：

若最近一次延时发包操作的发生时间与当前时间之间的时间间隔大于实际发包时延，则对本端当前的拥塞窗口执行乘性降窗处理，以获得调整后的拥塞窗口。

在一可选实施例中，处理器81在按照调整后的拥塞窗口，确定本端的网络速率的过程中，可用于：

若调整后的拥塞窗口的窗口规格大于最大传输单元，则将本端的发送窗口赋值为调整后的拥塞窗口；基于发送窗口控制本端的网络速率；

若调整后的拥塞窗口的窗口规格小于最大传输单元，则将本端的发送窗口赋值为最大传输单元，并将调整后的拥塞窗口转换为延时发包操作对应的理论发包时延；按照理论发包时延和发送窗口对后续数据包执行延时发包操作，以控制本端的网络速率；

其中，采用定时器实施延时发包操作，且在定时器存在异常的情况下，实际发包时延大于理论发包时延。

值得说明的是，上述关于通信端的各实施例中的技术细节，可参考前述的系统实施例中关于第一通信端的相关描述，为节省篇幅，在此不再赘述，但这不应造成本申请保护范围的损失。

在另一种可能的设计方案中，基于图8所示的通信端的结构，通信端还可用于执行图6相关的网络拥塞控制逻辑。这种情况下，处理器81可用于：

在本端与对端之间的网络时延大于指定的时延阈值的情况下，获取本端最近一次延时发包操作所对应的实际发包时延；

若最近一次延时发包操作的发生时间与当前时间之间的时间间隔小于实际发包时延，则以窗口规格不小于本端支持的最大传输单元为目标，调整本端的拥塞窗口；

按照调整后的拥塞窗口，确定本端的网络速率，以对本端进行拥塞控制；

其中，延时发包操作是在本端的历史拥塞窗口的窗口规格小于最大传输单元的情况下被触发的。其中，网络时延并不限于根据硬件时间来计算获得。

在一可选实施例中，处理器81在以窗口规格不小于本端支持的最大传输单元为目标，调整本端的拥塞窗口过程中，可用于：

按照预置的乘性降窗逻辑计算对本端当前的拥塞窗口进行乘性降窗后的窗口规格；

若计算出的窗口规格小于或等于最大传输单元，则将拥塞窗口赋值为最大传输单元，以获得调整后的拥塞窗口；

若计算出的窗口规格大于最大传输单元，则对当前的拥塞窗口执行乘性降窗处理，以获得调整后的拥塞窗口。

在一可选实施例中，处理器81还可用于：

若最近一次延时发包操作的发生时间与当前时间之间的时间间隔大于实际发包时延，则对本端当前的拥塞窗口执行乘性降窗处理，以获得调整后的拥塞窗口。

在一可选实施例中，处理器81在按照调整后的拥塞窗口，确定本端的网络速率的过程中，可用于：

若调整后的拥塞窗口的窗口规格大于最大传输单元，则将本端的发送窗口赋值为调整后的拥塞窗口；基于发送窗口控制本端的网络速率；

若调整后的拥塞窗口的窗口规格小于最大传输单元，则将本端的发送窗口赋值为最大传输单元，并将调整后的拥塞窗口转换为延时发包操作对应的理论发包时延；按照理论发包时延和发送窗口对后续数据包执行延时发包操作，以控制本端的网络速率；

其中，采用定时器实施延时发包操作，且在定时器存在异常的情况下，实际发包时延大于理论发包时延。

值得说明的是，该种可能的设计方案中，关于通信端的各实施例中的技术细节，可参考前述的图6相关方法实施例中的描述，为节省篇幅，在此不再赘述，但这不应造成本申请保护范围的损失。

在又一种可能的设计方案中，基于图8所示的通信端的结构，通信端还可用于执行图7相关的网络时延确定逻辑。这种情况下，处理器81可用于：

通过通信硬件82接收对端针对本端发送的目标数据包而返回的确收数据包，确收数据包中包含的对端发送时间和目标数据包的被接收时间记录，采用硬件时间；

获取本端接收确收数据包时的硬件时间，作为确收数据包对应的本端接收时间；

获取本端发送目标数据包时的硬件时间，作为目标数据包的发送时间记录；

根据确收数据包对应的本端接收时间和对端发送时间以及、目标数据包的发送时间记录和被接收时间记录，计算本端与对端之间的网络时延。

在一可选实施例中，处理器81具体可用于：

在接收到确收数据包的情况下，利用本端的通信硬件将当前硬件时间写入确收数据包，作为本端接收时间。

在一可选实施例中，处理器81还可用于：

在向对端发送目标数据包过程中，利用通信硬件将目标数据包经过通信硬件时的硬件时间写入目标数据包中，以供对端将硬件时间作为目标数据包的发送时间记录而写入确收数据包中；

其中，由对端将接收到目标数据包时的硬件时间写入确收数据包中作为目标数据包的被接收时间记录；将发送确收数据包时的硬件时间写入确收数据包中作为对端发送时间。

在一可选实施例中，处理器81在计算本端与对端之间的网络时延的过程中，可用于：

计算对端发送时间与目标数据包的被接收时间记录之间的差值，作为对端处理时间；

计算本端接收时间与目标数据包的发送时间记录之间的差值，作为本端等待时间；

将本端等待时间与对端处理时间之间的差值，作为本端与对端之间的网络时延。

值得说明的是，该种可能的设计方案中，关于通信端的各实施例中的技术细节，可参考前述的图7相关方法实施例中的描述，为节省篇幅，在此不再赘述，但这不应造成本申请保护范围的损失。

进一步，如图8所示，该通信端还包括：电源组件83等其它组件。图8中仅示意性给出部分组件，并不意味着通信端只包括图8所示组件。

相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被执行时能够实现上述方法实施例中可由通信端执行的各步骤。

上述图8中的存储器，用于存储计算机程序，并可被配置为存储其它各种数据以支持在计算平台上的操作。这些数据的示例包括用于在计算平台上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器（SRAM），电可擦除可编程只读存储器（EEPROM），可擦除可编程只读存储器（EPROM），可编程只读存储器（PROM），只读存储器（ROM），磁存储器，快闪存储器，磁盘或光盘。

上述图8中的通信硬件，可被配置为便于通信端和对端之间有线或无线方式的通信。通信端可以接入基于通信标准的无线网络，如WiFi，2G、3G、4G/LTE、5G等移动通信网络，或它们的组合。在一个示例性实施例中，通信硬件经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信硬件还包括近场通信（NFC）模块，以促进短程通信。例如，在NFC模块可基于射频识别（RFID）技术，红外数据协会（IrDA）技术，超宽带（UWB）技术，蓝牙（BT）技术和其他技术来实现。

上述图8中的电源组件，为电源组件所在设备的各种组件提供电力。电源组件可以包括电源管理系统，一个或多个电源，及其他与为电源组件所在设备生成、管理和分配电力相关联的组件。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备（系统）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器 (CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器 (RAM) 和/或非易失性内存等形式，如只读存储器 (ROM) 或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存 (PRAM)、静态随机存取存储器 (SRAM)、动态随机存取存储器 (DRAM)、其他类型的随机存取存储器 (RAM)、只读存储器 (ROM)、电可擦除可编程只读存储器 (EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘 (DVD) 或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体 (transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (11)

1.一种网络拥塞控制方法，包括：

接收对端针对本端发送的目标数据包而返回的确收数据包，所述确收数据包中包含的对端发送时间和所述目标数据包的被接收时间记录，采用硬件时间；

获取本端接收所述确收数据包时的硬件时间，作为所述确收数据包对应的本端接收时间；

获取本端发送所述目标数据包时的硬件时间，作为所述目标数据包的发送时间记录；

根据所述确收数据包对应的本端接收时间和对端发送时间以及所述目标数据包的发送时间记录和被接收时间记录，计算本端与对端之间的网络时延；

基于所述网络时延，调整本端的网络速率，以对后续数据包进行拥塞控制；

其中，所述基于所述网络时延，调整本端的网络速率，以对后续数据包进行拥塞控制，包括：

在所述网络时延大于指定的时延阈值的情况下，获取本端最近一次延时发包操作所对应的实际发包时延；

若所述最近一次延时发包操作的发生时间与当前时间之间的时间间隔小于所述实际发包时延，则以窗口规格不小于本端支持的最大传输单元为目标，调整本端的拥塞窗口；

按照调整后的拥塞窗口，确定本端的网络速率，以对所述后续数据包进行拥塞控制；

其中，所述延时发包操作是在本端的历史拥塞窗口的窗口规格小于所述最大传输单元的情况下被触发的。

2.根据权利要求1所述的方法，所述获取本端接收所述确收数据包时的硬件时间，作为所述确收数据包对应的本端接收时间，包括：

在接收到所述确收数据包的情况下，利用本端的通信硬件将当前硬件时间写入所述确收数据包，以获得所述本端接收时间；

所述获取本端发送所述目标数据包时的硬件时间，作为所述目标数据包的发送时间记录，包括：

从所述确收数据包中读取所述目标数据包的发送时间记录。

3.根据权利要求2所述的方法，还包括：

在向对端发送所述目标数据包过程中，利用本端的通信硬件将所述目标数据包经过所述通信硬件时的硬件时间写入所述目标数据包中，以供对端将所述硬件时间作为所述目标数据包的发送时间记录而写入所述确收数据包中；

其中，由对端将接收到所述目标数据包时的硬件时间写入所述确收数据包中作为所述目标数据包的被接收时间记录；将发送所述确收数据包时的硬件时间写入所述确收数据包中作为所述对端发送时间。

4.根据权利要求1所述的方法，所述计算本端与对端之间的网络时延，包括：

计算所述对端发送时间与所述目标数据包的被接收时间记录之间的差值，作为对端处理时间；

计算所述本端接收时间与所述目标数据包的发送时间记录之间的差值，作为本端等待时间；

将所述本端等待时间与对端处理时间之间的差值，作为本端与对端之间的网络时延。

5.根据权利要求1所述的方法，所述以窗口规格不小于本端支持的最大传输单元为目标，调整本端的拥塞窗口，包括：

按照预置的乘性降窗逻辑计算对本端当前的拥塞窗口进行乘性降窗后的窗口规格；

若计算出的窗口规格小于或等于所述最大传输单元，则将所述拥塞窗口赋值为所述最大传输单元，以获得所述调整后的拥塞窗口；

若计算出的窗口规格大于所述最大传输单元，则对当前的拥塞窗口执行乘性降窗处理，以获得所述调整后的拥塞窗口。

6.根据权利要求1所述的方法，还包括：

若所述最近一次延时发包操作的发生时间与当前时间之间的时间间隔大于所述实际发包时延，则对本端当前的拥塞窗口执行乘性降窗处理，以获得所述调整后的拥塞窗口。

7.根据权利要求6所述的方法，所述按照调整后的拥塞窗口，确定本端的网络速率，包括：

若所述调整后的拥塞窗口的窗口规格大于所述最大传输单元，则将本端的发送窗口赋值为所述调整后的拥塞窗口；基于所述发送窗口控制本端的网络速率；

若所述调整后的拥塞窗口的窗口规格小于所述最大传输单元，则将本端的发送窗口赋值为所述最大传输单元，并将所述调整后的拥塞窗口转换为延时发包操作对应的理论发包时延；按照所述理论发包时延和所述发送窗口对所述后续数据包执行延时发包操作，以控制本端的网络速率；

其中，采用定时器实施所述延时发包操作，且在所述定时器存在异常的情况下，所述实际发包时延大于所述理论发包时延。

8.一种网络拥塞控制方法，包括：

在本端与对端之间的网络时延大于指定的时延阈值的情况下，获取本端最近一次延时发包操作所对应的实际发包时延；

若所述最近一次延时发包操作的发生时间与当前时间之间的时间间隔小于所述实际发包时延，则以窗口规格不小于本端支持的最大传输单元为目标，调整本端的拥塞窗口；

按照调整后的拥塞窗口，确定本端的网络速率，以对本端进行拥塞控制；

其中，所述延时发包操作是在本端的历史拥塞窗口的窗口规格小于所述最大传输单元的情况下被触发的。

9.根据权利要求8所述的方法，所述以窗口规格不小于本端支持的最大传输单元为目标，调整本端的拥塞窗口，包括：

按照预置的乘性降窗逻辑计算对本端当前的拥塞窗口进行乘性降窗后的窗口规格；

若计算出的窗口规格小于或等于所述最大传输单元，则将所述拥塞窗口赋值为所述最大传输单元，以获得所述调整后的拥塞窗口；

若计算出的窗口规格大于所述最大传输单元，则对当前的拥塞窗口执行乘性降窗处理，以获得所述调整后的拥塞窗口。

10.一种通信端，包括存储器、处理器和通信组件；

所述存储器用于存储一条或多条计算机指令；

所述处理器与所述存储器和所述通信组件耦合，用于执行所述一条或多条计算机指令，以用于：

通过所述通信组件接收对端针对本端发送的目标数据包而返回的确收数据包，所述确收数据包中包含的对端发送时间和所述目标数据包的被接收时间记录，采用硬件时间；

获取本端接收所述确收数据包时的硬件时间，作为所述确收数据包对应的本端接收时间；

获取本端发送所述目标数据包时的硬件时间，作为所述目标数据包的发送时间记录；

根据所述确收数据包对应的本端接收时间和对端发送时间以及所述目标数据包的发送时间记录和被接收时间记录，计算本端与对端之间的网络时延；

基于所述网络时延，调整本端的网络速率，以对后续数据包进行拥塞控制；

其中，所述基于所述网络时延，调整本端的网络速率，以对后续数据包进行拥塞控制，包括：

在所述网络时延大于指定的时延阈值的情况下，获取本端最近一次延时发包操作所对应的实际发包时延；

若所述最近一次延时发包操作的发生时间与当前时间之间的时间间隔小于所述实际发包时延，则以窗口规格不小于本端支持的最大传输单元为目标，调整本端的拥塞窗口；

按照调整后的拥塞窗口，确定本端的网络速率，以对所述后续数据包进行拥塞控制；

其中，所述延时发包操作是在本端的历史拥塞窗口的窗口规格小于所述最大传输单元的情况下被触发的。

11.一种通信端，包括存储器、处理器和通信组件；

所述存储器用于存储一条或多条计算机指令；

所述处理器与所述存储器和所述通信组件耦合，用于执行所述一条或多条计算机指令，以用于：

在本端与对端之间的网络时延大于指定的时延阈值的情况下，获取本端最近一次延时发包操作所对应的实际发包时延；

若所述最近一次延时发包操作的发生时间与当前时间之间的时间间隔小于所述实际发包时延，则以窗口规格不小于本端支持的最大传输单元为目标，调整本端的拥塞窗口；

按照调整后的拥塞窗口，确定本端的网络速率，以对本端进行拥塞控制；

其中，所述延时发包操作是在本端的历史拥塞窗口的窗口规格小于所述最大传输单元的情况下被触发的。

Images