一种拦截确认包的方法以及接入网设备与流程

本申请涉及通信技术领域，具体涉及一种拦截确认包的方法以及接入网设备。

背景技术

流量控制(pacing)机制应用于无线网络时，可能会造成严重的限速，造成无线资源利用率低的问题。不同于有线传输，空口传输是不够可靠的。在实际的通信系统中，无线传输的可靠性要靠重传来保证。但多次重传会带来更长的时延，也会带来更长的无线传输技术往返时延(roundtriptime，rtt)样本。随着收到的大rtt样本，平滑的往返时延(smoothedroundtriptime，srtt)也会被放大，最终发送端的数据发送速率会被pacing机制限制。pacing试图解决的是转发节点上的缓存被撑爆的问题，但实际情况下并不存在pacing试图避免的问题。发送端的数据发送速率受到影响是因为空口的时延抖动造成pacing机制对网络状态的误判。

技术实现要素：

本申请提供了一种拦截确认包的方法以及接入网设备，用于在基站处实现pacing感知以及异常ack拦截机制，在一定程度上防止发送端收到异常ack后造成pacing速率减小，并且能有效避免信道质量突然恶化对pacing速率产生影响，使pacing速率尽可能接近无抖动的情况。因此对于存在时延抖动的无线环境，尤其是对于存在突发干扰的情况，本申请能在原有基础上有效提高使用pacing机制的传输层的性能。

有鉴于此，本申请实施例第一方面提供一种拦截确认包的方法，可以包括：接入网设备接收发送端发送的第一数据包；该第一数据包可以是上行数据包，也可以是下行数据包。该接入网设备向接收端发送该第一数据包；该接入网设备接收该接收端发送的第二数据包；该第二数据包可以是下行数据包，也可以是上行数据包。若该接入网设备确定该第二数据包为与该第一数据包对应的确认包，且确定该第二数据包异常，则该接入网设备拦截该第二数据包。

在本申请实施例中，当接入网设备接收第二数据包时，接入网设备可以对第二数据包进行判断，看是否异常，若确定第二数据包为第一数据包的确认包，且异常时，接入网设备对其进行拦截，从而，发送端就不会收到第二数据包了，因此，可以有效避免信道质量突然恶化对pacing速率产生影响，有效避免信道质量突然恶化对pacing速率产生影响。

可选的，在本申请的一些实施例中，该接入网设备确定该第二数据包为与该第一数据包对应的确认包，可以包括：该接入网设备根据预先保存的映射表，确定该第二数据包为与该第一数据包对应的确认包，其中，该映射表中保存有触发该接收端反馈确认包，对应的该发送端发送的数据包。需要说明的是，当接入网设备接收发送端的第一数据包符合触发ack的预置条件时，接入网设备会将该第一数据包加入映射表，当接入网设备再接收到接收端发送的第二数据包，确定第二数据包的类型，当第二数据包为确认包，则可以在映射表中对应的查找到该第二数据包为哪个数据包的确认包。

在本申请实施例中，接入网设备提供了一种确定第二数据包是否为第一数据包的确认包的具体实现方式，增加了方案的可行性。

可选的，在本申请的一些实施例中，该方法还可以包括：该接入网设备记录该第一数据包的第一接收时刻；该接入网设备记录该第二数据包的第二接收时刻；该确定该第二数据包异常，可以包括：该接入网设备根据该第一接收时刻和该第二接收时刻，确定中间时长；若该中间时长大于第一预置阈值，则该接入网设备确定该第二数据包异常。

在本申请实施例中，当接入网设备确定第二数据包为第一数据包的确认包后，因为接入网设备在接收第一数据包时，对应的会记录第一接收时刻，在接收第二数据包时，对应的会记录第二接收时刻。根据第一接收时刻和第二接收时刻，确定中间时长，当中间时长大于第一预置阈值时，接入网设备可以确定该第二数据包异常。提供了一种接入网设备确定第二数据包是否异常的具体实现方式，使得本申请技术方案更加完整，清楚。

