一种差异化可靠传输控制机制

殷明，任勇毛，张运栋，周旭＊，徐安民，于德雷

1.中国科学院计算机网络信息中心，北京 100083

2.中国科学院大学，北京 100049

3.华为技术有限公司，北京 100085

引言

随着互联网技术的飞速发展，为了满足用户多样化的服务需求，互联网也随之涌现出许多新型应用。与过去的仅需完全可靠和有序的数据传输的应用不同，现有的互联网应用对网络提出了更多、更复杂的服务要求。不同类型的网络应用对于数据传输的可靠性要求都不尽相同。许多应用对数据可靠度的需求是有弹性的，是能容忍一定程度的数据丢失率的。这类应用对可靠性的要求不一定需要100%，一定程度的数据丢失不一定会对应用提供的服务质量产生太大影响。比如，对于一些多媒体应用数据传输，1%～2%的视频信息丢失并不会对视频的观看体验产生太大影响[1-2]；对于科研数据传输，许多科学观测实验数据的传输能容忍约2%的丢包率，小部分的数据丢失可以通过数值拟合等方法补偿或恢复[3]。许多具有较软实时约束的应用对数据传输可靠性的要求是灵活的，这类应用可以以容忍一定程度的丢包率为代价，来保证良好的用户体验。

互联网本身提供的是一种尽力而为的服务，它不能保证数据传输的可靠性。它会尽可能将数据传送到目的地，但它不能保证每一个数据分组都能及时可靠地到达目的地。因此上层应用需要传输层的传输协议提供能保证可靠性的传输服务。

目前互联网使用的传输协议大都继续沿用传统的传输协议。这些协议在当初设计时未考虑到新型应用出现的情况，不能完全满足这些新型应用的传输需求，不能达到理想的传输效果。

目前主流传输协议是传输控制协议(Transmission Control Protocol,TCP)[4]和用户数据报协议(User Datagram Protocol,UDP)[5]。TCP 协议提供完全可靠的传输服务，能保证数据的完整性。TCP 是通过重传机制来保证数据的可靠性，这种可靠度保证是以传输延迟增加和吞吐率降低为代价的。另一方面，UDP 虽然可以保证高吞吐量且不会产生额外的延迟，但是缺乏可靠性保证。此外，UDP 既不提供数据排序，也不提供流量控制或拥塞控制，这些机制都需要上层应用自身来实现，增加上层应用的复杂度。目前互联网广泛使用的两个通用传输协议TCP 与UDP 所提供的服务现在都不能完全满足新型应用差异化的可靠度需求。现在的新型应用（比如新型的多媒体应用）所需要的是一种兼备TCP 与UDP 所提供的服务特性的网络服务，既能满足应用的确定性可靠度需求，也能保证数据传输的高效性。

本文针对以上问题提出了一种新的传输协议-差异化可靠传输控制协议(Differentiated Reliable Transmission Protocol,DRTP)，它提供了一种既能满足软实时要求，也能保证确定性可靠度的传输服务。DRTP 是一种基于发送端的部分可靠传输协议，是一种通用传输层协议。DRTP 协议能够在现有的互联网基础设施内工作，也能配合使用现有的拥塞控制算法。差异化可靠传输协议一般更适用于在那些允许部分数据缺失，且不会对终端用户的体验造成太大的影响的业务，比如实时语音业务和在线视频业务等。

本文重点介绍DRTP 协议的重传控制机制，主要避免了超时触发，减少在当前传输可靠度满足应用可靠度需求时的不必要的数据重传次数，进而提高传输效率。我们基于NS-3[6]网络模拟器对DRTP协议进行了实现，并在不同网络条件下开展了实验性能评价。实验结果表明，与TCP 相比，在存在一定丢包率的网络链路上，DRTP 在保证应用需要的可靠度要求的同时，可显著提升传输吞吐率。本文也在Linux 系统上完成机制的实现，并进行系统测试，验证该机制的可行性。

