一種差異化可靠傳輸控制機(jī)制

殷明，任勇毛，張運(yùn)棟，周旭＊，徐安民，于德雷

1.中國科學(xué)院計(jì)算機(jī)網(wǎng)絡(luò)信息中心，北京 100083

2.中國科學(xué)院大學(xué)，北京 100049

3.華為技術(shù)有限公司，北京 100085

引言

隨著互聯(lián)網(wǎng)技術(shù)的飛速發(fā)展，為了滿足用戶多樣化的服務(wù)需求，互聯(lián)網(wǎng)也隨之涌現(xiàn)出許多新型應(yīng)用。與過去的僅需完全可靠和有序的數(shù)據(jù)傳輸?shù)膽?yīng)用不同，現(xiàn)有的互聯(lián)網(wǎng)應(yīng)用對網(wǎng)絡(luò)提出了更多、更復(fù)雜的服務(wù)要求。不同類型的網(wǎng)絡(luò)應(yīng)用對于數(shù)據(jù)傳輸?shù)目煽啃砸蠖疾槐M相同。許多應(yīng)用對數(shù)據(jù)可靠度的需求是有彈性的，是能容忍一定程度的數(shù)據(jù)丟失率的。這類應(yīng)用對可靠性的要求不一定需要100%，一定程度的數(shù)據(jù)丟失不一定會(huì)對應(yīng)用提供的服務(wù)質(zhì)量產(chǎn)生太大影響。比如，對于一些多媒體應(yīng)用數(shù)據(jù)傳輸，1%～2%的視頻信息丟失并不會(huì)對視頻的觀看體驗(yàn)產(chǎn)生太大影響[1-2]；對于科研數(shù)據(jù)傳輸，許多科學(xué)觀測實(shí)驗(yàn)數(shù)據(jù)的傳輸能容忍約2%的丟包率，小部分的數(shù)據(jù)丟失可以通過數(shù)值擬合等方法補(bǔ)償或恢復(fù)[3]。許多具有較軟實(shí)時(shí)約束的應(yīng)用對數(shù)據(jù)傳輸可靠性的要求是靈活的，這類應(yīng)用可以以容忍一定程度的丟包率為代價(jià)，來保證良好的用戶體驗(yàn)。

互聯(lián)網(wǎng)本身提供的是一種盡力而為的服務(wù)，它不能保證數(shù)據(jù)傳輸?shù)目煽啃浴Ｋ鼤?huì)盡可能將數(shù)據(jù)傳送到目的地，但它不能保證每一個(gè)數(shù)據(jù)分組都能及時(shí)可靠地到達(dá)目的地。因此上層應(yīng)用需要傳輸層的傳輸協(xié)議提供能保證可靠性的傳輸服務(wù)。

目前互聯(lián)網(wǎng)使用的傳輸協(xié)議大都繼續(xù)沿用傳統(tǒng)的傳輸協(xié)議。這些協(xié)議在當(dāng)初設(shè)計(jì)時(shí)未考慮到新型應(yīng)用出現(xiàn)的情況，不能完全滿足這些新型應(yīng)用的傳輸需求，不能達(dá)到理想的傳輸效果。

目前主流傳輸協(xié)議是傳輸控制協(xié)議(Transmission Control Protocol,TCP)[4]和用戶數(shù)據(jù)報(bào)協(xié)議(User Datagram Protocol,UDP)[5]。TCP 協(xié)議提供完全可靠的傳輸服務(wù)，能保證數(shù)據(jù)的完整性。TCP 是通過重傳機(jī)制來保證數(shù)據(jù)的可靠性，這種可靠度保證是以傳輸延遲增加和吞吐率降低為代價(jià)的。另一方面，UDP 雖然可以保證高吞吐量且不會(huì)產(chǎn)生額外的延遲，但是缺乏可靠性保證。此外，UDP 既不提供數(shù)據(jù)排序，也不提供流量控制或擁塞控制，這些機(jī)制都需要上層應(yīng)用自身來實(shí)現(xiàn)，增加上層應(yīng)用的復(fù)雜度。目前互聯(lián)網(wǎng)廣泛使用的兩個(gè)通用傳輸協(xié)議TCP 與UDP 所提供的服務(wù)現(xiàn)在都不能完全滿足新型應(yīng)用差異化的可靠度需求。現(xiàn)在的新型應(yīng)用（比如新型的多媒體應(yīng)用）所需要的是一種兼?zhèn)銽CP 與UDP 所提供的服務(wù)特性的網(wǎng)絡(luò)服務(wù)，既能滿足應(yīng)用的確定性可靠度需求，也能保證數(shù)據(jù)傳輸?shù)母咝浴?/p>

本文針對以上問題提出了一種新的傳輸協(xié)議-差異化可靠傳輸控制協(xié)議(Differentiated Reliable Transmission Protocol,DRTP)，它提供了一種既能滿足軟實(shí)時(shí)要求，也能保證確定性可靠度的傳輸服務(wù)。DRTP 是一種基于發(fā)送端的部分可靠傳輸協(xié)議，是一種通用傳輸層協(xié)議。DRTP 協(xié)議能夠在現(xiàn)有的互聯(lián)網(wǎng)基礎(chǔ)設(shè)施內(nèi)工作，也能配合使用現(xiàn)有的擁塞控制算法。差異化可靠傳輸協(xié)議一般更適用于在那些允許部分?jǐn)?shù)據(jù)缺失，且不會(huì)對終端用戶的體驗(yàn)造成太大的影響的業(yè)務(wù)，比如實(shí)時(shí)語音業(yè)務(wù)和在線視頻業(yè)務(wù)等。

本文重點(diǎn)介紹DRTP 協(xié)議的重傳控制機(jī)制，主要避免了超時(shí)觸發(fā)，減少在當(dāng)前傳輸可靠度滿足應(yīng)用可靠度需求時(shí)的不必要的數(shù)據(jù)重傳次數(shù)，進(jìn)而提高傳輸效率。我們基于NS-3[6]網(wǎng)絡(luò)模擬器對DRTP協(xié)議進(jìn)行了實(shí)現(xiàn)，并在不同網(wǎng)絡(luò)條件下開展了實(shí)驗(yàn)性能評價(jià)。實(shí)驗(yàn)結(jié)果表明，與TCP 相比，在存在一定丟包率的網(wǎng)絡(luò)鏈路上，DRTP 在保證應(yīng)用需要的可靠度要求的同時(shí)，可顯著提升傳輸吞吐率。本文也在Linux 系統(tǒng)上完成機(jī)制的實(shí)現(xiàn)，并進(jìn)行系統(tǒng)測試，驗(yàn)證該機(jī)制的可行性。

