我正在读一本教科书，上面写着：
让我们通过考虑 TCP 如何估计发送方和接收方之间的往返时间来开始我们对 TCP 定时器管理的研究。这是按如下方式完成的。一个段的样本 RTT，表示为 SampleRTT，是从发送段（即传递到 IP）到接收到段的确认之间的时间量。大多数 TCP 实现一次只进行一次 SampleRTT 测量，而不是为每个传输的段测量一个 SampleRTT。也就是说，在任何时间点，SampleRTT 仅针对已传输但当前未确认的段之一进行估计，从而导致大约每个 RTT 一次的 SampleRTT 新值。
我在这里有点困惑，黑色的文字说它不会为每个段测量 SampleRTT，然后它说 SampleRTT 的新值将大约是每个 RTT 一次，这听起来仍然像 TCP 为每个段测量 SampleRTT平均 RTT？
从发送者的角度来看，发送窗口中的段都同时“处于飞行中”。因此，与其尝试跟踪每个段的 RTT，不如一次只跟踪一个段。由于 RTT 需要发送一个段并接收 ACK，因此每个 RTT 采用一个样本。
如果您要跟踪每个段的 RTT ，那么发送窗口中的段数 = 窗口大小 / 每个 RTT 的段大小样本 - 这实际上超出了您的需要，因此会浪费内存和处理能力。
正如 Jeff 在他的回答中指出的那样，今天的实现通常使用 TCP 时间戳选项来简化 RTT 测量。时间戳提供更细粒度的信息，处理开销更少。请查看 Jeff 的链接，因为它们非常值得一读。
我建议您从阅读 RFC 1323 §3 RTTM: Round-Trip Time Measurement开始，这是对这个问题的精彩介绍，很好地说明了非常聪明的人在这个问题上工作了多长时间，以及自 1992 年以来变化不大。
Linux tcp_input.c源代码还包含许多有用的评论和一些关于该主题的较新学术论文的链接。
如果您检查自己的工作站，使用tcpdumpor wireshark，您会发现您的计算机交换的大多数 TCP 段都有一个时间戳选项。这允许更频繁的 RTT 测量为用于计算 RTO 的平滑 RTT 提供更好的输入，并且复杂性更低。
如果没有 TCP 时间戳，系统必须执行 Zac67 描述的操作，相关问题/限制在上述链接和所有关于该主题的文献中都讨论过。