CN115987895A - 拥塞确定方法及装置 - Google Patents

Abstract

本申请提供拥塞确定方法及装置，其中所述拥塞确定方法包括：接收客户端回复的确认数据包；基于所述确认数据包的确认包信息以及与所述客户端关联的通信信息，确定往返时延信息；将所述往返时延信息与预设拥塞条件进行比对，并根据比对结果确定与所述客户端之间的通信链路的链路状态。实现了基于往返时延信息对通信链路进行拥塞判断，提高了拥塞判断的准确性。

Description

拥塞确定方法及装置

技术领域

本申请涉及通信技术领域，特别涉及拥塞确定方法。本申请同时涉及拥塞确定装置，一种计算设备，以及一种计算机可读存储介质。

背景技术

在网络队列中，其容量往往存在上限，若是对网络注入过多的数据则会导致网络产生拥塞，轻则出现较高的延迟，重则会出现丢包导致了带宽的浪费。在BBR算法之前，拥塞算法对网络拥塞的判断多是基于丢包，如CUBIC等传统的拥塞控制算法。但是在真实的网络链路中，丢包的出现不仅仅由网络拥塞导致，也可能是因为机器硬件等其他原因导致的，也就是说基于丢包进行网络拥塞判断通常不准确，因此，亟需提供一种解决上述问题的方案。

发明内容

有鉴于此，本申请实施例提供了拥塞确定方法。本申请同时涉及拥塞确定装置，一种计算设备，以及一种计算机可读存储介质，以解决现有技术中存在的拥塞判断不准确的问题。

根据本申请实施例的第一方面，提供了一种拥塞确定方法，包括：

接收客户端回复的确认数据包；

基于所述确认数据包的确认包信息以及与所述客户端关联的通信信息，确定往返时延信息；

将所述往返时延信息与预设拥塞条件进行比对，并根据比对结果确定与所述客户端之间的通信链路的链路状态。

根据本申请实施例的第二方面，提供了一种拥塞确定装置，包括：

接收模块，被配置为接收客户端回复的确认数据包；

确定模块，被配置为基于所述确认数据包的确认包信息以及与所述客户端关联的通信信息，确定往返时延信息；

比对模块，被配置为将所述往返时延信息与预设拥塞条件进行比对，并根据比对结果确定与所述客户端之间的通信链路的链路状态。

根据本申请实施例的第三方面，提供了一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行所述计算机指令时实现所述拥塞确定方法的步骤。

根据本申请实施例的第四方面，提供了一种计算机可读存储介质，其存储有计算机指令，该计算机指令被处理器执行时实现所述拥塞确定方法的步骤。

本申请提供的拥塞确定方法，为了提高确定通信链路是否处于拥塞状态的效率以及准确率，通过接收客户端针对通信数据包回复的确认数据包，并基于确认数据包的确认包信息以及与客户端关联的通信信息，确定往返时延信息，并将往返时延信息与预设拥塞条件进行比对，实现了基于往返时延信息进行拥塞判断，并在根据比对结果确定与客户端之间的通信链路的链路状态，提高了判断通信链路的链路状态的准确性。

附图说明

图1是本申请一实施例提供的一种拥塞确定方法的示意图；

图2是本申请一实施例提供的一种拥塞确定方法的流程图；

图3是本申请一实施例提供的一种拥塞确定方法中的拥塞判断流程图；

图4是本申请一实施例提供的一种拥塞确定方法的交互示意图；

图5是本申请一实施例提供的一种应用于BBRv2的拥塞确定方法的处理流程图；

图6是本申请一实施例提供的一种拥塞确定装置的结构示意图；

图7是本申请一实施例提供的一种计算设备的结构框图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

在本申请一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请一个或多个实施例。在本申请一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本申请一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

首先，对本申请一个或多个实施例涉及的名词术语进行解释。

ACK：(Acknowledgecharacter，确认字符)，在数据通信中，接收端发给发送端的一种传输类控制字符，用以表示发来的数据已确认接收无误。

QUIC(QuickUDPInternetConnection，快速UDP互联网连接)：是一种基于UDP的低时延的互联网传输层协议，标准化以后为HTTP/3.0协议。

RTT(RoundTripTime，往返时延)：它是在计算机网络中它是一个重要的性能指标，表示从发送端发送数据开始，到发送端收到来自接收端的确认(接收端收到数据后便立即发送确认)，总共经历的时延。

带宽时延积(bandwidth-delayproduct，BDP)：指的是一个数据链路的能力与来回通信延迟的乘积。

BBRv2：全称BottleneckBandwidthandRound-trippropagationtime(BBR)是在2016年开发的一种新型的TCP拥塞控制算法。它是一种对丢包判断依赖较低的算法，尤其适合在存在一定丢包率的弱网环境下使用。BBRv2是基于BBR技术上进行一个较大改进的版本，加入了较多对丢包的判断，而且在需要更高带宽的情况下，它更接近于成为Reno/CUBIC的完全替代品。

ProbeBw：为BBR类算法中的一个自循环状态，在快速探测阶段结束后，BBR类算法会进入ProbeBw状态进行一个自循环控速发包。

在本申请中，提供了拥塞确定方法，本申请同时涉及拥塞确定装置，一种计算设备，以及一种计算机可读存储介质，在下面的实施例中逐一进行详细说明。

参见图1所示的示意图，本申请提供的拥塞确定方法，为了提高确定通信链路是否处于拥塞状态的效率以及准确率，通过接收客户端针对通信数据包回复的确认数据包，并基于确认数据包的确认包信息以及与客户端关联的通信信息，确定往返时延信息，并将往返时延信息与预设拥塞条件进行比对，实现了基于往返时延信息进行拥塞判断，并在根据比对结果确定与客户端之间的通信链路的链路状态，提高了判断通信链路的链路状态的准确性。

图2示出了根据本申请一实施例提供的一种拥塞确认方法的流程图，所述拥塞确定方法应用于服务端，具体包括以下步骤：

步骤202：接收客户端回复的确认数据包。