本文的其余部分組織如下：第一節(jié)討論了相關(guān)工作；第二節(jié)重點(diǎn)介紹DRTP 控制機(jī)制的設(shè)計(jì)，包括DRTP協(xié)議框架、可靠度計(jì)算以及重傳控制機(jī)制等；然后，第三節(jié)對DRTP 的性能進(jìn)行了實(shí)驗(yàn)評價(jià)；最后，第四節(jié)對全文進(jìn)行總結(jié)并指出了下一步研究方向。

1 相關(guān)工作

不同應(yīng)用場景對于傳輸數(shù)據(jù)的可靠度需求也不盡相同，針對網(wǎng)絡(luò)應(yīng)用對傳輸性能的差異化需求，在滿足應(yīng)用可靠度需求的前提下提高傳輸速率，是傳輸協(xié)議設(shè)計(jì)的一個(gè)重要研究課題[7]。為滿足應(yīng)用差異化傳輸需求，目前的解決方案主要通過部分可靠傳輸協(xié)議實(shí)現(xiàn)。部分可靠傳輸協(xié)議允許應(yīng)用程序可以通過犧牲部分傳輸數(shù)據(jù)可靠性以提升網(wǎng)絡(luò)傳輸速率，降低延遲抖動(dòng)[8]。

目前對于這一方向的研究尚很缺乏，已有的研究主要為特定應(yīng)用設(shè)計(jì)的，例如，對于多媒體應(yīng)用，已經(jīng)提出了一些部分可靠的傳輸協(xié)議，諸如偏序連接POCv2(Partially Ordered Connection V2)[9]、選 擇性重傳協(xié)議SRP(Selective Retransmission Protocol)[10]和基于部分可靠性的實(shí)時(shí)流PERES(Partial Reliability Based Real-Time Streaming)[11]。這些協(xié)議都只能用于它們設(shè)計(jì)的特定應(yīng)用，不具備通用性。

目前的部分可靠協(xié)議也有基于現(xiàn)有特殊傳輸協(xié)議實(shí)現(xiàn)部分可靠的擴(kuò)展，例如基于DCCP 協(xié)議擴(kuò)展的PR-DCCP(Partial Reliability Datagram Congestion Control Protocol)[12]、基于SCTP 協(xié)議擴(kuò)展的PR-SCTP(Partial Reliability Stream Control Transmission Protocol)[13]、基于MPTCP的MO-PR(Message-Oriented Partial-Reliability)[14]和PR-MPTCP+(Partial Reliability Multipath Transport Control Protocol)[15]、基于Quic 的rQUIC[16-17]等。這些部分可靠傳輸協(xié)議一方面受到它們原本協(xié)議適用范圍的限制；另一方面，它們大都也僅適用于特定應(yīng)用，不具備通用性。

基于通用傳輸協(xié)議的改進(jìn)的研究也相對匱乏。目前已有的通用的部分可靠傳輸協(xié)議有PRTP-ECN(Partially Reliable Transport Protocol using ECN)[18]。PRTP是為具有軟實(shí)時(shí)要求的多媒體應(yīng)用而設(shè)計(jì)。PRTP 提供部分可靠的服務(wù)，允許應(yīng)用程序以一定程度的數(shù)據(jù)丟失為代價(jià)換取更高的吞吐率和更低的延遲。PRTP 是作為TCP 的擴(kuò)展而開發(fā)，是基于接收端設(shè)計(jì)的協(xié)議。在PRTP 實(shí)現(xiàn)中，PRTP 允許應(yīng)用程序指定0%到100%之間的可靠性級別，保證該應(yīng)用程序保持其設(shè)置的可靠性級別。PRTP 能提供確定性的可靠度保證，它主要通過更改ACK 方案來調(diào)整重傳策略。接收端為允許丟失的數(shù)據(jù)包發(fā)送“假”ACK，以“欺騙”發(fā)送端，從而減少重傳次數(shù)，提高傳輸速率，但易導(dǎo)致TCP 的擁塞控制失效?！凹俚摹盇CK 反饋不能正確指示網(wǎng)絡(luò)擁塞的情況，當(dāng)實(shí)際出現(xiàn)網(wǎng)絡(luò)擁塞的情況時(shí)，發(fā)送端仍然認(rèn)為網(wǎng)絡(luò)狀況是良好的，不會(huì)馬上對實(shí)際網(wǎng)絡(luò)情況做出反應(yīng)[19]。所以，基于ACK 反饋的擁塞控制機(jī)制并不適用于PRTP 協(xié)議。因此PRTP-ECN 選擇使用ECN 標(biāo)記來通知發(fā)送端網(wǎng)絡(luò)擁塞情況，但這就必須要中間路由器的配合，限制了其可部署性。

現(xiàn)有的部分可靠傳輸協(xié)議，并不具備滿足多應(yīng)用類型差異化可靠傳輸?shù)哪芰?。所以，我們致力于設(shè)計(jì)一種新的通用的部分可靠傳輸協(xié)議，以供應(yīng)用程序使用。這個(gè)協(xié)議既能提供確定性的可靠度服務(wù)，也能根據(jù)應(yīng)用需求，自適應(yīng)調(diào)整傳輸策略，提高傳輸效率。這個(gè)協(xié)議是基于發(fā)送端的端到端的傳輸協(xié)議，方便在現(xiàn)有的互聯(lián)網(wǎng)基礎(chǔ)設(shè)施內(nèi)工作，不需要中間路由器特別配合，也易于部署。

2 差異化可靠傳輸控制機(jī)制設(shè)計(jì)

現(xiàn)有的部分可靠傳輸機(jī)制基本上是基于時(shí)間和單一類型應(yīng)用進(jìn)行重傳策略的設(shè)計(jì)，并不具備滿足多種應(yīng)用類型差異化確定性可靠傳輸需求的能力。目前的部分可靠傳輸協(xié)議局限于對已有協(xié)議改進(jìn)，受限于原有協(xié)議的適用范圍，具有較大的局限性，不方便在網(wǎng)絡(luò)中部署和使用。

因此針對應(yīng)用差異化的確定性可靠傳輸需求，我們設(shè)計(jì)了一種新的差異化可靠傳輸控制協(xié)議-DRTP 協(xié)議，該協(xié)議能在滿足應(yīng)用可靠度需求的前提下，降低傳輸延遲、提高吞吐率。本節(jié)將詳細(xì)介紹DRTP 的協(xié)議框架和差異化可靠傳輸控制機(jī)制的設(shè)計(jì)。