可选的，在本申请的一些实施例中，该接入网设备拦截该第二数据包之后，该方法还可以包括：若该接入网设备确定第一定时器超时，则该接入网设备向该发送端发送该第二数据包，其中，该第一定时器用于计时该接入网设备向该发送端最近发送的确认包与当前时刻的时长。

可选的，在本申请的一些实施例中，该接入网设备拦截该第二数据包之后，该方法还可以包括：若该接入网设备确定第二定时器超时，则该接入网设备向该发送端发送该第二数据包，其中，该第二定时器用于计时该接入网设备接收该发送端最近发送的第三数据包与当前时刻的时长。

在上述两种可选的实现方式中，需要停止拦截确认包。一种是发送端长时间未收到ackonly包，发送进程被拥塞窗口卡死；另一种是发送端长时间未收到ackonly包，出现tlp或者rto。这两类问题可以利用两个定时器来解决，定时器超时后就进入补偿模式，主动停止拦截，并直接向发送端发送一个ackonly包。随后，系统回到正常模式。

本申请实施例第二方面提供一种接入网设备，具有防止发送端收到异常ack后造成pacing速率减小，并且能有效避免信道质量突然恶化对pacing速率产生影响，有效提高使用pacing机制的传输层的性能的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。

本申请实施例又一方面提供一种接入网设备，可以包括：收发器，用于与所述接入网设备之外的装置进行通信；存储器，用于存储计算机执行指令；一个或多个处理器，通过总线与所述存储器和所述收发器连接，当所述处理器执行所述存储器中存储的计算机执行指令，以及一个或多个计算机程序，其中，所述一个或多个计算机程序被存储在所述存储器中，所述一个或多个计算机程序包括指令，当所述指令被所述接入网设备执行时，使得所述接入网设备执行如上述各方面或各方面任一可选方式所述的方法。

本申请实施例又一方面提供一种无线通信装置，可以包括：

至少一个处理器，存储器，收发电路和总线系统，所述处理器，所述存储器，所述收发电路通过所述总线系统耦合，所述无线通信装置通过所述收发电路与服务器相通信，所述存储器用于存储程序指令，所述至少一个处理器用于执行所述存储器中存储的所述程序指令，使得所述无线通信装置执行如本申请实施例上述各方面所述的方法中所述接入网设备操作的部分。所述无线通信装置既可以是接入网设备，也可以是应用在接入网设备中执行相应功能的芯片。

本申请实施例又一方面提供一种存储介质，需要说明的是，本申请技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产口的形式体现出来，该计算机软件产品存储在一个存储介质中，用于储存为上述接入网设备所用的计算机软件指令，其包含用于执行上述各方面为接入网设备所设计的程序。

该存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

本申请实施例又一方面提供一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行如上述各方面或各方面任一可选实现方式中所述的方法。

附图说明

为了更清楚地说明本申请实施例技术方案，下面将对实施例和现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，还可以根据这些附图获得其它的附图。

图1为本申请实施例中quic中pacing机制的原理示意图；

图2为quic发送端的流量控制速率的变化趋势对比的示意图；

图3为本申请实施例中接入网设备的一个实施例示意图；

图4为本申请实施例中拦截确认包的方法的实施例示意图；

图5为本申请实施例中基站的映射表生成机制的一个示意图；

图6为本申请实施例中ack拦截模块的执行流程示意图；

图7为本申请实施例中对quic拥塞窗口的持续估计流程图；

图8为本申请实施例中接入网设备的一个实施例示意图；

图9为本申请实施例中接入网设备的另一个实施例示意图。

具体实施方式

本申请实施例提供了一种拦截确认包的方法以及接入网设备，用于在基站处实现pacing感知以及异常ack拦截机制，在一定程度上防止发送端收到异常ack后造成pacing速率减小，并且能有效避免信道质量突然恶化对pacing速率产生影响，使pacing速率尽可能接近无抖动的情况。因此对于存在时延抖动的无线环境，尤其是对于存在突发干扰的情况，本申请能在原有基础上有效提高使用pacing机制的传输层的性能。

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，都应当属于本申请保护的范围。

