確認包的處理方法、設備及系統與流程
2023-09-11 12:46:25
確認包的處理方法、設備及系統本申請要求於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)等。以上所述，僅為本發明的具體實施方式，但本發明的保護範圍並不局限於此，任何熟悉本技術領域的技術人員在本發明揭露的技術範圍內，可輕易想到的變化或替換，都應涵蓋在本發明的保護範圍之內。因此，本發明的保護範圍應該以權利要求的保護範圍為準。