具体的，客户端是指与服务端进行通信的应用程序(视频APP、直播APP等)或智能设备(比如：手机、平板电脑、笔记本电脑、台式机等)。该客户端可以理解为接收端，服务端可以理解为发送端。相应的，确认数据包，是指客户端针对接收的通信数据包所回复的ACK包。具体实施时，服务端向客户端发送通信数据包，客户端在接收到通信数据包后，向服务端回复该通信数据包对应的确认数据包。服务端接收到确定数据包表示客户端已经成功接收到对应的通信数据包。其中，通信数据包，是指服务端向客户端发送的数据包，该通信数据包中包含服务端和客户端的地址信息。通常在服务端和客户端进行通信时，单个消息被划分为多个通信数据包，这些通信数据包沿着不同的路径在一个或多个网络中传输，并且在客户端重新组合。

实际应用中，服务端和客户端作为通信协议的两端，二者进行通信时，为了保障通信的效率以及稳定性，需要尽量减少出现拥塞情况。具体的，拥塞是指到达通信子网中某一部分的通信数据包的数量过多，使得该部分网络来不及处理，以致引起这部分乃至整个网络性能下降的现象，严重时甚至会导致网络通信业务陷入停顿，即出现死锁现象。因此，为了减少拥塞时长，需要精准判断网络是否处于拥塞状态，并对处于拥塞状态的网络进行快速调控，从而尽快恢复正常通信。其中，通信协议可以QUIC协议，TCP协议等，在此不做限制。而拥塞控制算法是通信协议中很重要的算法，用于降低网络拥塞程度，本实施例中的拥塞确定方法用以对拥塞控制算法进行改进。

需要说明的是，本申请提供的拥塞确定方法的核心在于如何确定网络是否处于拥塞状态，针对于不同服务端，拥塞确定的过程基本相同，本实施例为方便描述，以视频服务端为例对本实施例进行说明，其他服务端的拥塞确定的过程均可参见本实施例相同或相应的描述内容，本实施例在此不作过多赘述。

比如：视频客户端接收到视频服务端发送的通信数据包81，则向视频服务端回复该通信数据包81对应的确认数据包81，视频服务端接收视频客户端回复的确认数据包81。

步骤204：基于所述确认数据包的确认包信息以及与所述客户端关联的通信信息，确定往返时延信息。

具体的，在上述接收到确认数据包的基础上，考虑到根据丢包信息对通信链路的拥塞情况进行判断会出现不准确的现象，本实施例中，确定通信过程中的往返时延信息，以便后续基于往返时延信息进行拥塞判断。

其中，通信链路是指一个连接两个或两个以上设备的传输介质中的信道，用以进行数据传输。确认包信息，是指确认数据包所携带信息。该确认包信息中可以包括：确认数据包对应的通信数据包的发送时间、该通信数据包包含的数据量、以及确认数据包的接收时间等信息。通信信息，是指服务端和客户端在通信过程中产生的信息。该通信信息可以包括此次接收确认数据包之前进行通信所累计获得的信息，和/或每次发送/接收数据包获得的信息的集合。往返时延信息，是指在服务端与客户端通信过程中产生的与往返时延相关的信息。比如，该往返时延信息，可以是最大往返时延、最小往返时延和/或当前往返时延等信息，在此不做限制。

实际应用中，由于传输数据量可以单独作为判断通信链路是否拥塞的判断依据，因此，为了减少判断拥塞所需的计算资源，可以先计算处于传输状态的通信数据包的传输数据量，并基于该传输数据量进行拥塞判断。本实施例中，在所述基于所述确认数据包的确认包信息以及与所述客户端关联的通信信息，确定往返时延信息之前，还包括：

基于所述确认包信息以及所述通信信息，计算向所述客户端发送的处于传输状态的通信数据包的传输数据量；

在所述传输数据量不满足传输量阈值的情况下，执行所述基于所述确认数据包的确认包信息以及与所述客户端关联的通信信息，确定往返时延信息。

其中，处于传输状态的通信数据包，是指服务端已发送但未收到客户端回复确定数据包的通信数据包。相应的，传输数据量，是指处于传输状态的通信数据包的数据量。比如：服务端向客户端发送了90个通信数据包。其中，有10个通信数据包未收到对应的确认数据包，则这10个通信数据包为处于传输状态的通信数据包，这10个通信数据包中包含的数据的数据量之和即为传输数据量。

传输量阈值，是指用以判断传输数据量是否可以致使传输链路发生拥塞的阈值。该传输量阈值可以预先根据经验值进行设置，也可以根据当前网络的实际情况获得，在此不做限制。若传输数据量不满足传输量阈值，表明该传输数据量较小，无法直接根据传输数据量确定通信链路是否拥塞，因此需要再基于往返时延信息进行拥塞判断，则根据确认包信息以及通信信息确定往返时延信息，并在往返时延信息的基础上，判断通信链路是否拥塞；若传输数据量满足传输量阈值，表明该传输数据量较大，可能直接导致通信链路拥塞，因此无需进行其他判断，则确定与客户端之间的通信链路处于拥塞状态。

具体实施时，计算该传输数据量的方式是多种多样的，本实施例中提供一种传输数据量的计算方式，所述基于所述确认数据包的确认包信息以及与所述客户端关联的通信信息，计算向所述客户端发送的处于传输状态的通信数据包的传输数据量，具体实现如下所示：

在所述确认包信息中提取当前确认数据量，并在所述通信信息中提取向所述客户端发送的通信数据包的总数据量以及所述总数据量对应的历史确认数据量；

根据所述总数据量、所述历史确认数据量以及所述当前确认数据量进行计算，获得所述传输数据量。

具体的，当前确认数据量，是指当前确认数据包对应的通信数据包中包含的数据的数据量。总数据量，是指服务端向客户端发送的通信数据包中包含的数据的总量。相应的，历史确认数据量，是指除当前确认数据量之外，收到确认数据包的通信数据包中包含的数据的数据量。