当前广泛使用的网络传输层协议主要有两种：用户数据报协议(userdatagramprotocol，udp)和传输控制协议(transmissioncontrolprotocol，tcp)，其中，tcp是一种面向连接的、具备可靠性的传输协议，udp是一种面向无连接的传输协议。相比于udp，tcp虽然控制开销较大、具有队头阻塞、连接建立延迟较高等问题，但是由于具备较高的可靠性，并且传统的网络业务对实时性要求不高，因此tcp一直被广泛应用与研究。由于新拥塞控制算法部署的困难和tcp固有的问题，研究人员在互联网工程任务组(internetengineeringtaskforce，ietf)的讨论会上公开了一种被命名为快速udp互联网连接协议(quickudpinternetconnections，quic)的新型控制协议。

无论是tcp还是quic协议，拥塞控制都是一个研究热点。根据拥塞控制机制，处于发送窗口中的包可以被发送。传统tcp版本中，进入发送窗口中的tcp包会被一起发送。在特定场景下，如多个确认信息(acknowledgement，ack)造成的发送窗口快速移动，会带来较大的数据突发。网络中难免存在缓存较小的转发节点，大的数据突发会因为转发速率受限而导致缓存溢出。为了解决此问题，研究人员提出pacing机制。pacing机制可以看做是拥塞控制机制的一部分，在quic和部分tcp版本中被采用。以quicpacing为例对pacing机制进行说明。quic中pacing机制的原理如图1所示，图1为本申请实施例中quic中pacing机制的原理示意图。

在图1所示中，包1、2和3同时进入发送窗口。但pacing机制不会让这三个包同时被发送，而是会以一定间隔来发送。间隔根据平滑的往返时延(smoothedroundtriptime，srtt)和发送窗口大小来确定。除了上面介绍的pacing机制，还有其他pacing机制可供选择。不同机制的区别在于计算包发送间隔的方式，但间隔的设置都是基于对网络状态的估计。

以此种方式发送可以有效减少数据突发对网络带来的压力。但在解决了突发问题的同时，当被应用于无线网络时pacing也会带来一些其他问题。仿真情况显示pacing虽然在某些场景(比如多跳无线网络)下会带来比较好的吞吐率、公平性以及低丢包率；但是大多数情况下pacing会导致吞吐率更低。在应用于无线网络时，可能会造成更严重的限速，造成无线资源利用率低的问题。不同于有线传输，空口传输是不够可靠的。

在实际应用中，无线传输的可靠性要靠重传来保证。多次重传会带来更长的时延，也会带来更长的往返时延(roundtriptime，rtt)样本。随着收到的大rtt样本，srtt也会被放大，最终发送端的数据发送速率会被pacing机制限制。pacing试图解决的是转发节点上的缓存被撑爆的问题，但实际情况下并不存在pacing试图避免的问题。发送端的数据发送速率受到影响是因为空口的时延抖动造成pacing机制对网络状态的误判。

接下来，以quic为例，通过一系列仿真测试验证无线信道的时延抖动对quic的传输性能造成的影响。仿真测试模拟基站到终端的无线信道、无丢包率、正常时延80ms，为了凸显对比性，设置抖动时延800ms。quic客户端向quic服务器请求128kb数据，带宽速率为50mbps，上行包不受影响，下行包在一定概率下遭遇时延抖动。

如图2所示，图2为quic发送端的流量控制速率(pacingrate)的变化趋势对比的示意图。测试场景中quic发送端的pacingrate受到时延抖动的影响非常大。影响的因素主要包括两方面：时延抖动产生点的分布以及时延抖动产生的概率。总体趋势为时延抖动产生的概率越大，quic发送端的pacingrate下降越大；时延抖动产生点分布越均匀，对quic发送端的pacingrate的影响越大。

quic的带宽估计机制导致quic发送端在收到受时延影响的ack或者收到对受时延抖动影响的下行包进行应答的ack后，quic发送端计算的瞬时rtt会立即增大，从而导致srtt增大，并进一步导致quic发送端的pacing速率下降。显然对于网络拥塞的情况，这样的做法是有必要的。但是对于无线环境信道质量突然恶化的情况，这种做法没必要并且会降低quic的传输性能。

