基于tcp的數(shù)據(jù)傳輸方法和tcp代理裝置制造方法
【專利摘要】本發(fā)明提供了一種基于TCP的數(shù)據(jù)傳輸方法和TCP代理裝置，其中，基于TCP的數(shù)據(jù)傳輸方法包括：TCP代理接收本端的接入層發(fā)送的通知消息；TCP代理根據(jù)通知消息中攜帶的可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度的信息，按照TCP分組的序號，順序從緩存的TCP分組中選擇至少一個TCP分組發(fā)送給接入層，選擇TCP分組的長度總和小于等于可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度，且，選擇的各個TCP分組的序號小于或等于本端的TCP層當前連續(xù)已發(fā)或待發(fā)的TCP分組的最大序號值加一；TCP代理針對發(fā)送給接入層的TCP分組構(gòu)造確認報文，并反饋給TCP層。通過本發(fā)明，避免了長期演進網(wǎng)絡(luò)中無線鏈路不穩(wěn)定性對傳輸控制協(xié)議分組數(shù)據(jù)傳輸?shù)挠绊憽?br> 【專利說明】基于TCP的數(shù)據(jù)傳輸方法和TCP代理裝置

【技術(shù)領(lǐng)域】
[0001] 本發(fā)明涉及通信【技術(shù)領(lǐng)域】，特別是涉及一種長期演進（Long Time Evolution, LTE)網(wǎng)絡(luò)下的基于傳輸控制協(xié)議（Transmission Control Protocol, TCP)的數(shù)據(jù)傳輸方 法和傳輸控制協(xié)議代理裝置。

【背景技術(shù)】
[0002] TCP是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議，由IETF的RFC793 定義，包括排序、重復包丟棄、丟包重傳、流控制和擁塞控制等主要功能。
[0003] 在LTE網(wǎng)絡(luò)中使用TCP進行數(shù)據(jù)傳輸時，TCP為數(shù)據(jù)負載的每一個字節(jié)都編上序 號。當數(shù)據(jù)發(fā)送端（本端）發(fā)出一個TCP報文時，會將該報文數(shù)據(jù)負載的第一個字節(jié)序號 填入首部的SEQ字段；同時，數(shù)據(jù)接收端（對端）在收到一個TCP報文后，會將當前它已連 續(xù)接收的最大字節(jié)序號加1填入ACK字段，并將該值填入一個確認包中反饋給數(shù)據(jù)發(fā)送端。 TCP報文的數(shù)據(jù)發(fā)送端始終能夠根據(jù)本端已發(fā)送報文的SEQ信息，以及收到的對端ACK信 息，計算出當前已發(fā)出而未確認的數(shù)據(jù)字節(jié)總量（稱之為空中數(shù)據(jù)）。TCP報文的數(shù)據(jù)發(fā)送 端維護著一個發(fā)送窗口的變量，并始終保持空中數(shù)據(jù)量小于等于發(fā)送窗口大小。
[0004] 在數(shù)據(jù)傳輸過程中，TCP通過發(fā)送窗口值的調(diào)整來實現(xiàn)流量控制和擁塞控制兩大 功能。其中，對于流量控制，TCP報文的數(shù)據(jù)發(fā)送端根據(jù)TCP報文的數(shù)據(jù)接收端返回的反饋 包中的WIN字段獲悉數(shù)據(jù)接收端的接收緩存剩余空間（被稱為通告窗口），并與本端的空中 數(shù)據(jù)量進行比較，如果空中數(shù)據(jù)量達到通告窗口大小，則暫時不再發(fā)送數(shù)據(jù)（否則可能會 造成對端接收緩存溢出），一直等到空中數(shù)據(jù)量減少（由于反饋的ACK值更新）或者通告窗 口增大（由于反饋的WIN值變大）才會發(fā)送新傳報文。在實際TCP業(yè)務(wù)中，通告窗口的最 大值不應(yīng)該設(shè)置得很小，即不能夠使接收緩存大小成為速率的瓶頸，因為在穩(wěn)定狀態(tài)下數(shù) 據(jù)傳輸?shù)钠骄俾实扔诖翱谥党酝禃r延（Round-Trip Time，RTT)。
[0005] TCP報文的數(shù)據(jù)發(fā)送端還維護著一個被稱為擁塞窗口 CWND的相關(guān)變量，這個擁塞 窗口和通告窗口的最小值就是TCP報文的數(shù)據(jù)發(fā)送端的發(fā)送窗口值。CWND會隨著反饋包 ACK信息的更新而不斷增大，一開始CWND值很小，并以二次方的指數(shù)方式快速增大，此階段 為慢啟動狀態(tài)；當增大到一定門限時，CWND按照線性方式增大，此階段為擁塞避免狀態(tài)。另 一方面，如果TCP報文的數(shù)據(jù)發(fā)送端判斷遇到了重傳事件，則認為網(wǎng)絡(luò)中發(fā)生了擁塞，就需 要收縮擁塞窗口即減慢發(fā)送速率以緩解擁塞。
[0006] TCP擁塞控制是在傳統(tǒng)以太網(wǎng)絡(luò)中很重要的一種機制，TCP協(xié)議認為在以太網(wǎng)絡(luò) 中，造成丟包和亂序的原因是擁塞，即TCP發(fā)送窗口過大速率過高，超過了網(wǎng)絡(luò)鏈路中間設(shè) 備的緩存而造成丟包。然而在LTE網(wǎng)絡(luò)環(huán)境中，物理信道波動普遍存在，即便在良好的物理 信道環(huán)境下，丟包和亂序現(xiàn)象也時有發(fā)生，這并不是由于速率過高產(chǎn)生擁塞，而是由于LTE 鏈路的不可靠性導致的。因此，傳統(tǒng)以太網(wǎng)絡(luò)中的TCP擁塞控制機制并不適用于LTE網(wǎng)絡(luò)， 在LTE網(wǎng)絡(luò)環(huán)境波動導致出現(xiàn)丟包亂序時，使用傳統(tǒng)以太網(wǎng)絡(luò)中的TCP擁塞控制機制會導 致不適當?shù)挠|發(fā)TCP的擁塞窗口收縮，進而影響LTE網(wǎng)絡(luò)中的數(shù)據(jù)傳輸。


【發(fā)明內(nèi)容】

[0007] 本發(fā)明提供了一種基于傳輸控制協(xié)議的數(shù)據(jù)傳輸方法和傳輸控制協(xié)議代理裝置， 以解決傳統(tǒng)以太網(wǎng)絡(luò)中的傳輸控制協(xié)議擁塞控制在長期演進網(wǎng)絡(luò)環(huán)境波動導致出現(xiàn)丟包 亂序情況下，導致不適當?shù)挠|發(fā)傳輸控制協(xié)議的擁塞窗口收縮，進而影響長期演進網(wǎng)絡(luò)中 的數(shù)據(jù)傳輸?shù)膯栴}。
[0008] 為了解決上述問題，本發(fā)明公開了一種基于傳輸控制協(xié)議的數(shù)據(jù)傳輸方法，包括： 傳輸控制協(xié)議代理接收本端的長期演進接入層發(fā)送的通知消息；所述傳輸控制協(xié)議代理根 據(jù)所述通知消息中攜帶的可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度的信息，按照傳輸控制協(xié)議分組的 序號，順序從緩存的傳輸控制協(xié)議分組中選擇至少一個傳輸控制協(xié)議分組發(fā)送給所述接入 層，其中，選擇的所述至少一個傳輸控制協(xié)議分組的長度總和小于或等于所述可用數(shù)據(jù)傳 輸資源的數(shù)據(jù)長度，且，選擇的各個所述傳輸控制協(xié)議分組的序號小于或等于本端的傳輸 控制協(xié)議層當前連續(xù)已發(fā)或待發(fā)的傳輸控制協(xié)議分組的最大序號值加一；所述傳輸控制協(xié) 議代理針對發(fā)送給所述接入層的所述傳輸控制協(xié)議分組構(gòu)造確認報文，并將所述確認報文 反饋給向所述傳輸控制協(xié)議代理發(fā)送傳輸控制協(xié)議分組的傳輸控制協(xié)議層。
[0009] 為了解決上述問題，本發(fā)明還公開了一種基于傳輸控制協(xié)議的傳輸控制協(xié)議代理 裝置，所述裝置包括：接收模塊，用于接收本端的長期演進接入層發(fā)送的通知消息；選擇發(fā) 送模塊，用于根據(jù)所述通知消息中攜帶的可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度的信息，按照傳輸 控制協(xié)議分組的序號，順序從緩存的傳輸控制協(xié)議分組中選擇至少一個傳輸控制協(xié)議分組 發(fā)送給所述接入層，其中，選擇的所述至少一個傳輸控制協(xié)議分組的長度總和小于或等于 所述可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度，且，選擇的各個所述傳輸控制協(xié)議分組的序號小于或 等于本端的傳輸控制協(xié)議層當前連續(xù)已發(fā)或待發(fā)的傳輸控制協(xié)議分組的最大序號值加一； 反饋模塊，用于針對發(fā)送給所述接入層的所述傳輸控制協(xié)議分組構(gòu)造確認報文，并將所述 確認報文反饋給向所述傳輸控制協(xié)議代理裝置發(fā)送傳輸控制協(xié)議分組的傳輸控制協(xié)議層。 [0010] 與現(xiàn)有技術(shù)相比，本發(fā)明具有以下優(yōu)點：
[0011] 本發(fā)明的數(shù)據(jù)傳輸方案中，利用傳輸控制協(xié)議代理來優(yōu)化端到端傳輸控制協(xié)議的 性能。傳輸控制協(xié)議代理根據(jù)長期演進接入層發(fā)送的通知消息，獲取可用數(shù)據(jù)傳輸資源的 數(shù)據(jù)長度的信息；進而，根據(jù)該可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度，按照一定的規(guī)則從緩存中選 擇傳輸控制協(xié)議分組發(fā)送給長期演進接入層；并且，在發(fā)送傳輸控制協(xié)議分組的報文后，構(gòu) 造并向傳輸控制協(xié)議層反饋確認報文。傳輸控制協(xié)議代理針對發(fā)出的傳輸控制協(xié)議分組構(gòu) 造并向本端的傳輸控制協(xié)議層發(fā)送相應(yīng)的確認報文，使得本端的傳輸控制協(xié)議層認為所發(fā) 出的傳輸控制協(xié)議分組總是被對端正確的接收，從而使傳輸控制協(xié)議層發(fā)送窗口始終保持 增長的態(tài)勢，并且穩(wěn)定連續(xù)地將數(shù)據(jù)發(fā)送到傳輸控制協(xié)議代理，從而避免了長期演進網(wǎng)絡(luò) 中無線鏈路不穩(wěn)定性對傳輸控制協(xié)議分組數(shù)據(jù)傳輸?shù)挠绊懀沟靡苿咏K端在進行各種數(shù)據(jù) 傳輸業(yè)務(wù)時，傳輸性能能夠達到系統(tǒng)帶寬的極限，解決了傳統(tǒng)以太網(wǎng)絡(luò)中的傳輸控制協(xié)議 擁塞控制在長期演進網(wǎng)絡(luò)環(huán)境波動導致出現(xiàn)丟包亂序情況下，導致不適當?shù)挠|發(fā)傳輸控制 協(xié)議的擁塞窗口收縮，進而影響長期演進網(wǎng)絡(luò)中的數(shù)據(jù)傳輸?shù)膯栴}。

【專利附圖】

【附圖說明】
[0012] 圖1是根據(jù)本發(fā)明實施例一的一種基于TCP的數(shù)據(jù)傳輸方法的步驟流程圖；
[0013] 圖2是根據(jù)本發(fā)明實施例二的一種基于TCP的數(shù)據(jù)傳輸方法的步驟流程圖；
[0014] 圖3是根據(jù)本發(fā)明實施例三的一種基于TCP的數(shù)據(jù)傳輸方法的步驟流程圖；
[0015] 圖4是根據(jù)本發(fā)明實施例五的一種基于TCP的傳輸控制協(xié)議代理裝置的結(jié)構(gòu)框 圖；
[0016] 圖5是根據(jù)本發(fā)明實施例六的一種基于TCP的傳輸控制協(xié)議代理裝置的結(jié)構(gòu)框 圖；
[0017] 圖6是使用本發(fā)明的數(shù)據(jù)傳輸方案的FTP上下行業(yè)務(wù)速率效果圖；
[0018] 圖7是使用本發(fā)明的數(shù)據(jù)傳輸方案的IperfTCP上下行業(yè)務(wù)速率效果圖。