实际应用中，为了避免每次重新统计向客户端发送的通信数据包中包含的数据的数据量之和，可以每发送一个通信数据包之后，将该通信数据包对应的数据量与之前发送的数据量进行累加，作为总数据量进行记录。则在计算传输数据量时，无需重新计算该总数据量，而可以直接提取预先记载的总数据量。

沿用上例，在视频服务端接收视频客户端回复的确认数据包81的基础上，在该确认数据包81的确认包信息中提取当前确认数据量为ad个字节，并在通信信息中提取的向视频客户端发送的通信数据包中包含的数据的总数据量为D个字节，并且这D个字节中出当前确认数据量之外已经确认了AD个字节(即历史确认数据量为AD个字节)，则传输数据量为sd＝D-AD-ad。

综上，根据服务端已发送的总数据量、历史已经确认的数据量(历史确认数据量)以及当前确认数据量进行计算，获得传输数据量，保障了传输数据量计算的准确性。

除上述计算传输数据量的方式之外，为了进一步提高计算效率，可以在每次计算获得传输数据量之后，将计算的传输数据量作为历史传输数据量进行存储，则下次需要计算传输数据量时，直接在通信信息中提取该历史传输数据量，并在历史传输数据量的基础上进行计算即可。因此，本实施例提供第二种传输数据量的计算方式，所述基于所述确认数据包的确认包信息以及与所述客户端关联的通信信息，计算向所述客户端发送的处于传输状态的通信数据包的传输数据量，具体实现如下所示：

在所述确认包信息中提取当前确认数据量，并在所述通信信息中提取向所述客户端发送的处于传输状态的通信数据包的历史传输数据量；

根据所述历史传输数据量以及所述当前确认数据量进行计算，获得所述传输数据量。

具体的，历史传输数据量，是指在接收确认数据包之前，服务端所统计已发送但未被确认的数据量。在接收确认数据包之后，由于确认数据包中存在新确认的数据量，因此，需要在历史传输数据量中移除当前确认数据量，获得最新的传输数据量。此外，在获得传输数据量的基础上，将该传输数据量作为历史传数据量进行记录。

沿用上例，在视频服务端接收视频客户端回复的确认数据包81的基础上，在该确认数据包81的确认包信息中提取当前确认数据量为ad个字节，并在通信信息中提取的向视频客户端发送处于传输状态的通信数据包对应的历史传输数据量为hSD个字节，则传输数据量为sd＝hSD-ad。

综上，根据服务端发送处于传输状态的通信数据包对应的历史传输数据量，以及当前确认数量进行计算，获得传输数据量，提高了传输数据量的计算效率以及准确性。

具体实施时，考虑到网络状态瞬息万变，凭借经验设置的传输量阈值，可能导致对通信链路的拥塞判断并不准确，因此，为了进一步提高拥塞确定的准确性，本实施例中，所述根据所述确认包信息以及所述通信信息确定往返时延信息之前，还包括：

基于所述确认数据包的确认包信息以及与所述客户端关联的通信信息，计算所述通信链路对应的链路最大带宽以及链路最小往返时延；

基于所述链路最大带宽以及所述链路最小往返时延，计算带宽时延积；

将预设倍数的带宽时延积作为所述传输量阈值。

具体的，链路最大带宽，可以理解为对于服务端与客户端之间的通信链路的带宽所估算的最大值。链路最大带宽可以是在发速率和确认速率中选取最小值，其中，发送速率，可以通过发送的数据量除以发送时长(当前发送的最后一个通信数据包的发送时间和发送的第一个通信数据包的发送时间之间的总时长)进行计算。确认速率可以通过确认的数据量除以确认时长(当前发送的最后一个确认数据包的接收时间和接收的第一个确认数据包的接收时间之间的总时长)进行计算。

具体实施时，若计算的链路带宽小于接收该确认数据包之前记录的链路最大带宽，则将接收该确认数据包之前记录的链路最大带宽作为当前链路最大带宽。若计算的链路带宽大于或等于接收该确认数据包之前记录的链路最大带宽，则将计算的链路带宽作为链路最大带宽。

类似地，链路最小往返时延，是指服务端与客户端通信过程中所统计的相对较小的往返时延，即在已经接收的确认数据包统计的包级别的往返时延中选取较小的往返时延作为链路最小往返时延。具体实施时，若基于当前接收的确认数据包计算的往返时延小于接收该确认数据包之前记录的链路最小往返时延，则将当前计算的往返时延作为链路最小时延。若计算的往返时延大于或等于接收该确认数据包之前记录的链路最小往返时延，则将记录的链路最小往返时延作为当前链路最小往返时延。

需要说明的是，还可以设置时延过期时间(比如10秒，15秒等)，若时延过期时间内未对记录的链路最小往返时延进行更新，表示历史记录的链路最小往返时延可能已经失去可参考性，则可以在近期计算的往返时延中选取最小的往返时延作为链路最小往返时延，并以之替换记录的链路最小往返时延。

进一步的，将链路最大带宽以及链路最小往返时延进行乘积，获得带宽时延积，该带宽时延积表示通信链路中可以存放的最大容量。预设倍数，是指预先设置的倍数，该预设倍数可以是1.25，1.2，1.1等倍数，在此不做限制。由于带宽时延积表示通信链路的容量极限，因此将预设倍数的带宽时延积作为传输量阈值，可以用以衡量当前的传输数据量是否已经超过网络极限，若超过(即满足传输量阈值)，则表示通信链路处于拥塞状态；若不超过(即不满足传输量阈值)，则需要基于往返时延信息进一步进行拥塞判断。

比如：计算的链路最大带宽为Maxbw，计算的链路最小时延为MinRTT，则带宽时延积为BDP＝Maxbw*MinRTT。在预设倍数为1.25的情况下，传输量阈值为1.25*BDP。

综上，计算带宽时延积，并将预设倍数的带宽时延积作为传输量阈值，提升了判断传输数据量是否达到网络容量上限的准确性，并进一步提高了确定通信链路是否处于拥塞状态的准确性。

步骤206：将所述往返时延信息与预设拥塞条件进行比对，并根据比对结果确定与所述客户端之间的通信链路的链路状态。