本文的其余部分组织如下：第一节讨论了相关工作；第二节重点介绍DRTP 控制机制的设计，包括DRTP协议框架、可靠度计算以及重传控制机制等；然后，第三节对DRTP 的性能进行了实验评价；最后，第四节对全文进行总结并指出了下一步研究方向。

1 相关工作

不同应用场景对于传输数据的可靠度需求也不尽相同，针对网络应用对传输性能的差异化需求，在满足应用可靠度需求的前提下提高传输速率，是传输协议设计的一个重要研究课题[7]。为满足应用差异化传输需求，目前的解决方案主要通过部分可靠传输协议实现。部分可靠传输协议允许应用程序可以通过牺牲部分传输数据可靠性以提升网络传输速率，降低延迟抖动[8]。

目前对于这一方向的研究尚很缺乏，已有的研究主要为特定应用设计的，例如，对于多媒体应用，已经提出了一些部分可靠的传输协议，诸如偏序连接POCv2(Partially Ordered Connection V2)[9]、选 择性重传协议SRP(Selective Retransmission Protocol)[10]和基于部分可靠性的实时流PERES(Partial Reliability Based Real-Time Streaming)[11]。这些协议都只能用于它们设计的特定应用，不具备通用性。

目前的部分可靠协议也有基于现有特殊传输协议实现部分可靠的扩展，例如基于DCCP 协议扩展的PR-DCCP(Partial Reliability Datagram Congestion Control Protocol)[12]、基于SCTP 协议扩展的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]等。这些部分可靠传输协议一方面受到它们原本协议适用范围的限制；另一方面，它们大都也仅适用于特定应用，不具备通用性。

基于通用传输协议的改进的研究也相对匮乏。目前已有的通用的部分可靠传输协议有PRTP-ECN(Partially Reliable Transport Protocol using ECN)[18]。PRTP是为具有软实时要求的多媒体应用而设计。PRTP 提供部分可靠的服务，允许应用程序以一定程度的数据丢失为代价换取更高的吞吐率和更低的延迟。PRTP 是作为TCP 的扩展而开发，是基于接收端设计的协议。在PRTP 实现中，PRTP 允许应用程序指定0%到100%之间的可靠性级别，保证该应用程序保持其设置的可靠性级别。PRTP 能提供确定性的可靠度保证，它主要通过更改ACK 方案来调整重传策略。接收端为允许丢失的数据包发送“假”ACK，以“欺骗”发送端，从而减少重传次数，提高传输速率，但易导致TCP 的拥塞控制失效。“假的”ACK 反馈不能正确指示网络拥塞的情况，当实际出现网络拥塞的情况时，发送端仍然认为网络状况是良好的，不会马上对实际网络情况做出反应[19]。所以，基于ACK 反馈的拥塞控制机制并不适用于PRTP 协议。因此PRTP-ECN 选择使用ECN 标记来通知发送端网络拥塞情况，但这就必须要中间路由器的配合，限制了其可部署性。

现有的部分可靠传输协议，并不具备满足多应用类型差异化可靠传输的能力。所以，我们致力于设计一种新的通用的部分可靠传输协议，以供应用程序使用。这个协议既能提供确定性的可靠度服务，也能根据应用需求，自适应调整传输策略，提高传输效率。这个协议是基于发送端的端到端的传输协议，方便在现有的互联网基础设施内工作，不需要中间路由器特别配合，也易于部署。

2 差异化可靠传输控制机制设计

现有的部分可靠传输机制基本上是基于时间和单一类型应用进行重传策略的设计，并不具备满足多种应用类型差异化确定性可靠传输需求的能力。目前的部分可靠传输协议局限于对已有协议改进，受限于原有协议的适用范围，具有较大的局限性，不方便在网络中部署和使用。