综上所述，相同的问题也会出现在使用pacing机制的tcp版本上。因此本申请主要是在基站处实现pacing感知以及异常ack拦截机制，在一定程度上防止发送端收到异常ack后造成pacing速率减小，并且能有效避免信道质量突然恶化对pacing速率产生影响，使pacing速率尽可能接近无抖动的情况。因此，对于存在时延抖动的无线环境，尤其是对于存在突发干扰的情况，本申请可以在原有基础上有效提高使用pacing机制的传输层性能。

本申请所要解决的技术问题为：在无线场景下使用quic协议或者tcp协议等进行通信，因为空口传输的时延波动，会造成发送端的pacing速率降低，数据包的发包间隔变大，最终造成空口资源利用率低。本方案通过拦截大延迟的ack包，保证发送端的pacingrate，以提高空口资源利用率。

本申请技术方案适用于所有使用pacing技术的无线通信系统，例如传输协议可以替换成使用pacing的tcp协议，网络可以替换成通用移动通信系统(universalmobiletelecommunicationssystem，umts)/高速下行链路分组接入(highspeeddownlinkpackageaccess，hsdpa)，或者，无线局域网(wirelesslocalareanetwork，wlan)。

在本申请实施例中提到的发送端可以是服务器，也可以是客户端；提到的接收端可以是客户端，也可以是服务端。下面以发送端为服务器，接收端为客户端为例进行说明。

接入网设备可以是lte系统、下一代(nextradio，nr)移动通信系统或者授权辅助接入长期演进(authorizedauxiliaryaccesslong-termevolution，laa-lte)系统中的演进型基站(evolutionalnodeb，简称可以为enb或e-nodeb)宏基站、微基站(也称为“小基站”)、微微基站、接入站点(accesspoint，ap)、传输站点(transmissionpoint，tp)或gnodeb(newgenerationnodeb，新一代基站)等。

客户端可称之为终端设备(userequipment，ue)、移动台(mobilestation，ms)、移动终端(mobileterminal)、智能终端等，该终端设备可以经无线接入网(radioaccessnetwork，ran)与一个或多个核心网进行通信。例如，终端设备可以是移动电话(或称为“蜂窝”电话)、具有移动终端的计算机等，终端设备还可以是便携式、袖珍式、手持式、计算机内置的或者车载的移动装置以及未来nr网络中的终端设备，它们与无线接入网交换语音或数据。对终端设备的说明：本申请中，终端设备还可以包括中继relay，和基站可以进行数据通信的都可以看为终端设备。

示例性的，图3为本申请实施例中针对quic协议在长期演进(longtermevolution，lte)网络下的优化方案框图，并与现有的基线方案进行了对比。相比于现有的基线方案，图3提出的优化方案添加了七个模块：

ackonly包判断模块：根据quic包的包长和ackonly包长估计模块提供的ackonly包长估计值，确定当前收到的quic包是否为ackonly包。

quic包与ack映射模块：根据quic的ack生成机制，来判断下行quic包和上行ackonly包之间的对应关系。根据对应关系，可以确定每个ackonly包的时延，并估计此ackonly包对应的rtt样本大小。

ack拦截模块：根据估计出的rtt样本，判断当前ackonly包是否会造成quic发送速率下降。如果不会产生影响，视为正常ackonly包，直接向发送端转发。如果会造成降速，视为异常ackonly包，存入异常ack缓存。

异常ack缓存：缓存所有被拦截的异常ackonly包。

发送端状态估计模块：主要负责估计发送端的两个状态，srtt和计算机网络中拥塞窗口(congestionwindow，cwnd)。

发送端超时判断定时器：根据ack转发的情况，判断当前是否会出现尾部丢包检测(tailloseprobe，tlp)或者重传超时(retransmissiontimeout，rto)超时。如果定时器超时，说明有tlp或rto超时风险，停止拦截ackonly包，并直接发送被拦截的最新一个ackonly包。

