[發明專利]數據傳輸方法、接收裝置、發送裝置、介質、設備及系統

有效

• 申請號: 201910762460.0
• 申請日: 2019-08-19
• 公開（公告）號: CN112398797B
• 公開（公告）日: 2023-05-02
• 發明（設計）人: 盧暢
• 申請（專利權）人: 貴州白山云科技股份有限公司
• 主分類號: H04L9/40
• 分類號: H04L9/40;H04L67/5682
• 代理公司: 北京名華博信知識產權代理有限公司 11453
• 代理人: 李冬梅

本發明公開了一種數據傳輸方法、數據傳輸接收裝置、發送裝置、介質、設備及系統，數據傳輸方法應用于接收端，接收下發的多個數據包和與其一一對應的標記；在接收時長內的預定時刻，判斷接收到的多個所述標記經過排列后是否符合預定順序，若否，則存在所述數據包丟失。本發明中的數據傳輸方法、數據傳輸接收裝置、發送裝置、介質、設備及系統，能夠在數據更新過程中快速確定是否有數據丟失，以確保數據傳輸的完整性，提高數據傳輸成功率。

技術領域

本發明涉及互聯網技術領域，尤其涉及一種數據傳輸方法、數據傳輸接收裝置、發送裝置、介質、設備及系統。

背景技術

Content?Delivery?Network(簡稱CDN)，即內容分發網絡，將網站的內容發布到最接近用戶的網絡“邊緣”，使用戶可以就近取得所需要的內容，從而有效提高用戶訪問網站的響應速度，解決網絡擁塞問題。

當目標業務的提供者需要對業務服務器內的目標業務進行升級或變更時，業務服務器中存儲的目標業務需要進行更新。此時，需要對緩存有目標業務的CDN的全部節點服務器進行更新，以保證用戶終端通過CDN的節點服務器獲取到的目標業務的內容資源為更新后的內容資源。

在現有技術的傳統CDN緩存機制中，全網內容更新基于消息隊列的形式實現。當內容更新時，由一臺中心服務器管理上千臺節點服務器，中心服務器需要確認所有節點服務器的狀態并跟蹤節點服務器的推送情況，但由于比如中心服務器負載高、距離其它節點服務器距離遠、跨運營商等原因，造成通過節點服務器跟蹤失敗需要重傳的問題，導致系統無法一次實現內容在全網更新完成。

因此，現有技術中的傳統CDN緩存機制以及相應的解決方法存在如下缺陷：

1.中心服務器無法獲知推送內容是否成功；

2.目前通用的提高下發成功率的方法一般就是進行多次下發操作，以提高下發成功率，但是該方法效率低下，且占據帶寬資源；

3.通過對內容分發網絡中每個邊緣節點進行檢查，以確保內容下發成功，但該方法效率低下，特別是當邊緣節點多時，造成內容分發速度極慢；

4.當使用TCP進行傳輸時，建立鏈接需要進行三次握手，訪問數據需要持續的交互時間較長。

發明內容

為了解決上述技術問題，本發明提供了一種數據傳輸方法、數據傳輸接收裝置、發送裝置、介質、設備及系統。

本發明提供的數據傳輸方法，應用于接收端，包括：

接收下發的多個數據包和與其一一對應的標記；

在接收時長內的預定時刻，判斷接收到的多個所述標記經過排列后是否符合預定順序，若否，則存在所述數據包丟失。

上述數據傳輸方法還具有以下特點：所述數據傳輸方法包括：

在接收時長內進行n次檢測，所述預定時刻為從第二次檢測的結束時刻至第n次檢測的結束時刻之間的任意時刻。

上述數據傳輸方法還具有以下特點：所述數據傳輸方法進一步包括：

在接收時長內，進行連續的n次檢測，所述預定時刻為第二次檢測至第n次檢測中任意一次檢測的結束時刻。

上述數據傳輸方法還具有以下特點：所述數據傳輸方法進一步包括：

在接收時長內，進行連續的n次檢測，所述預定時刻為判斷周期的結束時刻；

所述判斷周期定義為：所述第二次檢測至第n-1次檢測中的任意一次檢測作為基礎周期，所述基礎周期的開始時刻減去期望時長的時刻為第一時刻，所述基礎周期的結束時刻加上期望時長的時刻為第二時刻，所述第一時刻與第二時刻之間為判斷周期，所述第二時刻為所述預定時刻；