因此针对应用差异化的确定性可靠传输需求，我们设计了一种新的差异化可靠传输控制协议-DRTP 协议，该协议能在满足应用可靠度需求的前提下，降低传输延迟、提高吞吐率。本节将详细介绍DRTP 的协议框架和差异化可靠传输控制机制的设计。

2.1 协议框架

DRTP 设计为一种通用的传输层协议，而不是仅针对某些特定应用设计。

DRTP协议基本原理如图1所示。在正常情况下，传输过程中未发生丢包时的操作与传统TCP 的运行流程大致一致，但当传输过程中发生报文丢失时，发送端会根据目前的传输情况，决策这个丢失的数据报文是否需要重传，若判断为不需要重传这个丢失数据报文，发送端马上通知接收端无需等待这个丢失数据报文并继续后续数据的传输；接收端收到发送端发送的决策信息便主动将已接收的数据递交给上层应用，前移接收窗口，更新确认信息ACK 值，将实际接收情况反馈给发送端以更新传输情况。这种机制可以防止传统TCP 中接收端因为长时间等待丢失数据包导致的队头阻塞问题。一些应用如多媒体应用，少量数据的丢失并不会影响它们的服务质量，但若是因为等待一些不重要的数据导致接收端无法将已接收到的应用数据及时向上层递交，这种情况会对应用的服务质量造成更大的影响。这种机制也适用于目前包含重传确认机制的其他传输协议。

2.2 可靠度计算

不同类型的应用数据的可靠度传输需求不尽相同。为了尽可能提高网络传输效率，兼顾数据传输质量和应用服务质量，因此需要在业务特性和服务需求的基础上，具体量化传输过程中的传输效果。传输效果的量化结果可以为传输方案带来有效反馈，由此调整传输策略，进一步优化决策过程。

现有的传输协议对于可靠度没有具体的量化标准，已提出的部分可靠传输协议采用简单的ACK 机制和时间机制，也没有对可靠度进行较好的量化。差异化可靠传输协议与传统传输控制协议区别在于其需要时刻感知当前可靠度与目标可靠度的情况，通过判别当前时刻网络传输可靠度与应用所需可靠度的差别，进而实现差异化的可靠传输控制机制。

DRTP 会在传输前先让上层应用确定一个应用的需求可靠度(required reliability level,rrl)，并在传输过程中在每次收到ACK 信息时更新当前可靠度(current reliability level,crl)来衡量当前传输情况，并与rrl 来比较看是否满足应用传输需求。但传输层不能完全了解具体的应用传输数据量，像PRTP 协议这种完全统计所有发送的数据来计算crl，在数据量大的情况下，计算量也会比较大，影响运行效率。所以我们采取一种基于一定数据量的周期性计算方式，确定一个计算周期，将整个传输过程以计算周期为单位分割成每一小段，以周期为单位保证传输情况满足rrl，最终整体传输也能满足rrl。当前可靠度crl的一种计算方式：

可靠度基于周期进行计算，其中，n为周期内数据报文传输个数，pk为第k个数据报文的接收情况指示符，当第k个数据报文成功接收时为1，否则为0，bk为第k个数据报文的字节数。方案中数据传输策略会基于crl 计算结果作为决策依据。

可靠度周期的设置可以根据上层应用传输的数据量和数据特征，自行设置。设置的周期值偏大些，一个周期内可进行主动丢弃处理操作的个数就会多些，传输控制可以更灵活；如果设置的周期值偏小，则可处理的数据报文个数也会较少，如果链路丢包严重，处理数量较易用完。

可靠度进行周期性计算优势在于可以保证此连接的数据传输过程中主动丢弃的数据报文均匀分布在每个周期内，避免出现连续主动丢弃数据的情况，保证每周期内数据传输的可靠度。可靠度一方面反映此连接可容忍数据丢失情况，反映当前周期内网络数据传输的稳定程度，另一方面也可以反映网络当前时刻拥塞程度。

2.3 重传控制机制

2.3.1 设计概述