发送端拥塞判断定时器：根据下行quic包到达间隔，来判断当前发送端是否出现了发送拥塞的问题，即当前发包进程已经被拥塞窗口卡住。定时器超时说明出现发送拥塞问题，停止拦截ackonly包，并直接发送被拦截的最新一个ackonly包。

需要说明的是，如果针对的是tcp协议包，那么，在图3所示中，ackonly包判断模块不存在，而且，tcp协议对应的是ack包，不是ackonly包。当基站接收上行包或者下行包时，可以直接读出上行包或者下行包的类型，来确认是否为ack包，不需要判断上行包或者下行包是否为ackonly包。其他和上述图3所示的功能模块类似，在tcp协议包传输时，可以参考上述图3所示的处理流程，此处不再赘述。

本申请的工作过程可以如下所示：每当基站收到下行quic包时，对包到达时间进行记录。收到上行quic包时，对包类型进行判断。如果是ackonly包，查找其与下行quic包之间的映射关系，并估计rtt样本。然后由ack拦截模块，判断该ackonly包是否异常。如果异常，就进行拦截。但在一些特定情况下，需要停止拦截。特定情况主要包括两种：一种是发送端长时间未收到ackonly包，发送进程被拥塞窗口卡死；另一种是发送端长时间未收到ackonly包，出现tlp或者rto。这两类问题可以利用两个定时器来解决，定时器超时后就进入补偿模式，主动停止拦截，并直接向发送端发送一个ackonly包。随后，系统回到正常模式。

如图4所示，图4为本申请实施例中拦截确认包的方法的实施例示意图。可以包括：

401、基站接收服务器发送的下行包。

该步骤可以由图3所示中的quic包与ack映射模块执行。基站接收到quic服务器的下行包后，根据该下行包的信息，选择是否将该下行包加入映射表并重置计数参数。其中，基站的映射表生成方式遵循quic的ack触发机制。

如图5所示，图5为本申请实施例中基站的映射表生成机制的一个示意图。quic包与ack映射模块维护一个计数器。示例性的，基站收到下行包后，首先判断该下行包是否为ack包，若该下行包为ack包，并且该下行包为连续的第二十个ack包，则将该下行包加入映射表；否则说明该下行包为非ack包并判断该下行包是否为乱序包，若是乱序包则将该包加入映射表；否则若该下行包为连续的第二个非ack包时，将该下行包加入映射表。

可以理解的是，每次将下行包加入映射表后，将计数器重置。另外，映射表每次加入下行包时，下行包对应的上行ack帧号严格递增。

402、基站向客户端发送下行包。

基站收到quic服务器发送的下行包时，可以将该下行包向quic客户端转发。

403、客户端向基站发送上行包。

示例性的，quic客户端根据quic的ack触发机制，正常情况下，quic客户端每次收到2个非ackonly包时触发ackonly包发送。若是quic客户端收到乱序包，则立即发送ackonly包。若是quic客户端当前只收到ackonly包，则在连续收到20个ackonly包时触发ackonly包的发送。

ack包长估计模块：终端确定包长估计值，该包长估计值用于判断下行包是否为ackonly包，该包长估计值为ackonly包的包长估计值。

可选的，首个到达数据链路层的ackonly包的包长是固定的，客户端可以将此固定包长设置为包长估计值的初始值即初始包长值。当有下行包发送至数据链路层时，客户端根据上述初始包长值和当前下行包的包长值判断当前下行包是否为ackonly包，并且，对ackonly包的包长以及出现次数最高的ackonly包的包长作为包长估计值进行ackonly包的判断。

客户端将下行包的包长与包长估计值进行比较，若下行包的包长与上述ackonly包的包长估计值之间的包长偏差值在预设偏差范围内，则客户端确定下行包类型为ackonly包；若包长偏差值不在预设范围内，则客户端确定下行包类型为非ackonly包。

404、若基站确定上行包为下行包的确认包，且上行包异常，则基站拦截上行包。

