TCP RTT 采集方法值得一提：
- 正常状态采集的 RTT 因加入了接收端 Delayed ACK，积累 ACK 等原因而偏大。
- Disorder，Recovery 状态采集的 RTT 相对准确，通过 Timestamps，SACK 采集。
平时抓包，Wireshark 如何解析 RTT 散点呢？如下图(注意，发送端抓包)：
这些 RTT 散点如何采集的呢？如果手算，步骤如下：
- 点取一个 ACK 报文，记录其到达时间 T1。
- 查找上一个 ACK 报文的 ACK 字段 S。
- 定位序号 S 的报文，记录其发送时间 T2。
- T1 - T2 即序号 S 报文的 RTT 散点。
Linux TCP 也和 Wireshark 一样采集 RTT，原理图如下：
该采集结果包含接收端延迟，包括不限于 Delayed ACK，积累 ACK，LRO/GRO 。
相对精确的 RTT 需在 Disorder，Recovery 状态采集：
采集就是这样，至于计算就是各种移动指数平均了。
事情还有另一半。接收端如何采集 RTT。
对单向传输，接收端不发送任何数据，接收端仅靠收到的信息估算 RTT 的原理如下：
- 理论上接收端在一个 RTT 接收一个 rwnd 的数据。
收到 rwnd 数据的时间即估算为 rcv_rtt。
考虑到发送端由于 app limited 导致了 Delay，或由于拥塞而 cwnd limited，上述原理估算的结果偏大。有一种校准手段，即使用 Timestamps 选项的 tsecr 校准。原理如下：
- 接收端 ACK 的 tsval 字段会在下一个发送端发送报文的 tsecr 字段 echo 回来。
设 rwnd 估算的 rcv_rtt 为 R1，校准的 RTT 为 now - tsecr = R2，若 R2 < R1，则用 R2 作为 rcv_rtt。
洋洋洒洒这么一篇，只是顺便。
还是遇到了精度问题，在 IDC 环境，ms 精度的 tsecr 会使 rcv_rtt 偏大，而 Linux TCP 需要 rcvbuff 至少要能容纳 BDP，偏大的 rcv_rtt 会导致偏大的 BDP，进而通告较小的 rwnd 影响发送效率。
浙江温州皮鞋湿，下雨进水不会胖。