DR-TP 协议提出了一种新的基于可靠度的报文重传控制机制，根据应用可靠度的要求来进行报文重传决策。

传统的TCP 协议没有考虑应用对可靠度的差异化需求，过于追求完全可靠，它没有关注到传输业务自身的特性，对所有数据都是基于统一标准进行操作。许多丢失报文虽然可以通过重传机制恢复丢失，但若在数据传输过程中出现数据报文丢失时，接收端不会立即将其它已接收的数据递交给上层使用，直至缺失的数据报文成功接收之后，才将所有已接收数据递交给上层应用。如果丢失的数据报文本身并不具备重要度，即使丢失也不会对上层服务质量产生特别大的影响，那么完全可靠的数据传输就会产生比较大的传输时延，且可能会影响上层应用服务质量[19-20]。

TCP 的重传机制有快速重传和超时重传这两种方式。快速重传通过重复ACK 来判断丢失，能及时恢复丢失数据，它本身并不会对TCP 的传输效率造成太大影响。但超时重传的触发会显著降低TCP 传输性能，因为超时情况的出现一般是由于传输中批量的数据丢失造成发送端不能及时收到确认信息而一直处于等待状态。超时的触发需要发送端等待重传超时(Retransmission Timeout,RTO)，RTO 一般是RTT 的2-4 个数量级，等待时间较长。而且超时重传会使TCP 进入Loss 状态，在此状态下，发送端会将发送窗口内所有未确认的数据报文标记为丢失，拥塞窗口重新从1MSS 开始增加，发送端在丢失数据全部确认前不会继续发送新数据，导致TCP 传输停滞，严重影响TCP 传输效率[21]。

对超时产生原因进行细分，主要导致超时重传触发的原因是双重重传和尾部重传这两种情况。双重重传是指通过快速重传或超时重传的重传数据再次丢失或延迟，进而导致新的超时的触发。在易损网络的条件下，这种情况比较容易触发[21]。尾部重传主要发生在流的尾部，如果流的尾部数据丢失，TCP 发送端可能会因为无法收到足够的重复ACK 触发快速重传操作，只能通过超时重传恢复丢失数据[22]。若发送窗口内出现大量数据报文的连续丢失或者发送窗口过小，也可能导致TCP 发送端因收不到足够的重复ACK 来触发快速重传而等待超时的情况。

因此我们提出了一种新的重传控制机制来减少超时触发的次数。该机制通过降低对数据传输可靠性的要求，主动降低部分丢失数据的可靠度要求，避免因这一部分数据的丢失造成数据流阻塞，导致用户应用体验的降低。新设计的重传控制机制保留快速重传机制，并提出了一种新的通知机制来灵活控制可靠度情况。新设计的机制主要通过引入比超时定时器更积极的定时器，称作通知定时器，减少因丢包导致超时触发产生的负面影响，它对可能导致超时的丢失报文在当前周期满足可靠度的情况下，允许不重传已丢失数据报文，通知接收端跳过丢失数据，前移接收窗口，返回新的ACK 值，使发送端继续发送新的数据报文。

2.3.2 通知机制

发送端与接收端在握手建立期间确定差异化可靠功能的开启，若不支持也可退回到原来的传输机制。在传输过程中，发送端发送数据报文时，同时开启通知定时器和超时定时器，并在每次收到新的ACK 信息后及时更新当前可靠度值，基本操作与传统TCP 流程一致。但当发送端在传输过程中一段时间内未收到ACK 信息的更新时，发送端便会通过通知定时器的触发监测到这一事件，发送端先根据当前传输可靠度来判断当前数据是否需要重传。发送端若判断为当前不需要重传数据，允许接收端主动放弃该数据，发送端便会构造一个携带丢包处理信息的通知报文发往接收端。接收端在收到这个通知报文后，主动更新确认点信息，把未接收到的数据报文当作是正常接收到一样处理，主动前移接收窗口，并向发送端返回最新的ACK 信息和处理信息以用作发送端的可靠度更新和发送新数据。接收端及时将已缓存的数据及时提交到上层应用，减少了上层应用等待数据的时延。