该步骤可以由ackonly包判断模块、quic包与ack映射模块、ack拦截模块和异常ackonly缓存模块来完成。

需要说明的是，接入网设备确定第二数据包为与第一数据包对应的确认包，可以包括：接入网设备根据预先保存的映射表，确定第二数据包为与第一数据包对应的确认包，其中，映射表中保存有触发接收端反馈确认包，对应的发送端发送的数据包。

其中，接入网设备记录第一数据包的第一接收时刻；接入网设备记录第二数据包的第二接收时刻；确定第二数据包异常，可以包括：接入网设备根据第一接收时刻和第二接收时刻，确定中间时长；若中间时长大于第一预置阈值，则接入网设备确定第二数据包异常。

基站接收quic客户端发送的上行包之后，可以先判断该上行包的包类型，若是确认ackonly包，还可以根据上述的映射表确定该上行包与下行包的映射关系，并估计出rtt样本。再确定该上行包是否异常，若异常，则进行拦截，放入异常ackonly缓存模块。

示例性的，ackonly包判断模块：根据上行包的包长和ackonly包长估计模块提供的ackonly包长估计值，确定当前收到的上行包是否为ackonly包。若是ackonly包，则进入quic包与ack映射模块。

quic包与ack映射模块：根据映射表，查找出该上行包对应的下行包被基站接收的第一时间点，该上行包被基站接收的第二时间点已知。

ack拦截模块：根据第一时间点和第二时间点确定时间差，若该时间差大于预置阈值，则确定该上行包异常，ack拦截模块进行拦截，放入异常ack包缓存。如果为正常，则向quic服务器转发。

如图6所示，图6为本申请实施例中ack拦截模块的执行流程示意图。ack拦截模块每次收到ackonly包时将接收计数加一，并将接收计数与映射表中对应的ack帧号匹配，确定对应下行包的发送时间，并结合当前接收时间计算当前的瞬时rtt。若当前的瞬时rtt位于判定门限内，则判定当前ackonly包为正常包，并直接将该ackonly包上行，否则将该ackonly包放入异常ack包缓存。

异常ack包缓存：负责缓存ack拦截模块拦截的ackonly包，并根据定时器指示发送被缓存的ackonly包。同一时刻只缓存一个ackonly包，即如果有新的ackonly包被拦截，就可以丢弃已经被缓存的ackonly包。

405、若基站确定服务器超时判断定时器超时，则向服务器发送ackonly包。

若接入网设备确定第二定时器超时，则接入网设备向发送端发送第二数据包，其中，第二定时器用于计时接入网设备接收发送端最近发送的第三数据包与当前时刻的时长。

406、若基站确定服务器拥塞判断定时器超时，则向服务器发送ackonly包。

若接入网设备确定第一定时器超时，则接入网设备向发送端发送第二数据包，其中，第一定时器用于计时接入网设备向发送端最近发送的确认包与当前时刻的时长。

需要说明的是，步骤405和406为可选的步骤，且步骤405和406的时序不做限定。

在本申请实施例中，服务器状态估计模块：需要估计服务器的srtt和cwnd。

(1)首先给出srtt的估计方案。

需要说明的是，在服务器侧，srtt的计算参照如下公式如下所示：

其中，rtt对应每个rtt样本。在服务器，rtt样本利用下行包的发送时间和对应ackonly包的接收时间来计算。但在基站无法如此计算，所以需要通过其他方式进行近似计算得到。rtt可以拆分成有线rtt和无线rtt。基站可以直接测量得到无线rtt，有线rtt需要基站向quic服务器发送探测包来主动测量。以此种方式就可以在基站估计srtt。

(2)然后是cwnd的估计方案。

假定基站到客户端之间不存在乱序，由于拥塞窗口是基于ack应答包的包号进行调整，因此只需要能够大致估计ack应答包的包号，就可以在基站处模拟拥塞窗口的变化情况。根据lte网络的特性，其混合自动重传请求(hybridautomaticrepeatrequest，harq)机制以及无线链路控制层协议(radiolinkcontrol，rlc)的确认模式一般情况下都能够基本保证lte无线网络中包的可靠按序向上递交。