具体的，在上述确定往返时延信息的基础上，由于往返时延信息的变化情况可以表明通信链路的拥塞情况，因此，将往返时延信息与预设拥塞条件进行比对，并根据比对结果，确定与客户端之间的通信链路的链路状态。

其中，预设拥塞条件，是指预先设置的用以对往返时延信息进行衡量，从而判断通信链路是否拥塞的条件。比如，该预设拥塞条件，可以是最大往返时延大于最大时延阈值、和/或最小往返时延大于最小时延阈值等条件，在此不做限制。链路状态，是指通信链路的拥塞状态或非拥塞状态。

基于此，若往返时延信息与判断拥塞状态的预设拥塞条件匹配，表明当前的通信链路已经趋于拥塞，则确定通信链路处于拥塞状态；若往返时延信息与判断非拥塞状态的预设拥塞条件匹配，表明当前的通信链路趋于良好，则可以确定通信链路处于非拥塞状态；此外，若往返时延信息与预设拥塞条件都不匹配，则维持接收确认数据包之前对通信链路的拥塞判断。

考虑到若基于通信过程中的全部确认数据包计算最大往返时延和最小往返时延，由于前期通信过程中的往返时延可能对于当前的网络状态失去了参考意义，因此，为了提高往返时延信息的准确性，本实施例中，所述根据所述确认包信息以及所述通信信息确定往返时延信息，具体实现如下所示：

根据所述确认包信息中的通信包发送时间以及确认包接收时间，计算所述确认数据包对应的目标通信数据包的往返时延；

在所述通信信息中提取预设通信包范围内的历史通信数据包的历史往返时延；

在所述往返时延以及所述预设通信包范围内的历史通信数据包的历史往返时延中，选取最大往返时延以及最小往返时延，将所述最大往返时延以及所述最小往返时延作为往返时延信息。

具体的，通信包发送时间，是指确认数据包对应的通信数据包对应的发送时间；确认包接收时间，是指接收确认数据包的时间。目标通信数据包，是指确认数据包对应的通信数据包。将确认包接收时间与通信包发送时间相减，即可获得目标通信数据包对应的往返时延。

预设通信包范围，是指预先设置的用以统计最大往返时延和最小往返时延的通信数据包的范围，比如从第71个通信数据包到第80个通信数据包之间的通信数据包(历史通信数据包)。其中，历史通信数据包是指服务端历史已发送的通信数据包。实际应用中，该预设通信包范围是可以一个顺次移动的窗口范围，比如在接收下一个确认数据包之后，该预设通信包范围变为从第72个通信数据包到第81个通信数据包之间的历史通信数据包。历史往返时延，是指预设通信包范围内的各个历史通信数据包对应的往返时延。

沿用上例，若传输数据量sd小于或等于1.25BDP，则在确认数据包81的确认包信息中提取通信包发送时间t1以及确认包接收时间t2，并根据二者计算通信数据包81对应的往返时延RTT＝t2-t1。在通信信息中提取第71个通信数据包到第80个通信数据包这10个通信数据包分别对应的10个历史往返时延。这10个历史往返时延分别为RTT1、RTT2、RTT3、……、RTT10，则在10个历史往返时延以及通信数据包81对应的往返时延RTT中选取数值最大的往返时延RTT10作为最大往返时延MaxRTT，并在10个历史往返时延以及通信数据包81对应的往返时延RTT中选取数值最小的往返时延RTT2作为最小往返时延MRTT。并将最大往返时延MaxRTT以及最小往返时延MRTT作为往返时延信息。

综上，在预设范围的通信数据包对应的往返时延中确定最大往返时延以及最小往返时延，保障了最大往返时延以及最小往返时延用以确定拥塞状态参考价值。

在上述确定最大往返时延和最小往返时延的基础上，考虑到仅对二者进行预设数值的比较无法满足网络状态变化的复杂场景，可能存在拥塞确定不准确的情况，因此，为了进一步提升拥塞判断的准确性，将所述往返时延信息与预设拥塞条件进行比对，并根据比对结果确定与所述客户端之间的通信链路的链路状态，具体实现如下所示：

判断所述往返时延信息中的所述最大往返时延是否小于或等于预先记录的历史最大往返时延，并判断所述往返时延信息中的所述最小往返时延是否大于预先记录的历史最小往返时延；

若判断结果均为是，确定与客户端之间的通信链路处于拥塞状态。

具体的，历史最大往返时延，是指接收当前确认数据包之前记录的最大往返时延。历史最小往返时延，是指接收当前确认数据包之前记录的最小往返时延。

基于此，将最大往返时延与历史最大往返时延进行比较，并将最小往返时延与历史最小往返时延进行比较，可以获得最大往返时延以及最小往返时延的变化趋势。进一步的，最大往返时延小于或等于历史最大往返时延，表示最大往返时延变小；最小往返时延大于历史最小往返时延，表示最小往返时延变大；若这两种趋势皆存在，表明通信链路趋近于拥塞，则确定与客户端之间的通信链路处于拥塞状态；若这两种趋势只存在任意一种或两种趋势都不存在，则无法表明通信链路趋于拥塞，不做处理即可。

沿用上例，在记录的历史最大往返时延为hMaxRTT，记录的历史最小往返时延为hMRTT的情况下，判断MaxRTT是否小于或等于hMaxRTT的判断结果为是，并且判断MRTT是否大于hMRTT的判断结果为是，表明与视频客户端之间的通信链路正趋于拥塞，则确定该通信链路处于拥塞状态。

综上，将对最大往返时延以及最小往返时延进行变化趋势的判断作为预设拥塞条件，提升了拥塞确定的准确性。

在确定通信链路处于拥塞状态的基础上，若仍旧按照原来的发包速率发送通信数据包，则通信链路的拥塞状态无法得到缓解。因此为了使通信链路的拥塞状态得到缓解，本实施例中，可以下调发包速率，具体实施如下所示：

获取所述通信链路对应的第一发包速率；

