[發明專利]TCP報文的調度方法、裝置及通信設備

有效

• 申請號: 201910943022.4
• 申請日: 2019-09-30
• 公開（公告）號: CN110855575B
• 公開（公告）日: 2022-05-06
• 發明（設計）人: 許虎;李兵
• 申請（專利權）人: 榮耀終端有限公司
• 主分類號: H04L47/00
• 分類號: H04L47/00;H04L9/40
• 代理公司: 北京匯思誠業知識產權代理有限公司 11444
• 代理人: 馮偉

本申請實施例提供一種TCP報文的調度方法、裝置及通信設備，該方法包括：多次統計一段時長內操作系統中GPU渲染指令數和每個線程傳輸的TCP報文數；根據多次統計結果，確定GPU渲染指令數和每個線程的TCP報文數的相關關系；根據相關關系，將每個線程分類為前臺關鍵線程或非前臺關鍵線程；配置第一類報文的傳輸速度高于第二類報文的傳輸速度，其中，第一類報文為前臺關鍵線程傳輸的報文，第二類報文為非前臺關鍵線程傳輸的報文。本申請通過操作系統中GPU渲染指令數和每個線程傳輸的TCP報文數的相關程度，找出前臺關鍵線程，進而對前臺關鍵線程發送的報文配置較高的傳輸速度，解決了相關技術中后臺TCP流量占用帶寬較多導致前臺TCP報文傳輸時間較長的技術問題。

技術領域

本申請涉及通信技術領域，特別涉及TCP報文的調度方法、裝置及通信設備。

背景技術

傳輸控制協議(Transmission Control Protocol，簡稱TCP)是一種面向連接的、可靠的、基于字節流的傳輸層通信協議。TCP是一種流協議(stream protocol)。這就意味著數據是以字節流的形式傳遞給接收者的，沒有固有的報文或報文邊界的概念。從這方面來說，讀取TCP數據就像從串行端口讀取數據一樣，無法預先得知在一次指定的讀調用中會返回多少字節(也就是說能知道全部總共要讀多少，但是不知道具體某一次讀多少)。為了避免網絡擁塞，相關技術提供了幾種TCP擁塞算法，如CUBIC算法和LEDBAT算法等。Cubic擁塞窗口增長曲線與反正切函數的曲線相似，凸曲線部分為穩定增長階段，凹曲線部分為最大帶寬探測階段。在剛開始時，擁塞窗口增長很快，在接近最大窗口時，增長速度變得平緩，避免流量突增而導致丟包。在最大窗口附近，擁塞窗口不再增加。之后開始緩慢地探測網絡最大吞吐量，保證穩定性(在最大窗口附近容易出現擁塞)，在遠離最大窗口后，增大窗口增長的速度，保證了帶寬的利用率。LEDBAT算法使用所有可用帶寬，在沒有其他流量時維持低排隊時延，限制因其他流量增加的排隊時延，是應快速讓位給其他共享同一有限鏈路的標準TCP。其中，基于Linux系統的Android系統默認采用CUBIC算法，所有的TCP流均采用相同的算法各自評估本端的時延和丟包情況，從而控制本端的發送速度，并且盡可能的保證各條流之間的公平性。發明人發現，相關技術中的TCP擁塞算法不能區別性的對用戶關心的前臺流量進行優先傳輸，在后臺流量較高的情況下，存在大量TCP丟包重傳的現象，導致前臺TCP傳輸時間較久。

發明內容

本申請提供了一種TCP報文的調度方法、裝置及通信設備，以解決相關技術中計算TCP報文傳輸速度的算法在后臺流量較高的情況下，前臺TCP傳輸時間較久的技術問題。

第一方面，本申請提供了一種TCP報文的調度方法，該方法包括：多次統計一段時長內操作系統中GPU渲染指令數和每個線程傳輸的TCP報文數；根據多次統計結果，確定GPU渲染指令數和每個線程的TCP報文數的相關關系；根據相關關系，將每個線程分類為前臺關鍵線程或非前臺關鍵線程；配置第一類報文的傳輸速度高于第二類報文的傳輸速度，其中，第一類報文為前臺關鍵線程傳輸的報文，第二類報文為非前臺關鍵線程傳輸的報文。通過本實施例提供的方案，通過操作系統中GPU渲染指令數和每個線程傳輸的TCP報文數的相關程度，找出前臺關鍵線程，進而對前臺關鍵線程發送的報文配置較高的傳輸速度，解決了相關技術中后臺TCP流量占用帶寬較多導致前臺TCP報文傳輸時間較長的技術問題。

在一種可能的設計中，多次統計一段時長內操作系統中GPU渲染指令數和每個線程傳輸的TCP報文數，包括：統計在一段時長內操作系統中新增的GPU渲染指令數；統計每個線程在一段時長內發起的TCP報文數。通過本實施例提供的方案，僅統計新增的指令和新增的TCP報文，可以減少不同次統計的結果的相互影響。

在一種可能的設計中，根據多次統計結果，確定GPU渲染指令數和每個線程的TCP報文數的相關關系，包括：針對每個線程，將操作系統的GPU渲染指令數和多次統計結果中對應線程的TCP報文數利用相關程度計算公式計算，得到GPU渲染指令數和每個線程的TCP報文數的相關關系，其中，相關程度計算公式為：