确认包的处理方法、设备及系统与流程

确认包的处理方法、设备及系统本申请要求于2012年03月21日提交的申请号为PCT/CN2012/072726、发明名称为“确认包的处理方法、设备及系统”的国际专利申请的优先权，其全部内容通过引用结合在本申请中。技术领域本发明涉及通信技术领域，特别涉及一种确认包的处理方法、设备及系统。

背景技术：
传输控制协议(TransmissionControlProtocol，英文缩写为TCP)提供了一种面向连接的字节流服务，终端和服务器之间在建立连接后可以正常发送数据，并且使用TCP协议进行的数据传输具有数据包确认机制以及重传功能。在下行TCP业务中，服务器向终端发送数据包，终端在接收数据包后向服务器回复确认包，服务器根据收到的确认包来发送剩余的数据包。基于TCP业务的优点，TCP从传统的有线传输业务渐渐地运用到了无线传输业务上。现有技术中，由于传输控制协议/因特网互联协议(TransmissionControlProtocol/InternetProtocol，英文缩写为TCP/IP)是针对有线传输进行开发和设计的。当引入到无线系统后，例如长期演进(LongTermEvolution，英文缩写为LTE)系统，无线通信自身的限制会导致空口信号的波动，服务器可能在几毫秒或几百毫秒内接收不到终端回复的确认包，然后在空口信号波动消失后，服务器在短时间内收到大量的确认包。因此，现有技术由于缺少在新到达确认包时的区分处理方式，可能导致服务器需要根据收到的大量确认包而向终端下发大量的数据包的问题。同样，在上行数据传输上，当终端向服务器上传数据包的时候也会存在同样的问题。

