基于分塊校驗與確認的衛(wèi)星網絡tcp協(xié)議性能增強方法
【專利摘要】本發(fā)明公開了一種基于分塊校驗與確認的衛(wèi)星網絡TCP協(xié)議性能增強方法，涉及衛(wèi)星通信領域中TCP協(xié)議性能增強技術。它在兼容標準TCP協(xié)議流量控制、差錯控制、擁塞控制等基本機制的基礎上，基于“合并傳輸、分塊重傳”的思路，利用TCP協(xié)議的擴展選項，通過引入數據分塊校驗與分塊確認的新機制，在不明顯增加TCP協(xié)議開銷的前提下，提高了TCP協(xié)議在高誤碼環(huán)境中的傳輸性能。本發(fā)明公開的方法具有兼容標準TCP協(xié)議、抗誤碼能力強、校驗信息開銷低的優(yōu)點，特別適合利用TCP協(xié)議進行數據傳輸的衛(wèi)星通信系統(tǒng)使用。
【專利說明】基于分塊校驗與確認的衛(wèi)星網絡TCP協(xié)議性能增強方法

【技術領域】
[0001] 本發(fā)明公開一種基于分塊校驗與確認的衛(wèi)星網絡TCP協(xié)議性能增強方法，涉及衛(wèi) 星通信領域中的TCP協(xié)議性能增強技術，特別適合利用TCP協(xié)議進行數據傳輸的衛(wèi)星通信 系統(tǒng)使用。