因此，虽然quic的加密性质导致其ack指针(frame)中的应答信息无法获得，但是在lte网络下也可以对ack的应答包进行大致推测，所以，理论上在基站处是可以大致模拟quic服务器拥塞窗口的变化情况的。

下面给出估计quic拥塞窗口的方案：

如图7所示，图7为本申请实施例中对quic拥塞窗口的持续估计流程图。

首先，对图7中各个参数的定义加以说明：图中的n定义为从上次上行ackonly开始到当前基站接收到ackonly时，所有应答的下行包的个数，这里可以假定每个ackonly均应答2个下行包，因此，每次在判定当前上行包为ackonly包时，n加2。

在上行过程中，若是当前上行包是允许上行的ackonly包，则判定当前是否“受到拥塞窗口限制”。根据lte网络的rlc确认模式以及harq机制，可以认为底层的乱序包和丢失包能够被有效处理，因此底层的乱序和丢失反映到端到端即为底层的时延波动。

由于端到端一般不存在包的丢失，因此可以认为quic一直处于慢启动阶段，所以，当前对于是否“受到拥塞窗口限制”的判断，只需要比较当前正在传输的数据量与当前拥塞窗口一半的大小。若是当前正在传输的数据量大于当前拥塞窗口一半的大小，则说明当前“受到拥塞窗口限制”，此时在上行ackonly包时增大当前拥塞窗口的大小以及减小当前正在传输数据量的大小。

根据quic实现的cubic拥塞控制算法，quic每次増窗的大小为当前确认字节数的一半，由于ackonly一般确认的是2个下行包，每个下行包的大小定义为1350字节，则在“受到拥塞窗口限制”的情况下，quic服务器的拥塞窗口在每次收到ackonly后增加的大小为1350字节。因为quic数据包大部分都是1350字节，所以上行ackonly确认数据包时设定其确认的数据包大小均为1350字节，所以即便下行过程能够获得准确的下行包的包长，但是，也在每次下行一个下行包时，将正在传输的数据量增加1350字节。

在下行过程中，若是判定当前下行包为quic包并且可重传(比如数据包)，则更新当前正在传输的数据量，其更新公式为：当前正在传输的数据量＝正在传输的数据量+1350。

在上行过程中，基站若是判定当前接收到的上行包为quic的ackonly包，将当前被应答包计数n加2。之后对该ackonly包进行是否为大延迟的判定。若是能正常上行，则在n大于0的情况下，进入更新当前正在传输的数据量以及更新当前拥塞窗口大小的阶段，该阶段是循环更新的。

根据quic机制，对于每个被应答的包，服务器都会更新当前正在传输的数据量以及判断当前是否需要增加拥塞窗口大小。由于假定的quic数据包均为1350字节大小，因此对于每个被应答的数据包，首先比较当前正在传输的数据量与拥塞窗口一半的大小。若是当前正在传输的数据量大于拥塞窗口的一半，则增大拥塞窗口的大小，增大公式为：拥塞窗口大小＝拥塞窗口大小+675，之后减少当前正在传输的数据量；减小公式为：当前正在传输的数据量＝正在传输的数据量-1350；否则若是当前正在传输的数据量小于拥塞窗口的一半，则只减小当前正在传输的数据量。最后将n减1，若是此时n依然大于0，则重复这一更新过程。

服务器拥塞判断定时器：根据状态估计模块得到的srtt和cwnd，可以计算出quic服务器的pacingrate，即发包间隔。此定时器定时长度可以为发包间隔，或者发包间隔*保护间隔。如果此定时长度内没有收到下行包且定时长度期间没有发送过ackonly包，就认为当前quic服务器的发送进程被拥塞窗口卡住，基站需要尽快向quic服务器反馈ackonly包。

服务器超时判断定时器：此定时器的目的主要是避免因为过多的拦截ackonly包造成quic服务器出现rto超时，而最终导致发送降速。此定时器的时长可以设置为(2srtt-twired)，其中twired是从基站到quic服务器的传输时延。设置成此时长是为了保证发送的ackonly包能够在超时之前到达服务器。