技术实现要素：
本发明实施例提供一种确认包的处理方法、数据传输设备和通信系统，以解决数据包大量突发的技术问题。第一方面，本发明实施例提供一种确认包的处理方法，包括：发送确认包；更新当前发送周期内所有已发送的确认包反映的数据接收端已确认的总数据量；比较更新后的总数据量与数据量门限；根据比较结果控制在当前发送周期内是否继续发送确认包。第二方面，本发明实施例提供一种数据传输设备，包括：接收电路，用于接收确认包；发送电路，用于发送确认包；存储器，存储数据量门限；处理器，分别与所述接收电路、发送电路、存储器连接，用于更新当前发送周期内所有已发送的确认包反映的数据接收端已确认的总数据量，且比较更新后的总数据量与所述数据量门限，根据比较结果控制所述发送电路在当前发送周期内是否继续发送确认包。第三方面，本发明实施例提供一种数据传输设备，包括：发送单元，用于发送确认包；更新单元，用于更新当前发送周期内所有已发送的确认包反映的数据接收端已确认的总数据量；控制单元，用于比较更新后的总数据量与数据量门限，根据比较结果控制在当前发送周期内是否继续发送确认包。第四方面，本发明实施例提供一种通信系统，包括数据发送端、数据接收端以及如第二方面或第三方面所述的数据传输设备，其中所述数据发送端通过所述数据传输设备与数据接收端进行通信。第五方面，本发明实施例提供一种计算机程序产品，包括计算机可读介质，所述计算机可读介质包括一组程序代码，用于执行如第一方面所述的方法。可见，在以上各个方面，通过在数据传输设备上设置发送周期与数据量门限，从而利用数据量门限控制每个发送周期内数据传输设备发送给数据发送端的确认包满足所有发送的确认包反映的数据接收端已确认的总数据量在数据量门限之内，使得数据发送端在每个发送周期所接收到的确认包满足所有接收到的确认包反映的数据接收端已确认的总数据量在数据量门限之内，从而解决了数据接收端发送大量的数据包的问题。附图说明为了更清楚地说明本发明实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。图1为本发明一个实施例提供的确认包的处理方法流程图；图2为本发明另一个实施例提供的确认包的处理方法流程图；图3为本发明另一个实施例提供的确认包的处理方法流程图；图4为本发明另一个实施例提供的确认包的处理方法流程图；图5为本发明另一个实施例提供的确认包的处理方法流程图；图6为本发明另一个实施例提供的确认包的处理设备结构示意图；图7为本发明另一个实施例提供的确认包的处理设备结构示意图；图8为本发明实施例一提供的数据传输设备的结构示意图；图9为本发明实施例二提供的一种确认包处理方法的流程示意图；图10为本发明实施例二提供的一种更新总数据量方法的流程示意图；图11为本发明实施例三提供的一种确认包处理方法的流程示意图；图12为本发明实施例四提供的一种确认包的处理方法的流程示意图；图13为图12所示确认包的处理方法的步骤S122的详细流程示意图；图14为图13所示确认包的处理方法的步骤S131的详细流程示意图；图15本发明实施例五提供的一种确认包的处理方法的流程示意图；图16为本发明实施例六提供的一种数据传输设备的结构示意图；图17为本发明实施例七提供的一种确认包处理方法的流程示意图；图18为本发明实施例八提供的一种数据传输设备的结构示意图。具体实施方式下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。为使本发明技术方案的优点更加清楚，下面结合附图和实施例对本发明作详细说明。TCP/IP是针对有线传输进行开发和设计的，引入无线通信系统后，由于无线通信系统自身的限制会导致空口信号的波动。在下行数据传输上，服务器可能在几毫秒或几百毫秒内接收不到终端回复的确认包，然后在空口信号波动消失后，服务器在短时间内收到大量的确认包，导致服务器根据收到的大量确认包而向终端下发大量的数据包的问题。同样，在上行数据传输上，当终端向服务器上传数据包的时候也会存在同样的问题。本发明实施例考虑到此问题的存在，在数据传输设备上设置发送周期与数据量门限，从而利用数据量门限控制每个发送周期内数据传输设备发送给数据发送端的确认包满足所有发送的确认包反映的数据接收端已确认的总数据量在数据量门限之内，使得数据发送端在每个发送周期所接收到的确认包满足所有接收到的确认包反映的数据接收端已确认的总数据量在数据量门限之内，从而解决了数据接收端发送大量的数据包的问题。本发明实施例中所述的数据传输设备可以是无线网络中现有的数据传输节点设备，例如接入网设备、核心网设备，也可以是设置于接入网侧独立于现有接入网设备的数据传输设备，或者设置于核心网侧独立于现有核心网设备的数据传输设备。例如，所述数据传输设备可以为各种通信系统中的基站，如基站收发台(BaseTransceiverStation，BTS)、节点B(nodeB)、演进型节点B(EvolutionalNodeB，eNB或eNodeB)等；也可以是全球移动通信系统(GlobalSystemforMobileCommunications，GSM)中的基站控制器(BaseStationController，BSC)或通用移动通信系统(UniversalMobileTelecommunicationsSystem，UMTS)中的无线网络控制器(RadioNetworkController，RNC)，本发明不做任何限制。本发明实施例中的数据发送端可以为服务器，也可以为终端；相应的数据接收端可以为终端，也可以为服务器。例如，在上行数据传输中，数据发送端为终端、数据接收端为服务器；在下行数据传输中，数据发送端为服务器、数据接收端为终端。本发明不做任何限制。相应的，本发明实施例中的确认包可以为上行确认包，也可以为下行确认包。请参考图8，其为本发明实施例一提供的数据传输设备的结构示意图，如图所示，该数据传输设备800包括接收电路810、发送电路820、存储器830以及分别与接收电路810、发送电路820和存储器830连接的处理器840。其中，接收电路810用于接收确认包；发送电路820用于发送确认包；存储器830存储数据量门限；处理器840用于更新当前发送周期内所有已发送的确认包反映的数据接收端已确认的总数据量，且根据更新后的总数据量与存储器840存储的数据量门限，控制发送电路820在当前发送周期内是否继续发送确认包。以上数据传输设备在发送周期内会更新所有已发送的确认包反映的数据接收端已确认的总数据量，并比较更新后的总数据量与本地存储的数据量门限，根据比较结果控制当前发送周期内是否继续发送确认包，使得一个发送周期内达到数据发送端的确认包不至于太多，从而解决了数据发送端发送大量的数据包的问题。而数据发送端发送大量的数据包，可能会导致数据包传输不及时和丢包问题。例如，服务器的发送能力通常比较强，当其一定时间内接收到较多的确认包时，会根据接收到的确认包下发大量数据包，导致数据突发，而中间传输网元的发送能力往往不够，导致数据包传输不及时和丢包问题。而以上实施例相当于在中间传输网元上限制使用了服务器的发送能力，从而解决了数据发送端数据突发引起的数据包传输不及时和丢包问题。需要说明的是，本领域技术人员可以根据实际需要或者运营商的需求，自行设定数据量门限的取值或范围，本发明不做任何限制。例如，在下行数据传输中，由于服务器的处理能力比较强，而数据传输设备所在无线网络的承载能力无法满足服务器数据突发时带来的冲击，从而导致丢包和传输不及时的问题。此时，可以以承载网络的承载能力为依据，设置数据量门限。所述承载网络的承载能力可以为接入网与核心网之间的传输网元的承载能力，例如，交换机、路由器等的承载能力。再如，该数据量门限也可以受限于承载链路的限制速率，所述承载链路可以为接入网与核心网之间的链路。再如，该数据量门限也可以受限于数据传输设备所在无线网络的传输带宽。再如，一旦数据发送端或数据接收端的处理能力有限时，也可以根据数据发送端或数据接收端的处理能力来确定，例如，根据数据发送端的传输控制协议TCP发送窗口或数据接收端的TCP接收窗口确定。另外，关于更新当前发送周期内所有已发送的确认包反映的数据接收端已确认的总数据量，可以每发送一个确认包更新一次，也可以每发送两个或更多的确认包更新一次，也可以将发送周期分时段，前面时段，多个确认包更新一次，后面时段一个确认包更新一次。另外，也可以根据上一次更新后的结果，确定下一次更新所隔的确认包的个数。考虑到实现简单，可以每发送一个确认包更新一次，但本发明不做任何限制。相应于实施例一，本发明实施例二还提供一种确认包的处理方法。请参考图9，其为本发明实施例二提供的一种确认包处理方法的流程示意图。如图9所示，该方法包括如下步骤：S910：发送确认包；S920：更新当前发送周期内所有已发送的确认包反映的数据接收端已确认的总数据量；S930：比较更新后的总数据量与所述数据量门限；S940：根据比较结果控制在当前发送周期内是否继续发送确认包。以上确认包的处理方法在发送周期内会更新所有已发送的确认包反映的数据接收端已确认的总数据量，并比较更新后的总数据量与本地存储的数据量门限，根据比较结果控制当前发送周期内是否继续发送确认包，使得一个发送周期内达到数据发送端的确认包不至于太多，从而解决了数据发送端发送大量的数据包的问题。而数据发送端发送大量的数据包，可能会导致数据包传输不及时和丢包问题。例如，服务器的发送能力通常比较强，当其一定时间内接收到较多的确认包时，会根据接收到的确认包下发大量数据包，导致数据突发，而中间传输网元的发送能力往往不够，导致数据包传输不及时和丢包问题。而以上实施例相当于在中间传输网元上限制使用了服务器的发送能力，从而解决了数据发送端数据突发引起的数据包传输不及时和丢包问题。关于数据量门限和更新总数据量的说明，同实施例一，在此不再赘述。下面对处理器840更新总数据量的过程或以上步骤S920更新总数据量的过程进行详细说明。以上总数据量的更新，可以根据确认包的确认包序号进行。所述确认包的确认包序号为TCPACK的序号，该TCPACK的序号表示该序号以前的数据均已被数据接收端确认。因此，每发送一个确认包便可以根据当前发送的确认包与上一个发送的确认包的序号之差，确定当前发送的确认包所反映的数据接收端所确认的数据量。如此，便可以利用每个确认包所反映的数据接收端所确认的数据量，更新一个发送周期内所发送的所有确认包所反映的数据接收端所确认的总数据量。例如，假设某一个发送的确认包序号为747337662，其表示该第747337662字节以前的数据均已被数据接收端确认；且在该确认包之后发送的确认包序号为747340582，其表示该第747340582字节以前的数据均已接收。此时，更新后的总数据量＝更新前的总数据量+(747340582-747337662)。即，如图10所示，以上步骤S920：更新当前发送周期内所有已发送的确认包反映的数据接收端已确认的总数据量，进一步可以包括：S101：根据当前发送的确认包的确认包序号与上一个发送的确认包的确认包序号之差，确定当前发送的确认包反映的数据接收端所确认的数据量；S102：根据所述当前发送的确认包反映的数据接收端所确认的数据量，更新所述总数据量。需要说明的是，确认包的确认包序号通常以n位二进制的形式来表示，当编号到其所能表达的最大数值时，将重新开始编号，这种情况称为绕回现象。当当前发送的确认包的确认包序号发生绕回时，其与上一个确认包之差就会出现负值，按以上方法更新就会出现问题。因此，当当前发送的确认包的确认包序号发生绕回时，可以不做更新，即保持总数据量不变。此时，虽然少计算了一个确认包所反映的数据量，但是并不影响实现的效果。这是因为，本发明实施例并不是要把一个发送周期内发送给数据发送端的确认包所反映的总数据量严格控制在数据量门限以内，而是要控制在数据量门限左右，即使超过数据量门限一个确认包所反映出的数据量，并不会影响本发明的实质，且也不会对方案的效果实现造成实质上的影响。下面对处理器840根据比较结果控制发送电路820在当前发送周期内是否继续发送确认包的过程或步骤S940根据比较结果控制在当前发送周期内是否继续发送确认包的过程进行详细说明。当更新后的总数据量大于数据量门限时，停止在当前发送周期内发送确认包，具体可以通过处理器840控制发送电路820在当前发送周期内停止发送确认包来实现。当更新后的总数据量小于数据量门限时，可以继续在当前发送周期内发送确认包，具体可以通过处理器840控制发送电路820在当前发送周期内继续发送确认包来实现。下面对当更新后的总数据量等于数据量门限时的处理方式进行说明。此时，可以在当前发送周期内停止发送确认包，也可以继续发送确认包。例如，处理器840可以控制发送电路820在当前发送周期内停止发送确认包，也可以控制发送电路820在当前发送周期内继续发送确认包。这是因为，本发明实施例并不是要把一个发送周期内数据传输设备800发送给数据发送端的确认包所反映的数据接收端已确认的总数据量严格控制在数据量门限以内，而是要控制在数据量门限左右，即使超过数据量门限一个确认包所反映出的数据量，也不会对方案的效果实现造成实质上的影响。另外，也可以以包括数据量门限一定范围的取值作为停止和继续发送确认包的依据。例如，在比较更新后的总数据量和数据量门限时，发现更新后的总数据量接近数据量门限，但还未达到时，也可以停止发送确认包。总之，本发明对比较更新后的总数据量与所述数据量门限，根据比较结果控制所述发送电路在当前发送周期内是否继续发送确认包的过程没有严格限制，只要将一个发送周期内发送给数据发送端的确认包所反映的数据接收端已确认的总数据量控制在数据量门限左右即可，本领域技术人员可据此做变通，得到不同实施例，均在本发明的保护范围内。因此，在具体实现上，本实施例可以有多种实现方式，下面进行举例说明，然而，这些例子并非用于限制本发明。请参考图11，其为本发明实施例三提供的一种确认包处理方法的流程示意图。该方法的执行主体为数据传输设备，该数据传输设备预存有数据量门限，且利用发送序列号(SendSeq)体现一个发送周期内所有已发送的确认包反映的数据接收端已确认的总数据量。如图11所示，该方法包括如下步骤：S110：在发送周期开始时，将SendSeq置零；而后，在当前发送周期内每发送一个确认包，更新一次SendSeq，且每次更新SendSeq之后，判断更新后的SendSeq与数据量门限之间的关系。即在当前发送周期内，重复执行以下步骤S111至S113，直至当前发送周期结束或者更新后的SendSeq大于数据量门限。S111：发送确认包；S112：更新SendSeq；S113：确定更新后的SendSeq与数据量门限之间的关系。如果更新后的SendSeq小于数据量门限，则继续执行步骤S111至S113；如果更新后的SendSeq大于数据量门限，则执行步骤S114。S114：在当前发送周期内暂停发送确认包直至当前发送周期结束，在下一个发送周期将SendSeq置零后继续发送确认包。关于数据量门限的说明同实施例一，在此不再赘述。在本实施例中，SendSeq可以通过确认包序号之差确定的，其中确认包序号用于表示该确认包序号之前的数据均已被数据接收端确定，那么两个确认包序号之差便可以反映出当前所发送的确认包对应的已确定的数据量，且，每发送一个确认包，通过发送的确认包对应的已确定的数据量进行累加来对SendSeq进行更新，更新后的SendSeq便可以反映出一个周期内数据传输设备已发送的确认包所反映的已确定的总数据量。从而通过对SendSeq的监控来控制一个发送周期内发送的确认包数量，以解决数据发送端发送大量的数据包的问题，进而解决了由其导致的数据包传输不及时和丢包问题。需要说明的是，如果更新后的SendSeq等于数据量门限，可以暂停发送确认包直至当前发送周期结束，在下一发送周期将发送序列号置零后继续发送确认包。也可以继续发送确认包，其原因同以上实施例，在此，不再赘述。在以上步骤S112更新SendSeq的过程中，更新后的SendSeq与更新前的SendSeq之间的关系如下：更新后的SendSeq＝更新前的SendSeq+Max(0，第一确认包的确认包序号-第二确认包的确认包序号)；其中，Max()表示取最大值，所述第一确认包和所述第二确认包为数据传输设备连续向数据发送端发送的两个确认包，其中第一确认包为更新SendSeq之前最近发送的确认包，第二确认包为在第一确认包之前发送的确认包。为了在更新SendSeq可以使用第二确认包的确认包序号，需要在发送第二确认包之前存储该确认包序号，故第二确认包的确认包序号也即数据传输设备已存储的确认包序号。即，更新后的SendSeq＝更新前的SendSeq+Max(0，更新SendSeq之前最近发送的确认包的确认包序号-已存储的确认包序号)。可见，在SendSeq的更新过程中，每发送一个确认包，则以该确认包的确认包序号更新已存储的确认包序号。即，在更新所述SendSeq之后，所述方法还包括：更新已存储的确认包的确认包序号；其中，更新已存储的确认包序号时，如果更新SendSeq之前最近发送的确认包的确认包序号大于已存储的确认包序号，或者更新SendSeq之前最近发送的确认包的确认包序号与已存储的确认包序号的差值小于预设值，以所述更新SendSeq之前最近发送的确认包的确认包序号更新当前已存储的确认包序号；否则，说明前后发送的两个确认包序号相同，则可以保持已存储的确认包序号不变，其中所述预设值是根据确认包序号的位数确定的。当确认包序号利用n位字符来表示时，所述预设值为-2n-1。当更新发送序列号之前最近发送的确认包的确认包序号与已存储的确认包序号的差值小于预设值时，则表明发生了绕回，即确认包重新从“0”开始编号，以所述更新发送序列号之前最近发送的确认包的确认包序号更新当前已存储的确认包序号，以方便后续的SendSeq更新。另外，在发生绕回的时候，可以不更新SendSeq，即更新后的SendSeq＝更新前的SendSeq+Max(0，-2n-1)＝更新前的SendSeq。此时，虽然会引起多发送一个确认包，但并不会对方案的效果实现造成实质上的影响。例如，利用32位字符来表示，此时所述预设值为-2147483648。当更新发送序列号之前最近发送的确认包的确认包序号与已存储的确认包序号的差值小于-2147483648时，则表明发生了绕回，则可以不更新SendSeq，但更新已存储的确认包序号。在本发明一实施例中，可以通过在数据传输设备内设置定时器，以通过定时器来实现以上发送周期的控制，其中，所述定时器的时长等于所述发送周期。此时，以上步骤S110，即在发送周期开始时，将发送序列号置零可以通过以下方式实现：启动所述定时器，将发送序列号置零。以上步骤S114，即在当前发送周期内暂停发送确认包直至当前发送周期结束，在下一个发送周期将SendSeq置零后继续发送确认包可以通过以下方式实现：在定时器到时时，重启所述定时器，将发送序列号置零后继续发送确认包。请继续参考图12，其为本发明实施例四提供的一种确认包的处理方法的流程示意图。该方法的执行主体为数据传输设备，且利用SendSeq体现一个发送周期内所有已发送的确认包反映的数据接收端已确认的总数据量。如图12所示，该方法包括如下步骤：S120：接收新确认包；S121：确定是否已缓存有其他确认包；如果已缓存有其他确认包则执行步骤S122，否则执行步骤S123。S122：缓存所述新确认包，以在向数据发送端发送所述其他确认包之后发送所述新确认包；S123：确定当前SendSeq与数据量门限之间的关系，如果当前SendSeq大于数据量门限，则执行步骤S124；如果当前SendSeq小于数据量门限，则执行步骤S125。S124：缓存所述新确认包，并在下一个发送周期将SendSeq置零后向数据发送端发送所述新确认包；S125：向数据发送端发送所述新确认包。需要说明的是，当更新后的发送序列号等于数据量门限时，可以暂停发送确认包直至当前发送周期结束，在下一发送周期将发送序列号置零后继续发送确认包，也可以继续发送确认包。请继续参考图13，以上步骤S122在向数据发送端发送所述其他确认包之后发送所述新确认包可以包括以下步骤：S131：发送所述其他确认包；S132：更新SendSeq；S133：确定更新后的SendSeq与数据量门限之间的关系，如果更新后的SendSeq小于数据量门限，则执行步骤S134，如果更新后的SendSeq大于数据量门限，则执行步骤S135。对于更新后的SendSeq等于数据量门限时，可以执行步骤S134，也可以执行步骤S135，理由同以上描述，在此不再赘述。S134：发送所述新确认包；S135：暂停发送所述新确认包直至当前发送周期结束，在下一发送周期将发送序列号置零后发送所述新确认包。需要说明的是，数据传输设备在接收到新确认包时，其内可能缓存一个其他确认包，也可能缓存多个。即，所述其他确认包可以是多个也可以是一个。且请参考图14，当所述其他确认包为多个时，以上步骤S131，即发送所述其他确认包可以包括：按队列顺序逐一发送所述其他确认包，且每发送一个确认包，重复以下步骤，直至将所述其他确认包都发送完：S141：更新SendSeq；S142：确定更新后的SendSeq与数据量门限之间的关系；如果更新后的SendSeq小于数据量门限，执行步骤S143，如果更新后的SendSeq大于数据量门限，则执行步骤S144。对于更新后的SendSeq等于数据量门限时，可以执行步骤S143，也可以执行步骤S144，理由同以上描述，在此不再赘述。S143：继续发送下一个确认包；S144：暂停发送确认包直至当前发送周期结束，在下一发送周期将发送序列号置零后继续发送下一个确认包。关于SendSeq的更新过程同实施例三，在此不再赘述。且在本实施例中，也可以通过在数据传输设备内设置定时器，以通过定时器来实现以上发送周期的控制，其中，所述定时器的时长等于所述发送周期。需要说明的是，在以上实施例三和四中，均在发送周期开始时将SendSeq置零，并以此为基础根据发送确认包反映的已确认的数据量来更新SendSeq。其仅为举例，在其它实施例中，也可以将SendSeq置“1”或其它数值，并据此调整数据量门限即可，甚至在SendSeq置“1”等较小值，而不影响本发明效果实现时，也可以不调整数据量门限，总之本发明实施例对此不做任何限制。例如，在本发明实施例五中，在发送周期开始时，将SendSeq设置为数据量门限，且在每发送一个确认包之后，以递减的方式更新SendSeq，并在递减至零或者小于零时，停止本周期内确认包的发送。请参考图15，此时，确认包的处理方法，包括以下步骤：S150：在发送周期开始时，将SendSeq设置为数据量门限；而后，在当前发送周期内每发送一个确认包，更新一次SendSeq，且每次更新SendSeq之后，判断更新后的SendSeq与零之间的关系。即在当前发送周期内，重复执行以下步骤S151至S153，直至当前发送周期结束或者更新后的SendSeq小于零。S151：发送确认包；S152：更新SendSeq；S153：确定更新后的SendSeq与零之间的关系。如果更新后的SendSeq大于零，则继续执行步骤S151至S153；如果更新后的SendSeq小于零，则执行步骤S154。S154：在当前发送周期内暂停发送确认包直至当前发送周期结束，在下一个发送周期将SendSeq设置为数据量门限后继续发送确认包。此时，SendSeq的更新如下：更新后的SendSeq＝更新前的SendSeq-Max(0，第一确认包的确认包序号-第二确认包的确认包序号)；其中，Max()表示取最大值，所述第一确认包和所述第二确认包为数据传输设备连续向数据发送端发送的两个确认包，其中第一确认包为更新SendSeq之前最近发送的确认包，第二确认包为在第一确认包之前发送的确认包。为了在更新SendSeq可以使用第二确认包的确认包序号，需要在发送第二确认包之前存储该确认包序号，故第二确认包的确认包序号也即接入网设备已存储的确认包序号。即，更新后的SendSeq＝更新前的SendSeq-Max(0，更新发送序列号之前最近发送的确认包的确认包序号-已存储的确认包序号)。可见，在SendSeq的更新过程中，每发送一个确认包，则以该确认包的确认包序号更新已存储的确认包序号。即，在更新所述SendSeq之后，所述方法还包括：更新已存储的确认包的确认包序号；其中，更新已存储的确认包序号同实施例三，在此不再赘述。另外，关于当更新后的SendSeq等于零的情况，可以暂停发送确认包直至当前发送周期结束，在下一发送周期将发送序列号设置为数据量门限后继续发送确认包。也可以继续发送确认包。请继续参考图16，其为本发明实施例六提供的一种数据传输设备的结构示意图，如图16所示，该数据传输设备160包括接收电路161、发送电路162、存储器163和处理器164。其中，接收电路161用于接收确认包；发送电路162用于发送确认包；存储器163存储数据量门限；处理器164分别与接收电路161、发送电路162、存储器163连接，处理器164用于更新数据量门限与总数据量的差，所述总数据量为当前发送周期内所有已发送的确认包反映的数据接收端已确认的总数据量，且处理器164还用于根据更新后数据量门限与总数据量的差控制发送电路162在当前发送周期内是否继续发送确认包。可见，本实施例与实施例一的区别在于处理器164以数据量门限基础，更新数据量门限与总数据量的差，并根据这个差来控制162在当前发送周期内是否继续发送确认包。由于数据量门限是预设好的，数据量门限与总数据量的差的变化实际上就反映了总数据量的变化，因此，利用该差控制发送周期内是否继续发送确认包可以达到与实施例一相同的效果。相应于实施例六，本发明实施例七还提供一种确认包的处理方法。请参考图17，其为本发明实施例七提供的一种确认包处理方法的流程示意图。如图17所示，该方法包括如下步骤：S171：发送确认包；S172：更新数据量门限与总数据量的差，所述总数据量为当前发送周期内所有已发送的确认包反映的数据接收端已确认的总数据量；S173：根据更新后数据量门限与总数据量的差控制在当前发送周期内是否继续发送确认包。关于实施例六和七中数据量门限的说明，同实施例一，在此不再赘述。而更新数据量门限与总数据量的差的方式与频率，例如，同实施例一的描述，在此不再赘述。下面对处理器164更新数据量门限与总数据量的差的过程或以上步骤S172更新总数据量的过程进行说明。更新数据量门限与总数据量的差，就是以数据量门限为基础，更新总数据量的过程，而该总数据量的更新同以上实施例一，且在每次更新总数量之后，将数据量门限与总数据量作差，便可以得到更新后的数据量门限与总数据量的差。且，当当前确认包序号发生绕回时，同样可以不做更新。具体，在发送周期开始时，可以以数据量门限为基础，开始进行更新，且每发送一个确认包，将该确认包反映的数据接收端所确认的数据量进行递减，当递减到零或者接近零时，停止本发送周期内的确认包发送。请继续参考图18，其为本发明实施例八提供的一种数据传输设备的结构示意图。如图18所示，该设备包括发送单元181、更新单元182和控制单元183，其中，发送单元181用于发送确认包；更新单元182用于更新当前发送周期内所有已发送的确认包反映的数据接收端已确认的总数据量；控制单元183用于比较更新后的总数据量与所述数据量门限，根据比较结果控制在当前发送周期内是否继续发送确认包。关于数据量门限的说明，同实施例一，在此不再赘述。另外，关于更新单元182的更新过程以及控制单元183的控制过程，同实施例一的描述，在此不再赘述。本发明各实施例中的确认包可以为上行确认包，这里的上行指终端设备至基站)，或者终端设备至无线网络控制器(RadioNetworkController，英文缩写为RNC)，或者终端设备至服务器等。本发明的一个实施例提供一种确认包的处理方法，如图1所示，所述方法包括如下步骤。100、到达新确认包。101、第一实体确定是否已缓存有其他确认包，如果已缓存有其他确认包，则执行步骤102；否则，视不同情况执行步骤103至步骤105中的一项。102、缓存所述新确认包，并在发送所述其他确认包之后发送所述新确认包。103、如果所述第一实体的定时器未启动，则启动所述定时器，并发送所述新确认包。104、如果所述第一实体的定时器已启动，且发送序列号SendSeq大于确认包发送门限，则缓存所述新确认包，并重启所述定时器，在所述定时器超时之前发送所述新确认包。105、如果所述第一实体的定时器已启动，且发送序列号SendSeq小于或等于确认包发送门限，则发送所述新确认包。其中，所述SendSeq为所述第一实体在所述定时器启动后发送的确认包的总数据量，所述确认包发送门限为所述第一实体在所述定时器的时长内被允许发送的确认包的总数据量。可选的，在所述定时器启动或重启时，所述SendSeq的取值为0；在发送所述新确认包之后，所述方法还包括：更新所述SendSeq。例如，如果已缓存有其他确认包，则缓存所述新确认包包括：将所述新确认包缓存在所述其他确认包之后；所述在发送所述其他确认包之后发送所述新确认包包括：在所述第一实体的定时器超时时，将缓存中的确认包按队列顺序逐一发送。可选的，在步骤102之后，所述方法还包括：每发送一个确认包，执行一次更新所述Sendseq。可选的，在步骤102之后，所述方法还包括：每执行一次更新所述Sendseq之后，确定更新后的Sendseq是否大于所述确认包发送门限；如果在发送所述新确认包之前，更新后的Sendseq大于所述确认包发送门限，则停止发送所述第一实体中已缓存的确认包，重启所述定时器，在所述定时器超时之前发送所述新确认包。例如，更新所述Sendseq时，更新后的SendSeq与更新前的SendSeq之间的关系为：更新后的SendSeq＝更新前的SendSeq+Max(0，第一确认包的确认包序号-第二确认包的确认包序号)；其中，所述第一确认包和所述第二确认包为所述第一实体连续发送的前后两个确认包。进一步的，在更新所述SendSeq之后，所述方法还包括：更新确认包的确认包序号；其中，更新所述第二确认包的确认包序号时，如果所述第一确认包的确认包序号大于所述第二确认包的确认包序号，或者所述第一确认包的序号与所述第二确认包的确认包序号的差值小于-2147483648，则将所述第一确认包的确认包序号作为所述第二确认包的确认包序号；否则，将所述第一实体读取到的所述第二确认包的确认包序号作为所述第二确认包的确认包序号。其中，所述确认包发送门限的取值为平均发送字节速度AvgSendByte与所述定时器的时长的乘积，所述AvgSendByte是根据聚合最大比特速率AMBR和最大吞吐率MaxThroughput确定的，其中：当MaxThroughput为0时，其中，符号位表示向下取整；当MaxThroughput不为0时，其中，符号位表示向下取整。其中，所述定时器的时长为所述第一实体发送确认包的周期，所述确认包为不大于80字节、且包含确认字符的上行数据包。进一步的，当到达新确认包时，如果不存在用于缓存和发送所述新确认包的第一实体，则所述方法还包括：建立所述第一实体，所述第一实体位于基站。可选的，本实施例中的第一实体可以是基站，例如NodeB、eNodeB、HNodeB或HeNodeB，也可以是RNC。与现有技术相比，本发明实施例能够在第一实体接收到确认包后，对确认包进行处理，为确认包设置发送周期以及发送数据量门限，控制每个发送周期内向服务器发送的确认包的总数据量，进而控制确认包的数量，以使确认包能够以平稳的速率发送到达服务器，避免因确认包数量突增，以及由其导致的下行数据包传输不及时和丢包问题，进而避免网络吞吐量下降，并提高网络传输效率。本发明的另一个实施例提供一种确认包的处理方法，如图2所示，所述方法包括如下步骤。200、到达新确认包。201、第二实体确定是否存在用于缓存和发送所述新确认包的第一实体，，如果存在所述第一实体，则执行步骤202；否则，视不同情况执行步骤203至步骤205中的一项。202、将所述确认包发送给所述第一实体。203、如果不存在所述第一实体，已存在的第三实体的个数小于第二门限m，且已缓存有确认包的第三实体的个数不大于第三门限n，则建立所述第一实体，并将所述新确认包发送给所述第一实体。204、如果不存在所述第一实体，已存在的第三实体的个数不小于第二门限m，且已缓存有确认包的第三实体的个数不大于第三门限n，则删除至少一个未缓存有确认包的第三实体，并建立所述第一实体，将所述新确认包发送给所述第一实体。205、如果不存在所述第一实体，且已缓存有确认包的第三实体的个数大于第三门限n，向服务器发送所述新确认包。其中，所述m为允许建立的用于缓存和发送确认包的实体的个数上限，所述n为允许同时缓存有确认包的第三实体的个数上限。可选的，本实施例中的第一实体可以是基站，例如NodeB、eNodeB、HNodeB或HeNodeB，也可以是RNC。与现有技术相比，本发明实施例能够在有新确认包到达第二实体时，第二实体为所述新确认包设置针对新到达的确认包进行判断以决定缓存和/或发送等处理方式的第一实体，通过第一实体对确认包进行处理，以使确认包能够以平稳的速率发送到达服务器，避免因确认包数量突增，以及由其导致的下行数据包传输不及时和丢包问题，进而避免网络吞吐量下降，并提高网络传输效率。本发明的另一个实施例提供一种确认包的处理方法，该实施例的细节可视为前两个实施例的举例。如图3所示，所述方法包括如下步骤：301、当到达新确认包时，第二实体确定是否存在用于缓存和发送所述新确认包的第一实体，如果不存在第一实体，执行步骤302；如果存在第一实体，执行步骤303。其中，确认包应满足三个条件：数据包的方向为上行；数据包的大小不大于80字节；数据包包含确认字符(Acknowledgement，英文缩写为ACK)。所述第一实体为基站中处理确认包的操作单元，实体在被建立时带有源IP、目的IP、源端口号、目的端口号、定时器、确认包序号和发送序列号SendSeq等参数。其中，LastSeq表示前面一个被发送的确认包的序号，SendSeq为所述第一实体在所述定时器启动后发送的确认包的总数据量，初始化时，确认包序号和SendSeq均为0。302、第二实体为新确认包建立对应的第一实体。可选的，所述方法还包括：如果不存在所述第一实体，已存在的第三实体的个数小于第二门限m，且已缓存有确认包的第三实体的个数不大于第三门限n，则建立所述第一实体，并将所述新确认包发送给所述第一实体；如果不存在所述第一实体，已存在的第三实体的个数不小于第二门限m，且已缓存有确认包的第三实体的个数不大于第三门限n，则删除至少一个未缓存有确认包的第三实体，并建立所述第一实体，将所述新确认包发送给所述第一实体。可选的，所述方法还包括：如果不存在所述第一实体，且已缓存有确认包的第三实体的个数大于第三门限n，向服务器发送所述新确认包；其中，所述m为允许建立的用于缓存和发送确认包的实体的个数上限，所述n为允许同时缓存有确认包的第三实体的个数上限。303、第二实体将新确认包发送给第一实体。304、当新确认包到达时，如果第一实体已缓存有其他确认包，则将新确认包缓存在其他确认包之后。305、第一实体判断定时器是否超时，如果定时器超时，执行步骤307；如果定时器未超时，执行步骤306。其中，所述定时器的时长为所述第一实体发送确认包的周期。306、第一实体按照队列顺序和发送间隔向服务器发送确认包，每发送一个确认包，执行一次更新所述Sendseq，当更新后的Sendseq大于确认包发送门限后，停止发送确认包，执行步骤308。其中，SendSeq为所述第一实体在定时器启动后发送的确认包的总数据量，所述确认包发送门限为所述第一实体在所述定时器的时长内被允许发送的确认包的总数据量，确认包发送门限的取值为平均发送字节速度AvgSendByte与所述定时器的时长的乘积，所述AvgSendByte是根据聚合最大比特速率AMBR和最大吞吐率MaxThroughput确定的，其中：当MaxThroughput为0时，其中，符号位表示向下取整；当MaxThroughput不为0时，其中，符号位表示向下取整。具体的，更新所述Sendseq时，更新后的SendSeq与更新前的SendSeq之间的关系为：更新后的SendSeq＝更新前的SendSeq+Max(0，第一确认包的确认包序号-第二确认包的确认包序号)；其中，所述第一确认包和所述第二确认包为所述第一实体连续发送的前后两个确认包。可选的，在更新所述SendSeq之后，还要相应更新确认包的确认包序号；其中，更新所述第二确认包的确认包序号时，如果所述第一确认包的确认包序号大于所述第二确认包的确认包序号，或者所述第一确认包的序号与所述第二确认包的确认包序号的差值小于-2147483648，则将所述第一确认包的确认包序号作为所述第二确认包的确认包序号；否则，将所述第一实体读取到的所述第二确认包的确认包序号作为所述第二确认包的确认包序号。307、第一实体将缓存中的确认包按队列顺序逐一发送给服务器，每发送一个确认包，执行一次更新所述Sendseq，直至更新后的Sendseq大于确认包发送门限，停止发送确认包。308、第一实体重启所述定时器，在下一个发送周期发送新确认包。需要说明的是，本实施例中的第一实体、第二实体和第三实体可以均位于基站。与现有技术相比，本发明实施例中当有新确认包到达时，第二实体查找或建立第一实体，将所述新确认包发送给第一实体，第一实体将所述确认包缓存在其他确认包之后进行发送，同时为确认包设置发送周期以及发送数据量门限，控制每个发送周期内向服务器发送的确认包的总数据量，进而控制确认包的数量，以使确认包能够以平稳的速率发送到达服务器，避免因确认包数量突增，以及由其导致的下行数据包传输不及时和丢包问题，进而避免网络吞吐量下降，并提高网络传输效率。本发明的另一个实施例提供一种确认包的处理方法，该实施例与上一实施例相比区别在于，当有新确认包到达第一实体时，第一实体没有缓存其他确认包，并且未启动定时器，如图4所示，所述方法包括如下步骤：401、第二实体将新确认包发送给第一实体。其中，第一实体的查找与建立过程参照上一实施例的步骤301-步骤302。402、当新确认包到达时，如果第一实体未缓存有其他确认包，且第一实体的定时器未启动，则向服务器发送新确认包，并更新发送序列号SendSeq。其中，所述定时器的时长为所述第一实体发送确认包的周期，所述SendSeq为所述第一实体在所述定时器启动后发送的确认包的总数据量。具体的，更新所述Sendseq时，更新后的SendSeq与更新前的SendSeq之间的关系为：更新后的SendSeq＝更新前的SendSeq+Max(0，第一确认包的确认包序号-第二确认包的确认包序号)；其中，所述第一确认包和所述第二确认包为所述第一实体连续发送的前后两个确认包。可选的，在更新所述SendSeq之后，还要相应更新确认包的确认包序号；其中，更新所述第二确认包的确认包序号时，如果所述第一确认包的确认包序号大于所述第二确认包的确认包序号，或者所述第一确认包的序号与所述第二确认包的确认包序号的差值小于-2147483648，则将所述第一确认包的确认包序号作为所述第二确认包的确认包序号；否则，将所述第一实体读取到的所述第二确认包的确认包序号作为所述第二确认包的确认包序号。需要说明的是，本实施例中的第一实体、第二实体和第三实体可以均位于基站。与现有技术相比，本发明实施例中当有新确认包到达时，第二实体查找或建立第一实体，将所述新确认包发送给第一实体，第一实体在没有缓存其他确认包且没有启动定时器时，为所述新确认包启动定时器，并将所述新确认包发送给服务器，同时为确认包设置发送周期以及发送数据量门限，控制每个发送周期内向服务器发送的确认包的总数据量，进而控制确认包的数量，以使确认包能够以平稳的速率发送到达服务器，避免因确认包数量突增，以及由其导致的下行数据包传输不及时和丢包问题，进而避免网络吞吐量下降，并提高网络传输效率。本发明的另一个实施例提供一种确认包的处理方法，该实施例与前两个实施例相比区别在于，当有新确认包到达第一实体时，第一实体没有缓存其他确认包，并且定时器已启动，如图5所示，所述方法包括如下步骤：501、第二实体将新确认包发送给第一实体。其中，第一实体的查找与建立过程参照第三个实施例的步骤301-步骤302。502、当新确认包到达时，如果第一实体未缓存有其他确认包，且第一实体的定时器已启动，第一实体确定发送序列号SendSeq是否大于确认包发送门限，如果SendSeq大于确认包发送门限，执行步骤506；如果SendSeq不大于确认包发送门限，执行步骤505。其中，所述SendSeq为所述第一实体在所述定时器启动后发送的确认包的总数据量，所述确认包发送门限为所述第一实体在所述定时器的时长内被允许发送的确认包的总数据量，所述定时器的时长为所述第一实体发送确认包的周期。例如，所述确认包发送门限的取值为平均发送字节速度AvgSendByte与所述定时器的时长的乘积：所述AvgSendByte是根据聚合最大比特速率AMBR和最大吞吐率MaxThroughput确定的，其中：当MaxThroughput为0时，其中，符号位表示向下取整；当MaxThroughput不为0时，其中，符号位表示向下取整。503、第一实体向服务器发送新确认包，并更新发送序列号SendSeq。可选的，如果更新后的SendSeq大于发送门限，则停止发送后续的确认包。例如，更新后的SendSeq＝更新前的SendSeq+Max(0，第一确认包的确认包序号-第二确认包的确认包序号)；其中，所述第一确认包和所述第二确认包为所述第一实体连续发送的前后两个确认包。可选的，在更新所述SendSeq之后，还要相应更新确认包的确认包序号；其中，更新所述第二确认包的确认包序号时，如果所述第一确认包的确认包序号大于所述第二确认包的确认包序号，或者所述第一确认包的序号与所述第二确认包的确认包序号的差值小于-2147483648，则将所述第一确认包的确认包序号作为所述第二确认包的确认包序号；否则，将所述第一实体读取到的所述第二确认包的确认包序号作为所述第二确认包的确认包序号。504、第一实体缓存所述新确认包，并重启所述定时器，在所述定时器超时之前发送所述新确认包。需要说明的是，本实施例中的第一实体、第二实体和第三实体可以均位于基站。与现有技术相比，本发明实施例中当有新确认包到达时，第二实体查找或建立第一实体，将所述新确认包发送给第一实体，第一实体在没有缓存其他确认包并且已经启动定时器后，确定当前的发送序列号Sendseq是否超过了数据量门限，如果没有超过门限则直接发送新确认包，如果超过门限则重启定时器，在下一个发送周期发送新确认包。通过控制每个发送周期内向服务器发送的确认包的总数据量，进而控制确认包的数量，以使确认包能够以平稳的速率发送到达服务器，避免因确认包数量突增，以及由其导致的下行数据包传输不及时和丢包问题，进而避免网络吞吐量下降，并提高网络传输效率。本发明实施例还提供用于执行上述实施例提供的方法的设备，以下做举例说明。为描述方便，下述举例涉及的可选描述和细节描述等未作详细说明，可参照上述方法实施例中的举例。本发明的另一个实施例提供一种确认包的处理设备，如图6所示，所述设备包括第一接收器61、第一处理器62、存储器63、第一发送器64和定时器65，其中：所述第一接收器61用于接收确认包；所述存储器63用于缓存所述第一接收器61接收的确认包；所述第一发送器64用于发送所述存储器63缓存的确认包；所述第一处理器62用于当新确认包到达所述第一接收器61时，如果确定所述存储器63已缓存有其他确认包，则触发所述存储器63缓存所述新确认包，并命令所述第一发送器64在发送所述其他确认包之后发送所述新确认包；或者，当新确认包到达所述第一接收器61时，如果确定所述存储器63未缓存有其他确认包，且所述定时器65未启动，则触发所述定时器65启动，并触发所述第一发送器64发送所述新确认包；或者，当新确认包到达所述第一接收器61时，如果确定所述存储器63未缓存有其他确认包，所述定时器65已启动，且发送序列号SendSeq大于确认包发送门限，则触发所述存储器63缓存所述新确认包，触发所述定时器65重启，以及命令所述第一发送器64在所述定时器65超时之前发送所述新确认包；或者，当新确认包到达所述第一接收器61时，如果确定所述存储器63未缓存有其他确认包，所述定时器65已启动，且发送序列号SendSeq小于或等于确认包发送门限，则触发所述第一发送器64发送所述新确认包；其中，所述SendSeq为所述定时器65启动后发送的确认包的总数据量，所述确认包发送门限为在所述定时器65的时长内被允许发送的确认包的总数据量。可选的，所述第一处理器62还用于：在所述第一发送器64发送所述新确认包之后，更新所述SendSeq。例如，所述存储器63具体用于：将所述新确认包缓存在所述其他确认包之后；所述第一发送器64具体用于：在所述定时器65超时时，将所述存储器63中缓存的确认包按队列顺序逐一发送。可选的，所述第一处理器62还用于：在所述第一发送器64发送每发送一个确认包之后，执行一次更新所述Sendseq。可选的，所述第一处理器62还用于：每执行一次更新所述Sendseq之后，确定更新后的Sendseq是否大于所述确认包发送门限；当所述第一发送器64发送所述新确认包之前，所述第一处理器62更新后的Sendseq大于所述确认包发送门限时，触发所述第一发送器64停止发送所述第一实体中已缓存的确认包，触发所述定时器65重启，并命令所述第一发送器64在所述定时器65超时之前，发送所述新确认包。可选的，所述第一处理器62还用于：更新确认包的确认包序号；其中，更新所述第二确认包的确认包序号时，如果所述第一确认包的确认包序号大于所述第二确认包的确认包序号，或者所述第一确认包的序号与所述第二确认包的确认包序号的差值小于-2147483648，则将所述第一确认包的确认包序号作为所述第二确认包的确认包序号；否则，将所述第一实体读取到的所述第二确认包的确认包序号作为所述第二确认包的确认包序号。其中，所述定时器65的时长为发送确认包的周期。需要说明的是，本实施例中的设备可以是基站，例如NodeB、eNodeB、HNodeB或HeNodeB，也可以是RNC。与现有技术相比，本发明实施例能够在第一实体接收到确认包后，对确认包进行处理，为确认包设置发送周期以及发送数据量门限，控制每个发送周期内向服务器发送的确认包的总数据量，进而控制确认包的数量，以使确认包能够以平稳的速率发送到达服务器，避免因确认包数量突增，以及由其导致的下行数据包传输不及时和丢包问题，进而避免网络吞吐量下降，并提高网络传输效率。本发明的另一个实施例提供一种确认包的处理设备，如图7所示，所述设备包括第二接收器71、第二处理器72和第二发送器73，其中：所述第二接收器71用于接收确认包；所述第二发送器73用去向第一实体发送所述第二接收器71接收的确认包，所述第一实体用于缓存和发送所述新确认包给服务器；所述第二处理器72用于当新确认包到达所述第二接收器71时，如果确定存在所述第一实体，则触发所述第二发送器73将所述确认包发送给所述第一实体；或者，当新确认包到达所述第二接收器71时，如果确定不存在所述第一实体，已存在的第三实体的个数小于第二门限m，且已缓存有确认包的第三实体的个数不大于第三门限n，则建立所述第一实体，并触发所述第二发送器73将所述新确认包发送给所述第一实体；或者，当新确认包到达所述第二接收器71时，如果确定不存在所述第一实体，已存在的第三实体的个数不小于第二门限m，且已缓存有确认包的第三实体的个数不大于第三门限n，则删除至少一个未缓存有确认包的第三实体，建立所述第一实体，并触发所述第二发送器73将所述新确认包发送给所述第一实体；或者，当新确认包到达所述第二接收器71时，如果确定不存在所述第一实体，且已缓存有确认包的第三实体的个数大于第三门限n，则触发所述第二发送器73向服务器发送所述新确认包；其中，所述m为允许建立的用于缓存和发送确认包的实体的个数上限，所述n为允许同时缓存有确认包的第三实体的个数上限。需要说明的是，本实施例中的设备可以是基站，例如NodeB、eNodeB、HNodeB或HeNodeB，也可以是RNC。与现有技术相比，本发明实施例能够在有新确认包到达第二实体时，第二实体为所述新确认包设置针对新到达的确认包进行判断以决定缓存和/或发送等处理方式的第一实体，通过第一实体对确认包进行处理，以使确认包能够以平稳的速率发送到达服务器，避免因确认包数量突增，以及由其导致的下行数据包传输不及时和丢包问题，进而避免网络吞吐量下降，并提高网络传输效率。本发明实施例提供的确认包的处理设备可以实现上述提供的方法实施例，具体功能实现请参见方法实施例中的说明，在此不再赘述。本发明实施例提供的确认包的处理方法及设备可以适用于TCP传输业务中的数据传输，但不仅限于此。本发明实施例还提供一种系统，可以包括上述如图6所示的设备和/或如图7所示的设备。本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-OnlyMemory，ROM)或随机存储记忆体(RandomAccessMemory，RAM)等。以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。