2.3.3 发送端控制

发送端在数据发送时启动通知定时器，当一段时间内未收到ACK 的更新时，通知定时器触发进入通知报文处理流程（见算法1）。发送端先检查当前传输状态是否满足通知报文发送的条件，若不满足条件，则等待一个RTT 后再次进入该函数检查传输状态是否满足通知报文发送条件；满足条件的话再根据当前传输可靠度情况判断当前数据是否需要重传。若当前传输情况满足应用可靠度需求(crl>=rrl)，发送端允许主动放弃丢失的数据报文，向接收端发送一个携带丢包处理信息的通知报文；若不满足应用可靠度需求，则等待超时触发重传。

如图2 所示通知机制触发的两种场景，通知机制的触发条件需要满足下面两个条件之一便可触发通知机制流程。第一个条件是当前报文(cur_pkt)已经被重传过。我们设计的机制仍使用快速重传机制，如果在一定时间内能通过快速重传恢复丢失的数据报文，便不会进行其他操作。但若重传的数据报文再次丢失，按照原来TCP 机制，发送端只能等待RTO 超时触发，这会影响传输效率。因此，若该数据报文在通知定时器触发时已经被重传，发送端会根据当前可靠度情况判断是否允许主动放弃该数据，继续后续数据传输。第二个条件是发送端当前已发送但未确认的数据报文个数（packets_out）小于阈值α。若传输过程中出现连续批量的数据报文丢失，发送端就可能因为收不到足够数量的重复ACK 而无法通过快速重传操作恢复丢失数据报文，最终需要等待RTO 触发超时重传。所以当通知定时器触发时，发送端发现目前已发送且未确认的数据量少于一定数量时，发送端根据当前传输可靠度情况，判断是否需要重传该范围内未确认的数据。α 默认取10，该值的设置具体需要因使用的不同拥塞算法而进行调整。

图2 通知机制触发的两种场景Fig.2 Two scenarios triggered by the notification mechanism

若当前发送端不满足这两个条件中的任意一个，便会等待1 个RTT 后再次探询当前状态是否满足条件。当发送端当前状态满足两个条件中任意一个就可继续通知机制流程。发送端还需根据当前周期是否满足应用可靠度要求来判断是否允许主动通知接收端放弃未接收数据。如果当前周期满足应用可靠度要求，发送端向接收端发送通知报文，通知接收端允许放弃当前周期内未接收数据，主动前移接收窗口，更新ACK 信息，发送端继续发送后续数据。如果当前周期不满足应用可靠度要求或接近应用可靠度要求的底线，发送端判断当前传输情况不能满足应用可靠度要求，不允许接收端主动放弃未接收数据，发送端通过传输协议的重传机制重传数据来保证应用可靠度要求。

通知机制设置一个通知定时器，在当前实现中，将定时器设置为1.5 个RTT(Round-Trip Time)。通常情况下，发送端至多能在2 个RTT 内收到数据报文的确认。若传输过程中未发生报文丢失，发送端应该能够再约一个RTT 内收到数据报文的确认；传输过程中如果发生报文丢失，若发送端能触发快速重传机制且重传数据顺利到达接收端，这期间总共需约1.5 个RTT 的时间，收到数据报文的确认就共需要约2 个RTT 的时间。发送端若触发了快速重传机制重传数据后，发送端也会马上发送一个通知报文，如果重传的数据报文在传输过程中再次丢失，接收端也能马上收到通知报文，及时进行丢失数据的处理；如果重传的数据报文顺利到达接收端，那么接收端即使收到后面的通知报文，也不会对接收端造成影响。如果传输过程中发生了数据丢失且发送端未能触发快速重传，那么发送端在1.5 个RTT 后也能及时响应数据丢失事件，通知接收端处理丢失数据。