2.1 協(xié)議框架

DRTP 設(shè)計(jì)為一種通用的傳輸層協(xié)議，而不是僅針對某些特定應(yīng)用設(shè)計(jì)。

DRTP協(xié)議基本原理如圖1所示。在正常情況下，傳輸過程中未發(fā)生丟包時(shí)的操作與傳統(tǒng)TCP 的運(yùn)行流程大致一致，但當(dāng)傳輸過程中發(fā)生報(bào)文丟失時(shí)，發(fā)送端會(huì)根據(jù)目前的傳輸情況，決策這個(gè)丟失的數(shù)據(jù)報(bào)文是否需要重傳，若判斷為不需要重傳這個(gè)丟失數(shù)據(jù)報(bào)文，發(fā)送端馬上通知接收端無需等待這個(gè)丟失數(shù)據(jù)報(bào)文并繼續(xù)后續(xù)數(shù)據(jù)的傳輸；接收端收到發(fā)送端發(fā)送的決策信息便主動(dòng)將已接收的數(shù)據(jù)遞交給上層應(yīng)用，前移接收窗口，更新確認(rèn)信息ACK 值，將實(shí)際接收情況反饋給發(fā)送端以更新傳輸情況。這種機(jī)制可以防止傳統(tǒng)TCP 中接收端因?yàn)殚L時(shí)間等待丟失數(shù)據(jù)包導(dǎo)致的隊(duì)頭阻塞問題。一些應(yīng)用如多媒體應(yīng)用，少量數(shù)據(jù)的丟失并不會(huì)影響它們的服務(wù)質(zhì)量，但若是因?yàn)榈却恍┎恢匾臄?shù)據(jù)導(dǎo)致接收端無法將已接收到的應(yīng)用數(shù)據(jù)及時(shí)向上層遞交，這種情況會(huì)對應(yīng)用的服務(wù)質(zhì)量造成更大的影響。這種機(jī)制也適用于目前包含重傳確認(rèn)機(jī)制的其他傳輸協(xié)議。

2.2 可靠度計(jì)算

不同類型的應(yīng)用數(shù)據(jù)的可靠度傳輸需求不盡相同。為了盡可能提高網(wǎng)絡(luò)傳輸效率，兼顧數(shù)據(jù)傳輸質(zhì)量和應(yīng)用服務(wù)質(zhì)量，因此需要在業(yè)務(wù)特性和服務(wù)需求的基礎(chǔ)上，具體量化傳輸過程中的傳輸效果。傳輸效果的量化結(jié)果可以為傳輸方案帶來有效反饋，由此調(diào)整傳輸策略，進(jìn)一步優(yōu)化決策過程。

現(xiàn)有的傳輸協(xié)議對于可靠度沒有具體的量化標(biāo)準(zhǔn)，已提出的部分可靠傳輸協(xié)議采用簡單的ACK 機(jī)制和時(shí)間機(jī)制，也沒有對可靠度進(jìn)行較好的量化。差異化可靠傳輸協(xié)議與傳統(tǒng)傳輸控制協(xié)議區(qū)別在于其需要時(shí)刻感知當(dāng)前可靠度與目標(biāo)可靠度的情況，通過判別當(dāng)前時(shí)刻網(wǎng)絡(luò)傳輸可靠度與應(yīng)用所需可靠度的差別，進(jìn)而實(shí)現(xiàn)差異化的可靠傳輸控制機(jī)制。

DRTP 會(huì)在傳輸前先讓上層應(yīng)用確定一個(gè)應(yīng)用的需求可靠度(required reliability level,rrl)，并在傳輸過程中在每次收到ACK 信息時(shí)更新當(dāng)前可靠度(current reliability level,crl)來衡量當(dāng)前傳輸情況，并與rrl 來比較看是否滿足應(yīng)用傳輸需求。但傳輸層不能完全了解具體的應(yīng)用傳輸數(shù)據(jù)量，像PRTP 協(xié)議這種完全統(tǒng)計(jì)所有發(fā)送的數(shù)據(jù)來計(jì)算crl，在數(shù)據(jù)量大的情況下，計(jì)算量也會(huì)比較大，影響運(yùn)行效率。所以我們采取一種基于一定數(shù)據(jù)量的周期性計(jì)算方式，確定一個(gè)計(jì)算周期，將整個(gè)傳輸過程以計(jì)算周期為單位分割成每一小段，以周期為單位保證傳輸情況滿足rrl，最終整體傳輸也能滿足rrl。當(dāng)前可靠度crl的一種計(jì)算方式：

可靠度基于周期進(jìn)行計(jì)算，其中，n為周期內(nèi)數(shù)據(jù)報(bào)文傳輸個(gè)數(shù)，pk為第k個(gè)數(shù)據(jù)報(bào)文的接收情況指示符，當(dāng)?shù)趉個(gè)數(shù)據(jù)報(bào)文成功接收時(shí)為1，否則為0，bk為第k個(gè)數(shù)據(jù)報(bào)文的字節(jié)數(shù)。方案中數(shù)據(jù)傳輸策略會(huì)基于crl 計(jì)算結(jié)果作為決策依據(jù)。

可靠度周期的設(shè)置可以根據(jù)上層應(yīng)用傳輸?shù)臄?shù)據(jù)量和數(shù)據(jù)特征，自行設(shè)置。設(shè)置的周期值偏大些，一個(gè)周期內(nèi)可進(jìn)行主動(dòng)丟棄處理操作的個(gè)數(shù)就會(huì)多些，傳輸控制可以更靈活；如果設(shè)置的周期值偏小，則可處理的數(shù)據(jù)報(bào)文個(gè)數(shù)也會(huì)較少，如果鏈路丟包嚴(yán)重，處理數(shù)量較易用完。

可靠度進(jìn)行周期性計(jì)算優(yōu)勢在于可以保證此連接的數(shù)據(jù)傳輸過程中主動(dòng)丟棄的數(shù)據(jù)報(bào)文均勻分布在每個(gè)周期內(nèi)，避免出現(xiàn)連續(xù)主動(dòng)丟棄數(shù)據(jù)的情況，保證每周期內(nèi)數(shù)據(jù)傳輸?shù)目煽慷?。可靠度一方面反映此連接可容忍數(shù)據(jù)丟失情況，反映當(dāng)前周期內(nèi)網(wǎng)絡(luò)數(shù)據(jù)傳輸?shù)姆€(wěn)定程度，另一方面也可以反映網(wǎng)絡(luò)當(dāng)前時(shí)刻擁塞程度。