在本申请实施例中，基站接收发送端发送的第一数据包；基站记录第一数据包的信息，以及向接收端发送第一数据包；基站接收该接收端发送的第二数据包；若基站确定第二数据包为与第一数据包对应的确认包，且确定第二数据包异常，则基站拦截第二数据包。因为异常确认包被基站拦截，所以，能够避免无线传输时延波动造成的quic降速，提高无线资源的利用效率，进而提升系统吞吐量。

需要说明的是，在上述实施例中，是先以服务器发送下行包，客户端收到下行包之后对应的反馈上行包为例进行说明的。当客户端先发送上行包，服务器收到上行包对应的反馈下行包，也是类似的。可以参考图4所示实施例中的说明，此处不再赘述。

上述本申请实施例中的拦截确认包的方法进行了说明，下面对本申请实施例中的接入网设备进行说明。如图8所示，图8为本申请实施例中接入网设备的一个实施例示意图。可以包括：

接收模块801，用于接收发送端发送的第一数据包；接收接收端发送的第二数据包；

发送模块802，用于向接收端发送第一数据包；

处理模块803，用于若接入网设备确定第二数据包为与第一数据包对应的确认包，且确定第二数据包异常，则拦截第二数据包。

可选的，在本申请的一些实施例中，

处理模块803，具体用于根据预先保存的映射表，确定第二数据包为与第一数据包对应的确认包，其中，映射表中保存有触发接收端反馈确认包，对应的发送端发送的数据包。

可选的，在本申请的一些实施例中，

处理模块803，还用于记录第一数据包的第一接收时刻；记录第二数据包的第二接收时刻；具体用于根据第一接收时刻和第二接收时刻，确定中间时长；若中间时长大于第一预置阈值，则确定第二数据包异常。

可选的，在本申请的一些实施例中，

发送模块802，还用于若接入网设备确定第一定时器超时，则向发送端发送第二数据包，其中，第一定时器用于计时接入网设备向发送端最近发送的确认包与当前时刻的时长。

可选的，在本申请的一些实施例中，

发送模块802，还用于若接入网设备确定第二定时器超时，则向发送端发送第二数据包，其中，第二定时器用于计时接入网设备接收发送端最近发送的第三数据包与当前时刻的时长。

如图9所示，图9为本申请实施例中接入网设备的另一个实施例示意图，可以包括：

收发器901、存储器902和处理器903，其中，收发器901、存储器902和处理器903互相之间通过总线连接；

收发器901，用于接收发送端发送的第一数据包；接收所述接收端发送的第二数据包；向接收端发送所述第一数据包；

处理器903，用于若所述接入网设备确定所述第二数据包为与所述第一数据包对应的确认包，且确定所述第二数据包异常，则拦截所述第二数据包。

可选的，在本申请的一些实施例中，

处理器903，具体用于根据预先保存的映射表，确定所述第二数据包为与所述第一数据包对应的确认包，其中，所述映射表中保存有触发所述接收端反馈确认包，对应的所述发送端发送的数据包。

可选的，在本申请的一些实施例中，

处理器903，还用于记录所述第一数据包的第一接收时刻；记录所述第二数据包的第二接收时刻；具体用于根据所述第一接收时刻和所述第二接收时刻，确定中间时长；若所述中间时长大于第一预置阈值，则确定所述第二数据包异常。

可选的，在本申请的一些实施例中，

收发器901，还用于若所述接入网设备确定第一定时器超时，则向所述发送端发送所述第二数据包，其中，所述第一定时器用于计时所述接入网设备向所述发送端最近发送的确认包与当前时刻的时长。

可选的，在本申请的一些实施例中，

收发器901，还用于若所述接入网设备确定第二定时器超时，则向所述发送端发送所述第二数据包，其中，所述第二定时器用于计时所述接入网设备接收所述发送端最近发送的第三数据包与当前时刻的时长。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如固态硬盘solidstatedisk(ssd))等。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。