RTT 是使用RFC 2988[23]的RTT 估计算法进行计算。1.5 的设置是因为从发送端第一次发送这个数据报文，至发送端收到因这个数据报文的丢失产生的三次重复ACK 而触发快速重传，时间约1 个RTT；发送端重传当前数据报文且重传的数据报文到达接收端的时间约0.5 个RTT。全过程总共约1.5个RTT。发送端设置为在1.5个RTT时发送通知报文。通知报文本身具备探测性质，可以探测重传是否成功，若重传成功了，接收端就不做其他操作，若不成功就处理丢失数据。

本文提出的差异化可靠传输控制机制作为一种新的通用的传输层控制机制，它的实现不依赖于其他协议，可以独立实现和运行。在实际的开发实现过程中，为便于保留TCP 协议的拥塞控制机制等优点，本文选择基于TCP 协议，对其可靠传输控制机制替换成本文所提出的差异化可靠传输控制机制，以此实现DRTP 协议。本文通过setsockopt()函数来实现应用层对DRTP 协议的设置，应用层应用可以通过该函数进行DRTP 协议的启用和应用可靠度、可靠度计算周期等DRTP 协议相关参数的设置。

在通知机制流程中，若发送端允许进行丢包处理的操作，发送端便会发送一个通知报文给接收端，通知报文复用丢失数据报文序列号，去掉原先的数据负载，只通过选项保留通知信息。通知报文采取单独发包的方式，操作灵活且便于扩展，因没有数据负载只有报头信息和其携带的通知信息，比较轻量，不会给网络带来太大的负载。通知报文选项信息格式参见图3。通知报文信息包含当前周期允许的最大可丢包数目和当前周期的序列号范围。为了防止出现通知报文丢失使接收端无法处理丢失数据报文的情况，发送端也单独给通知报文设置一个定时器，若1 个RTT 内未收到接收端返回的ACK 信息，便会进行通知报文重传操作。一般情况下，通知报文到达接收端且发送端收到接收端返回的新的确认信息最多需要约1 个RTT 的时间。若在此期间内，发送端未收到新的ACK，就会判断通知报文可能丢失了，这就需要重传通知报文给接收端。

图3 发送端通知报文选项结构Fig.3 Sender notification message option structure

通知报文选项参数含义：

·Kind：标明该选项是通知报文选项。这个参数标记此TCP 报文是通知报文。接收端通过这个Kind值来识别是否接收到通知报文。

·Length：标识整个选项长度为8 个字节。

·DroppableCount：告知接收端当前发送端周期范围内可允许主动丢包处理的最大数据报文个数。

·EndSeq：告知接收端允许主动丢包处理的序列号的最大界限，通知报文序列号复用当前发送窗口内第一个数据报文的序列号Seq，可丢包处理范围为[Seq,EndSeq]，至多可丢DroppableCount 个数据报文。

2.3.4 接收端控制

通知机制中接收端的操作如算法2 所示。接收端通过报文首部里选项的Kind 字段来判断这个TCP报文是否是通知报文。当接收端接收到通知报文时，接收端根据通知报文选项内携带信息遍历接收窗口，处理窗口内丢失报文并记录主动处理的丢失数据报文信息，把未接收到的数据报文当作是正常接收到一样处理，主动前移接收窗口，将已接收到的数据主动向上层递交，更新ACK 信息并将实际丢失数据报文处理信息添加到ACK 选项里，随ACK 报文一起反馈给发送端，用以准确计算可靠度。接收端ACK 反馈报文信息选项格式见图4。

图4 接收端ACK 反馈报文选项结构Fig.4 Receiver ACK feedback message option structure

ACK 反馈报文选项设计的参数含义：

·Kind：标明该选项是ACK 反馈报文选项。这个参数标记该TCP 报文是接收端发给发送端的ACK反馈报文。

·Length：整个选项长度为10 个字节。