2.3 重傳控制機(jī)制

2.3.1 設(shè)計(jì)概述

DR-TP 協(xié)議提出了一種新的基于可靠度的報(bào)文重傳控制機(jī)制，根據(jù)應(yīng)用可靠度的要求來進(jìn)行報(bào)文重傳決策。

傳統(tǒng)的TCP 協(xié)議沒有考慮應(yīng)用對可靠度的差異化需求，過于追求完全可靠，它沒有關(guān)注到傳輸業(yè)務(wù)自身的特性，對所有數(shù)據(jù)都是基于統(tǒng)一標(biāo)準(zhǔn)進(jìn)行操作。許多丟失報(bào)文雖然可以通過重傳機(jī)制恢復(fù)丟失，但若在數(shù)據(jù)傳輸過程中出現(xiàn)數(shù)據(jù)報(bào)文丟失時(shí)，接收端不會(huì)立即將其它已接收的數(shù)據(jù)遞交給上層使用，直至缺失的數(shù)據(jù)報(bào)文成功接收之后，才將所有已接收數(shù)據(jù)遞交給上層應(yīng)用。如果丟失的數(shù)據(jù)報(bào)文本身并不具備重要度，即使丟失也不會(huì)對上層服務(wù)質(zhì)量產(chǎn)生特別大的影響，那么完全可靠的數(shù)據(jù)傳輸就會(huì)產(chǎn)生比較大的傳輸時(shí)延，且可能會(huì)影響上層應(yīng)用服務(wù)質(zhì)量[19-20]。

TCP 的重傳機(jī)制有快速重傳和超時(shí)重傳這兩種方式?？焖僦貍魍ㄟ^重復(fù)ACK 來判斷丟失，能及時(shí)恢復(fù)丟失數(shù)據(jù)，它本身并不會(huì)對TCP 的傳輸效率造成太大影響。但超時(shí)重傳的觸發(fā)會(huì)顯著降低TCP 傳輸性能，因?yàn)槌瑫r(shí)情況的出現(xiàn)一般是由于傳輸中批量的數(shù)據(jù)丟失造成發(fā)送端不能及時(shí)收到確認(rèn)信息而一直處于等待狀態(tài)。超時(shí)的觸發(fā)需要發(fā)送端等待重傳超時(shí)(Retransmission Timeout,RTO)，RTO 一般是RTT 的2-4 個(gè)數(shù)量級，等待時(shí)間較長。而且超時(shí)重傳會(huì)使TCP 進(jìn)入Loss 狀態(tài)，在此狀態(tài)下，發(fā)送端會(huì)將發(fā)送窗口內(nèi)所有未確認(rèn)的數(shù)據(jù)報(bào)文標(biāo)記為丟失，擁塞窗口重新從1MSS 開始增加，發(fā)送端在丟失數(shù)據(jù)全部確認(rèn)前不會(huì)繼續(xù)發(fā)送新數(shù)據(jù)，導(dǎo)致TCP 傳輸停滯，嚴(yán)重影響TCP 傳輸效率[21]。

對超時(shí)產(chǎn)生原因進(jìn)行細(xì)分，主要導(dǎo)致超時(shí)重傳觸發(fā)的原因是雙重重傳和尾部重傳這兩種情況。雙重重傳是指通過快速重傳或超時(shí)重傳的重傳數(shù)據(jù)再次丟失或延遲，進(jìn)而導(dǎo)致新的超時(shí)的觸發(fā)。在易損網(wǎng)絡(luò)的條件下，這種情況比較容易觸發(fā)[21]。尾部重傳主要發(fā)生在流的尾部，如果流的尾部數(shù)據(jù)丟失，TCP 發(fā)送端可能會(huì)因?yàn)闊o法收到足夠的重復(fù)ACK 觸發(fā)快速重傳操作，只能通過超時(shí)重傳恢復(fù)丟失數(shù)據(jù)[22]。若發(fā)送窗口內(nèi)出現(xiàn)大量數(shù)據(jù)報(bào)文的連續(xù)丟失或者發(fā)送窗口過小，也可能導(dǎo)致TCP 發(fā)送端因收不到足夠的重復(fù)ACK 來觸發(fā)快速重傳而等待超時(shí)的情況。

因此我們提出了一種新的重傳控制機(jī)制來減少超時(shí)觸發(fā)的次數(shù)。該機(jī)制通過降低對數(shù)據(jù)傳輸可靠性的要求，主動(dòng)降低部分丟失數(shù)據(jù)的可靠度要求，避免因這一部分?jǐn)?shù)據(jù)的丟失造成數(shù)據(jù)流阻塞，導(dǎo)致用戶應(yīng)用體驗(yàn)的降低。新設(shè)計(jì)的重傳控制機(jī)制保留快速重傳機(jī)制，并提出了一種新的通知機(jī)制來靈活控制可靠度情況。新設(shè)計(jì)的機(jī)制主要通過引入比超時(shí)定時(shí)器更積極的定時(shí)器，稱作通知定時(shí)器，減少因丟包導(dǎo)致超時(shí)觸發(fā)產(chǎn)生的負(fù)面影響，它對可能導(dǎo)致超時(shí)的丟失報(bào)文在當(dāng)前周期滿足可靠度的情況下，允許不重傳已丟失數(shù)據(jù)報(bào)文，通知接收端跳過丟失數(shù)據(jù)，前移接收窗口，返回新的ACK 值，使發(fā)送端繼續(xù)發(fā)送新的數(shù)據(jù)報(bào)文。

2.3.2 通知機(jī)制

發(fā)送端與接收端在握手建立期間確定差異化可靠功能的開啟，若不支持也可退回到原來的傳輸機(jī)制。在傳輸過程中，發(fā)送端發(fā)送數(shù)據(jù)報(bào)文時(shí)，同時(shí)開啟通知定時(shí)器和超時(shí)定時(shí)器，并在每次收到新的ACK 信息后及時(shí)更新當(dāng)前可靠度值，基本操作與傳統(tǒng)TCP 流程一致。但當(dāng)發(fā)送端在傳輸過程中一段時(shí)間內(nèi)未收到ACK 信息的更新時(shí)，發(fā)送端便會(huì)通過通知定時(shí)器的觸發(fā)監(jiān)測到這一事件，發(fā)送端先根據(jù)當(dāng)前傳輸可靠度來判斷當(dāng)前數(shù)據(jù)是否需要重傳。發(fā)送端若判斷為當(dāng)前不需要重傳數(shù)據(jù)，允許接收端主動(dòng)放棄該數(shù)據(jù)，發(fā)送端便會(huì)構(gòu)造一個(gè)攜帶丟包處理信息的通知報(bào)文發(fā)往接收端。接收端在收到這個(gè)通知報(bào)文后，主動(dòng)更新確認(rèn)點(diǎn)信息，把未接收到的數(shù)據(jù)報(bào)文當(dāng)作是正常接收到一樣處理，主動(dòng)前移接收窗口，并向發(fā)送端返回最新的ACK 信息和處理信息以用作發(fā)送端的可靠度更新和發(fā)送新數(shù)據(jù)。接收端及時(shí)將已緩存的數(shù)據(jù)及時(shí)提交到上層應(yīng)用，減少了上層應(yīng)用等待數(shù)據(jù)的時(shí)延。

