前言
我们已经在很多地方了解TCP 的功能和常用字段。但是TCP 传输发生的异常情况总是让我们很棘手，不知改如何处理。陷入迷茫之中。本文章只针对RTT 和RTO 做了解。
描述
RTT (Round Trip Time)
对于 Ping 和 Traceroute，这测量了发送 Ping 数据包和取回 ICMP 数据包之间的往返时间。对于 TCP 连接，它非常相似；它测量发送数据包到从目标主机获得确认数据包的时间。
在TCP 三次握手时:
1.计算机 A 向计算机 B 发送 TCP SYN 数据包（这是 RTT 计时器开始的地方）
2.计算机 B 向计算机 A 发送 TCP SYN-ACK 数据包（这是 RTT 计时器结束的地方）
3.然后计算机 A 向计算机 B 发送一个 TCP ACK 数据包（TCP 连接现已建立！
如果您使用wireshark 来捕获和分析数据包，您可以通过tcp.analysis.ack_rtt 过滤字段获取
很容易理解，对吧？但是当数据包丢失时会发生什么？ TCP 协议具有用于确保接收数据包的内置逻辑。因此，为了确保数据包被接收，发送方将重新发送数据包给对方。
我们大多数人都非常了解的重传的逻辑。在初始数据包序列上，有一个称为重传超时 (RTO Retransmission TimeOut) 的计时器，其初始值为三秒。每次重传后，RTO 的值加倍，计算机最多重试 3 次。这意味着如果发送方在 3 秒（或 RTT > 3 秒）后没有收到确认，它将重新发送数据包。此时，发送者将等待六秒钟来获得确认。如果发送方仍然没有得到确认，它将第三次重新发送数据包并等待 12 秒，此时它将放弃。3>6>12
虽然这是 RTO 已广为人知，但它并不是 TCP 中唯一重传处理逻辑。 TCP 协议的设计考虑到两台计算机之间的连接是不一样的——因此在两台计算机靠近的情况下，重传应该更快。这就是 RTT 开始影响 RTO 的地方。
TCP 连接建立时，有一个 RTT 值，RTO 将根据 Smoothed RTT (SRTT) 计算进行调整。该计算将平滑因子应用于 RTT，从而创建有利于保证预测数据包往返时间。 SRTT 公式为：
SRTT(ALPHA * SRTT) + ((1-ALPHA) * RTT)
ALPHA = smoothing factor between .8 and .9 平滑因子在0.8 到0.9 之间
RTT = Round Trip Time
计算出 SRTT 后，它将用作主机在重新传输段之前等待多长时间的决定因素，其计算如下 RTO：
RTO = min[UBOUND, max[LBOUND(BETA * SRTT)]]
UBOUND = upper bound on the timeout (e.g. 1 minute) 超时上限值，例如1分钟
LBOUND = lower bound on the timeout (e.g. 1 second) 超时下线值 例如1秒
BETA = delay variance factor (e.g. 1.3-2.0) BETA = 延迟方差因子（例如 1.3-2.0）
如果在发送段后没有收到响应包，则每次重传后 RTO 加倍，在 RTT 计算中忽略前一次重传。这种策略被称为卡恩算法，被认为是非常有效的，尤其是在数据包延迟较高的区域。
请记住，新的 RTO 是基于 SRTT 计算的，而 SRTT 是基于 RTT 的，这会导致在遇到网络延迟时非常有效的调整。最低 RTO 会因操作系统（或 TCP 实现）而异；在 Windows 中为 300 毫秒，在 Linux 中为 200 毫秒。
在 Web 浏览器的情况下，计算机会打开到同一主机的多个连接。对于 Windows，每个连接都有自己的 SRTT 计算，因此一个连接不会影响另一个连接。对于 Linux，可能是相同的。
那么RTO 很大程度取决于RTT 的大小来进行计算。对于RTT 比较高的场景，我们需要最相应的优化措施。