【具體實施方式】
[0019] 為使本發(fā)明的上述目的、特征和優(yōu)點能夠更加明顯易懂，下面結(jié)合附圖和具體實 施方式對本發(fā)明作進一步詳細的說明。
[0020] 為便于描述，本發(fā)明實施例中，使用SND表示TCP(傳輸控制協(xié)議）層當前連續(xù)已 發(fā)或待發(fā)的TCP分組的最大序號值加一，使用RCV表示TCPAgent (傳輸控制協(xié)議代理）從 TCP層接收到的TCP分組的最大序號值加一，使用UNA表示已被TCP分組接收端連續(xù)確認 的TCP分組的最大序號值，使用WIN表示TCP分組接收端反饋的ACK報文（確認報文）中 的win字段值，即通告窗口大小。
[0021] 實施例一
[0022] 參照圖1，示出了根據(jù)本發(fā)明實施例一的一種基于TCP的數(shù)據(jù)傳輸方法的步驟流 程圖。
[0023] 本實施例的基于TCP的數(shù)據(jù)傳輸方法包括以下步驟：
[0024] 步驟S102 :TCPAgent接收本端的LTE接入層發(fā)送的通知消息。
[0025] 其中，所述通知消息中攜帶有可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度的信息。
[0026] 步驟S104 :TCPAgent根據(jù)通知消息中攜帶的可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度的信 息，按照TCP分組的序號，順序從緩存的TCP分組中選擇至少一個TCP分組發(fā)送給所述接入 層。
[0027] 其中，選擇的至少一個TCP分組的長度總和小于或等于可用數(shù)據(jù)傳輸資源的數(shù)據(jù) 長度，且，選擇的各個TCP分組的序號小于或等于本端的SND (即TCP層當前連續(xù)已發(fā)或待 發(fā)的TCP分組的最大序號值加一）。
[0028] 例如，LTE網(wǎng)絡(luò)中，每當接入層使用PUSCH(物理上行共享信道）上行空口資源之 后，會發(fā)給TCPAgent -個通知，該通知的內(nèi)容中包含有可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度的信 息，TCPAgent根據(jù)該長度從緩存中選擇若干TCP分組發(fā)給接入層。
[0029] 步驟S106 :TCPAgent針對發(fā)送給所述接入層的TCP分組構(gòu)造確認報文（如ACK報 文），并將所述確認報文反饋給向TCPAgent發(fā)送TCP分組的TCP層。
[0030] 在一個包含若干TCP分組的TCP報文發(fā)給接入層之后，TCPAgent需要針對該報文 中的最后一個TCP分組構(gòu)造一個確認報文回復給本端的TCP層，以通知TCP層該TCP報文 已被正確接收而可以正常增長發(fā)送窗口，該確認報文的確認字段值與所發(fā)TCP分組的最大 序號值加1相等。
[0031] 通過上述過程，使得TCPAgent回復確認報文的速率與LTE帶寬相一致，這能使本 端TCP窗口穩(wěn)步增長。一方面，本端數(shù)據(jù)的立即響應(yīng)有利于窗口的快速增大，但另一方面緩 存數(shù)據(jù)量的不斷加大使得所緩存報文被發(fā)出的時機越來越遲，即本端觀測到的RTT越來越 大，從而減緩了窗口增長的速度。這正反兩方面因素達到合理的平衡點，與LTE的帶寬速率 最終相統(tǒng)一。
[0032] 通過本實施例，利用TCPAgent來優(yōu)化端到端TCP的性能。TCPAgent根據(jù)LTE接入 層發(fā)送的通知消息，獲取可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度的信息；進而，根據(jù)該可用數(shù)據(jù)傳輸 資源的數(shù)據(jù)長度，按照一定的規(guī)則從緩存中選擇TCP分組發(fā)送給LTE接入層；并且，在發(fā)送 TCP分組的報文后，構(gòu)造并向TCP層反饋確認報文。TCPAgent針對發(fā)出的TCP分組構(gòu)造并 向本端的TCP層發(fā)送相應(yīng)的確認報文，使得本端的TCP層認為所發(fā)出的TCP分組總是被對 端正確的接收，從而使TCP層發(fā)送窗口始終保持增長的態(tài)勢，并且穩(wěn)定連續(xù)地將數(shù)據(jù)發(fā)送 至IJ TCPAgent，從而避免了 LTE網(wǎng)絡(luò)中無線鏈路不穩(wěn)定性對TCP分組數(shù)據(jù)傳輸?shù)挠绊?，使得?動終端在進行各種數(shù)據(jù)傳輸業(yè)務(wù)時，傳輸性能能夠達到系統(tǒng)帶寬的極限，解決了傳統(tǒng)以太 網(wǎng)絡(luò)中的TCP擁塞控制在LTE網(wǎng)絡(luò)環(huán)境波動導致出現(xiàn)丟包亂序情況下，導致不適當?shù)挠|發(fā) TCP的擁塞窗口收縮，進而影響LTE網(wǎng)絡(luò)中的數(shù)據(jù)傳輸?shù)膯栴}。
[0033] 實施例二
[0034] 參照圖2,示出了根據(jù)本發(fā)明實施例二的一種基于TCP的數(shù)據(jù)傳輸方法的步驟流 程圖。
[0035] 本實施例的數(shù)據(jù)傳輸方法包括以下步驟：
[0036] 步驟S202 :TCPAgent接收本端TCP層發(fā)送的TCP分組。
[0037] 在本發(fā)明實施例中，本端TCP層不是直接將TCP分組發(fā)送給對端，而是首先發(fā)送給 本端的TCPAgent進行緩存。
[0038] 步驟S204 :TCPAgent判斷TCP層發(fā)送的TCP分組的序號是否與TCPAgent已緩存 的TCP分組的序號重復；若重復，則執(zhí)行步驟S206 ;若不重復，則執(zhí)行步驟S208。
[0039] 通過判斷接收的TCP分組的序號是否與已緩存的TCP分組重復，可以避免TCP分 組的重復緩存，減輕緩存負擔和占用空間。
[0040] 步驟S206 :若TCP層發(fā)送的TCP分組的序號與TCPAgent已緩存的TCP分組的序 號重復，則丟棄該TCP分組，轉(zhuǎn)步驟S210執(zhí)行。
[0041] 步驟S208 :若TCP層發(fā)送的TCP分組的序號與TCPAgent已緩存的TCP分組的序 號不重復，則TCPAgent緩存該TCP分組，轉(zhuǎn)步驟S210執(zhí)行。
[0042] 步驟S210 :TCPAgent接收本端的LTE接入層發(fā)送的通知消息。
[0043] 其中，所述通知消息中攜帶有可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度的信息，可用數(shù)據(jù)傳 輸資源的數(shù)據(jù)長度可以通過多種方式設(shè)定，一種優(yōu)選方式為：由接入層根據(jù)設(shè)定次數(shù)的發(fā) 送TCP分組使用的資源均值和設(shè)定的放大系數(shù)確定。
[0044] 也即，TCPAgent接收LTE接入層發(fā)送的、攜帶了發(fā)送TCP分組的可用數(shù)據(jù)傳輸資 源的數(shù)據(jù)長度的信息的通知消息；其中，可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度由所述接入層根據(jù) 設(shè)定次數(shù)的發(fā)送TCP分組使用的資源均值和設(shè)定的放大系數(shù)確定。但不限于此，其它設(shè)定 可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度的方式也同樣適用，如，根據(jù)發(fā)送通知消息時的實際可用數(shù) 據(jù)傳輸資源的數(shù)據(jù)長度設(shè)定等。而由接入層根據(jù)設(shè)定次數(shù)的發(fā)送TCP分組使用的資源均值 和設(shè)定的放大系數(shù)確定，一方面可以靈活地適應(yīng)資源變化情況，另一方面也能夠為傳輸TCP 分組提供充足的傳輸資源。
[0045] 步驟S212 :TCPAgent根據(jù)通知消息中攜帶的可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度的信 息，按照TCP分組的序號，順序從緩存的TCP分組中選擇至少一個TCP分組發(fā)送給LTE接入 層。
[0046] 其中，選擇的至少一個TCP分組的長度總和小于或等于可用數(shù)據(jù)傳輸資源的數(shù)據(jù) 長度，且，選擇的各個TCP分組的序號小于或等于本端的SND。
[0047] -般情況下，可用數(shù)據(jù)傳輸資源能夠傳輸一至多個TCP分組，此時，該一至多個 TCP分組的數(shù)據(jù)長度總和應(yīng)小于或等于可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度。
[0048] 但需要說明的是，在某些情況下，有可能出現(xiàn)待傳輸?shù)腡CP分組的數(shù)據(jù)長度大于 可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度的情況，也即，可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度小于該TCP分 組的數(shù)據(jù)長度，此時，則選擇序號最小的TCP分組發(fā)送給LTE接入層。為有效處理這種情 況，優(yōu)選地，在步驟S210之后，S卩：TCPAgent接收本端的LTE接入層發(fā)送的通知消息之后， TCPAgent還可以判斷可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度是否小于緩存的TCP分組中序號最小 的TCP分組的長度；若是，則選擇序號最小的TCP分組發(fā)送給LTE接入層；若否，則執(zhí)行本步 驟S212, S卩，TCPAgent根據(jù)可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度的信息，按照TCP分組的序號，順 序從緩存的TCP分組中選擇至少一個TCP分組發(fā)送給LTE接入層。通過這種處理，避免了 某個數(shù)據(jù)長度較大的TCP分組長時間無法得到傳輸資源，提高了數(shù)據(jù)傳輸效率。
[0049] 步驟S214 :TCPAgent針對發(fā)送給接入層的TCP分組構(gòu)造確認報文，并將所述確認 報文反饋給向TCPAgent發(fā)送TCP分組的TCP層。
[0050] 其中，TCPAgent針對發(fā)送給接入層的TCP分組構(gòu)造確認報文可以采用以下方式。
[0051] 方式一：
[0052] 當TCPAgent從緩存的TCP分組中選擇了多個TCP分組時，TCPAgent針對發(fā)送給 所述接入層的TCP分組構(gòu)造確認報文的步驟包括：TCPAgent僅針對多個TCP分組中的最后 一個TCP分組構(gòu)造純確認報文。
[0053] 其中，純確認報文中的確認字段值等于多個TCP分組中的最后一個TCP分組的序 號值加一；對于純確認報文中的窗口字段值，當RCV與UNA的差大于或等于TCP分組接收端 的通告窗口值時，即RCV - UNA> = WIN時，所述純確認報文中的窗口字段值設(shè)置為0,以通 知TCP層暫停向TCPAgent發(fā)送TCP分組；反之，所述純確認報文中的窗口字段值為TCP接 收端的通告窗口值WIN。
[0054] 方式二：
[0055] 不管TCPAgent從緩存的TCP分組中選擇了一個還是多個TCP分組，TCPAgent均 可針對發(fā)送給所述接入層的每個TCP分組構(gòu)造純確認報文。
[0056] 其中，所述純確認報文中的確認字段值等于與所述純確認報文相對應(yīng)的TCP分組 的序號值與該TCP分組的長度之和再加一；對于所述純確認報文中的窗口字段值，當RCV與 UNA的差大于或等于TCP分組接收端的通告窗口值WIN時，所述純確認報文中的窗口字段值 設(shè)置為〇,以通知TCP層暫停向TCPAgent發(fā)送TCP分組；反之，所述純確認報文中的窗口字 段值為TCP分組接收端的通告窗口值。
[0057] 優(yōu)選地，本實施例還提供了針對TCP分組接收端發(fā)送的捎帶確認報文的處理方 案。為此，TCPAgent中還設(shè)置有捎帶確認報文計數(shù)器，該捎帶確認報文計數(shù)器用于對向TCP 層透傳 TCP分組接收端的捎帶確認報文的次數(shù)計數(shù)，則在步驟S214的TCPAgent將確認報 文反饋給向TCPAgent發(fā)送TCP分組的TCP層的步驟之后，還包括：TCPAgent接收到TCP分 組接收端發(fā)送的捎帶確認報文；判斷緩存中是否存在待發(fā)送的TCP分組；若存在，且捎帶確 認報文計數(shù)器的計數(shù)值為3時，則構(gòu)造純確認報文，將該純確認報文的確認字段值設(shè)置為 所述緩存中的當前連續(xù)已發(fā)或待發(fā)的傳輸控制協(xié)議分組的最大序號值加一，向TCP層發(fā)送 該純確認報文并透傳該捎帶確認報文，將捎帶確認報文計數(shù)器置〇 ;若不存在，則透傳該捎 帶確認報文，將捎帶確認報文計數(shù)器加1。
[0058] 在此基礎(chǔ)上，為了提高確認報文構(gòu)造效率，優(yōu)選地，在TCPAgent針對發(fā)送給LTE接 入層的每個TCP分組構(gòu)造純確認報文的步驟之前，還包括：判斷是否已為當前TCP分組構(gòu)造 過純確認報文；若已構(gòu)造過，則不再為當前傳輸控制協(xié)議分組構(gòu)造的純確認報文。未構(gòu)造 過，才進行純確認報文構(gòu)造。
[0059] 上述捎帶確認報文（即捎帶ACK報文）的處理極大地減小了修改每一個捎帶ACK 數(shù)據(jù)包帶來的巨大開銷。采用修改數(shù)據(jù)的方案帶來的開銷，主要是對每一個報文都重新計 算并修改TCP校驗和，這需要對整個數(shù)據(jù)內(nèi)容進行遍歷和數(shù)值計算，CPU消耗極大。而采用 本方案，報文無需修改，也不是每一個捎帶ACK都會觸發(fā)純ACK的構(gòu)造，更重要的是即使構(gòu) 造純ACK，因為純ACK字節(jié)少且大部分內(nèi)容使用的是保存的數(shù)據(jù)模板，CPU消耗極小。
[0060] 通過本實施例，可以使TCP分組發(fā)送端的TCP層發(fā)送窗口始終保持增長的態(tài)勢，并 且穩(wěn)定連續(xù)地將數(shù)據(jù)發(fā)送到TCPAgent，從而避免了 LTE網(wǎng)絡(luò)中無線鏈路不穩(wěn)定性對TCP分 組數(shù)據(jù)傳輸?shù)挠绊懀沟靡苿咏K端在進行各種數(shù)據(jù)傳輸業(yè)務(wù)時，傳輸性能能夠達到系統(tǒng)帶 寬的極限。
[0061] 實施例三
[0062] 參照圖3,示出了根據(jù)本發(fā)明實施例三的一種基于TCP的數(shù)據(jù)傳輸方法的步驟流 程圖。
[0063] 本實施例著重從冗余確認報文（如冗余ACK報文）處理方面對本發(fā)明的數(shù)據(jù)傳輸 方案進行說明，其它部分請參照前述實施例的相應(yīng)部分，本實施例中不再進行詳細描述。
[0064] 本實施例的基于TCP的數(shù)據(jù)傳輸方法包括以下步驟：
[0065] 步驟S302 :TCPAgent接收本端TCP層發(fā)送的TCP分組。
[0066] 步驟S304 :TCPAgent判斷TCP層發(fā)送的TCP分組的序號是否與TCPAgent已緩存 的TCP分組的序號重復；若重復，則執(zhí)行步驟S306 ;若不重復，則執(zhí)行步驟S308。
[0067] 步驟S306 :若TCP層發(fā)送的TCP分組的序號與TCPAgent已緩存的TCP分組的序 號重復，則丟棄該TCP分組，轉(zhuǎn)步驟S310執(zhí)行。
[0068] 步驟S308 :若TCP層發(fā)送的TCP分組的序號與TCPAgent已緩存的TCP分組的序 號不重復，則TCPAgent緩存該TCP分組，轉(zhuǎn)步驟S310執(zhí)行。
[0069] 步驟S310 :TCPAgent接收本端的LTE接入層發(fā)送的通知消息。
[0070] 步驟S312 :TCPAgent根據(jù)通知消息中攜帶的可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度的信 息，按照TCP分組的序號，順序從緩存的TCP分組中選擇至少一個TCP分組發(fā)送給LTE接入 層。
[0071] 步驟S314 :TCPAgent針對發(fā)送給接入層的TCP分組構(gòu)造確認報文，并將所述確認 報文反饋給向TCPAgent發(fā)送TCP分組的TCP層。
[0072] 步驟S316 :TCPAgent接收TCP分組接收端反饋的確認報文。
[0073] 步驟S318 :TCPAgent判斷當前接收到的所述反饋的確認報文中的確認字段值是 否大于本端當前記錄的UNA ;若是，則執(zhí)行步驟S320,若否，則執(zhí)行步驟S322。
[0074] 步驟S320 :TCPAgent將本端當前記錄的UNA更新為當前收到的所述反饋的確認報 文中的確認字段值，并將TCP分組的序號值小于更新后的UNA的所有TCP分組刪除，轉(zhuǎn)步驟 S324執(zhí)行。
[0075] 步驟S322 :TCPAgent將重傳計數(shù)器加1，并且，當重傳計數(shù)器達到3時，確定發(fā)生 確認報文冗余事件，根據(jù)反饋的確認報文確定冗余類型，根據(jù)確定的冗余類型進行TCP分 組重傳，并在重傳后將重傳計數(shù)器清0。
[0076] 其中，根據(jù)反饋的確認報文確定冗余類型，根據(jù)確定的冗余類型進行TCP分組重 傳的步驟包括：
[0077] 確定反饋的確認報文為選擇性確認報文（即SACK報文），且，該選擇性確認報文指 示TCP分組接收端接收的TCP分組發(fā)生亂序或丟包，則將TCPAgent緩存的、UNA與SND之間 的、除該選擇性確認報文指示的已被TCP分組接收端接收到的TCP分組之外的所有TCP分 組重傳給TCP分組接收端；
[0078] 或者，
[0079] 確定反饋的確認報文為選擇性確認報文（即SACK報文），且，該選擇性確認報文指 示TCP分組接收端接收的TCP分組發(fā)生重復，則不做處理；
[0080] 或者，
[0081] 確定反饋的確認報文為確認報文（即ACK報文），且，該確認報文指示TCP分組接 收端接收的TCP分組發(fā)生丟包，則將TCPAgent緩存的、該確認報文中的確認字段值至SND 之間的所有TCP分組重傳給TCP分組接收端。
[0082] SACK報文是目前TCP常用的一種新增特性（RFC2018/2883)，SACK報文的相關(guān)字段 位于反饋包的TCP首部選項中，通過SACK報文能夠?qū)⒅貜秃蛠y序這兩種情況反映出來。對 于重復情況，SACK報文的序號范圍沿是重復報文的序號范圍且小于ACK字段值，ACK不應(yīng)被 當做冗余ACK被處理因為它并不對應(yīng)著亂序或丟包。對于亂序情況，SACK的序號范圍是ACK 字段值之后已經(jīng)連續(xù)接收到的一個或多個報文對應(yīng)的序號范圍，此ACK是一個冗余ACK。借 助于SACK報文，能夠從冗余ACK中篩選掉由重復包引發(fā)的情況，減少由此產(chǎn)生的不必要的 重傳；也能夠明確指示需要重傳的范圍，有利于無線帶寬的利用率。通過上述對SACK報文 的支持處理，能夠讓重傳范圍控制在更為精確的序號區(qū)間。
[0083] 假如LTE系統(tǒng)的空中接口有報文丟失發(fā)生，則該報文之后的窗口內(nèi)連續(xù)報文會觸 發(fā)大量冗余ACK事件。為了減少不必要的重傳規(guī)模，在第一次較激進的重傳策略之后，如果 繼續(xù)發(fā)生在同一 UNA值上的冗余ACK事件，則采取保守的重傳策略，即僅僅重傳 UNA值對應(yīng) 的一個TCP分組。
[0084] 也即，一種優(yōu)選方案為，在確定發(fā)生確認報文冗余事件之后，根據(jù)所述反饋的確認 報文確定冗余類型，根據(jù)確定的冗余類型進行TCP分組重傳之前，還可以包括：
[0085] 判斷確認報文冗余事件是否是發(fā)生在UNA上的首次冗余事件；
[0086] 若是首次冗余，則將TCPAgent緩存的、UNA與SND之間的、除所述選擇性確認報文 指示的已被TCP分組接收端接收到的TCP分組之外的所有TCP分組重傳給TCP分組接收端 (針對SACK報文）；或者，則將TCPAgent緩存的、確認報文中的確認字段值至SND之間的所 有TCP分組重傳給TCP分組接收端（針對ACK報文）；
[0087] 若不是首次冗余，則僅重傳 UNA加一后對應(yīng)的TCP分組。
[0088] 步驟S324 :TCPAgent判斷上述反饋的確認報文的類型；若反饋的確認報文為純確 認報文，則丟棄；若反饋的確認報文為捎帶確認報文，則將捎帶確認報文透傳至TCP層。
[0089] 也即，TCPAgent在根據(jù)反饋的確認報文確定冗余類型，根據(jù)確定的冗余類型進行 上述的TCP分組重傳之后，最后還要對該反饋的確認報文進行后續(xù)處理，包括：判斷反饋的 確認報文的類型；若反饋的確認報文為純確認報文，則丟棄；若反饋的確認報文為捎帶確 認報文，則將捎帶確認報文透傳至TCP層。
[0090] 通過本實施例，在使TCP分組發(fā)送端的TCP層發(fā)送窗口始終保持增長的態(tài)勢，并且 穩(wěn)定連續(xù)地將數(shù)據(jù)發(fā)送到TCPAgent，避免了 LTE網(wǎng)絡(luò)中無線鏈路不穩(wěn)定性對TCP分組數(shù)據(jù) 傳輸?shù)挠绊?，使得移動終端在進行各種數(shù)據(jù)傳輸業(yè)務(wù)時，傳輸性能能夠達到系統(tǒng)帶寬的極 限的基礎(chǔ)上，針對冗余報文進一步提供了處理方案，不僅能夠讓重傳范圍控制在更為精確 的序號區(qū)間，而且減少了不必要的重傳規(guī)模。
[0091] 在TCP數(shù)據(jù)傳輸過程中，還需要對連接進行維護，對其它一些相關(guān)報文進行支持， 因此，在上述實施例一至實施例三的方案的基礎(chǔ)上，本發(fā)明進一步提供了包括對連接進行 監(jiān)測和對其它相關(guān)報文進行處理的連接維護方案。
[0092] 該連接維護方案可以包括以下至少之一：
[0093] (1)針對結(jié)束報文（即FIN報文）
[0094] 包括：TCPAgent確定接收到TCP層的結(jié)束報文，則進入本地關(guān)閉狀態(tài)，丟棄所述結(jié) 束報文之后收到的TCP層發(fā)送的TCP分組，并且，將緩存的所有剩余TCP分組發(fā)送給TCP分 組接收端且被TCP分組接收端確認后，將所述結(jié)束報文發(fā)送給TCP分組接收端；
[0095] 或者，
[0096] TCPAgent確定接收到TCP分組接收端發(fā)送的結(jié)束報文，則將所述結(jié)束報文透傳給 TCP 層。
[0097] (2)針對復位報文（即RST報文）
[0098] 包括：TCPAgent確定接收到復位報文，則立即清空TCPAgent緩存的所有TCP分 組，并將所述復位報文透傳給TCP層。
[0099] (3)針對窗口探測報文
[0100] 包括：TCPAgent在針對發(fā)送給LTE接入層的TCP分組構(gòu)造確認報文之后，當確定 接收到TCP層發(fā)送的窗口探測報文；則構(gòu)造純確認報文回復TCP層，并丟棄所述窗口探測報 文，其中，構(gòu)造的純確認報文的確認字段值為SND，窗口字段值為0。
[0101] (4)針對連接監(jiān)測
[0102] 包括：TCPAgent確定維護的對TCP分組接收端連接進行監(jiān)控的分鐘量級監(jiān)控定時 器超時，則立即清空TCPAgent緩存的所有TCP分組，并構(gòu)造復位報文透傳給TCP層和TCP 分組接收端。
[0103] 通過上述報文處理，使得本發(fā)明的TCP代理對TCP連接的維護方案更為完善，通過 上述的連接監(jiān)測，能夠使TCPAgent能夠長期穩(wěn)定的工作。
[0104] 實施例四
[0105] 本實施例以具體實例的形式，對本發(fā)明的基于TCP的數(shù)據(jù)傳輸方案進行說明。
[0106] 本實施例在終端中設(shè)置了 TCPAgent，對終端的TCP協(xié)議進行代理，它可以部署于 終端的LTE AS之上。這個TCPAgent能夠針對本端TCP層發(fā)出的數(shù)據(jù)包構(gòu)造相應(yīng)的ACK 應(yīng)答包（即確認報文），使得本端的TCP層認為所發(fā)出的數(shù)據(jù)包總是被對端正確的接收， 從而使TCP發(fā)送窗口始終保持增長的態(tài)勢并且穩(wěn)定連續(xù)地將數(shù)據(jù)包發(fā)到TCPAgent。對于 對端的TCP，這個TCPAgent將來自本端TCP層的報文緩存，并根據(jù)對端的ACK/SACK (確認 報文/選擇性確認報文）反饋信息，去判斷一個已緩存報文是否已經(jīng)被收到或需要被重 傳。TCPAgent還能夠攔截來自對端的純ACK(純確認報文）以及放行攜帶數(shù)據(jù)負載的捎帶 ACK(捎帶確認報文）。
[0107] 此外，本實施例還提供了流量控制機制，以避免僅僅按照上述實現(xiàn)，有可能發(fā)生的 本端TCP層源源不斷地發(fā)出數(shù)據(jù)包并超出了 TCPAgent或者LTE的緩存能力而造成大量 的擁塞丟包的情況。本實施例中采用的流控機制，是通過LTE當前的緩存量來逐漸增大 TCPAgent回復ACK的時延，當LTE緩存量越大，TCPAgent越遲回復所構(gòu)造的ACK。最終達 到平衡時，本端TCP的窗口大小與LTE緩存報文量相一致。
[0108] 本實施例從多個方面分別對本發(fā)明的數(shù)據(jù)傳輸方案進行說明，在此之前，本實施 例中設(shè)定：
[0109] RCV :該值記錄著TCPAgent當前從本端TCP層已接收到的TCP分組的最大序號值 加1 ;
[0110] SND :該值記錄著本端TCP層當前連續(xù)的已發(fā)或待發(fā)的TCP分組的最大序號值加 1，SND之前的報文序號都是TCPAgent層已緩存的連續(xù)序號范圍；
[0111] UNA :該值記錄著已經(jīng)被對端連續(xù)確認的TCP分組的最大序號值；
[0112] WIN :該值記錄著對端ACK中的win字段值，即通告窗口大小。
[0113] 本實施例的數(shù)據(jù)傳輸?shù)臉I(yè)務(wù)邏輯都是基于一條TCP連接的，每一條TCP連接都維 護著上面的一系列參數(shù)。
[0114] 以下，從不同方面對本實施例的數(shù)據(jù)傳輸方案進行說明，包括：
[0115] (1) TCPAgent接收到本端TCP層新傳數(shù)據(jù)的流程：
[0116] 在此過程中TCPAgent需要進行一些檢查，包括：冗余檢查，即檢查該新傳數(shù)據(jù)是 否與已有的一個已緩存報文的TCP序號范圍（通過序號字段和負載長度字段判斷）是否完 全重復；和/或，交疊檢查，類似于冗余檢查，針對的是TCP序號范圍與已緩存報文有局部重 復的情況，當新達報文的序號范圍能夠被已緩存的若干報文的序號范圍完全覆蓋時，也認 為該報文重復。被判定重復的報文會被丟棄，即既不緩存也不發(fā)給對端。
[0117] 對于非重復報文，TCPAgent會將其緩存在本地，但并不立即遞交給LTEAS發(fā)出，這 個操作需等待AS的通知。如果該報文連續(xù)，則更新SND值。
[0118] (2) TCPAgent發(fā)包指示流程：
[0119] 發(fā)包指示指的是AS發(fā)送給TCPAgent的通知消息，如每當AS使用PUSCH上行空口 資源之后，會發(fā)給TCPAgent -個通知，該通知的內(nèi)容包含了最近若干次（比如50次，可調(diào) 整）的上行資源均值再乘以一個放大系數(shù)，表示為數(shù)據(jù)長度的形式。TCPAgent根據(jù)該長度 從緩沖中選擇若干TCP分組發(fā)給AS，選取規(guī)則如下 ：
[0120] (A)這些TCP分組的長度總和不超過通告數(shù)據(jù)長度；
[0121] (B)該TCP分組序號范圍不超過SND值。
[0122] 在一個TCP分組報文發(fā)給AS之后，需要針對該報文構(gòu)造一個純ACK回復給本端 TCP層，以通知其該報文已被正確接收而可以正常增長發(fā)送窗口，該ACK報文的ack字段值 與所發(fā)數(shù)據(jù)報文的最大序號值加 1相等。在構(gòu)造 ACK時，可以采用類似于TCP的DelayedACK 機制，即減少純ACK報文數(shù)，對一次發(fā)包指示中選取的多個TCP分組報文，僅針對對于最后 一個分組報文構(gòu)造純ACK。
[0123] 所構(gòu)造的純ACK中的win字段值，一般情況下直接采用WIN值即可。因為發(fā)端發(fā) 出的數(shù)據(jù)量可能超出win字段值造成對端本地緩存擁塞丟包，所以當RCV-UNA〉= WIN，即潛 在的空中數(shù)據(jù)量總和占滿通告窗口時，TCPAgent進入zero-win狀態(tài)。在此狀態(tài)下收到的 所有新傳數(shù)據(jù)，在構(gòu)造 ACK時需要將win字段值設(shè)置為0,以通知本端暫停發(fā)包。
[0124] (3) TCPAgent接收到對端報文的流程：
[0125] TCPAgent首先解析對端報文中的首部信息：對ACK和SACK的解析，需要將ack字 段值以及多個SACK分段中的選擇性確認序號區(qū)間記錄下來；對win字段解析，總是將字段 值記錄到本地WIN變量中。
[0126] 對于非冗余ACK的正常情況（即ACK大于UNA)，則報文中必不包含SACK丟包信 息，此時將UNA值更新為ACK。同時，要將新舊UNA值之間覆蓋到的所有TCP分組進行刪除 (考慮到存在交疊的分組，故須要某分組的SN全部范圍都落入應(yīng)刪除范圍，才能刪除）
[0127] 對于連續(xù)冗余ACK的事件，包含如下幾種情形：
[0128] A).非SACK報文：在同一個UNA值上發(fā)生了連續(xù)三次重復的ACK，認為此UNA處發(fā) 生了丟包，將從UNA到SND之間的所有TCP分組（但總數(shù)不超過Nretx個，Nretx值可調(diào)整， 比如20個）全部重傳給對端。
[0129] B). SACK重復報文：該類型報文表示對端聲稱收到了一個已經(jīng)連續(xù)接收的重復分 組，對于此情況什么都不處理。
[0130] C). SACK亂序/丟失報文：該類型報文表示對端聲稱收到了一個未連續(xù)接收的分 組，當在同一個UNA值上連續(xù)發(fā)生三次之后，將從UNA到SND之間的并且處于SACK聲稱分 組之外的所有分組（也不超過Nretx個）全部重傳給對端。
[0131] 假如空中接口有報文丟失發(fā)生，則該報文之后的窗口內(nèi)連續(xù)報文會觸發(fā)大量冗余 ACK事件。為了減少不必要的重傳規(guī)模，在第一次較激進的重傳策略之后，如果繼續(xù)發(fā)生在 同一 UNA值上的冗余ACK事件，則采取保守的重傳策略，即僅僅重傳 UNA值對應(yīng)的一個TCP 分組。
[0132] 當TCPAgent處于zero-win狀態(tài)時，并且UNA的更新使得RCV_UNA〈WIN時，則進入 正常狀態(tài)。此時需要構(gòu)造一個純ACK報文，其中ack字段為SND值，win字段則是WIN值。 該報文通知本端重新恢復已暫停的發(fā)包流程。
[0133] 最后針對該報文的后續(xù)處理：若該報文是純ACK則會被丟棄；如果該報文是攜帶 數(shù)據(jù)負載的捎帶ACK，則不修改報文的任何內(nèi)容直接透傳給本端TCP層。
[0134] (4)連接維護：
[0135] 如果TCPAgent收到本端的FIN報文，則進入本地關(guān)閉狀態(tài)。該狀態(tài)下將丟棄之后 收到的任何本地新傳數(shù)據(jù)（即位于RCV之后的數(shù)據(jù)），并且要一直把緩存中的所有數(shù)據(jù)全部 被對端確認接收之后，才將該FIN報文發(fā)給對端。如果收到對端的FIN報文，則將該FIN報 文透傳給本端TCP層即可。
[0136] TCPAgent不管在哪一端上收到了 RST報文，立即清空該報文對應(yīng)的本地緩存，并 透傳該報文。
[0137] 除了正常的連接關(guān)閉流程，為了增強本發(fā)明的健壯性，TCPAgent需要對連接進行 監(jiān)測。
[0138] TCPAgent維護一個對端連接監(jiān)控定時器（時長可配，在分鐘量級），每當收到對端 的任何報文時重啟該定時器。如果該定時器超時則認為與對端的連接斷開，此時會清空該 連接對應(yīng)的本地緩存，并且構(gòu)造 RST報文發(fā)給本端與對端。
[0139] 在長期處于zero-win的情況下，TCPAgent有可能會收到本端TCP層發(fā)送的窗口 探測包，其中包含了長度為1的數(shù)據(jù)。針對該報文立刻構(gòu)造 ACK進行回復，其中ack字段為 SND值，win字段為0。
[0140] (5) TCPAgent對捎帶ACK的特殊處理：
[0141] 當TCPAgent接受到對端的捎帶ACK，是不修改該報文內(nèi)容的，但因為在有數(shù)據(jù)緩 存時，該ACK值必定是小于當前已回復的最大ACK值，即SND，所以這個捎帶ACK必定會被認 為是一個冗余ACK。針對這種情況，本方案提出了一種特殊處理。首先維護一個計數(shù)器，計 數(shù)值在透傳一個捎帶ACK會加一，在完成一次（2)中的純ACK流程會重置為0。當該計數(shù)值 達到3時，即表明此次透傳操作將會觸發(fā)本端TCP層的快速恢復算法。此時如果發(fā)送緩存 中有待發(fā)數(shù)據(jù)，則需要在透傳之前構(gòu)造一個純ACK，該純ACK的ack字段值，采用發(fā)送緩存中 SND值對應(yīng)的第一個報文的數(shù)據(jù)最大序號值加1。如果發(fā)送緩存沒有數(shù)據(jù)，說明沒有業(yè)務(wù)， 無需構(gòu)造純ACK。
[0142] 另外如果發(fā)生了以上純ACK的構(gòu)造，那么當以后（2)中的流程再需要構(gòu)造相同ack 字段值的純ACK時，就不需要再構(gòu)造了。
[0143] 通過本實施例，提供了一種提高LTE系統(tǒng)中TCP數(shù)據(jù)傳輸性能的方案，該方案通過 避免無線鏈路不穩(wěn)定性對TCP傳輸協(xié)議的影響，從而使得TCP業(yè)務(wù)的傳輸性能能夠達到系 統(tǒng)帶寬的極限。
[0144] 為了簡化本方案的實現(xiàn)復雜度，可以將TCPAgent部署于LTE系統(tǒng)內(nèi)部，作為LTE 系統(tǒng)軟件的一部分放置在AS之上，或者，將TCPAgent放在PC側(cè)終端網(wǎng)口驅(qū)動之中，以在性 能上引入的額外開銷可以集中到系統(tǒng)資源更加充裕的PC系統(tǒng)中。
[0145] 通過本方案中的TCPAgent發(fā)包指示機制，使得TCPAgent回復ACK的速率與LTE 帶寬相一致，這能使本端TCP窗口穩(wěn)步增長。一方面，本端數(shù)據(jù)的立即響應(yīng)有利于窗口的快 速增大，但另一方面緩存數(shù)據(jù)量的不斷加大使得所緩存報文被發(fā)出的時機越來越遲，即本 端觀測到的RTT越來越大，從而減緩了窗口增長的速度。這正反兩方面因素達到合理的平 衡點，與LTE的帶寬速率最終相統(tǒng)一。
[0146] 通過本方案中的TCPAgent對捎帶ACK的特殊處理，極大地減小了修改每一個捎帶 ACK數(shù)據(jù)包帶來的巨大開銷。采用修改數(shù)據(jù)的方案帶來的開銷，主要是對每一個報文都重新 計算并修改TCP校驗和，這需要對整個數(shù)據(jù)內(nèi)容進行遍歷和數(shù)值計算，CPU消耗極大。而采 用本方案，報文無需修改，也不是每一個捎帶ACK都會觸發(fā)純ACK的構(gòu)造，更重要的是即使 構(gòu)造純ACK，因為純ACK字節(jié)少且大部分內(nèi)容使用的是保存的數(shù)據(jù)模板，CPU消耗極小。
[0147] 通過本方案中的TCPAgent通過zero-win狀態(tài)避免了空中數(shù)據(jù)量超過通告窗口的 情況出現(xiàn)；通過對SACK機制的支持能夠讓重傳范圍控制在更為精確的序號區(qū)間；對通過連 接的監(jiān)控能讓TCPAgent能夠長期穩(wěn)定的工作。
[0148] 實施例五
[0149] 參照圖4,示出了根據(jù)本發(fā)明實施例五的一種基于TCP的TCPAgent (傳輸控制協(xié)議 代理）裝置的結(jié)構(gòu)框圖。
[0150] 本實施例的基于TCP的TCPAgent裝置用于在TCP數(shù)據(jù)傳輸中的TCP代理，該裝置 包括：
[0151] 接收模塊402,用于接收本端的LTE AS層發(fā)送的通知消息；
[0152] 選擇發(fā)送模塊404,用于根據(jù)通知消息中攜帶的可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度的 信息，按照TCP分組的序號，順序從緩存的TCP分組中選擇至少一個TCP分組發(fā)送給所述AS 層，其中，選擇的至少一個TCP分組的長度總和小于或等于所述可用數(shù)據(jù)傳輸資源的數(shù)據(jù) 長度，且，選擇的各個TCP分組的序號小于或等于本端的SND ;
[0153] 反饋模塊406，用于針對發(fā)送給所述AS層的TCP分組構(gòu)造確認報文，并將所述確認 報文反饋給向TCPAgent裝置發(fā)送TCP分組的TCP協(xié)議層。
[0154] 通過本實施例的TCPAgent裝置，針對發(fā)出的TCP分組構(gòu)造并向本端的TCP層發(fā)送 相應(yīng)的確認報文，使得本端的TCP層認為所發(fā)出的TCP分組總是被對端正確的接收，從而使 TCP層發(fā)送窗口始終保持增長的態(tài)勢，并且穩(wěn)定連續(xù)地將數(shù)據(jù)發(fā)送到TCPAgent裝置，從而 避免了 LTE網(wǎng)絡(luò)中無線鏈路不穩(wěn)定性對TCP分組數(shù)據(jù)傳輸?shù)挠绊懀沟靡苿咏K端在進行各 種數(shù)據(jù)傳輸業(yè)務(wù)時，傳輸性能能夠達到系統(tǒng)帶寬的極限，解決了傳統(tǒng)以太網(wǎng)絡(luò)中的TCP擁 塞控制在LTE網(wǎng)絡(luò)環(huán)境波動導致出現(xiàn)丟包亂序情況下，導致不適當?shù)挠|發(fā)TCP的擁塞窗口 收縮，進而影響LTE網(wǎng)絡(luò)中的數(shù)據(jù)傳輸?shù)膯栴}。
[0155] 實施例六
[0156] 參照圖5,示出了根據(jù)本發(fā)明實施例六的一種基于TCP的實施例六裝置的結(jié)構(gòu)框 圖。
[0157] 本實施例的基于TCP的TCPAgent裝置用于在TCP數(shù)據(jù)傳輸中的TCP代理，可設(shè)置 于LTE系統(tǒng)內(nèi)部的AS層之上，或者，將TCPAgent裝置放在PC側(cè)終端網(wǎng)口驅(qū)動裝置之中。
[0158] 本實施例的TCPAgent裝置包括：
[0159] 接收模塊502,用于接收本端的LTE AS層發(fā)送的通知消息；
[0160] 選擇發(fā)送模塊504,用于根據(jù)通知消息中攜帶的可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度的 信息，按照TCP分組的序號，順序從緩存的TCP分組中選擇至少一個TCP分組發(fā)送給所述AS 層，其中，選擇的至少一個TCP分組的長度總和小于或等于所述可用數(shù)據(jù)傳輸資源的數(shù)據(jù) 長度，且，選擇的各個TCP分組的序號小于或等于本端的SND ;
[0161] 反饋模塊506，用于針對發(fā)送給所述AS層的TCP分組構(gòu)造確認報文，并將所述確認 報文反饋給向TCPAgent裝置發(fā)送TCP分組的TCP層。
[0162] 優(yōu)選地，本實施例的TCPAgent裝置還包括：
[0163] 判斷模塊508,用于在接收模塊502接收本端的LTE AS層發(fā)送的通知消息之后，判 斷所述可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度是否小于所述緩存的TCP分組中序號最小的TCP分組 的長度；
[0164] 所述選擇發(fā)送模塊504,用于若判斷模塊508的判斷結(jié)果為是，則選擇所述序號最 小的TCP分組發(fā)送給所述AS層；若判斷模塊508的判斷結(jié)果為否，則根據(jù)所述可用數(shù)據(jù)傳 輸資源的數(shù)據(jù)長度的信息，按照TCP分組的序號，順序從緩存的TCP分組中選擇至少一個 TCP分組發(fā)送給所述AS層。
[0165] 優(yōu)選地，當選擇發(fā)送模塊504從緩存的TCP分組中選擇了多個TCP分組時，所述反 饋模塊506,用于僅針對所述多個TCP分組中的最后一個TCP分組構(gòu)造純確認報文，以及，將 構(gòu)造的純確認報文反饋給向TCPAgent裝置發(fā)送TCP分組的TCP層；
[0166] 其中，
[0167] 所述純確認報文中的確認字段值等于所述最后一個TCP分組的序號值加一；
[0168] 當RCV與UNA的差大于或等于TCP分組接收端的通告窗口值時，所述純確認報文 中的窗口字段值設(shè)置為〇,以通知TCP層暫停向TCPAgent裝置發(fā)送TCP分組；反之，所述純 確認報文中的窗口字段值為TCP分組接收端的通告窗口值。
[0169] 優(yōu)選地，反饋模塊506,用于針對發(fā)送給所述AS層的每個TCP分組構(gòu)造純確認報 文，并將構(gòu)造的所述純確認報文反饋給向TCPAgent裝置發(fā)送TCP分組的TCP層；
[0170] 其中，
[0171] 所述純確認報文中的確認字段值等于與所述純確認報文相對應(yīng)的TCP分組的序 號值與該TCP分組的長度之和加一；
[0172] 當RCV與UNA的差大于或等于TCP分組接收端的通告窗口值時，所述純確認報文 中的窗口字段值設(shè)置為〇,以通知TCP層暫停向TCPAgent裝置發(fā)送TCP分組；反之，所述純 確認報文中的窗口字段值為TCP分組接收端的通告窗口值。
[0173] 優(yōu)選地，本實施例的TCPAgent裝置中設(shè)置有捎帶確認報文計數(shù)器，用于對向TCP 層透傳 TCP分組接收端的捎帶確認報文的次數(shù)計數(shù)；
[0174] 所述TCPAgent裝置還包括：
[0175] 捎帶確認報文處理模塊510,用于在反饋模塊506將所述確認報文反饋給向 TCPAgent裝置發(fā)送TCP分組的TCP層之后，接收到TCP分組接收端發(fā)送的捎帶確認報文； 判斷緩存中是否存在待發(fā)送的TCP分組；若存在，且所述捎帶確認報文計數(shù)器的計數(shù)值為 3時，則構(gòu)造純確認報文，將該純確認報文的確認字段值設(shè)置為所述緩存中的當前連續(xù)已發(fā) 或待發(fā)的TCP分組的最大序號值加一，向TCP層發(fā)送該純確認報文并透傳所述捎帶確認報 文，將所述捎帶確認報文計數(shù)器置〇 ;若不存在，則透傳所述捎帶確認報文，將所述捎帶確 認報文計數(shù)器加1。
[0176] 優(yōu)選地，本實施例的TCPAgent裝置還包括：
[0177] 報文判斷模塊512,用于在反饋模塊506針對發(fā)送給所述AS層的每個TCP分組構(gòu) 造純確認報文之前，判斷是否已為當前TCP分組構(gòu)造過純確認報文；若已構(gòu)造過，則不再為 當前TCP分組構(gòu)造的純確認報文。
[0178] 優(yōu)選地，接收模塊502,用于接收所述AS層發(fā)送的、攜帶了發(fā)送TCP分組的可用數(shù) 據(jù)傳輸資源的數(shù)據(jù)長度的信息的通知消息；其中，所述可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度由所 述AS層根據(jù)設(shè)定次數(shù)的發(fā)送TCP分組使用的資源均值和設(shè)定的放大系數(shù)確定。
[0179] 優(yōu)選地，本實施例的TCPAgent裝置還包括：
[0180] 重復判斷模塊514,用于在接收模塊502接收本端的LTE AS層發(fā)送的通知消息之 前，判斷TCP層發(fā)送的TCP分組的序號是否與TCPAgent裝置已緩存的TCP分組的序號重復； 若重復，則丟棄該TCP分組；若不重復，則緩存該TCP分組。
[0181] 優(yōu)選地，本實施例的TCPAgent裝置還包括：
[0182] 第一確認報文處理模塊516,用于在反饋模塊506將所述確認報文反饋給向 TCPAgent裝置發(fā)送TCP分組的TCP層之后，接收TCP分組接收端反饋的確認報文；判斷當前 接收到的所述反饋的確認報文中的確認字段值是否大于本端當前記錄的UNA;若是，則將 本端當前記錄的UNA更新為當前收到的所述反饋的確認報文中的確認字段值，并將TCP分 組的序號值小于更新后的UNA的所有TCP分組刪除；若否，則將重傳計數(shù)器加1，并且，當重 傳計數(shù)器達到3時，確定發(fā)生確認報文冗余事件，根據(jù)所饋的確認報文確定冗余類型，根據(jù) 確定的冗余類型進行TCP分組重傳，并在重傳后將重傳計數(shù)器清0。
[0183] 優(yōu)選地，第一確認報文處理模塊516在根據(jù)反饋的確認報文確定冗余類型，根據(jù) 確定的冗余類型進行TCP分組重傳時：
[0184] 確定反饋的確認報文為選擇性確認報文，且，所述選擇性確認報文指示TCP分組 接收端接收的TCP分組發(fā)生亂序或丟包，則將TCP代理緩存的UNA與SND之間的、除所述選 擇性確認報文指示的已被TCP分組接收端接收到的TCP分組之外的所有TCP分組重傳給 TCP分組接收端；
[0185] 或者，
[0186] 確定反饋的確認報文為選擇性確認報文，且，所述選擇性確認報文指示TCP分組 接收端接收的TCP分組發(fā)生重復，則不做處理；
[0187] 或者，
[0188] 確定反饋的確認報文為確認報文，且，所述確認報文指示TCP分組接收端接收的 TCP分組發(fā)生丟包，則將TCPAgent裝置緩存的、所述確認報文中的確認字段值至SND之間的 所有TCP分組重傳給TCP分組接收端。
[0189] 優(yōu)選地，本實施例的TCPAgent裝置還包括：
[0190] 保守重傳模塊518,用于在第一確認報文處理模塊516確定發(fā)生確認報文冗余事 件之后，根據(jù)反饋的確認報文確定冗余類型，根據(jù)確定的冗余類型進行TCP分組重傳之前， 判斷確認報文冗余事件是否是發(fā)生在UNA上的首次冗余事件；
[0191] 若是首次冗余，則將TCPAgent裝置緩存的、UNA與SND之間的、除所述選擇性確認 報文指示的已被TCP分組接收端接收到的TCP分組之外的所有TCP分組重傳給TCP分組接 收端，或者，則將TCPAgent裝置緩存的、所述確認報文中的確認字段值至SND之間的所有 TCP分組重傳給TCP分組接收端；
[0192] 若不是首次冗余，則僅重傳 UNA加一后對應(yīng)的TCP分組。
[0193] 優(yōu)選地，本實施例的TCPAgent裝置還包括：
[0194] 第二確認報文處理模塊520,用于在第一確認報文處理模塊516根據(jù)反饋的確認 報文確定冗余類型，根據(jù)確定的冗余類型進行TCP分組重傳之后，判斷反饋的確認報文的 類型；若反饋的確認報文為純確認報文，則丟棄；若反饋的確認報文為捎帶確認報文，則將 捎帶確認報文透傳至TCP層。
[0195] 優(yōu)選地，本實施例的TCPAgent裝置還包括：
[0196] 第一連接維護模塊（圖中未示出），用于確定接收到TCP層的結(jié)束報文，則進入本 地關(guān)閉狀態(tài)，丟棄結(jié)束報文之后收到的TCP層發(fā)送的TCP分組，并且，將緩存的所有剩余TCP 分組發(fā)送給TCP分組接收端且被TCP分組接收端確認后，將結(jié)束報文發(fā)送給TCP分組接收 端；
[0197] 或者，
[0198] 用于確定接收到TCP分組接收端發(fā)送的結(jié)束報文，則將結(jié)束報文透傳給TCP層。
[0199] 優(yōu)選地，本實施例的TCPAgent裝置還包括：
[0200] 第二連接維護模塊（圖中未示出），用于確定接收到復位報文，則立即清空 TCPAgent裝置緩存的所有TCP分組，并將復位報文透傳給TCP層。
[0201] 優(yōu)選地，本實施例的TCPAgent裝置還包括：
[0202] 第三連接維護模塊（圖中未示出），用于確定維護的對TCP分組接收端連接進行監(jiān) 控的分鐘量級監(jiān)控定時器超時，則立即清空TCPAgent裝置緩存的所有TCP分組，并構(gòu)造復 位報文透傳給TCP層和TCP分組接收端。
[0203] 優(yōu)選地，本實施例的TCPAgent裝置還包括：
[0204] 第四連接維護模塊（圖中未示出），用于在反饋模塊506針對發(fā)送給所述AS層的 TCP分組構(gòu)造確認報文之后，確定接收到TCP層發(fā)送的窗口探測報文；構(gòu)造純確認報文回復 TCP層，并丟棄窗口探測報文，其中，構(gòu)造的純確認報文的確認字段值為SND，窗口字段值為 0〇
[0205] 本實施例的TCPAgent裝置用于實現(xiàn)前述多個方法實施例中相應(yīng)的基于TCP的數(shù) 據(jù)傳輸方法中的TCPAgent的功能，并具有相應(yīng)的有益效果，在此不再贅述。
[0206] 通過本發(fā)明的TCPAgent，終端設(shè)備的LTE網(wǎng)口速率能夠立刻達到與LTE帶寬的 理論上限，而LTE網(wǎng)絡(luò)不穩(wěn)定性造成的速率波動不會對網(wǎng)口速率產(chǎn)生影響。使用本發(fā)明的 TCPAgent進行FTP和Iperf TCP兩種場景進行上下行業(yè)務(wù)速率對比分別如圖6和圖7所 /_J、1 〇
[0207] 其中，圖6是FTP上下行業(yè)務(wù)速率對比效果圖，在圖6中，未使用本發(fā)明的 TCPAgent的平均速率是下行60. 2+上行5. 68mbps，使用本發(fā)明的TCPAgent的平均速率是 下行 60. 5+ 上行 15. 4mbps。
[0208] 圖7是IperfTCP上下行業(yè)務(wù)速率對比效果圖，在圖7中，未使用本發(fā)明的 TCPAgent的平均速率是下行47. 1+上行9. 08mbps，使用本發(fā)明的TCPAgent的平均速率是 下行 53. 4+ 上行 15. 3mbps。
[0209] 從圖6和圖7中可以看出，傳統(tǒng)的TCP數(shù)據(jù)傳輸業(yè)務(wù)尤其是上行業(yè)務(wù)存在非常明 顯抖動，這嚴重影響了均值速率的表現(xiàn)，而通過本發(fā)明的方案，有效減少了業(yè)務(wù)抖動，提高 了均值速率。
[0210] 本說明書中的各個實施例均采用遞進的方式描述，每個實施例重點說明的都是與 其他實施例的不同之處，各個實施例之間相同相似的部分互相參見即可。對于裝置實施例 而言，由于其與方法實施例基本相似，所以描述的比較簡單，相關(guān)之處參見方法實施例的部 分說明即可。
[0211] 以上對本發(fā)明所提供的一種基于TCP的數(shù)據(jù)傳輸方法和TCPAgent裝置進行了詳 細介紹，本文中應(yīng)用了具體個例對本發(fā)明的原理及實施方式進行了闡述，以上實施例的說 明只是用于幫助理解本發(fā)明的方法及其核心思想；同時，對于本領(lǐng)域的一般技術(shù)人員，依據(jù) 本發(fā)明的思想，在【具體實施方式】及應(yīng)用范圍上均會有改變之處，綜上所述，本說明書內(nèi)容不 應(yīng)理解為對本發(fā)明的限制。
【權(quán)利要求】
1. 一種基于傳輸控制協(xié)議的數(shù)據(jù)傳輸方法，其特征在于，包括： 傳輸控制協(xié)議代理接收本端的長期演進接入層發(fā)送的通知消息； 所述傳輸控制協(xié)議代理根據(jù)所述通知消息中攜帶的可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度的 信息，按照傳輸控制協(xié)議分組的序號，順序從緩存的傳輸控制協(xié)議分組中選擇至少一個傳 輸控制協(xié)議分組發(fā)送給所述接入層，其中，選擇的所述至少一個傳輸控制協(xié)議分組的長度 總和小于或等于所述可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度，且，選擇的各個所述傳輸控制協(xié)議分 組的序號小于或等于本端的傳輸控制協(xié)議層當前連續(xù)已發(fā)或待發(fā)的傳輸控制協(xié)議分組的 最大序號值加一； 所述傳輸控制協(xié)議代理針對發(fā)送給所述接入層的所述傳輸控制協(xié)議分組構(gòu)造確認報 文，并將所述確認報文反饋給向所述傳輸控制協(xié)議代理發(fā)送傳輸控制協(xié)議分組的傳輸控制 協(xié)議層。
2. 根據(jù)權(quán)利要求1所述的方法，其特征在于，在所述傳輸控制協(xié)議代理接收本端的長 期演進接入層發(fā)送的通知消息的步驟之后，還包括： 判斷所述可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度是否小于所述緩存的傳輸控制協(xié)議分組中序 號最小的傳輸控制協(xié)議分組的長度； 若是，則選擇所述序號最小的傳輸控制協(xié)議分組發(fā)送給所述接入層；若否，則執(zhí)行所述 傳輸控制協(xié)議代理根據(jù)所述可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度的信息，按照傳輸控制協(xié)議分組 的序號，順序從緩存的傳輸控制協(xié)議分組中選擇至少一個傳輸控制協(xié)議分組發(fā)送給所述接 入層的步驟。
3. 根據(jù)權(quán)利要求1或2所述的方法，其特征在于，當所述傳輸控制協(xié)議代理從緩存的傳 輸控制協(xié)議分組中選擇了多個傳輸控制協(xié)議分組時，所述傳輸控制協(xié)議代理針對發(fā)送給所 述接入層的所述傳輸控制協(xié)議分組構(gòu)造確認報文的步驟包括： 所述傳輸控制協(xié)議代理僅針對所述多個傳輸控制協(xié)議分組中的最后一個傳輸控制協(xié) 議分組構(gòu)造純確認報文； 其中， 所述純確認報文中的確認字段值等于所述最后一個傳輸控制協(xié)議分組的序號值加 當所述傳輸控制協(xié)議代理從所述傳輸控制協(xié)議層接收到的傳輸控制協(xié)議分組的最大 序號值加一，與，已被傳輸控制協(xié)議分組接收端連續(xù)確認的傳輸控制協(xié)議分組的最大序號 值的差，大于或等于所述傳輸控制協(xié)議分組接收端的通告窗口值時，所述純確認報文中的 窗口字段值設(shè)置為〇,以通知所述傳輸控制協(xié)議層暫停向所述傳輸控制協(xié)議代理發(fā)送傳輸 控制協(xié)議分組；反之，所述純確認報文中的窗口字段值為所述傳輸控制協(xié)議分組接收端的 通告窗口值。
4. 根據(jù)權(quán)利要求1或2所述的方法，其特征在于，所述傳輸控制協(xié)議代理針對發(fā)送給所 述接入層的所述傳輸控制協(xié)議分組構(gòu)造確認報文的步驟包括： 所述傳輸控制協(xié)議代理針對發(fā)送給所述接入層的每個所述傳輸控制協(xié)議分組構(gòu)造純 確認報文； 其中， 所述純確認報文中的確認字段值等于與所述純確認報文相對應(yīng)的傳輸控制協(xié)議分組 的序號值與該傳輸控制協(xié)議分組的長度之和加一； 當所述傳輸控制協(xié)議代理從所述傳輸控制協(xié)議層接收到的傳輸控制協(xié)議分組的最大 序號值加一，與，已被傳輸控制協(xié)議分組接收端連續(xù)確認的傳輸控制協(xié)議分組的最大序號 值的差，大于或等于所述傳輸控制協(xié)議分組接收端的通告窗口值時，所述純確認報文中的 窗口字段值設(shè)置為0,以通知所述傳輸控制協(xié)議層暫停向所述傳輸控制協(xié)議代理發(fā)送傳輸 控制協(xié)議分組；反之，所述純確認報文中的窗口字段值為所述傳輸控制協(xié)議分組接收端的 通告窗口值。
5. 根據(jù)權(quán)利要求4所述的方法，其特征在于，所述傳輸控制協(xié)議代理中設(shè)置有捎帶確 認報文計數(shù)器，用于對向所述傳輸控制協(xié)議層透傳所述傳輸控制協(xié)議分組接收端的捎帶確 認報文的次數(shù)計數(shù)； 在將所述確認報文反饋給向所述傳輸控制協(xié)議代理發(fā)送傳輸控制協(xié)議分組的傳輸控 制協(xié)議層的步驟之后，所述方法還包括： 所述傳輸控制協(xié)議代理接收到所述傳輸控制協(xié)議分組接收端發(fā)送的捎帶確認報文； 判斷緩存中是否存在待發(fā)送的傳輸控制協(xié)議分組； 若存在，且所述捎帶確認報文計數(shù)器的計數(shù)值為3時，則構(gòu)造純確認報文，將該純確認 報文的確認字段值設(shè)置為所述緩存中的當前連續(xù)已發(fā)或待發(fā)的傳輸控制協(xié)議分組的最大 序號值加一，向所述傳輸控制協(xié)議層發(fā)送該純確認報文并透傳所述捎帶確認報文，將所述 捎帶確認報文計數(shù)器置〇 ; 若不存在，則透傳所述捎帶確認報文，將所述捎帶確認報文計數(shù)器加1。
6. 根據(jù)權(quán)利要求5所述的方法，其特征在于，在所述傳輸控制協(xié)議代理針對發(fā)送給所 述接入層的每個所述傳輸控制協(xié)議分組構(gòu)造純確認報文的步驟之前，還包括： 判斷是否已為當前傳輸控制協(xié)議分組構(gòu)造過純確認報文； 若已構(gòu)造過，則不再為當前傳輸控制協(xié)議分組構(gòu)造的純確認報文。
7. 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述傳輸控制協(xié)議代理接收本端的長期 演進接入層發(fā)送的通知消息的步驟包括： 所述傳輸控制協(xié)議代理接收所述接入層發(fā)送的、攜帶了發(fā)送傳輸控制協(xié)議分組的可用 數(shù)據(jù)傳輸資源的數(shù)據(jù)長度的信息的通知消息； 其中，所述可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度由所述接入層根據(jù)設(shè)定次數(shù)的發(fā)送傳輸控制 協(xié)議分組使用的資源均值和設(shè)定的放大系數(shù)確定。
8. 根據(jù)權(quán)利要求1所述的方法，其特征在于，在所述傳輸控制協(xié)議代理接收本端的長 期演進接入層發(fā)送的通知消息的步驟之前，還包括： 所述傳輸控制協(xié)議代理判斷所述傳輸控制協(xié)議層發(fā)送的傳輸控制協(xié)議分組的序號是 否與所述傳輸控制協(xié)議代理已緩存的傳輸控制協(xié)議分組的序號重復； 若重復，則丟棄該傳輸控制協(xié)議分組；若不重復，則所述傳輸控制協(xié)議代理緩存該傳輸 控制協(xié)議分組。
9. 根據(jù)權(quán)利要求1所述的方法，其特征在于，在將所述確認報文反饋給向所述傳輸控 制協(xié)議代理發(fā)送傳輸控制協(xié)議分組的傳輸控制協(xié)議層的步驟之后，還包括： 接收傳輸控制協(xié)議分組接收端反饋的確認報文； 判斷當前接收到的所述反饋的確認報文中的確認字段值是否大于本端當前記錄的、已 被傳輸控制協(xié)議分組接收端連續(xù)確認的傳輸控制協(xié)議分組的最大序號值； 若是，則將本端當前記錄的已被傳輸控制協(xié)議分組接收端連續(xù)確認的傳輸控制協(xié)議分 組的最大序號值更新為當前收到的所述反饋的確認報文中的確認字段值，并將傳輸控制協(xié) 議分組的序號值小于更新后的所述最大序號值的所有傳輸控制協(xié)議分組刪除； 若否，則將重傳計數(shù)器加1，并且，當所述重傳計數(shù)器達到3時，確定發(fā)生確認報文冗余 事件，根據(jù)所述反饋的確認報文確定冗余類型，根據(jù)確定的所述冗余類型進行傳輸控制協(xié) 議分組重傳，并在重傳后將所述重傳計數(shù)器清0。
10. 根據(jù)權(quán)利要求9所述的方法，其特征在于，根據(jù)所述反饋的確認報文確定冗余類 型，根據(jù)確定的所述冗余類型進行傳輸控制協(xié)議分組重傳的步驟包括： 確定所述反饋的確認報文為選擇性確認報文，且，所述選擇性確認報文指示所述傳輸 控制協(xié)議分組接收端接收的傳輸控制協(xié)議分組發(fā)生亂序或丟包，則將所述傳輸控制協(xié)議代 理緩存的、已被所述傳輸控制協(xié)議分組接收端連續(xù)確認的傳輸控制協(xié)議分組的最大序號值 與所述傳輸控制協(xié)議層當前連續(xù)已發(fā)或待發(fā)的傳輸控制協(xié)議分組的最大序號值加一之間 的、除所述選擇性確認報文指示的已被所述傳輸控制協(xié)議分組接收端接收到的傳輸控制協(xié) 議分組之外的所有傳輸控制協(xié)議分組重傳給所述傳輸控制協(xié)議分組接收端； 或者， 確定所述反饋的確認報文為選擇性確認報文，且，所述選擇性確認報文指示所述傳輸 控制協(xié)議分組接收端接收的傳輸控制協(xié)議分組發(fā)生重復，則不做處理； 或者， 確定所述反饋的確認報文為確認報文，且，所述確認報文指示所述傳輸控制協(xié)議分組 接收端接收的傳輸控制協(xié)議分組發(fā)生丟包，則將所述傳輸控制協(xié)議代理緩存的、所述確認 報文中的確認字段值至所述傳輸控制協(xié)議層當前連續(xù)已發(fā)或待發(fā)的傳輸控制協(xié)議分組的 最大序號值加一之間的所有傳輸控制協(xié)議分組重傳給所述傳輸控制協(xié)議分組接收端。
11. 根據(jù)權(quán)利要求10所述的方法，其特征在于，在確定發(fā)生確認報文冗余事件之后，根 據(jù)所述反饋的確認報文確定冗余類型，根據(jù)確定的所述冗余類型進行傳輸控制協(xié)議分組重 傳之前，還包括： 判斷所述確認報文冗余事件是否是發(fā)生在已被傳輸控制協(xié)議分組接收端連續(xù)確認的 傳輸控制協(xié)議分組的最大序號值上的首次冗余事件； 若是首次冗余，則將所述傳輸控制協(xié)議代理緩存的、已被所述傳輸控制協(xié)議分組接收 端連續(xù)確認的傳輸控制協(xié)議分組的最大序號值與所述傳輸控制協(xié)議層當前連續(xù)已發(fā)或待 發(fā)的傳輸控制協(xié)議分組的最大序號值加一之間的、除所述選擇性確認報文指示的已被所述 傳輸控制協(xié)議分組接收端接收到的傳輸控制協(xié)議分組之外的所有傳輸控制協(xié)議分組重傳 給所述傳輸控制協(xié)議分組接收端，或者，則將所述傳輸控制協(xié)議代理緩存的、所述確認報文 中的確認字段值至所述傳輸控制協(xié)議層當前連續(xù)已發(fā)或待發(fā)的傳輸控制協(xié)議分組的最大 序號值加一之間的所有傳輸控制協(xié)議分組重傳給所述傳輸控制協(xié)議分組接收端； 若不是首次冗余，則僅重傳所述已被傳輸控制協(xié)議分組接收端連續(xù)確認的傳輸控制協(xié) 議分組的最大序號值加一后對應(yīng)的傳輸控制協(xié)議分組。
12. 根據(jù)權(quán)利要求10所述的方法，其特征在于，在根據(jù)所述反饋的確認報文確定冗余 類型，根據(jù)確定的所述冗余類型進行傳輸控制協(xié)議分組重傳的步驟之后，還包括： 判斷所述反饋的確認報文的類型； 若所述反饋的確認報文為純確認報文，則丟棄； 若所述反饋的確認報文為捎帶確認報文，則將所述捎帶確認報文透傳至所述傳輸控制 協(xié)議層。
13. 根據(jù)權(quán)利要求1所述的方法，其特征在于，還包括： 確定接收到所述傳輸控制協(xié)議層的結(jié)束報文，則進入本地關(guān)閉狀態(tài)，丟棄所述結(jié)束報 文之后收到的所述傳輸控制協(xié)議層發(fā)送的傳輸控制協(xié)議分組，并且，將緩存的所有剩余傳 輸控制協(xié)議分組發(fā)送給傳輸控制協(xié)議分組接收端且被所述傳輸控制協(xié)議分組接收端確認 后，將所述結(jié)束報文發(fā)送給所述傳輸控制協(xié)議分組接收端； 或者， 確定接收到所述傳輸控制協(xié)議分組接收端發(fā)送的結(jié)束報文，則將所述結(jié)束報文透傳給 所述傳輸控制協(xié)議層。
14. 根據(jù)權(quán)利要求1所述的方法，其特征在于，還包括： 確定接收到復位報文，則立即清空所述傳輸控制協(xié)議代理緩存的所有傳輸控制協(xié)議分 組，并將所述復位報文透傳給所述傳輸控制協(xié)議層。
15. 根據(jù)權(quán)利要求1所述的方法，其特征在于，還包括： 所述傳輸控制協(xié)議代理確定維護的對所述傳輸控制協(xié)議分組接收端連接進行監(jiān)控的 分鐘量級監(jiān)控定時器超時，則立即清空所述傳輸控制協(xié)議代理緩存的所有傳輸控制協(xié)議分 組，并構(gòu)造復位報文透傳給所述傳輸控制協(xié)議層和所述傳輸控制協(xié)議分組接收端。
16. 根據(jù)權(quán)利要求2或3所述的方法，其特征在于，在所述傳輸控制協(xié)議代理針對發(fā)送 給所述接入層的所述傳輸控制協(xié)議分組構(gòu)造確認報文的步驟之后，還包括： 所述傳輸控制協(xié)議代理確定接收到所述傳輸控制協(xié)議層發(fā)送的窗口探測報文； 構(gòu)造純確認報文回復所述傳輸控制協(xié)議層，并丟棄所述窗口探測報文，其中，構(gòu)造的純 確認報文的確認字段值為傳輸控制協(xié)議層當前連續(xù)已發(fā)或待發(fā)的傳輸控制協(xié)議分組的最 大序號值加一，窗口字段值為0。
17. -種基于傳輸控制協(xié)議的傳輸控制協(xié)議代理裝置，其特征在于，所述裝置包括： 接收模塊，用于接收本端的長期演進接入層發(fā)送的通知消息； 選擇發(fā)送模塊，用于根據(jù)所述通知消息中攜帶的可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度的信 息，按照傳輸控制協(xié)議分組的序號，順序從緩存的傳輸控制協(xié)議分組中選擇至少一個傳輸 控制協(xié)議分組發(fā)送給所述接入層，其中，選擇的所述至少一個傳輸控制協(xié)議分組的長度總 和小于或等于所述可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度，且，選擇的各個所述傳輸控制協(xié)議分組 的序號小于或等于本端的傳輸控制協(xié)議層當前連續(xù)已發(fā)或待發(fā)的傳輸控制協(xié)議分組的最 大序號值加一； 反饋模塊，用于針對發(fā)送給所述接入層的所述傳輸控制協(xié)議分組構(gòu)造確認報文，并將 所述確認報文反饋給向所述傳輸控制協(xié)議代理裝置發(fā)送傳輸控制協(xié)議分組的傳輸控制協(xié) 議層。
18. 根據(jù)權(quán)利要求17所述的裝置，其特征在于，還包括： 判斷模塊，用于在所述接收模塊接收本端的長期演進接入層發(fā)送的通知消息之后，判 斷所述可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度是否小于所述緩存的傳輸控制協(xié)議分組中序號最小 的傳輸控制協(xié)議分組的長度； 所述選擇發(fā)送模塊，用于若所述判斷模塊的判斷結(jié)果為是，則選擇所述序號最小的傳 輸控制協(xié)議分組發(fā)送給所述接入層；若所述判斷模塊的判斷結(jié)果為否，則根據(jù)所述可用數(shù) 據(jù)傳輸資源的數(shù)據(jù)長度的信息，按照傳輸控制協(xié)議分組的序號，順序從緩存的傳輸控制協(xié) 議分組中選擇至少一個傳輸控制協(xié)議分組發(fā)送給所述接入層。
19. 根據(jù)權(quán)利要求17或18所述的裝置，其特征在于，當所述選擇發(fā)送模塊從緩存的傳 輸控制協(xié)議分組中選擇了多個傳輸控制協(xié)議分組時，所述反饋模塊，用于僅針對所述多個 傳輸控制協(xié)議分組中的最后一個傳輸控制協(xié)議分組構(gòu)造純確認報文，以及，將構(gòu)造的所述 純確認報文反饋給向所述傳輸控制協(xié)議代理裝置發(fā)送傳輸控制協(xié)議分組的傳輸控制協(xié)議 層； 其中， 所述純確認報文中的確認字段值等于所述最后一個傳輸控制協(xié)議分組的序號值加 當所述傳輸控制協(xié)議代理裝置從所述傳輸控制協(xié)議層接收到的傳輸控制協(xié)議分組的 最大序號值加一，與，已被傳輸控制協(xié)議分組接收端連續(xù)確認的傳輸控制協(xié)議分組的最大 序號值的差，大于或等于所述傳輸控制協(xié)議分組接收端的通告窗口值時，所述純確認報文 中的窗口字段值設(shè)置為〇,以通知所述傳輸控制協(xié)議層暫停向所述傳輸控制協(xié)議代理裝置 發(fā)送傳輸控制協(xié)議分組；反之，所述純確認報文中的窗口字段值為所述傳輸控制協(xié)議分組 接收端的通告窗口值。
20. 根據(jù)權(quán)利要求17或18所述的裝置，其特征在于，所述反饋模塊，用于針對發(fā)送給所 述接入層的每個所述傳輸控制協(xié)議分組構(gòu)造純確認報文，并將構(gòu)造的所述純確認報文反饋 給向所述傳輸控制協(xié)議代理裝置發(fā)送傳輸控制協(xié)議分組的傳輸控制協(xié)議層； 其中， 所述純確認報文中的確認字段值等于與所述純確認報文相對應(yīng)的傳輸控制協(xié)議分組 的序號值與該傳輸控制協(xié)議分組的長度之和加一； 當所述傳輸控制協(xié)議代理裝置從所述傳輸控制協(xié)議層接收到的傳輸控制協(xié)議分組的 最大序號值加一，與，已被傳輸控制協(xié)議分組接收端連續(xù)確認的傳輸控制協(xié)議分組的最大 序號值的差，大于或等于所述傳輸控制協(xié)議分組接收端的通告窗口值時，所述純確認報文 中的窗口字段值設(shè)置為〇,以通知所述傳輸控制協(xié)議層暫停向所述傳輸控制協(xié)議代理裝置 發(fā)送傳輸控制協(xié)議分組；反之，所述純確認報文中的窗口字段值為所述傳輸控制協(xié)議分組 接收端的通告窗口值。
21. 根據(jù)權(quán)利要求20所述的裝置，其特征在于，所述傳輸控制協(xié)議代理裝置中設(shè)置有 捎帶確認報文計數(shù)器，用于對向所述傳輸控制協(xié)議層透傳所述傳輸控制協(xié)議分組接收端的 捎帶確認報文的次數(shù)計數(shù)； 所述裝置還包括： 捎帶確認報文處理模塊，用于在所述反饋模塊將所述確認報文反饋給向所述傳輸控 制協(xié)議代理裝置發(fā)送傳輸控制協(xié)議分組的傳輸控制協(xié)議層之后，接收到所述傳輸控制協(xié)議 分組接收端發(fā)送的捎帶確認報文；判斷緩存中是否存在待發(fā)送的傳輸控制協(xié)議分組；若存 在，且所述捎帶確認報文計數(shù)器的計數(shù)值為3時，則構(gòu)造純確認報文，將該純確認報文的確 認字段值設(shè)置為所述緩存中的當前連續(xù)已發(fā)或待發(fā)的傳輸控制協(xié)議分組的最大序號值加 一，向所述傳輸控制協(xié)議層發(fā)送該純確認報文并透傳所述捎帶確認報文，將所述捎帶確認 報文計數(shù)器置0 ;若不存在，則透傳所述捎帶確認報文，將所述捎帶確認報文計數(shù)器加1。
22. 根據(jù)權(quán)利要求21所述的裝置，其特征在于，所述裝置還包括： 報文判斷模塊，用于在所述反饋模塊針對發(fā)送給所述接入層的每個所述傳輸控制協(xié)議 分組構(gòu)造純確認報文之前，判斷是否已為當前傳輸控制協(xié)議分組構(gòu)造過純確認報文；若已 構(gòu)造過，則不再為當前傳輸控制協(xié)議分組構(gòu)造的純確認報文。
23. 根據(jù)權(quán)利要求17所述的裝置，其特征在于，所述接收模塊，用于接收所述接入層發(fā) 送的、攜帶了發(fā)送傳輸控制協(xié)議分組的可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度的信息的通知消息； 其中，所述可用數(shù)據(jù)傳輸資源的數(shù)據(jù)長度由所述接入層根據(jù)設(shè)定次數(shù)的發(fā)送傳輸控制 協(xié)議分組使用的資源均值和設(shè)定的放大系數(shù)確定。
24. 根據(jù)權(quán)利要求17所述的裝置，其特征在于，所述裝置還包括： 重復判斷模塊，用于在所述接收模塊接收本端的長期演進接入層發(fā)送的通知消息之 前，判斷所述傳輸控制協(xié)議層發(fā)送的傳輸控制協(xié)議分組的序號是否與所述傳輸控制協(xié)議代 理裝置已緩存的傳輸控制協(xié)議分組的序號重復；若重復，則丟棄該傳輸控制協(xié)議分組；若 不重復，則緩存該傳輸控制協(xié)議分組。
25. 根據(jù)權(quán)利要求17所述的裝置，其特征在于，所述裝置還包括： 第一確認報文處理模塊，用于在所述反饋模塊將所述確認報文反饋給向所述傳輸控制 協(xié)議代理裝置發(fā)送傳輸控制協(xié)議分組的傳輸控制協(xié)議層之后，接收傳輸控制協(xié)議分組接收 端反饋的確認報文；判斷當前接收到的所述反饋的確認報文中的確認字段值是否大于本端 當前記錄的、已被傳輸控制協(xié)議分組接收端連續(xù)確認的傳輸控制協(xié)議分組的最大序號值； 若是，則將本端當前記錄的已被傳輸控制協(xié)議分組接收端連續(xù)確認的傳輸控制協(xié)議分組的 最大序號值更新為當前收到的所述反饋的確認報文中的確認字段值，并將傳輸控制協(xié)議分 組的序號值小于更新后的所述最大序號值的所有傳輸控制協(xié)議分組刪除；若否，則將重傳 計數(shù)器加1，并且，當所述重傳計數(shù)器達到3時，確定發(fā)生確認報文冗余事件，根據(jù)所述反饋 的確認報文確定冗余類型，根據(jù)確定的所述冗余類型進行傳輸控制協(xié)議分組重傳，并在重 傳后將所述重傳計數(shù)器清0。
26. 根據(jù)權(quán)利要求25所述的裝置，其特征在于，所述第一確認報文處理模塊在根據(jù)所 述反饋的確認報文確定冗余類型，根據(jù)確定的所述冗余類型進行傳輸控制協(xié)議分組重傳 時： 確定所述反饋的確認報文為選擇性確認報文，且，所述選擇性確認報文指示所述傳輸 控制協(xié)議分組接收端接收的傳輸控制協(xié)議分組發(fā)生亂序或丟包，則將所述傳輸控制協(xié)議代 理裝置緩存的、已被所述傳輸控制協(xié)議分組接收端連續(xù)確認的傳輸控制協(xié)議分組的最大序 號值與所述傳輸控制協(xié)議層當前連續(xù)已發(fā)或待發(fā)的傳輸控制協(xié)議分組的最大序號值加一 之間的、除所述選擇性確認報文指示的已被所述傳輸控制協(xié)議分組接收端接收到的傳輸控 制協(xié)議分組之外的所有傳輸控制協(xié)議分組重傳給所述傳輸控制協(xié)議分組接收端； 或者， 確定所述反饋的確認報文為選擇性確認報文，且，所述選擇性確認報文指示所述傳輸 控制協(xié)議分組接收端接收的傳輸控制協(xié)議分組發(fā)生重復，則不做處理； 或者， 確定所述反饋的確認報文為確認報文，且，所述確認報文指示所述傳輸控制協(xié)議分組 接收端接收的傳輸控制協(xié)議分組發(fā)生丟包，則將所述傳輸控制協(xié)議代理緩存的、所述確認 報文中的確認字段值至所述傳輸控制協(xié)議層當前連續(xù)已發(fā)或待發(fā)的傳輸控制協(xié)議分組的 最大序號值加一之間的所有傳輸控制協(xié)議分組重傳給所述傳輸控制協(xié)議分組接收端。
27. 根據(jù)權(quán)利要求26所述的裝置，其特征在于，所述裝置還包括： 保守重傳模塊，用于在所述第一確認報文處理模塊確定發(fā)生確認報文冗余事件之后， 根據(jù)所述反饋的確認報文確定冗余類型，根據(jù)確定的所述冗余類型進行傳輸控制協(xié)議分組 重傳之前，判斷所述確認報文冗余事件是否是發(fā)生在已被傳輸控制協(xié)議分組接收端連續(xù)確 認的傳輸控制協(xié)議分組的最大序號值上的首次冗余事件； 若是首次冗余，則將所述傳輸控制協(xié)議代理裝置緩存的、已被所述傳輸控制協(xié)議分組 接收端連續(xù)確認的傳輸控制協(xié)議分組的最大序號值與所述傳輸控制協(xié)議層當前連續(xù)已發(fā) 或待發(fā)的傳輸控制協(xié)議分組的最大序號值加一之間的、除所述選擇性確認報文指示的已被 所述傳輸控制協(xié)議分組接收端接收到的傳輸控制協(xié)議分組之外的所有傳輸控制協(xié)議分組 重傳給所述傳輸控制協(xié)議分組接收端，或者，則將所述傳輸控制協(xié)議代理裝置緩存的、所 述確認報文中的確認字段值至所述傳輸控制協(xié)議層當前連續(xù)已發(fā)或待發(fā)的傳輸控制協(xié)議 分組的最大序號值加一之間的所有傳輸控制協(xié)議分組重傳給所述傳輸控制協(xié)議分組接收 端； 若不是首次冗余，則僅重傳所述已被傳輸控制協(xié)議分組接收端連續(xù)確認的傳輸控制協(xié) 議分組的最大序號值加一后對應(yīng)的傳輸控制協(xié)議分組。
28. 根據(jù)權(quán)利要求26所述的裝置，其特征在于，所述裝置還包括： 第二確認報文處理模塊，用于在所述第一確認報文處理模塊根據(jù)所述反饋的確認報文 確定冗余類型，根據(jù)確定的所述冗余類型進行傳輸控制協(xié)議分組重傳之后，判斷所述反饋 的確認報文的類型；若所述反饋的確認報文為純確認報文，則丟棄；若所述反饋的確認報 文為捎帶確認報文，則將所述捎帶確認報文透傳至所述傳輸控制協(xié)議層。
29. 根據(jù)權(quán)利要求17所述的裝置，其特征在于，所述裝置還包括： 第一連接維護模塊，用于確定接收到所述傳輸控制協(xié)議層的結(jié)束報文，則進入本地關(guān) 閉狀態(tài)，丟棄所述結(jié)束報文之后收到的所述傳輸控制協(xié)議層發(fā)送的傳輸控制協(xié)議分組，并 且，將緩存的所有剩余傳輸控制協(xié)議分組發(fā)送給傳輸控制協(xié)議分組接收端且被所述傳輸控 制協(xié)議分組接收端確認后，將所述結(jié)束報文發(fā)送給所述傳輸控制協(xié)議分組接收端； 或者， 用于確定接收到所述傳輸控制協(xié)議分組接收端發(fā)送的結(jié)束報文，則將所述結(jié)束報文透 傳給所述傳輸控制協(xié)議層。
30. 根據(jù)權(quán)利要求17所述的裝置，其特征在于，所述裝置還包括： 第二連接維護模塊，用于確定接收到復位報文，則立即清空所述傳輸控制協(xié)議代理裝 置緩存的所有傳輸控制協(xié)議分組，并將所述復位報文透傳給所述傳輸控制協(xié)議層。
31. 根據(jù)權(quán)利要求17所述的裝置，其特征在于，所述裝置還包括： 第三連接維護模塊，用于確定維護的對所述傳輸控制協(xié)議分組接收端連接進行監(jiān)控的 分鐘量級監(jiān)控定時器超時，則立即清空所述傳輸控制協(xié)議代理裝置緩存的所有傳輸控制協(xié) 議分組，并構(gòu)造復位報文透傳給所述傳輸控制協(xié)議層和所述傳輸控制協(xié)議分組接收端。
32.根據(jù)權(quán)利要求18或19所述的裝置，其特征在于，所述裝置還包括： 第四連接維護模塊，用于在所述反饋模塊針對發(fā)送給所述接入層的所述傳輸控制協(xié)議 分組構(gòu)造確認報文之后，確定接收到所述傳輸控制協(xié)議層發(fā)送的窗口探測報文；構(gòu)造純確 認報文回復所述傳輸控制協(xié)議層，并丟棄所述窗口探測報文，其中，構(gòu)造的純確認報文的確 認字段值為傳輸控制協(xié)議層當前連續(xù)已發(fā)或待發(fā)的傳輸控制協(xié)議分組的最大序號值加一， 窗口字段值為0。
【文檔編號】H04L29/08GK104093170SQ201410256949
【公開日】2014年10月8日 申請日期:2014年6月10日 優(yōu)先權(quán)日:2014年6月10日
【發(fā)明者】朱文博, 周光明, 蔣詩梅, 丁麗潔 申請人:北京創(chuàng)毅視訊科技有限公司