tcp协议系列文章（3）：TLP算法

最新推荐文章于 2024-05-10 10:00:00 发布

aflyeaglenku

最新推荐文章于 2024-05-10 10:00:00 发布

阅读量1.9k

点赞数

分类专栏：网络编程文章标签： tlp tcp

本文为博主原创文章，未经博主允许不得转载。（合作洽谈请联系QQ：1010316426）

本文链接：https://blog.csdn.net/aflyeaglenku/article/details/73198575

版权

网络编程专栏收录该内容

49 篇文章 4 订阅

订阅专栏

一、起因

近日在用物理损伤仪对公司无线网络相机进行测试时抓到一个数据包，包含有如下的tcp交互过程：

抓包命令为tcpdump -i any -vv -w p.pcap

因为抓的是所有网卡，未做任何过滤，且tcpdump也没有dropped packet。因此上面的抓包是完整的。

从图中可以看到，交互双方是192.168.139.50和1.2.3.4（用以指代对端ip）。在192.168.139.50未发送sack，也没有达到默认的超时重传超时时间，但是1.2.3.4却发送了一个重传包。而且发生这种重传的实际也不固定，没有规律可循。

于是在网上搜索了一番，发现了一个叫做TLP的算法。简单介绍一下。

下面内容的原文在http://perthcharles.github.io/2015/10/31/wiki-network-tcp-tlp/ 对原作者表示感谢。

关于TLP的RFC文档可在https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 下载到。该算法有两个版本，这个连接是较新的版本。

二、TLP算法

TLP全称是TCP Tail Loss Probe。

Early Retransmit机制解决了dupack较少，无法触发快速重传的问题。但是如果发生了尾丢包，由于尾包后面没有更多的数据包，也就没有办法触发任何的dupack。为解决这种尾丢包的问题，Google的几位大神提出了TLP算法。通过TLP算法，发送一个loss probe包，来产生足够的SACK/FACK的信息来触发RF。根据Google的测试，TLP能够有效的避免较长的RTO超时，进而提高TCP性能。

TLP基本策略

TLP算法会在TCP还是Open状态的时候，设置一个Probe TimeOut (PTO)。
当链路中有未被确认的数据包，同时在PTO时间内未收到任何ACK，则会触发PTO超时处理机制。
TLP会选择传输序号最大的一个数据包作为tail loss probe包，这个序号最大的包可能是一个可以发送的新的数据包，也可能是一个重传包。
TLP通过这样一个tail loss probe包，如果能够收到相应的ACK，则会触发FR机制，而不是RTO机制。

触发超时机制的常见场景
这些case还是用大神们的原文描述比较准确:)

a. Drop tail at the end of transactions.
b. Mid-transaction loss of an entire window of data or ACKs.
c. Insufficient number of duplicate ACKs to trigger fast recovery at sender.
    -- 基本被Eearly Retransmit机制解决了
d. An unexpectedly long round-trip time(RTT), such that the ACKs arrive after
   the RTO timer expires.
    -- F-RTO机制通过检测spurious retransmission，能够尽量的undo RTO造成的影响

Google Web servers上面，将近70%的重传是RTO超时重传，只有30%是Fast Recovery重传。
同时还有数据表明，96%的RTO超时重传是在没有收到任何dupack的情况下发生的。
没有到任何dupack就意味着FR和ER机制都是无法生效的。

（笔者注：换句话说，TLP算法最初的构想来自于统计数据！）

RTO与RTT的比值分布

Googler们还收集RTO/RTT的分布，来了解RTO值到底比RTT值大多少。下面是统计结果

Percentile      RTO/RTT
50%             4.3
75%             11.3
90%             28.9
95%             53.9
99%             214

根据这个数据，显然这是一个CDF的统计。也就是说，50%的流，RTO/RTT小于4.3，75%的流，RTO/RTT小于11.3
不过反过来看，有50%的流RTO/RTT超过4.3，25%的流RTO/RTT超过11.3。
不过这个数据Googler并没有进一步的解释，有很多疑问在里面。
RTO的min值默认是200ms，这数据里面的是多少？这个数据里面是否同时包含了internet-face流和local-face流。
比如说，local-face流的rtt一般很小，常见值就是1.875ms，而min RTO值200ms的话，显然RTO/RTT很容易超过100
不过话说回来，数据来看，local-face的流应该没有包括，但是min RTO就不清楚了。

Googler认为”Such large RTOs make a huge contribution to the long tail on the latency statistics of short flows.”
这点如果结合TLP考虑的情景，推断确实合理。

那将RTO的计算值设置的较小一点如何？可能会造成两个问题：
a. spurious retransmission
b. 更多的RTO => cwnd=1

TLP试图解决的方式是将”尾丢包+RTO”这种case转换为”尾丢包+尾探测+FR”。