对于下面附加的tcptrace输出(取自RTT stats下的站点http://tcptrace.org/manual/index.html )
1 arg remaining, starting with 'indica.dmp.gz'
Ostermann's tcptrace -- version 6.4.5 -- Fri Jun 13, 2003
153 packets seen, 153 TCP packets traced
elapsed wallclock time: 0:00:00.128422, 1191 pkts/sec analyzed
trace file elapsed time: 0:00:19.092645
TCP connection info:
1 TCP connection traced:
TCP connection 1:
host a: 192.168.0.70:32791
host b: webco.ent.ohiou.edu:23
complete conn: yes
first packet: Thu Aug 29 18:54:54.782937 2002
last packet: Thu Aug 29 18:55:13.875583 2002
elapsed time: 0:00:19.092645
total packets: 153
filename: indica.dmp.gz
a->b: b->a:
total packets: 91 total packets: 62
. . . . . .
. . . . . .
throughput: 10 Bps throughput: 94 Bps
RTT samples: 48 RTT samples: 47
RTT min: 74.1 ms RTT min: 0.1 ms
RTT max: 204.0 ms RTT max: 38.8 ms
RTT avg: 108.6 ms RTT avg: 8.1 ms
RTT stdev: 44.2 ms RTT stdev: 14.7 ms
RTT from 3WHS: 75.0 ms RTT from 3WHS: 0.1 ms
RTT full_sz smpls: 1 RTT full_sz smpls: 1
RTT full_sz min: 79.5 ms RTT full_sz min: 0.1 ms
RTT full_sz max: 79.5 ms RTT full_sz max: 0.1 ms
RTT full_sz avg: 79.5 ms RTT full_sz avg: 0.1 ms
RTT full_sz stdev: 0.0 ms RTT full_sz stdev: 0.0 ms
post-loss acks: 0 post-loss acks: 0所以我的问题是,如果你看到a->b的RTT平均值和b->a的RTT平均值,那么它们的值有很大的不同。我不期望它们是完全相同的,但差别是相当大的。我认为在计算RTT的方式背后发生了一些事情,我不确定。
发布于 2011-09-29 21:45:34
摘要:根据捕获位置的不同,确保查看对话的正确部分
This answer解释说,tcptrace使用数据段的时间戳与确认它的确认确认的时间戳之间的差值来计算RTT。这意味着 RTT计算将取决于您捕获跟踪的位置
例如,如果您在节点A上捕获数据包,那么在看到来自节点B的相应数据段之后,您几乎会立即看到A的ACK,因此在B->A数据段中看到的RTT值非常低。对于A->B网段,您将测量真实的RTT,因为在看到来自A的网段和来自b的相应ACK之间发生了一次“真实的”往返。
如果你在节点b上进行捕获,情况将会相反,如果你在中间的某个地方进行捕获,那么“真实”RTT将大致等于A->B + B->A。
发布于 2011-09-30 16:53:31
RTT计算不是在发送器节点进行的。它们可能是在沿途的某一点上造成的。a->b和b->a不一定在发送方和接收方节点之间。
它可以是这样的
其中S是发送方,R是接收方,A是S和R之间的某个点。a->b可以表示从A到R的S--A--------->R,而b->a可以表示从A到S的RTT。
https://stackoverflow.com/questions/7558117
复制相似问题