对所述第一发包速率进行下调处理，获得下调发包速率，并根据所述下调发包速率进行发包处理。

具体的，第一发包速率，是指服务端与客户端之间当前的发包速率，比如5万字节每秒，10万字节每秒等。下调发包速率，是指对第一发包速率进行下调后获得的发包速率。

在获取第一发包速率的基础上，对第一发包速率进行下调处理，是指将第一发包速率调整至一个较小的值。具体实施时，可以将第一发包速率调整至预设比例，比如将第一发包速率调整至70％，或85％等，在此不做限制。此外，还可以将第一发包速率减少预设值等。发包处理，是指服务端对后续的通信数据包进行发送。

沿用上例，在判断结果均为是的情况下，确定与视频客户端之间的通信链路处于拥塞状态，则获取通信链路对应的第一发包速率为S1，将第一发包速率调整至第一发包速率的70％，则获得下调发包速率为S2＝70％*S1。并按照该下调发包速率S2发送下一个通信数据包。

综上，在通信链路处于拥塞状态的情况下，先下调发包速率，再进行下一通信数据包的发送，有效地缓解了通信链路的拥塞情况，避免了通信链路长时间处于拥塞状态。

实际应用中，除上述判断结果均为是的情况之外，还存在可能至少一个判断结果为否的情况，这种情况下，本实施例中可以进一步判断最大往返时延的变化趋势，从而确定通信链路是否处于非拥塞状态，具体实现如下所示：

在存在至少一个判断结果为否的情况下，判断所述最大往返时延是否小于所述历史最大往返时延；

若小于，确定所述通信链路处于非拥塞状态。

具体的，存在任一判断结果为否，表明无法确定通信链路处于拥塞状态，则进一步判断最大往返时延是否在变小，若是，表明通信链路的网络情况在趋于良好，则确定通信链路处于非拥塞状态；若否，则无法确定通信链路的具体情况，不做处理即可。

假设，判断MaxRTT是否小于或等于hMaxRTT的判断结果为是，但判断MRTT是否大于hMRTT的判断结果为否，则进一步判断MaxRTT是否小于hMaxRTT，若是，表明与视频客户端之间的通信链路的网络情况趋于良好，则确定该通信链路处于非拥塞状态。

综上，在往返时延信息不满足预设拥塞条件的情况下，继续根据最大往返时延是否小于历史最大往返时延的判断结果，确定通信链路是否处于非拥塞状态，保障了对通信链路在非拥塞状态下的准确判断。

除上述两种判断情况之外，本实施例中还可以进一步判断最大往返时延以及最小往返时延的其他变化趋势，从而确定通信链路是否处于非拥塞状态，具体实现如下所示：

在存在至少一个判断结果为否的情况下，判断所述最大往返时延是否大于所述历史最大往返时延，并判断所述最小往返时延是否大于所述历史最小往返时延；

若均大于，确定所述通信链路处于非拥塞状态。

具体的，存在任一判断结果为否情况下，进一步判断最大往返时延是否在变大，并且最小往返时延是否也在变大，若两者均在变大，表明通信链路的网络情况仍有继续变拥挤的空间，则确定通信链路处于非拥塞状态；若任意一个不是在变大，则无法确定通信链路的具体情况，不做处理即可。

假设，判断MaxRTT是否小于或等于hMaxRTT的判断结果为否，但判断MRTT是否大于hMRTT的判断结果为是，则进一步判断MaxRTT是否大于hMaxRTT，并且判断MRTT是否大于hMRTT，若均大于，表明与视频客户端之间的通信链路的网络情况仍具有继续变拥挤的空间，则确定该通信链路处于非拥塞状态。

综上，在往返时延信息不满足预设拥塞条件的情况下，继续根据最大往返时延是否大于历史最大往返时延以及最小往返时延是否大于历史最小往返时延的判断结果，确定通信链路是否处于非拥塞状态，保障了对通信链路在非拥塞状态下的准确判断。

具体的，如图3所示的判断流程图，首先，收到ACK包，则记录最大RTT以及最小RTT，并将最大RTT与先前记录的最大RTT进行比较，将最小RTT与先前记录的最小RTT进行比较，判断最大RTT较之前是否变小或不变且最小RTT是否变大，若是，表明通信链路趋于拥塞，则确定通信链路为链路充满(即拥塞状态)，若否，未表明通信链路趋于拥塞，则继续判断是否最大RTT较之前变大且最小RTT较之前变大，或者最大RTT较之前变小，若是，则表明通信链路状态良好，则确定通信链路为链路未充满(即非拥塞状态)；若否，表明无法对通信链路的状态做进一步判断，则保持现有判断，即若接收确认数据包之前确定通信链路为链路充满，则仍确定通信链路为链路充满，若接收确认数据包之前确定通信链路为链路未充满，则仍确定通信链路为链路未充满。

进一步的，在上述确定通信链路处于非拥塞状态的情况下，为了避免通信链路中存在网络资源浪费，并进一步提高通信效率，本实施例中，还包括：

获取所述通信链路对应的第二发包速率；

对所述第二发包速率进行上调处理，获得上调发包速率，并根据所述上调发包速率进行发包处理。

具体的，第二发包速率，是指服务端与客户端之间当前的发包速率，该第二发包速率与上述第一发包速率实质相同。上调发包速率，是指对第二发包速率进行上调后获得的发包速率。

在获取第二发包速率的基础上，对第二发包速率进行上调处理，是指将第二发包速率调整至一个较大的值。具体实施时，可以将第二发包速率调整至第二发包速率的预设倍数，比如将第二发包速率调整至1.2倍，或1.1倍等，在此不做限制。此外，还可以将第二发包速率增加预设值等。

沿用上例，在确定与视频客户端之间的通信链路处于非拥塞状态的情况下，则获取通信链路对应的第二发包速率为S3，将第二发包速率调整至第二发包速率的1.2倍，则获得上调发包速率为S4＝1.2*S3。并按照该上调发包速率S4发送下一个通信数据包。

综上，在通信链路处于非拥塞状态的情况下，先上调发包速率，再进行下一通信数据包的发送，提高了通信链路的利用率，并提高了通信效率。