【背景技術】
[0002] 隨著基于TCP/IP協(xié)議族的地面互聯(lián)網的蓬勃發(fā)展，作為地面網絡延伸和備份的 衛(wèi)星通信網絡正朝著全IP化的方向快速演進，TCP協(xié)議也繼在地面網絡獲得巨大成功之 后，正逐漸成為衛(wèi)星通信網絡承載數據業(yè)務的主要協(xié)議。
[0003] 但是，衛(wèi)星信道是一種較為特殊的無線信道，具有傳播時延長、信道誤碼高等固有 缺陷，針對地面有線網絡較為優(yōu)越的傳輸環(huán)境而設計的TCP協(xié)議應用于衛(wèi)星通信網絡時， 惡劣的信道環(huán)境使其吞吐率、帶寬利用率等性能都大打折扣。
[0004] 地面網絡的傳輸往返時延一般為幾個到幾十個毫秒，衛(wèi)星信道的傳播延時則大得 多，特別是在對地靜止軌道衛(wèi)星通信系統(tǒng)中，兩地面站點對點往返傳輸時延在500毫秒左 右。一方面，超長的時延使得TCP協(xié)議的慢啟動過程較為漫長，慢啟動狀態(tài)花費的時間越 長，文件的傳輸時間就越長，慢啟動階段在整個文件傳輸中的時間比例越高，信道的有效帶 寬利用率就越低；另一方面，超長的時延還會對標準TCP協(xié)議的最大吞吐量形成嚴重制約， TCP連接的最大吞吐量可由下式計算得出：
[0005] 最大吞吐量=最大發(fā)送窗口 /往返時延
[0006] 標準TCP協(xié)議的最大發(fā)送窗口為64K字節(jié)，依據上式計算，在往返時延約為500毫 秒的靜止軌道衛(wèi)星通信系統(tǒng)中，標準TCP協(xié)議的最大吞吐量不會超過1Mbps，也就是說，即 便可用的衛(wèi)星信道帶寬遠遠大于1Mbps，使用標準TCP協(xié)議進行數據傳輸的速率也不會超 過1Mbps，這顯然不能滿足當今高速數據傳輸的需求，并會對寶貴的衛(wèi)星信道帶寬資源造成 嚴重浪費。
[0007] 衛(wèi)星信道的高誤碼特性也會對TCP傳輸造成嚴重影響。在通常的靜止軌道衛(wèi)星 通信環(huán)境下，衛(wèi)星信道主要呈現(xiàn)高斯加性白噪聲特性，誤碼以隨機誤碼為主，誤碼率一般在 1(Γ 4-1(Γ6的范圍內。當天氣條件惡化時，信道的誤碼率還會更大。
[0008] 標準TCP協(xié)議假設所有的錯包和丟包都是由鏈路擁塞導致的，因此，當檢測到錯 包或丟包后，會大幅降低發(fā)送速率，以減輕鏈路擁塞，使鏈路盡快恢復正常狀態(tài)。標準TCP 協(xié)議的這種處理方式在地面鏈路中是合理的，因為地面鏈路是以光纖、同軸電纜為主的高 質量有線鏈路，誤碼率極低，造成錯包和丟包的主要原因是鏈路擁塞。
[0009] 但標準TCP協(xié)議的上述假設在衛(wèi)星通信網絡中是不成立的。由于衛(wèi)星鏈路的高誤 碼特性，衛(wèi)星通信網絡中的錯包和丟包主要都是由信道誤碼導致的，當檢測到錯包或丟包 并重傳相應數據包后，鏈路并沒有發(fā)生擁塞，可用帶寬也并沒有降低，發(fā)送端如果降低發(fā)送 速率，會直接導致信道帶寬利用率的降低，造成對寶貴衛(wèi)星信道帶寬資源的浪費。
[0010] 為了克服衛(wèi)星信道對TCP協(xié)議的不利影響，必須采用TCP協(xié)議性能增強技術。從實 現(xiàn)途徑上看，TCP協(xié)議性能增強技術主要分為兩種：其一，直接對用戶計算機終端中的TCP 協(xié)議棧進行優(yōu)化修改，以克服衛(wèi)星信道的缺點；其二，設計專門的TCP性能增強代理，采用 協(xié)議變換的方式將標準TCP協(xié)議在衛(wèi)星鏈路上轉換為經過優(yōu)化的TCP協(xié)議，從而實現(xiàn)對用 戶透明的TCP協(xié)議性能增強。由于采用TCP性能增強代理無需用戶對計算機終端做出任何 修改，保持了對用戶的透明性，因而絕大多數衛(wèi)星通信系統(tǒng)都采用第二種方式實現(xiàn)TCP協(xié) 議性能增強。
[0011] 無論采用哪種實現(xiàn)方式，要實現(xiàn)TCP協(xié)議性能增強，都需要在兼容標準TCP協(xié)議的 前提下，針對衛(wèi)星信道特點，設計用于空間段的優(yōu)化的TCP協(xié)議傳輸流程，以提高TCP協(xié)議 在衛(wèi)星信道環(huán)境下的傳輸性能。


【發(fā)明內容】

[0012] 本發(fā)明的目的在于針對高誤碼對TCP協(xié)議的不利影響，在兼容標準TCP協(xié)議的前 提下，基于"合并傳輸、分塊重傳"的思路，對TCP協(xié)議流程進行改進，提供一種基于分塊校 驗與確認的衛(wèi)星網絡TCP協(xié)議性能增強方法，以提高TCP協(xié)議在衛(wèi)星通信高誤碼環(huán)境中的 傳輸性能。
[0013] 本發(fā)明的目的是這樣實現(xiàn)的，基于分塊校驗與確認的衛(wèi)星網絡TCP協(xié)議性能增強 方法，其特征在于包括以下步驟：
[0014] (1)依據標準TCP協(xié)議的規(guī)定，數據的發(fā)送端與接收端之間通過三次握手建立TCP 連接；
[0015] (2)發(fā)送端按照設定的分塊長度計算出待發(fā)TCP數據包的分塊數，并對分塊依次 序編號；發(fā)送端基于待發(fā)TCP數據包及計算出的分塊數，生成帶分塊校驗選項的TCP數據 包，并向接收端發(fā)送該TCP數據包；
[0016] (3)接收端收到TCP數據包后，首先依據標準TCP協(xié)議的規(guī)定，提取TCP數據包包 頭中的2字節(jié)標準校驗和，并對整個TCP數據包進行校驗；
[0017] 如果接收端對整個TCP數據包的校驗通過，則接收端正常接收該TCP數據包，并依 據標準TCP協(xié)議，生成ACK確認包回送給發(fā)送端，之后，轉入步驟（7);
[0018] 如果接收端對整個數據包的校驗未通過，則接收端檢測該TCP數據包包頭選項區(qū) 中是否包含分塊校驗選項；如果檢測到分塊校驗選項，則執(zhí)行步驟（4);如果未檢測到分塊 校驗選項，則依據標準TCP協(xié)議的規(guī)定，丟棄該TCP數據包，并向發(fā)送端回送重復ACK確認 包，之后，轉入步驟（7);
[0019] (4)接收端從數據包分塊校驗選項中提取TCP數據包包頭校驗和字節(jié)，并對TCP數 據包包頭進行校驗；
[0020] 如果接收端對TCP數據包包頭校驗通過，則執(zhí)行步驟（5);
[0021] 如果接收端對TCP數據包包頭校驗未通過，則認為數據包徹底損壞，就丟棄該數 據包，并向發(fā)送端回送重復ACK確認包，之后，轉入步驟（7);
[0022] (5)接收端從數據包分塊校驗選項中提取選項長度，用選項長度減去3得到數據 包分塊數；進而從分塊校驗選項中提取各個分塊的校驗和，并對各個分塊分別進行校驗；
[0023] 對于校驗未通過的分塊，記錄其在本數據包內的編號；并對校驗通過的分塊進行 接收，對校驗未通過的分塊進行丟棄；
[0024] (6)接收端基于步驟（5)中計算的數據包分塊數和記錄的未通過校驗的分塊編 號，填寫分塊確認選項的選項編號、選項長度、待確認數據包的總分塊數和錯誤分塊標記， 并將分塊確認選項添加到重復ACK確認包包頭的選項區(qū)；而后，將該帶有分塊確認選項的 重復ACK確認包回送給發(fā)送端；
[0025] (7)發(fā)送端收到ACK確認包后，檢測ACK確認包包頭選項中是否帶有分塊確認選 項；
[0026] 如果帶有分塊確認選項，則發(fā)送端從分塊確認選項中提取接收端未成功接收的數 據分塊的編號，并以ACK確認包中的ACK確認號為起點，結合設定的分塊長度，找到這些分 塊的起始字節(jié)和結束字節(jié)，進而將這些分塊分別單獨組包重傳；
[0027] 如果沒有分塊確認選項，則發(fā)送端依據標準TCP協(xié)議對ACK確認包的處理規(guī)定，判 斷該ACK確認包是否是重復的；如果不是重復的，則正常傳輸后續(xù)數據包；如果是重復的， 則判斷重復次數是否達到3次，如果重復沒有達到3次，則繼續(xù)傳輸后續(xù)數據包，如果重復 達到3次，則發(fā)送端重傳重復ACK確認包指示需要重傳的數據包。
[0028] 其中，步驟（2)中所述的分塊校驗選項具體格式為：第1個字節(jié)為選項編號66 ;第 2個字節(jié)為選項長度，取值范圍為5至7,對應的數據包分塊數為2至4 ;第3個字節(jié)為TCP 數據包包頭的CRC-8校驗和；第4至7個字節(jié)為第1至4個分塊的CRC-8校驗和。
[0029] 其中，步驟（2)中所述的生成帶分塊校驗選項的TCP數據包的方法，包括步驟：
[0030] (101)發(fā)送端根據分塊數，分別計算各個分塊的CRC-8校驗和，而后填寫分塊校驗 選項的選項編號、選項長度以及各分塊校驗和字段，分塊校驗選項的TCP數據包包頭校驗 和字節(jié)填為0 ;
[0031] (102)發(fā)送端將上述TCP包頭校驗和字節(jié)填為0的分塊校驗選項添加到TCP包頭 選項區(qū)，并將TCP包頭的2字節(jié)標準校驗和填為0 ;而后，發(fā)送端對包括選項區(qū)在內的整個 TCP包頭計算CRC-8校驗和，并將該校驗和填入分塊校驗選項的TCP包頭校驗和字節(jié)；
[0032] (103)發(fā)送端依據標準TCP協(xié)議的規(guī)定，計算整個TCP數據包的2字節(jié)標準校驗 和，并將之填入TCP包頭中的規(guī)定位置。
[0033] 其中，步驟（5)中對校驗通過的分塊進行接收時，判斷其是否是亂序分塊：如果是 亂序分塊，則將該分塊放入接收緩沖區(qū)進行緩存；如果不是亂序分塊，則正常接收該分塊， 并向上層應用程序交付。
[0034] 其中，步驟（6)中所述的分塊確認選項具體格式為：第1個字節(jié)為選項編號67 ;第 2個字節(jié)為選項長度，取值為3 ;第3個字節(jié)的高3比特為被確認數據包的分塊數；第3個字 節(jié)的低4比特為被確認數據包錯誤分塊標記，低4比特從低位到高位，分別對應第1至4分 塊，如果分塊正確，則對應的比特為0,如果分塊錯誤，則對應的比特為1。
[0035] 其中，步驟（7)中發(fā)送端重傳未成功接收的分塊后，不減小發(fā)送窗口；發(fā)送端重傳 重復ACK確認包指示需要重傳的數據包后，依據標準TCP協(xié)議的規(guī)定減小發(fā)送窗口。
[0036] 本發(fā)明具有以下優(yōu)點：
[0037] 1.本發(fā)明通過引入分塊校驗與分塊確認的新機制，提高了 TCP協(xié)議在衛(wèi)星通信高 誤碼環(huán)境中的傳輸性能。
[0038] 2.本發(fā)明不改變標準TCP協(xié)議流量控制、差錯控制、擁塞控制等基本機制，完全兼 容標準TCP協(xié)議。
[0039] 3.本發(fā)明在提高TCP協(xié)議抗誤碼性能的同時，引入的校驗信息開銷較低。

