TCP 时间戳妙用_tcp时间戳

盗图说个场景：
TCP in Painful Detail

这种场景怎么应对？怎么办？

其实我想描述的场景没这么复杂，它只是：

• 正向 Data 路径与反向 ACK 路径不是同一条路径，反向路径更坎坷。
• 正反向路径是同一条，但 ACK 路径上的策略配置与 Data 路径不同。

很多转发设备(比如 Wi-Fi )以与 Data 不同的方式对待 ACK，如乱丢 ACK，暂存 ACK 并聚集，ACK 优先排队等。然而 RTT 是包含 ACK 半程的，无论哪个半程发生抖动，TCP 发送端会无差别记账，因为它分不清哪个半程发生了抖动。

蹲了个厕所，想了个办法。借 TCP 时间戳可以区分两个半程的抖动。跟踪两个变量的方差即可：

• Data 半程时间差：D1 = ACK.TSval - ACK.TSecr。
• ACK 半程时间差：D2 = Now - ACK.TSval。

不用关心两端连接时间不同步，因为只需关注 D1 和 D2 两个变量随时间的变化情况而无需关注它们的值。

如果 D1_var 很大，说明 Data 半程发生了带宽争抢，buffer 堆积，此时需要收敛一下控制拥塞，反之，如果 D2_var 很大而 D1_var 很小，说明 Data 半程很稳定，没有拥塞，那就继续激进发送吧(但别太狠)。

若没此能力，仅凭 TCP 现有实现，RTT 抖动时，即使是 ACK 半程造成的抖动，也会一并记账到拥塞信号，此 RTT 会对拥塞控制算法施加影响，从而影响发送效率。

通过 TCP 时间戳，可更精细区分两个半程的延时抖动情况，之前说过，更准确的拥塞控制需要更多的信息，归根结底是需要 TCP 数据包更强的表达能力，多数 TCP 支持时间戳这没错，但如何利用这个时间戳，用尽它的信息熵，还是有更多玩法的。

半下午急着拉肚子，顺带了一个 issue，想了一个好办法识别 TCP 两个半程的延时抖动，挺不错的。我不知道这个好办法是不是我的原创，但至少在 Linux TCP 实现里还没有看到，别的实现我也没看过，不管怎样，想法是非常简单的，就是充分利用信息。我自己并不做这个领域，所以就简单记录下来几句话，哪天再有小长假了，验证一下试试看。

浙江温州皮鞋湿，下雨进水不会胖。