2.3.3 發(fā)送端控制

發(fā)送端在數(shù)據(jù)發(fā)送時(shí)啟動(dòng)通知定時(shí)器，當(dāng)一段時(shí)間內(nèi)未收到ACK 的更新時(shí)，通知定時(shí)器觸發(fā)進(jìn)入通知報(bào)文處理流程（見算法1）。發(fā)送端先檢查當(dāng)前傳輸狀態(tài)是否滿足通知報(bào)文發(fā)送的條件，若不滿足條件，則等待一個(gè)RTT 后再次進(jìn)入該函數(shù)檢查傳輸狀態(tài)是否滿足通知報(bào)文發(fā)送條件；滿足條件的話再根據(jù)當(dāng)前傳輸可靠度情況判斷當(dāng)前數(shù)據(jù)是否需要重傳。若當(dāng)前傳輸情況滿足應(yīng)用可靠度需求(crl>=rrl)，發(fā)送端允許主動(dòng)放棄丟失的數(shù)據(jù)報(bào)文，向接收端發(fā)送一個(gè)攜帶丟包處理信息的通知報(bào)文；若不滿足應(yīng)用可靠度需求，則等待超時(shí)觸發(fā)重傳。

如圖2 所示通知機(jī)制觸發(fā)的兩種場景，通知機(jī)制的觸發(fā)條件需要滿足下面兩個(gè)條件之一便可觸發(fā)通知機(jī)制流程。第一個(gè)條件是當(dāng)前報(bào)文(cur_pkt)已經(jīng)被重傳過。我們設(shè)計(jì)的機(jī)制仍使用快速重傳機(jī)制，如果在一定時(shí)間內(nèi)能通過快速重傳恢復(fù)丟失的數(shù)據(jù)報(bào)文，便不會(huì)進(jìn)行其他操作。但若重傳的數(shù)據(jù)報(bào)文再次丟失，按照原來TCP 機(jī)制，發(fā)送端只能等待RTO 超時(shí)觸發(fā)，這會(huì)影響傳輸效率。因此，若該數(shù)據(jù)報(bào)文在通知定時(shí)器觸發(fā)時(shí)已經(jīng)被重傳，發(fā)送端會(huì)根據(jù)當(dāng)前可靠度情況判斷是否允許主動(dòng)放棄該數(shù)據(jù)，繼續(xù)后續(xù)數(shù)據(jù)傳輸。第二個(gè)條件是發(fā)送端當(dāng)前已發(fā)送但未確認(rèn)的數(shù)據(jù)報(bào)文個(gè)數(shù)（packets_out）小于閾值α。若傳輸過程中出現(xiàn)連續(xù)批量的數(shù)據(jù)報(bào)文丟失，發(fā)送端就可能因?yàn)槭詹坏阶銐驍?shù)量的重復(fù)ACK 而無法通過快速重傳操作恢復(fù)丟失數(shù)據(jù)報(bào)文，最終需要等待RTO 觸發(fā)超時(shí)重傳。所以當(dāng)通知定時(shí)器觸發(fā)時(shí)，發(fā)送端發(fā)現(xiàn)目前已發(fā)送且未確認(rèn)的數(shù)據(jù)量少于一定數(shù)量時(shí)，發(fā)送端根據(jù)當(dāng)前傳輸可靠度情況，判斷是否需要重傳該范圍內(nèi)未確認(rèn)的數(shù)據(jù)。α 默認(rèn)取10，該值的設(shè)置具體需要因使用的不同擁塞算法而進(jìn)行調(diào)整。

圖2 通知機(jī)制觸發(fā)的兩種場景Fig.2 Two scenarios triggered by the notification mechanism

若當(dāng)前發(fā)送端不滿足這兩個(gè)條件中的任意一個(gè)，便會(huì)等待1 個(gè)RTT 后再次探詢當(dāng)前狀態(tài)是否滿足條件。當(dāng)發(fā)送端當(dāng)前狀態(tài)滿足兩個(gè)條件中任意一個(gè)就可繼續(xù)通知機(jī)制流程。發(fā)送端還需根據(jù)當(dāng)前周期是否滿足應(yīng)用可靠度要求來判斷是否允許主動(dòng)通知接收端放棄未接收數(shù)據(jù)。如果當(dāng)前周期滿足應(yīng)用可靠度要求，發(fā)送端向接收端發(fā)送通知報(bào)文，通知接收端允許放棄當(dāng)前周期內(nèi)未接收數(shù)據(jù)，主動(dòng)前移接收窗口，更新ACK 信息，發(fā)送端繼續(xù)發(fā)送后續(xù)數(shù)據(jù)。如果當(dāng)前周期不滿足應(yīng)用可靠度要求或接近應(yīng)用可靠度要求的底線，發(fā)送端判斷當(dāng)前傳輸情況不能滿足應(yīng)用可靠度要求，不允許接收端主動(dòng)放棄未接收數(shù)據(jù)，發(fā)送端通過傳輸協(xié)議的重傳機(jī)制重傳數(shù)據(jù)來保證應(yīng)用可靠度要求。