具体的，如图4所示的交互示意图，客户端和服务端建立连接后，二者之间进行数据请求与发送，服务端根据ACK包获取RTT等相关信息，则服务端中的拥塞判断模块根据往返时延信息判断当前通信链路的状态，并根据状态值调整接下来的数据包的发包速率，再向服务端提供下一个包的发包速率。以便服务端和客户端之间基于该发包速率进行数据请求与发送。

本申请提供的拥塞确定方法，为了提高确定通信链路是否处于拥塞状态的效率以及准确率，通过接收客户端针对通信数据包回复的确认数据包，并基于确认数据包的确认包信息以及与客户端关联的通信信息，确定往返时延信息，并将往返时延信息与预设拥塞条件进行比对，实现了基于往返时延信息进行拥塞判断，并在根据比对结果确定与客户端之间的通信链路的链路状态，提高了判断通信链路的链路状态的准确性。

下述结合附图5，以本申请提供的拥塞确定方法在BBRv2中的应用为例，对所述拥塞确定方法进行进一步说明。其中，图5示出了本申请一实施例提供的一种应用于BBRv2的拥塞确定方法的处理流程图，该拥塞确定方法应用于服务端，具体包括以下步骤：

步骤502：接收客户端回复的确认数据包。

具体的，服务端在对BBRv2算法进行改进的基础上进行拥塞控制。在BBR算法之前，拥塞算法对网络拥塞的判断多是基于丢包，如CUBIC等传统的拥塞控制算法。但是在真实的网络链路中，丢包的出现不仅仅由网络拥塞导致，也可能是因为机器硬件等其他原因导致的，这就导致了不必要的降速，由此导致的结果在视频流中的表现则为卡顿较高。BBR类算法则部分摆脱了对丢包判断的依赖，但BBRv2相较于BBR对丢包的判断和依赖更多一些。BBRv2在其部分阶段存在着根据丢包判断是增速还是减速，其目的是判断链路是否拥塞。

现有的BBRv2算法相较于BBRv1算法已经得到提升，但是因为加剧了对丢包判断的依赖故引入了新的问题。在原本的BBRv2算法中，会根据当前的轮次的丢包是否超过一个容忍度来衡量网络中的数据包是否过多，此目的是为了以一个恒定的丢包比例来判断网络是否拥塞。在现实网络环境中，各种网络环境复杂，不能以单一的一个恒定的丢包容忍度来衡量一个网络的拥塞情况。且并非所有的丢包都是由于网络拥塞导致的，所以这个值无论如何设置都是不能覆盖所有的网络环境。而这个对网络拥塞的判断的方法又会影响到后续算法对发包速率的控制，因此对于视频流业务，这种算法会导致对网络评估的不准确，由此会影响视频的传输质量，在用户侧的表现则是随着用户网络的波动，用户体验到的卡顿次数会增多，卡顿时长则会上升。本实施例对BBRv2中对链路是否填充满的粗略判断进行优化，由此提升视频流的传输质量，降低播放端的卡顿次数和卡顿时长，提升用户的观看体验。

本实施例中将BBRv2中原有对网络拥塞判断的固定值替换为一个依据RTT的变化判断链路是否填充满的方法。通过该方法最终对各种用户网络都能有较好的评估，由此充分利用链路带宽。并通过在BBRv2中融入该方法能够更快速准确地感知到用户测网络的波动，使得服务端可以以更准确的速度进行后续发包。

本实施例是一种根据RTT的变化判断链路是否拥塞的一种算法。其检测机制在于最大RTT和最小RTT对于链路拥塞的一个反应时差，当链路产生充满时，最大RTT较最小RTT会更快地趋于平稳，会更快地达到上限。而在恢复阶段，最小RTT则会更快的恢复，根据这个时间差可以判断出大致的链路充满的时间点。

步骤504：在确认数据包的确认包信息中提取当前确认数据量，并在与客户端关联的通信信息中提取向客户端发送的处于传输状态的通信数据包的历史传输数据量。

具体的，服务端处于BBRv2算法的ProbeBw自循环状态中的PROBE_UP状态。在接收到客户端回复的确认数据包之后，则在确认包信息中直接提取当前确认数据量。

步骤506：根据历史传输数据量以及当前确认数据量进行计算，获得传输数据量。

步骤508：在传输数据量不满足传输量阈值的情况下，根据确认包信息中的通信包发送时间以及确认包接收时间，计算确认数据包对应的目标通信数据包的往返时延。

具体的，该传输量阈值为预先计算的1.25倍的BDP，传输数据量不满足传输量阈值，具体是传输数据量小于或等于1.25*BDP。这种情况下，表明已经发出但未确认的数据量的不一定可以使通信链路达到拥塞状态，因此，需要进一步基于往返时延进行拥塞判断。

步骤510：在通信信息中提取预设通信包范围内的历史通信数据包的历史往返时延。

步骤512：在往返时延以及预设通信包范围内的历史通信数据包的历史往返时延中，选取最大往返时延以及最小往返时延。

步骤514：判断最大往返时延是否小于或等于预先记录的历史最大往返时延，并判断最小往返时延是否大于预先记录的历史最小往返时延；

若判断结果均为是，表明与客户端之间的通信链路趋于拥塞，则执行下述步骤516；

若判断结果不均为是，表明与客户端之间的通信链路未趋于拥塞，不做处理即可。

步骤516：确定与客户端之间的通信链路处于拥塞状态。

步骤518：获取通信链路对应的第一发包速率。

具体的，在确定与客户端之间的通信链路处于拥塞状态之后，则服务端从PROBE_UP状态切换到PROBE_DOWN状态，并进行降速处理。

步骤520：对第一发包速率进行下调处理，获得下调发包速率，并根据所述下调发包速率进行发包处理。