·StartSeq：接收端主动处理丢失数据报文的起始序列号。

·DropSize：接收端主动处理丢失数据报文起始序列号StartSeq 到ACK 范围内总共处理的数据量。

3 实验性能评价

本文先通过NS3 仿真平台实现DRTP 机制，测试机制的效果，并在Linux 上进行系统实现和部署，验证DRTP 的实际传输效果。

3.1 仿真实验测试

为了验证DRTP 重传控制机制的效果，我们先基于NS3 网络模拟器开发实现了DRTP 协议，并与TCP 协议进行对比实验。实验采用的系统为Ubuntu20.04。TCP 和DRTP 的拥塞控制算法都设置为NewReno。我们在不同丢包率、不同时延这两个条件下进行实验测试。

实验网络拓扑如图5 所示。实验拓扑图中其中客户端基于NS3 中BulkSendHelper 应用类实现数据流发送，服务器基于NS3 中PacketSinkHelper 类实现数据接收，丢包率设置基于NS3 中RateErrorModel差错模型类实现。实验测试的参数如表1 所示。双端缓冲区都设置为2*BDP(带宽时延积,bandwidthdelay product)，路由缓冲区设置为1.2*BDP。上层应用指定应用可靠度需求为95%。实验通过传输100MB 数据进行测试。

图5 NS3 仿真网络拓扑Fig.5 NS3 simulation network topology

表1 NS3仿真实验参数设置Table 1 NS3 simulation experiment parameter settings

3.1.1 不同链路丢包率下性能测试

这组实验里瓶颈带宽设置为100Mbps，时延设置为40ms，链路丢包率分别设置为0.1%、1%、2%、3%、4%、5%、8%。图6 分别显示DRTP 和TCP 在不同链路丢包率下的传输完成时间。结果明显能看出采用了通知机制的DRTP 协议比较TCP 能更早完成传输任务。链路丢包率越大，DRTP 提升的效率越明显。从表2 中可以看到，在链路丢包率0.1%至8%的网络场景下，DRTP 传输基本都保证了应用可靠度需求。

图6 不同链路丢包率下传输完成时间Fig.6 Transmission completion time under different link loss rates

在表2 中可以看到TCP 会因为丢包触发较多的超时重传，传输效果也明显会受到超时触发的影响。DRTP 明显减少了超时重传的触发次数，DRTP的快速重传的触发次数相较TCP 也有所减少，降低了DRTP 由于重传触发影响到传输效率的概率。在链路丢包率高的场景里，DRTP 的通知机制可以更有效地提高传输效率。DRTP 的通知机制设置的通知定时器约有1.5RTT。一般情况下，传输过程中因丢包触发快速重传机制且重传数据到达接收端，整个过程总共需花费约1.5 个RTT 的时间。发送端在触发快速重传且重传了数据报文之后不久，也会随之发送一个通知报文。如果重传的数据报文丢失，接收端也能马上收到发送端后面发送的通知报文，及时处理丢失数据；如果重传的数据报文顺利到达接收端，那么接收端收到后面的通知也不会产生影响。如果传输过程中发生了数据丢失且未能触发快速重传，发送端在1.5RTT 时也能及时响应数据丢失事件，通知接收端处理丢失数据。因此，结果表明DRTP的通知机制在丢包率高的场景下可以有效改善传输性能。

表2 不同链路丢包率下DRTP 传输情况统计Table 2 Statistics of DRTP transmission under different link loss rates

3.1.2 不同RTT 下性能测试

这组实验里瓶颈带宽设置为100Mbps，链路RTT 分别设置为20ms、40ms、100ms、180ms、300ms，链路丢包率分别设置为4%。图7 分别显示DRTP 和TCP 在不同RTT 下的传输完成时间，结果显示采用了通知机制的DRTP 协议比TCP 能更早完成传输任务。表3 显示DRTP 实际传输可靠度，DRTP 也基本满足应用可靠度需求。在表3 中DRTP相较TCP 明显减少了超时的触发次数，一定程度上提升了传输效率。不过，实验结果也可以看出，在不同RTT 下，DRTP 的提升效果不会受RTT 太大影响。