通知機(jī)制設(shè)置一個(gè)通知定時(shí)器，在當(dāng)前實(shí)現(xiàn)中，將定時(shí)器設(shè)置為1.5 個(gè)RTT(Round-Trip Time)。通常情況下，發(fā)送端至多能在2 個(gè)RTT 內(nèi)收到數(shù)據(jù)報(bào)文的確認(rèn)。若傳輸過程中未發(fā)生報(bào)文丟失，發(fā)送端應(yīng)該能夠再約一個(gè)RTT 內(nèi)收到數(shù)據(jù)報(bào)文的確認(rèn)；傳輸過程中如果發(fā)生報(bào)文丟失，若發(fā)送端能觸發(fā)快速重傳機(jī)制且重傳數(shù)據(jù)順利到達(dá)接收端，這期間總共需約1.5 個(gè)RTT 的時(shí)間，收到數(shù)據(jù)報(bào)文的確認(rèn)就共需要約2 個(gè)RTT 的時(shí)間。發(fā)送端若觸發(fā)了快速重傳機(jī)制重傳數(shù)據(jù)后，發(fā)送端也會(huì)馬上發(fā)送一個(gè)通知報(bào)文，如果重傳的數(shù)據(jù)報(bào)文在傳輸過程中再次丟失，接收端也能馬上收到通知報(bào)文，及時(shí)進(jìn)行丟失數(shù)據(jù)的處理；如果重傳的數(shù)據(jù)報(bào)文順利到達(dá)接收端，那么接收端即使收到后面的通知報(bào)文，也不會(huì)對接收端造成影響。如果傳輸過程中發(fā)生了數(shù)據(jù)丟失且發(fā)送端未能觸發(fā)快速重傳，那么發(fā)送端在1.5 個(gè)RTT 后也能及時(shí)響應(yīng)數(shù)據(jù)丟失事件，通知接收端處理丟失數(shù)據(jù)。

RTT 是使用RFC 2988[23]的RTT 估計(jì)算法進(jìn)行計(jì)算。1.5 的設(shè)置是因?yàn)閺陌l(fā)送端第一次發(fā)送這個(gè)數(shù)據(jù)報(bào)文，至發(fā)送端收到因這個(gè)數(shù)據(jù)報(bào)文的丟失產(chǎn)生的三次重復(fù)ACK 而觸發(fā)快速重傳，時(shí)間約1 個(gè)RTT；發(fā)送端重傳當(dāng)前數(shù)據(jù)報(bào)文且重傳的數(shù)據(jù)報(bào)文到達(dá)接收端的時(shí)間約0.5 個(gè)RTT。全過程總共約1.5個(gè)RTT。發(fā)送端設(shè)置為在1.5個(gè)RTT時(shí)發(fā)送通知報(bào)文。通知報(bào)文本身具備探測性質(zhì)，可以探測重傳是否成功，若重傳成功了，接收端就不做其他操作，若不成功就處理丟失數(shù)據(jù)。

本文提出的差異化可靠傳輸控制機(jī)制作為一種新的通用的傳輸層控制機(jī)制，它的實(shí)現(xiàn)不依賴于其他協(xié)議，可以獨(dú)立實(shí)現(xiàn)和運(yùn)行。在實(shí)際的開發(fā)實(shí)現(xiàn)過程中，為便于保留TCP 協(xié)議的擁塞控制機(jī)制等優(yōu)點(diǎn)，本文選擇基于TCP 協(xié)議，對其可靠傳輸控制機(jī)制替換成本文所提出的差異化可靠傳輸控制機(jī)制，以此實(shí)現(xiàn)DRTP 協(xié)議。本文通過setsockopt()函數(shù)來實(shí)現(xiàn)應(yīng)用層對DRTP 協(xié)議的設(shè)置，應(yīng)用層應(yīng)用可以通過該函數(shù)進(jìn)行DRTP 協(xié)議的啟用和應(yīng)用可靠度、可靠度計(jì)算周期等DRTP 協(xié)議相關(guān)參數(shù)的設(shè)置。

在通知機(jī)制流程中，若發(fā)送端允許進(jìn)行丟包處理的操作，發(fā)送端便會(huì)發(fā)送一個(gè)通知報(bào)文給接收端，通知報(bào)文復(fù)用丟失數(shù)據(jù)報(bào)文序列號，去掉原先的數(shù)據(jù)負(fù)載，只通過選項(xiàng)保留通知信息。通知報(bào)文采取單獨(dú)發(fā)包的方式，操作靈活且便于擴(kuò)展，因沒有數(shù)據(jù)負(fù)載只有報(bào)頭信息和其攜帶的通知信息，比較輕量，不會(huì)給網(wǎng)絡(luò)帶來太大的負(fù)載。通知報(bào)文選項(xiàng)信息格式參見圖3。通知報(bào)文信息包含當(dāng)前周期允許的最大可丟包數(shù)目和當(dāng)前周期的序列號范圍。為了防止出現(xiàn)通知報(bào)文丟失使接收端無法處理丟失數(shù)據(jù)報(bào)文的情況，發(fā)送端也單獨(dú)給通知報(bào)文設(shè)置一個(gè)定時(shí)器，若1 個(gè)RTT 內(nèi)未收到接收端返回的ACK 信息，便會(huì)進(jìn)行通知報(bào)文重傳操作。一般情況下，通知報(bào)文到達(dá)接收端且發(fā)送端收到接收端返回的新的確認(rèn)信息最多需要約1 個(gè)RTT 的時(shí)間。若在此期間內(nèi)，發(fā)送端未收到新的ACK，就會(huì)判斷通知報(bào)文可能丟失了，這就需要重傳通知報(bào)文給接收端。

圖3 發(fā)送端通知報(bào)文選項(xiàng)結(jié)構(gòu)Fig.3 Sender notification message option structure

通知報(bào)文選項(xiàng)參數(shù)含義：

·Kind：標(biāo)明該選項(xiàng)是通知報(bào)文選項(xiàng)。這個(gè)參數(shù)標(biāo)記此TCP 報(bào)文是通知報(bào)文。接收端通過這個(gè)Kind值來識(shí)別是否接收到通知報(bào)文。

·Length：標(biāo)識(shí)整個(gè)選項(xiàng)長度為8 個(gè)字節(jié)。

·DroppableCount：告知接收端當(dāng)前發(fā)送端周期范圍內(nèi)可允許主動(dòng)丟包處理的最大數(shù)據(jù)報(bào)文個(gè)數(shù)。

·EndSeq：告知接收端允許主動(dòng)丟包處理的序列號的最大界限，通知報(bào)文序列號復(fù)用當(dāng)前發(fā)送窗口內(nèi)第一個(gè)數(shù)據(jù)報(bào)文的序列號Seq，可丟包處理范圍為[Seq,EndSeq]，至多可丟DroppableCount 個(gè)數(shù)據(jù)報(bào)文。

2.3.4 接收端控制