【專利附圖】

【附圖說明】
[0040] 圖1是本發(fā)明的應用環(huán)境示意圖。
[0041] 圖2是本發(fā)明的分塊校驗選項格式圖。
[0042] 圖3是本發(fā)明的分塊確認選項格式圖。
[0043] 圖4是本發(fā)明的發(fā)送端數據包發(fā)送處理流程圖。
[0044] 圖5是本發(fā)明的接收端數據包接收處理流程圖。
[0045] 圖6是本發(fā)明的發(fā)送端對ACK確認包的處理流程圖。
[0046] 圖7是本發(fā)明的優(yōu)選實施例通信流程圖。

【具體實施方式】
[0047] 以下結合附圖1、2、3、4、5、6、7對本發(fā)明的優(yōu)選實施例進行說明，應當理解，此處 所描述的優(yōu)選實施例僅用于說明和解釋本發(fā)明，并不用于限定本發(fā)明。
[0048] 圖1示出了本發(fā)明的應用環(huán)境：衛(wèi)星通信站基于TCP性能增強代理，采用將地面段 的標準TCP協(xié)議在空間段轉換為基于本發(fā)明所述分塊校驗與確認機制的優(yōu)化TCP協(xié)議的方 式，實現(xiàn)對用戶透明的TCP協(xié)議性能增強。
[0049] 圖2是本發(fā)明的分塊校驗選項格式圖。其中，第1個字節(jié)為選項編號66;第2個 字節(jié)為選項長度，取值范圍為5至7 ;第3個字節(jié)為TCP數據包包頭的CRC-8校驗和；第4 至7個字節(jié)為第1至4個分塊的CRC-8校驗和。依據數據包分塊數的不同，分塊校驗選項 長度可能為5至7個字節(jié)，對應的分塊數為2至4塊。
[0050] 圖3是本發(fā)明的分塊確認選項格式圖。其中，第1個字節(jié)為選項編號67;第2個 字節(jié)為選項長度，取值為3 ;第3個字節(jié)的高3比特為被確認數據包的分塊數；第3個字節(jié) 的低4比特為被確認數據包錯誤分塊標記，低4比特從低位到高位，分別對應第1至4分 塊；如果分塊正確，則對應的比特為0,如果分塊錯誤，則對應的比特為1，例如，如果被確認 數據包的第2個分塊錯誤，則分塊確認選項第3字節(jié)低4比特應為0010。
[0051] 圖4是本發(fā)明的發(fā)送端數據包發(fā)送處理流程圖。該流程圖描述了發(fā)送端計算分塊 數、生成分塊校驗選項、發(fā)送數據包的大致流程。
[0052] 圖5是本發(fā)明的接收端數據包接收處理流程圖。該流程圖描述了接收端對數據包 各種錯誤情況的處理流程。
[0053] 圖6是本發(fā)明的發(fā)送端對ACK確認包的處理流程圖。該流程圖描述了發(fā)送端發(fā)送 數據后，收到接收端回送的ACK確認包時的各種處理流程。
[0054] 圖7是本發(fā)明的優(yōu)選實施例通信流程圖。該圖描述了本發(fā)明的一個優(yōu)選實施例， 通過對該實施例的分析，可以說明本發(fā)明具有提高TCP抗誤碼能力、兼容標準TCP協(xié)議、校 驗信息開銷低的優(yōu)點。
[0055] 下面，結合圖7所示優(yōu)選實施例中設置的幾種典型情況，對本發(fā)明進行詳細說明。 在本優(yōu)選實施例中，假定發(fā)送端發(fā)送的每個包的數據長度都為1200字節(jié)，并設定分塊長度 為400字節(jié)。基于分塊校驗與確認的衛(wèi)星網絡TCP協(xié)議性能增強方法，說明如下：
[0056] 情況1 :正常傳輸。
[0057] 1. 1數據的發(fā)送端與接收端之間通過三次握手建立TCP連接；
[0058] 1.2發(fā)送端連續(xù)發(fā)送2個數據長度為1200字節(jié)的數據包，2個數據包中的字節(jié)序 號分別為〇?1199和1200?2399,按照設定的分塊長度400,每個待發(fā)TCP數據包的分塊 數為3,每包內分塊的編號依次為1、2、3 ;
[0059] 發(fā)送端基于待發(fā)TCP數據包及計算出的分塊數3,生成帶分塊校驗選項的TCP數據 包，并向接收端發(fā)送這2個包；
[0060] 1. 3假設這2個數據包在傳輸過程中均無損壞，都正確到達接收端；
[0061] 1. 4接收端接收到這2個數據包后，首先按照標準TCP協(xié)議的規(guī)定，提取TCP包頭 中的2字節(jié)標準校驗和對整個數據包進行校驗，由于2個數據包在傳輸過程中沒有發(fā)生任 何損壞，所以校驗成功，接收端回送確認號分別為1200和2400的不包含分塊確認選項的 ACK確認包。
[0062] 情況2 :數據包嚴重損壞。
[0063] 2. 1接上，發(fā)送端繼續(xù)發(fā)送1個數據長度為1200字節(jié)的數據包，該數據包中的字節(jié) 序號為2400?3599,按照設定的分塊長度400,該待發(fā)TCP數據包的分塊數為3,包內分塊 的編號依次為1、2、3 ;
[0064] 發(fā)送端基于待發(fā)TCP數據包及計算出的分塊數3,生成帶分塊校驗選項的TCP數據 包，并向接收端發(fā)送該包；
[0065] 2. 2假設該數據包在傳輸過程中受誤碼影響發(fā)生嚴重損壞；
[0066] 2. 3接收端接收到該數據包后，首先按照標準TCP協(xié)議的規(guī)定，提取TCP包頭中的 2字節(jié)標準校驗和對整個數據包進行校驗，由于該數據包在傳輸過程中發(fā)生了錯誤，對整個 數據包進行的標準校驗未通過；
[0067] 而后，接收端檢測到該TCP數據包包頭選項區(qū)中包含分塊校驗選項，就從分塊校 驗選項中提取TCP包頭校驗和字節(jié)，并對TCP包頭進行校驗；
[0068] 在本優(yōu)選實施例中，接收端對該數據包的TCP包頭校驗未通過，這不但說明數據 包損壞較為嚴重，而且由于分塊校驗選項本身的正確性已無法保證，分塊校驗也就無需進 行了，所以丟棄該數據包，并向發(fā)送端回送確認號仍為2400的重復ACK確認包；
[0069] 2. 4發(fā)送端收到確認號仍為2400的重復ACK確認包后，檢測到該ACK確認包不帶 有分塊確認選項，并且雖然是重復ACK確認包，但重復次數還沒有達到3次，因此依據標準 TCP協(xié)議的規(guī)定，繼續(xù)傳輸字節(jié)序號為3600?4799的后續(xù)數據包；
[0070] 2. 5字節(jié)序號為3600?4799的數據包在傳輸過程中無損壞，正確到達接收端；
[0071] 2. 6接收端收到字節(jié)序號為3600?4799的數據包后，首先按照標準TCP協(xié)議的 規(guī)定，提取TCP包頭中的2字節(jié)標準校驗和對整個數據包進行校驗；由于該數據包在傳輸過 程中無損壞，所以校驗通過；因為此時接收端還未正確收到字節(jié)序號為2400?3599的數 據包，所以接收端將該字節(jié)序號為3600?4799的數據包放入接收緩沖區(qū)緩存，并依據標準 TCP協(xié)議，生成確認號仍為2400的重復ACK確認包回送給發(fā)送端；
[0072] 2. 7發(fā)送端收到確認號仍為2400的重復ACK確認包后，檢測到該ACK確認包不帶 有分塊確認選項，并且是重復ACK確認包，重復次數已經達到3次，因此，發(fā)送端重傳字節(jié)序 號為2400?3599的數據包；并且，由于重復ACK次數已經達到3次，依據標準TCP協(xié)議的 規(guī)定，發(fā)送端減小發(fā)送窗口，以降低發(fā)送速率；
[0073] 2. 8該重傳的字節(jié)序號為2400?3599的數據包在傳輸過程中無損壞，正確到達接 收端；
[0074] 2. 9接收端收到字節(jié)序號為2400?3599的數據包后，首先按照標準TCP協(xié)議的規(guī) 定，提取TCP包頭中的2字節(jié)標準校驗和對整個數據包進行校驗；由于該數據包在傳輸過程 中無損壞，所以校驗通過；而后，接收端依據該重傳數據包的字節(jié)序號（2400?3599)，將之 放入接收緩沖區(qū)的對應位置，此時，字節(jié)2400?4799已全部正確接收，于是接收端將緩沖 區(qū)中的字節(jié)2400?4799向上交付給應用程序，并依據標準TCP協(xié)議，生成確認號為4800 的ACK確認包回送給發(fā)送端。
[0075] 情況3 :數據包中的一個分塊發(fā)生損壞。
[0076] 3. 1接上，發(fā)送端繼續(xù)發(fā)送1個數據長度為1200字節(jié)的數據包，該數據包中的字節(jié) 序號為4800?5999,按照設定的分塊長度400,該待發(fā)TCP數據包的分塊數為3,包內分塊 的編號依次為1、2、3 ;
[0077] 發(fā)送端基于待發(fā)TCP數據包及計算出的分塊數3，生成帶分塊校驗選項的TCP數據 包，并向接收端發(fā)送該包；
[0078] 3. 2假設該數據包在傳輸過程中受誤碼影響發(fā)生損壞；
[0079] 3. 3接收端接收到該數據包后，首先按照標準TCP協(xié)議的規(guī)定，提取TCP包頭中的 2字節(jié)標準校驗和對整個數據包進行校驗，由于該數據包在傳輸過程中發(fā)生了損壞，整個數 據包的校驗未通過；
[0080] 而后，接收端檢測到該TCP數據包頭選項中包含分塊校驗選項，就從分塊校驗選 項中提取TCP包頭校驗和字節(jié)，并對TCP包頭進行校驗；
[0081] 在本優(yōu)選實施例中，接收端對該字節(jié)序號為4800?5999數據包的TCP包頭校驗 通過，這說明分塊校驗選項本身的正確性可以保證，可以進行分塊校驗；
[0082] 3. 4接收端從該數據包的分塊校驗選項中提取選項長度6,用選項長度6減去3得 到數據包分塊數為3 ;進而從分塊校驗選項中提取3個分塊的校驗和，并對3個分塊分別進 行校驗；在本優(yōu)選實施例中，該數據包的分塊1、3校驗通過，分塊2校驗未通過；
[0083] 由于分塊1校驗通過且不是亂序分塊，所以接收端正常接收該分塊，并向上層應 用程序交付；由于分塊3校驗通過且是亂序分塊，所以接收端將分塊3放入接收緩沖區(qū)進行 緩存；由于分塊2校驗未通過，所以接收端記錄分塊2在本數據包內的編號2,然后丟棄分 塊2 ;
[0084] 3. 5接收端按照上述校驗結果，填寫分塊確認選項的內容，其中，待確認數據包總 分塊數填為3,并標記分塊2為錯誤分塊，之后將該分塊確認選項添加到確認號為4800的 ACK確認包頭選項區(qū)；而后，接收端將該帶有分塊確認選項的ACK確認包回送給發(fā)送端；
[0085] 3. 6發(fā)送端收到上述確認號為4800的帶分塊確認選項的ACK確認包后，從分塊確 認選項中提取接收端未成功接收的數據分塊編號2,并將以4800字節(jié)為起始的數據包的第 2分塊（字節(jié)序號5200?5599)單獨組包重傳，由于分塊2的長度一定小于等于400字節(jié)， 所以該重傳包不用再進行分塊，包頭選項中也不包含分塊校驗選項；重傳該分塊后，發(fā)送端 不減小發(fā)送窗口，從而保持發(fā)送速率不降低；
[0086] 3. 7該重傳的字節(jié)序號為5200?5599的分塊在傳輸過程中無損壞，正確到達接收 端；
[0087] 3. 8接收端收到字節(jié)序號為5200?5599的重傳分塊后，按照標準TCP協(xié)議的規(guī) 定，提取TCP包頭中的2字節(jié)標準校驗和對之進行校驗；由于該重傳分塊在傳輸過程中無損 壞，所以校驗通過；而后，接收端依據該重傳分塊的字節(jié)序號（5200?5599)，將之放入接收 緩沖區(qū)的對應位置，此時，字節(jié)5200?5999已全部正確接收，于是接收端將緩沖區(qū)中的字 節(jié)5200?5999向上交付給應用程序，并依據標準TCP協(xié)議，生成確認號為6000的ACK確 認包回送給發(fā)送端。
[0088] 通過該優(yōu)選實施例可以看出，本發(fā)明基于TCP擴展選項實現(xiàn)，完全兼容標準TCP協(xié) 議。并且，與標準TCP協(xié)議相比，本發(fā)明只在較大的數據包中引入了長度為5?7字節(jié)的分 塊校驗選項，只在發(fā)生傳輸錯誤時在確認包中引入了長度僅有3字節(jié)的分塊確認選項，增 加的額外開銷較少。
[0089] 本發(fā)明對TCP協(xié)議在高誤碼環(huán)境中傳輸性能的提高，主要體現(xiàn)在以下兩方面： [0090] 第一，本發(fā)明基于"合并傳輸、分塊重傳"的思路，通過分塊計算校驗和以及分塊進 行確認的方法，使得在數據傳輸出錯時，只需重傳出錯的分塊，而不必重傳整個數據包。這 樣，每個重傳包的長度會大為減小，整個傳輸過程中重傳的數據總量也會大為減少。
[0091] 在相同誤碼率的環(huán)境下，重傳包長度越小，重傳的成功率就越高。例如，在誤碼率 為1〇_4的高誤碼環(huán)境下，平均每傳輸1250個字節(jié)就會出現(xiàn)1比特錯誤，此時如果重傳長度 為1250字節(jié)的數據包，那么，此種長度數據包的每次傳輸都會出錯，重傳成功概率為0 ;但 如果重傳的是長度為400字節(jié)的分塊，那么，重傳成功概率則會超過2/3。因此，重傳包長度 的大幅減小可以提升高誤碼條件下的傳輸性能。
[0092] 另外，整個傳輸過程中重傳數據總量的減少會減輕重傳數據對信道的占用，從而 為正常的數據傳輸留出更多的帶寬資源，提高信道的利用效率。
[0093] 第二，本發(fā)明中，發(fā)送端在重傳由分塊確認選項通告的校驗錯誤分塊后，不減小發(fā) 送窗口；在重傳重復ACK確認包指示需要重傳的數據包后，依據標準TCP協(xié)議的規(guī)定減小 發(fā)送窗口。實質上，這是利用分塊確認選項通知發(fā)送端傳輸錯誤是由誤碼而非擁塞造成的。 通過這種較為簡單的方式，可以在一定程度上將誤碼和擁塞區(qū)分開來，并在判定傳輸錯誤 是由誤碼造成的情況下，保持發(fā)送速率不降低，從而提高了高誤碼條件下TCP傳輸的信道 帶寬利用率。
[0094] 這種方法雖然并不能百分之百地保證區(qū)分誤碼與擁塞的正確性，但在概率的意義 上，該方法是合理的。因為，對于可分塊的TCP數據包來說，數據部分占整個包長的比例是 很大的，而包頭部分占整個包長的比例則較小。這樣，在均勻誤碼的條件下，如果由于誤碼 發(fā)生了比特錯誤，那么，錯誤發(fā)生在數據部分的概率很高，錯誤發(fā)生在包頭部分的概率很 低，也就是說，包頭部分不大可能因誤碼而被破壞。因此，在概率意義上，可以大致認為，只 有數據部分損壞而包頭部分完好的包錯誤一般都是由誤碼引起的。在本發(fā)明中，接收端正 好只有在包頭校驗成功而數據部分出錯的情況下，才會向發(fā)送端回送帶分塊確認選項的 ACK確認包，因此，發(fā)送端接收到帶分塊確認選項的ACK確認包后，可以認為傳輸錯誤是由 誤碼而非擁塞造成的，進而保持發(fā)送速率不降低，以提高信道利用率。
[0095] 綜上可見，本發(fā)明公開的方法具有兼容標準TCP協(xié)議、抗誤碼能力強、校驗信息開 銷低的優(yōu)點。
【權利要求】
1. 基于分塊校驗與確認的衛(wèi)星網絡TCP協(xié)議性能增強方法，其特征在于包括以下步 驟： (1) 依據標準TCP協(xié)議的規(guī)定，數據的發(fā)送端與接收端之間通過三次握手建立TCP連 接； (2) 發(fā)送端按照設定的分塊長度計算出待發(fā)TCP數據包的分塊數，并對分塊依次序編 號；發(fā)送端基于待發(fā)TCP數據包及計算出的分塊數，生成帶分塊校驗選項的TCP數據包，并 向接收端發(fā)送該TCP數據包； (3) 接收端收到TCP數據包后，首先依據標準TCP協(xié)議的規(guī)定，提取TCP數據包包頭中 的2字節(jié)標準校驗和，并對整個TCP數據包進行校驗； 如果接收端對整個TCP數據包的校驗通過，則接收端正常接收該TCP數據包，并依據標 準TCP協(xié)議，生成ACK確認包回送給發(fā)送端，之后，轉入步驟（7); 如果接收端對整個數據包的校驗未通過，則接收端檢測該TCP數據包包頭選項區(qū)中是 否包含分塊校驗選項；如果檢測到分塊校驗選項，則執(zhí)行步驟（4);如果未檢測到分塊校驗 選項，則依據標準TCP協(xié)議的規(guī)定，丟棄該TCP數據包，并向發(fā)送端回送重復ACK確認包，之 后，轉入步驟（7); (4) 接收端從數據包分塊校驗選項中提取TCP數據包包頭校驗和字節(jié)，并對TCP數據包 包頭進行校驗； 如果接收端對TCP數據包包頭校驗通過，則執(zhí)行步驟（5); 如果接收端對TCP數據包包頭校驗未通過，則認為數據包徹底損壞，就丟棄該數據包， 并向發(fā)送端回送重復ACK確認包，之后，轉入步驟（7); (5) 接收端從數據包分塊校驗選項中提取選項長度，用選項長度減去3得到數據包分 塊數；進而從分塊校驗選項中提取各個分塊的校驗和，并對各個分塊分別進行校驗； 對于校驗未通過的分塊，記錄其在本數據包內的編號；并對校驗通過的分塊進行接收， 對校驗未通過的分塊進行丟棄； (6) 接收端基于步驟（5)中計算的數據包分塊數和記錄的未通過校驗的分塊編號，填 寫分塊確認選項的選項編號、選項長度、待確認數據包的總分塊數和錯誤分塊標記，并將分 塊確認選項添加到重復ACK確認包包頭的選項區(qū)；而后，將該帶有分塊確認選項的重復ACK 確認包回送給發(fā)送端； (7) 發(fā)送端收到ACK確認包后，檢測ACK確認包包頭選項中是否帶有分塊確認選項； 如果帶有分塊確認選項，則發(fā)送端從分塊確認選項中提取接收端未成功接收的數據分 塊的編號，并以ACK確認包中的ACK確認號為起點，結合設定的分塊長度，找到這些分塊的 起始字節(jié)和結束字節(jié)，進而將這些分塊分別單獨組包重傳； 如果沒有分塊確認選項，則發(fā)送端依據標準TCP協(xié)議對ACK確認包的處理規(guī)定，判斷該 ACK確認包是否是重復的；如果不是重復的，則正常傳輸后續(xù)數據包；如果是重復的，則判 斷重復次數是否達到3次，如果重復沒有達到3次，則繼續(xù)傳輸后續(xù)數據包，如果重復達到 3次，則發(fā)送端重傳重復ACK確認包指示需要重傳的數據包。
2. 根據權利要求1所述的基于分塊校驗與確認的衛(wèi)星網絡TCP協(xié)議性能增強方法，其 特征在于：步驟（2)中所述的分塊校驗選項具體格式為：第1個字節(jié)為選項編號66 ;第2個 字節(jié)為選項長度，取值范圍為5至7,對應的數據包分塊數為2至4 ;第3個字節(jié)為TCP數據 包包頭的CRC-8校驗和；第4至7個字節(jié)為第1至4個分塊的CRC-8校驗和。
3. 根據權利要求1所述的基于分塊校驗與確認的衛(wèi)星網絡TCP協(xié)議性能增強方法，其 特征在于：步驟（2)中所述的生成帶分塊校驗選項的TCP數據包的方法，包括步驟： (101) 發(fā)送端根據分塊數，分別計算各個分塊的CRC-8校驗和，而后填寫分塊校驗選項 的選項編號、選項長度以及各分塊校驗和字段，分塊校驗選項的TCP數據包包頭校驗和字 節(jié)填為〇 ; (102) 發(fā)送端將上述TCP包頭校驗和字節(jié)填為0的分塊校驗選項添加到TCP包頭選項 區(qū)，并將TCP包頭的2字節(jié)標準校驗和填為0 ;而后，發(fā)送端對包括選項區(qū)在內的整個TCP包 頭計算CRC-8校驗和，并將該校驗和填入分塊校驗選項的TCP包頭校驗和字節(jié)； (103) 發(fā)送端依據標準TCP協(xié)議的規(guī)定，計算整個TCP數據包的2字節(jié)標準校驗和，并 將之填入TCP包頭中的規(guī)定位置。
4. 根據權利要求1所述的基于分塊校驗與確認的衛(wèi)星網絡TCP協(xié)議性能增強方法，其 特征在于：步驟（5)中對校驗通過的分塊進行接收時，判斷其是否是亂序分塊：如果是亂序 分塊，則將該分塊放入接收緩沖區(qū)進行緩存；如果不是亂序分塊，則正常接收該分塊，并向 上層應用程序交付。
5. 根據權利要求1所述的基于分塊校驗與確認的衛(wèi)星網絡TCP協(xié)議性能增強方法，其 特征在于：步驟（6)中所述的分塊確認選項具體格式為：第1個字節(jié)為選項編號67 ;第2個 字節(jié)為選項長度，取值為3 ;第3個字節(jié)的高3比特為被確認數據包的分塊數；第3個字節(jié)的 低4比特為被確認數據包錯誤分塊標記，低4比特從低位到高位，分別對應第1至4分塊， 如果分塊正確，則對應的比特為〇,如果分塊錯誤，則對應的比特為1。
6. 根據權利要求1所述的基于分塊校驗與確認的衛(wèi)星網絡TCP協(xié)議性能增強方法，其 特征在于：步驟（7)中發(fā)送端重傳未成功接收的分塊后，不減小發(fā)送窗口；發(fā)送端重傳重復 ACK確認包指示需要重傳的數據包后，依據標準TCP協(xié)議的規(guī)定減小發(fā)送窗口。
【文檔編號】H04L29/06GK104092707SQ201410373029
【公開日】2014年10月8日 申請日期:2014年7月31日 優(yōu)先權日:2014年7月31日
【發(fā)明者】彭華, 張亞生 申請人:中國電子科技集團公司第五十四研究所