图7 在不同RTT 下传输完成时间Fig.7 Transmission completion time under different RTTs

表3 不同RTT 下DRTP 传输情况统计Table 3 Statistics of DRTP transmission under different RTTs

3.2 实际系统实验测试

本文也在Linux 内核上进行DRTP 机制的开发实现并部署在Ubuntu 系统上，设备具体参数如表4所示。

表4 实验设备参数Table 4 Parameters of experimental equipment

本实验设置两台PC 电脑分别作为发送端和接收端。实验通过TC(Traffic Control)工具产生网络丢包和延时。实验中的应用可靠度要求设置为95%，可靠度计算周期设置为每1000 个报文进行计算。系统拥塞算法默认使用Cubic，系统参数设置都采用系统默认值。上层应用程序使用基于BSD socket API编写的文件传输工具，本实验使用43.5MB 大小的文件传输进行测试。

3.2.1 不同丢包率下性能测试

本组实验中发送端通过TC 设置时延为30ms，链路丢包率分别设置1%、2%、3%、4%、5%、8%、10%进行测试。表5 显示了不同丢包率下DRTP 实际接收的数据量，结果显示DRTP 在不同丢包率下传输基本都能保证其设定的应用可靠度。图8 分别显示了DRTP 和TCP 在不同丢包率下的传输完成时间，结果表明相较TCP，DRTP 在丢包率高的场景下能减少传输完成的时间，有效提升传输效率。测试结果与前面仿真的效果一致，符合DRTP 的预期效果。

表5 不同链路丢包率下DRTP 实际传输可靠度Table 5 Actual DRTP transmission reliability under different link loss rates

图8 在不同链路丢包率下传输完成时间Fig.8 Transmission completion time under different link loss rates

3.2.2 不同RTT 下性能测试

这组实验中发送端通过TC 设置链路丢包率为4%，链路RTT 分别设置为20ms、40ms、100ms、180ms、300ms 进行测试。根据表6 显示，DRTP 在不同RTT 下也都能保证其应用可靠度。根据图9 显示，系统测试效果也与前文仿真在不同RTT 下的测试效果接近。DRTP 能较TCP 更早完成传输任务，但其在不同RTT 下的提升效果相对有限。

图9 在不同RTT 下传输完成时间Fig.9 Transmission completion time at different RTTs

表6 不同RTT 下DRTP 实际传输可靠度Table 6 Actual transmission reliability of DRTP under different RTTs

4 结论与展望

在本论文，我们提出了一种新的通用的部分可靠传输协议DRTP，它为上层提供差异化和确定性的可靠性服务。DRTP 可以在满足应用所需的可靠性的前提下，提升传输效率。而且它作为一种通用的纯端到端传输协议，也易于部署使用。本论文中DRTP 的重传控制机制采用通知机制协调发送端和接收端之间的窗口滑动，避免超时重传的触发，减少在当前传输可靠度满足应用可靠度需求时的不必要的数据重传次数，提高传输效率。性能评估表明，DRTP 的重传控制机制在多种网络条件下都能正常工作。在具有丢包率的链路上，DRTP 在保证应用可靠度要求的前提下，减少了重传触发次数，避免了超时的触发，进而提升了传输效率。本文也基于Linux系统进行DRTP 机制的开发实现，并进行系统测试，验证其传输效果，DRTP 的性能评估结果也如预期，相较TCP，在丢包率高的场景下，能明显提升传输效率。下一步配合上层应用的特性，设计更加精细化的传输控制策略，为了更加适应不同应用的传输需求，加强传输层与应用层的控制信息交互，实现更加精细化的传输控制。

利益冲突声明

所有作者声明不存在利益冲突关系。