通知機(jī)制中接收端的操作如算法2 所示。接收端通過報(bào)文首部里選項(xiàng)的Kind 字段來判斷這個(gè)TCP報(bào)文是否是通知報(bào)文。當(dāng)接收端接收到通知報(bào)文時(shí)，接收端根據(jù)通知報(bào)文選項(xiàng)內(nèi)攜帶信息遍歷接收窗口，處理窗口內(nèi)丟失報(bào)文并記錄主動(dòng)處理的丟失數(shù)據(jù)報(bào)文信息，把未接收到的數(shù)據(jù)報(bào)文當(dāng)作是正常接收到一樣處理，主動(dòng)前移接收窗口，將已接收到的數(shù)據(jù)主動(dòng)向上層遞交，更新ACK 信息并將實(shí)際丟失數(shù)據(jù)報(bào)文處理信息添加到ACK 選項(xiàng)里，隨ACK 報(bào)文一起反饋給發(fā)送端，用以準(zhǔn)確計(jì)算可靠度。接收端ACK 反饋報(bào)文信息選項(xiàng)格式見圖4。

圖4 接收端ACK 反饋報(bào)文選項(xiàng)結(jié)構(gòu)Fig.4 Receiver ACK feedback message option structure

ACK 反饋報(bào)文選項(xiàng)設(shè)計(jì)的參數(shù)含義：

·Kind：標(biāo)明該選項(xiàng)是ACK 反饋報(bào)文選項(xiàng)。這個(gè)參數(shù)標(biāo)記該TCP 報(bào)文是接收端發(fā)給發(fā)送端的ACK反饋報(bào)文。

·Length：整個(gè)選項(xiàng)長度為10 個(gè)字節(jié)。

·StartSeq：接收端主動(dòng)處理丟失數(shù)據(jù)報(bào)文的起始序列號。

·DropSize：接收端主動(dòng)處理丟失數(shù)據(jù)報(bào)文起始序列號StartSeq 到ACK 范圍內(nèi)總共處理的數(shù)據(jù)量。

3 實(shí)驗(yàn)性能評價(jià)

本文先通過NS3 仿真平臺(tái)實(shí)現(xiàn)DRTP 機(jī)制，測試機(jī)制的效果，并在Linux 上進(jìn)行系統(tǒng)實(shí)現(xiàn)和部署，驗(yàn)證DRTP 的實(shí)際傳輸效果。

3.1 仿真實(shí)驗(yàn)測試

為了驗(yàn)證DRTP 重傳控制機(jī)制的效果，我們先基于NS3 網(wǎng)絡(luò)模擬器開發(fā)實(shí)現(xiàn)了DRTP 協(xié)議，并與TCP 協(xié)議進(jìn)行對比實(shí)驗(yàn)。實(shí)驗(yàn)采用的系統(tǒng)為Ubuntu20.04。TCP 和DRTP 的擁塞控制算法都設(shè)置為NewReno。我們在不同丟包率、不同時(shí)延這兩個(gè)條件下進(jìn)行實(shí)驗(yàn)測試。

實(shí)驗(yàn)網(wǎng)絡(luò)拓?fù)淙鐖D5 所示。實(shí)驗(yàn)拓?fù)鋱D中其中客戶端基于NS3 中BulkSendHelper 應(yīng)用類實(shí)現(xiàn)數(shù)據(jù)流發(fā)送，服務(wù)器基于NS3 中PacketSinkHelper 類實(shí)現(xiàn)數(shù)據(jù)接收，丟包率設(shè)置基于NS3 中RateErrorModel差錯(cuò)模型類實(shí)現(xiàn)。實(shí)驗(yàn)測試的參數(shù)如表1 所示。雙端緩沖區(qū)都設(shè)置為2*BDP(帶寬時(shí)延積,bandwidthdelay product)，路由緩沖區(qū)設(shè)置為1.2*BDP。上層應(yīng)用指定應(yīng)用可靠度需求為95%。實(shí)驗(yàn)通過傳輸100MB 數(shù)據(jù)進(jìn)行測試。

圖5 NS3 仿真網(wǎng)絡(luò)拓?fù)銯ig.5 NS3 simulation network topology

表1 NS3仿真實(shí)驗(yàn)參數(shù)設(shè)置Table 1 NS3 simulation experiment parameter settings

3.1.1 不同鏈路丟包率下性能測試

這組實(shí)驗(yàn)里瓶頸帶寬設(shè)置為100Mbps，時(shí)延設(shè)置為40ms，鏈路丟包率分別設(shè)置為0.1%、1%、2%、3%、4%、5%、8%。圖6 分別顯示DRTP 和TCP 在不同鏈路丟包率下的傳輸完成時(shí)間。結(jié)果明顯能看出采用了通知機(jī)制的DRTP 協(xié)議比較TCP 能更早完成傳輸任務(wù)。鏈路丟包率越大，DRTP 提升的效率越明顯。從表2 中可以看到，在鏈路丟包率0.1%至8%的網(wǎng)絡(luò)場景下，DRTP 傳輸基本都保證了應(yīng)用可靠度需求。

圖6 不同鏈路丟包率下傳輸完成時(shí)間Fig.6 Transmission completion time under different link loss rates

在表2 中可以看到TCP 會(huì)因?yàn)閬G包觸發(fā)較多的超時(shí)重傳，傳輸效果也明顯會(huì)受到超時(shí)觸發(fā)的影響。DRTP 明顯減少了超時(shí)重傳的觸發(fā)次數(shù)，DRTP的快速重傳的觸發(fā)次數(shù)相較TCP 也有所減少，降低了DRTP 由于重傳觸發(fā)影響到傳輸效率的概率。在鏈路丟包率高的場景里，DRTP 的通知機(jī)制可以更有效地提高傳輸效率。DRTP 的通知機(jī)制設(shè)置的通知定時(shí)器約有1.5RTT。一般情況下，傳輸過程中因丟包觸發(fā)快速重傳機(jī)制且重傳數(shù)據(jù)到達(dá)接收端，整個(gè)過程總共需花費(fèi)約1.5 個(gè)RTT 的時(shí)間。發(fā)送端在觸發(fā)快速重傳且重傳了數(shù)據(jù)報(bào)文之后不久，也會(huì)隨之發(fā)送一個(gè)通知報(bào)文。如果重傳的數(shù)據(jù)報(bào)文丟失，接收端也能馬上收到發(fā)送端后面發(fā)送的通知報(bào)文，及時(shí)處理丟失數(shù)據(jù)；如果重傳的數(shù)據(jù)報(bào)文順利到達(dá)接收端，那么接收端收到后面的通知也不會(huì)產(chǎn)生影響。如果傳輸過程中發(fā)生了數(shù)據(jù)丟失且未能觸發(fā)快速重傳，發(fā)送端在1.5RTT 時(shí)也能及時(shí)響應(yīng)數(shù)據(jù)丟失事件，通知接收端處理丟失數(shù)據(jù)。因此，結(jié)果表明DRTP的通知機(jī)制在丟包率高的場景下可以有效改善傳輸性能。