本申请提供的拥塞确定方法，为了提高确定通信链路是否处于拥塞状态的效率以及准确率，通过接收客户端针对通信数据包回复的确认数据包，并基于确认数据包的确认包信息以及与客户端关联的通信信息，确定往返时延信息，并将往返时延信息与预设拥塞条件进行比对，实现了基于往返时延信息进行拥塞判断，并在根据比对结果确定与客户端之间的通信链路的链路状态，提高了判断通信链路的链路状态的准确性。

与上述方法实施例相对应，本申请还提供了拥塞确定装置实施例，图6示出了本申请一实施例提供的一种拥塞确定装置的结构示意图。如图6所示，该装置包括：

接收模块602，被配置为接收客户端回复的确认数据包；

确定模块604，被配置为基于所述确认数据包的确认包信息以及与所述客户端关联的通信信息，确定往返时延信息；

比对模块606，被配置为将所述往返时延信息与预设拥塞条件进行比对，并根据比对结果确定与所述客户端之间的通信链路的链路状态。

可选地，所述拥塞确定装置，还包括：

计算模块，被配置为基于所述确认包信息以及所述通信信息，计算向所述客户端发送的处于传输状态的通信数据包的传输数据量；

在所述传输数据量不满足传输量阈值的情况下，执行所述确定模块604。

可选地，所述确定模块604，进一步被配置为：

根据所述确认包信息中的通信包发送时间以及确认包接收时间，计算所述确认数据包对应的目标通信数据包的往返时延；

在所述通信信息中提取预设通信包范围内的历史通信数据包的历史往返时延；

在所述往返时延以及所述预设通信包范围内的历史通信数据包的历史往返时延中，选取最大往返时延以及最小往返时延，将所述最大往返时延以及所述最小往返时延作为往返时延信息。

可选地，所述比对模块606，进一步被配置为：

判断所述往返时延信息中的所述最大往返时延是否小于或等于预先记录的历史最大往返时延，并判断所述往返时延信息中的所述最小往返时延是否大于预先记录的历史最小往返时延；

若判断结果均为是，执行所述确定与所述客户端之间的通信链路处于拥塞状态。

可选地，所述比对模块606，进一步被配置为：

在存在至少一个判断结果为否的情况下，判断所述最大往返时延是否小于所述历史最大往返时延；

若小于，确定所述通信链路处于非拥塞状态。

可选地，所述比对模块606，进一步被配置为：

在存在至少一个判断结果为否的情况下，判断所述最大往返时延是否大于所述历史最大往返时延，并判断所述最小往返时延是否大于所述历史最小往返时延；

若均大于，确定所述通信链路处于非拥塞状态。

可选地，所述拥塞确定装置，还包括：

第一获取模块，被配置为获取所述通信链路对应的第一发包速率；

下调模块，被配置为对所述第一发包速率进行下调处理，获得下调发包速率，并根据所述下调发包速率进行发包处理。

可选地，所述拥塞确定装置，还包括：

第二获取模块，被配置为获取所述通信链路对应的第二发包速率；

上调模块，被配置为对所述第二发包速率进行上调处理，获得上调发包速率，并根据所述上调发包速率进行发包处理。

可选地，所述计算模块，进一步被配置为：

在所述确认包信息中提取当前确认数据量，并在所述通信信息中提取向所述客户端发送的通信数据包的总数据量以及所述总数据量对应的历史确认数据量；

根据所述总数据量、所述历史确认数据量以及所述当前确认数据量进行计算，获得所述传输数据量。

可选地，所述计算模块，进一步被配置为：

在所述确认包信息中提取当前确认数据量，并在所述通信信息中提取向所述客户端发送的处于传输状态的通信数据包的历史传输数据量；

根据所述历史传输数据量以及所述当前确认数据量进行计算，获得所述传输数据量。

可选地，所述拥塞确定装置，还包括：

第二计算模块，被配置为基于所述确认数据包的确认包信息以及与所述客户端关联的通信信息，计算所述通信链路对应的链路最大带宽以及链路最小往返时延；

第三计算模块，被配置为基于所述链路最大带宽以及所述链路最小往返时延，计算带宽时延积；将预设倍数的带宽时延积作为所述传输量阈值。

本申请提供的拥塞确定装置，为了提高确定通信链路是否处于拥塞状态的效率以及准确率，通过接收客户端针对通信数据包回复的确认数据包，并基于确认数据包的确认包信息以及与客户端关联的通信信息，确定往返时延信息，并将往返时延信息与预设拥塞条件进行比对，实现了基于往返时延信息进行拥塞判断，并在根据比对结果确定与客户端之间的通信链路的链路状态，提高了判断通信链路的链路状态的准确性。

上述为本实施例的一种拥塞确定装置的示意性方案。需要说明的是，该拥塞确定装置的技术方案与上述的拥塞确定方法的技术方案属于同一构思，拥塞确定装置的技术方案未详细描述的细节内容，均可以参见上述拥塞确定方法的技术方案的描述。

图7示出了根据本申请一实施例提供的一种计算设备700的结构框图。该计算设备700的部件包括但不限于存储器710和处理器720。处理器720与存储器710通过总线730相连接，数据库750用于保存数据。

计算设备700还包括接入设备740，接入设备740使得计算设备700能够经由一个或多个网络760通信。这些网络的示例包括公用交换电话网(PSTN，PublicSwitchedTelephoneNetwork)、局域网(LAN，LocalAreaNetwork)、广域网(WAN，WideAreaNetwork)、个域网(PAN，PersonalAreaNetwork)或诸如因特网的通信网络的组合。接入设备740可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(NIC，networkinterfacecontroller))中的一个或多个，诸如IEEE802.11无线局域网(WLAN，WirelessLocalAreaNetwork)无线接口、全球微波互联接入(Wi-MAX，WorldwideInteroperabilityforMicrowaveAccess)接口、以太网接口、通用串行总线(USB，UniversalSerialBus)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC，NearFieldCommunication)接口，等等。

在本申请的一个实施例中，计算设备700的上述部件以及图7中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图7所示的计算设备结构框图仅仅是出于示例的目的，而不是对本申请范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。

计算设备700可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或个人计算机(PC，PersonalComputer)的静止计算设备。计算设备700还可以是移动式或静止式的服务器。

