测得的是一次往返过程
发送方记录发送时刻，并在相应确认到达后求时间差。测量包含去程、回程以及所用反馈机制引入的时间，不只是两台机器之间的物理传播。
同一路径的样本也会变化，原因可能包括排队、调度和确认延迟。单次低值或高值不足以描述所有后续请求，更不能直接代表服务器完成某项业务的耗时。
平滑估计与超时不是同一个值
RFC 6298的TCP重传计时算法同时维护平滑往返估计与变化幅度，再据此计算重传超时。这样可以让计时适应网络变化，而不是把最新一次样本不加余量地当成截止时间。
如果超时过短，仍在路上的数据会被误判丢失并重传；过长又会延后真实故障恢复。协议因此在响应速度与避免不必要重传之间保留明确的估计规则。
参考：[1]
重传与方向造成的歧义
同一数据重传以后，收到确认可能难以判断它对应第一次还是后来一次发送。Karn算法避免用这种含糊样本直接更新估计；TCP时间戳机制在相应条件下可以帮助消除歧义。
RTT同时包含两个方向，所以除以二不是精确测量单向延迟的方法。若要解释网页速度，还要把名称查询、连接建立、服务器处理和内容下载分别放回相应阶段。