表2 不同鏈路丟包率下DRTP 傳輸情況統(tǒng)計(jì)Table 2 Statistics of DRTP transmission under different link loss rates

3.1.2 不同RTT 下性能測試

這組實(shí)驗(yàn)里瓶頸帶寬設(shè)置為100Mbps，鏈路RTT 分別設(shè)置為20ms、40ms、100ms、180ms、300ms，鏈路丟包率分別設(shè)置為4%。圖7 分別顯示DRTP 和TCP 在不同RTT 下的傳輸完成時(shí)間，結(jié)果顯示采用了通知機(jī)制的DRTP 協(xié)議比TCP 能更早完成傳輸任務(wù)。表3 顯示DRTP 實(shí)際傳輸可靠度，DRTP 也基本滿足應(yīng)用可靠度需求。在表3 中DRTP相較TCP 明顯減少了超時(shí)的觸發(fā)次數(shù)，一定程度上提升了傳輸效率。不過，實(shí)驗(yàn)結(jié)果也可以看出，在不同RTT 下，DRTP 的提升效果不會(huì)受RTT 太大影響。

圖7 在不同RTT 下傳輸完成時(shí)間Fig.7 Transmission completion time under different RTTs

表3 不同RTT 下DRTP 傳輸情況統(tǒng)計(jì)Table 3 Statistics of DRTP transmission under different RTTs

3.2 實(shí)際系統(tǒng)實(shí)驗(yàn)測試

本文也在Linux 內(nèi)核上進(jìn)行DRTP 機(jī)制的開發(fā)實(shí)現(xiàn)并部署在Ubuntu 系統(tǒng)上，設(shè)備具體參數(shù)如表4所示。

表4 實(shí)驗(yàn)設(shè)備參數(shù)Table 4 Parameters of experimental equipment

本實(shí)驗(yàn)設(shè)置兩臺(tái)PC 電腦分別作為發(fā)送端和接收端。實(shí)驗(yàn)通過TC(Traffic Control)工具產(chǎn)生網(wǎng)絡(luò)丟包和延時(shí)。實(shí)驗(yàn)中的應(yīng)用可靠度要求設(shè)置為95%，可靠度計(jì)算周期設(shè)置為每1000 個(gè)報(bào)文進(jìn)行計(jì)算。系統(tǒng)擁塞算法默認(rèn)使用Cubic，系統(tǒng)參數(shù)設(shè)置都采用系統(tǒng)默認(rèn)值。上層應(yīng)用程序使用基于BSD socket API編寫的文件傳輸工具，本實(shí)驗(yàn)使用43.5MB 大小的文件傳輸進(jìn)行測試。

3.2.1 不同丟包率下性能測試

本組實(shí)驗(yàn)中發(fā)送端通過TC 設(shè)置時(shí)延為30ms，鏈路丟包率分別設(shè)置1%、2%、3%、4%、5%、8%、10%進(jìn)行測試。表5 顯示了不同丟包率下DRTP 實(shí)際接收的數(shù)據(jù)量，結(jié)果顯示DRTP 在不同丟包率下傳輸基本都能保證其設(shè)定的應(yīng)用可靠度。圖8 分別顯示了DRTP 和TCP 在不同丟包率下的傳輸完成時(shí)間，結(jié)果表明相較TCP，DRTP 在丟包率高的場景下能減少傳輸完成的時(shí)間，有效提升傳輸效率。測試結(jié)果與前面仿真的效果一致，符合DRTP 的預(yù)期效果。

表5 不同鏈路丟包率下DRTP 實(shí)際傳輸可靠度Table 5 Actual DRTP transmission reliability under different link loss rates

圖8 在不同鏈路丟包率下傳輸完成時(shí)間Fig.8 Transmission completion time under different link loss rates

3.2.2 不同RTT 下性能測試

這組實(shí)驗(yàn)中發(fā)送端通過TC 設(shè)置鏈路丟包率為4%，鏈路RTT 分別設(shè)置為20ms、40ms、100ms、180ms、300ms 進(jìn)行測試。根據(jù)表6 顯示，DRTP 在不同RTT 下也都能保證其應(yīng)用可靠度。根據(jù)圖9 顯示，系統(tǒng)測試效果也與前文仿真在不同RTT 下的測試效果接近。DRTP 能較TCP 更早完成傳輸任務(wù)，但其在不同RTT 下的提升效果相對有限。

圖9 在不同RTT 下傳輸完成時(shí)間Fig.9 Transmission completion time at different RTTs

表6 不同RTT 下DRTP 實(shí)際傳輸可靠度Table 6 Actual transmission reliability of DRTP under different RTTs

4 結(jié)論與展望

在本論文，我們提出了一種新的通用的部分可靠傳輸協(xié)議DRTP，它為上層提供差異化和確定性的可靠性服務(wù)。DRTP 可以在滿足應(yīng)用所需的可靠性的前提下，提升傳輸效率。而且它作為一種通用的純端到端傳輸協(xié)議，也易于部署使用。本論文中DRTP 的重傳控制機(jī)制采用通知機(jī)制協(xié)調(diào)發(fā)送端和接收端之間的窗口滑動(dòng)，避免超時(shí)重傳的觸發(fā)，減少在當(dāng)前傳輸可靠度滿足應(yīng)用可靠度需求時(shí)的不必要的數(shù)據(jù)重傳次數(shù)，提高傳輸效率。性能評估表明，DRTP 的重傳控制機(jī)制在多種網(wǎng)絡(luò)條件下都能正常工作。在具有丟包率的鏈路上，DRTP 在保證應(yīng)用可靠度要求的前提下，減少了重傳觸發(fā)次數(shù)，避免了超時(shí)的觸發(fā)，進(jìn)而提升了傳輸效率。本文也基于Linux系統(tǒng)進(jìn)行DRTP 機(jī)制的開發(fā)實(shí)現(xiàn)，并進(jìn)行系統(tǒng)測試，驗(yàn)證其傳輸效果，DRTP 的性能評估結(jié)果也如預(yù)期，相較TCP，在丟包率高的場景下，能明顯提升傳輸效率。下一步配合上層應(yīng)用的特性，設(shè)計(jì)更加精細(xì)化的傳輸控制策略，為了更加適應(yīng)不同應(yīng)用的傳輸需求，加強(qiáng)傳輸層與應(yīng)用層的控制信息交互，實(shí)現(xiàn)更加精細(xì)化的傳輸控制。

利益沖突聲明

所有作者聲明不存在利益沖突關(guān)系。