其中，处理器720执行所述计算机指令时实现所述的拥塞确定方法的步骤。

上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的拥塞确定方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述拥塞确定方法的技术方案的描述。

本申请一实施例还提供一种计算机可读存储介质，其存储有计算机指令，该计算机指令被处理器执行时实现如前所述拥塞确定方法的步骤。

上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的拥塞确定方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述拥塞确定方法的技术方案的描述。

上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，RandomAccessMemory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本申请所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上公开的本申请优选实施例只是用于帮助阐述本申请。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本申请的内容，可作很多的修改和变化。本申请选取并具体描述这些实施例，是为了更好地解释本申请的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本申请。本申请仅受权利要求书及其全部范围和等效物的限制。

Claims (14)

1.一种拥塞确定方法，其特征在于，应用于服务端，包括：

接收客户端回复的确认数据包；

基于所述确认数据包的确认包信息以及与所述客户端关联的通信信息，确定往返时延信息；

将所述往返时延信息与预设拥塞条件进行比对，并根据比对结果确定与所述客户端之间的通信链路的链路状态。

2.根据权利要求1所述的拥塞确定方法，其特征在于，所述基于所述确认数据包的确认包信息以及与所述客户端关联的通信信息，确定往返时延信息之前，还包括：

基于所述确认包信息以及所述通信信息，计算向所述客户端发送的处于传输状态的通信数据包的传输数据量；

在所述传输数据量不满足传输量阈值的情况下，执行所述基于所述确认数据包的确认包信息以及与所述客户端关联的通信信息，确定往返时延信息。

3.根据权利要求1所述的拥塞确定方法，其特征在于，所述基于所述确认数据包的确认包信息以及与所述客户端关联的通信信息，确定往返时延信息，包括：

根据所述确认包信息中的通信包发送时间以及确认包接收时间，计算所述确认数据包对应的目标通信数据包的往返时延；

在所述通信信息中提取预设通信包范围内的历史通信数据包的历史往返时延；

在所述往返时延以及所述预设通信包范围内的历史通信数据包的历史往返时延中，选取最大往返时延以及最小往返时延，将所述最大往返时延以及所述最小往返时延作为往返时延信息。

4.根据权利要求3所述的拥塞确定方法，其特征在于，所述将所述往返时延信息与预设拥塞条件进行比对，并根据比对结果确定与所述客户端之间的通信链路的链路状态，包括：

判断所述往返时延信息中的所述最大往返时延是否小于或等于预先记录的历史最大往返时延，并判断所述往返时延信息中的所述最小往返时延是否大于预先记录的历史最小往返时延；

若判断结果均为是，确定与所述客户端之间的通信链路处于拥塞状态。

5.根据权利要求4所述的拥塞确定方法，其特征在于，所述判断所述往返时延信息中的所述最小往返时延是否大于预先记录的历史最小往返时延之后，还包括：

在存在至少一个判断结果为否的情况下，判断所述最大往返时延是否小于所述历史最大往返时延；

若小于，确定所述通信链路处于非拥塞状态。

6.根据权利要求4所述的拥塞确定方法，其特征在于，所述判断所述往返时延信息中的所述最小往返时延是否大于预先记录的历史最小往返时延之后，还包括：

在存在至少一个判断结果为否的情况下，判断所述最大往返时延是否大于所述历史最大往返时延，并判断所述最小往返时延是否大于所述历史最小往返时延；

若均大于，确定所述通信链路处于非拥塞状态。

7.根据权利要求1所述的拥塞确定方法，其特征在于，还包括：

获取所述通信链路对应的第一发包速率；

对所述第一发包速率进行下调处理，获得下调发包速率，并根据所述下调发包速率进行发包处理。

8.根据权利要求5或6所述的拥塞确定方法，其特征在于，还包括：

获取所述通信链路对应的第二发包速率；

对所述第二发包速率进行上调处理，获得上调发包速率，并根据所述上调发包速率进行发包处理。

9.根据权利要求2所述的拥塞确定方法，其特征在于，所述基于所述确认包信息以及所述通信信息，计算向所述客户端发送的处于传输状态的通信数据包的传输数据量，包括：

在所述确认包信息中提取当前确认数据量，并在所述通信信息中提取向所述客户端发送的通信数据包的总数据量以及所述总数据量对应的历史确认数据量；

根据所述总数据量、所述历史确认数据量以及所述当前确认数据量进行计算，获得所述传输数据量。

10.根据权利要求2所述的拥塞确定方法，其特征在于，所述基于所述确认包信息以及所述通信信息，计算向所述客户端发送的处于传输状态的通信数据包的传输数据量，包括：

在所述确认包信息中提取当前确认数据量，并在所述通信信息中提取向所述客户端发送的处于传输状态的通信数据包的历史传输数据量；

根据所述历史传输数据量以及所述当前确认数据量进行计算，获得所述传输数据量。

11.根据权利要求2所述的拥塞确定方法，其特征在于，所述基于所述确认数据包的确认包信息以及与所述客户端关联的通信信息，确定往返时延信息之前，还包括：

基于所述确认包信息以及与所述通信信息，计算所述通信链路对应的链路最大带宽以及链路最小往返时延；

基于所述链路最大带宽以及所述链路最小往返时延，计算带宽时延积；

将预设倍数的带宽时延积作为所述传输量阈值。

12.一种拥塞确定装置，其特征在于，包括：

接收模块，被配置为接收客户端回复的确认数据包；

确定模块，被配置为基于所述确认数据包的确认包信息以及与所述客户端关联的通信信息，确定往返时延信息；

比对模块，被配置为将所述往返时延信息与预设拥塞条件进行比对，并根据比对结果确定与所述客户端之间的通信链路的链路状态。

13.一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，其特征在于，所述处理器执行所述计算机指令时实现权利要求1-11任意一项所述方法的步骤。

14.一种计算机可读存储介质，其存储有计算机指令，其特征在于，该计算机指令被处理器执行时实现权利要求1-11任意一项所述方法的步骤。

Images