使用 tcptrace 计算 RTT
对于下面附加的 tcptrace 输出（取自网站 http://tcptrace.org/manual/index .html 在 RTT 统计数据下）
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 和 b->a 的 RTT 平均值，则值之间存在重大差异。我不希望它们完全相同，但差异很大。我认为 RTT 的计算方式背后发生了一些我不确定的事情。
For the below attached tcptrace output (this is taken from the site http://tcptrace.org/manual/index.html under RTT stats)
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
So the question I have is that if you see RTT average for a->b and for b->a there is a major difference in the values. I dont expect them to be exaclty the same but the difference is quite big. I think there is something happening behind the scene in the way RTT is being calculated which I am not sure of.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
摘要： 确保您查看了正确的一半对话的 RTT，具体取决于您捕获的位置
这个答案解释了 tcptrace 使用数据段的时间戳和确认它的 ACK 的时间戳之间的差异来计算 RTT。这意味着RTT 计算将取决于您捕获跟踪的位置
例如，如果您在节点 A 上捕获数据包，则在您捕获数据包后，您几乎会立即看到 A 的 ACK看到从节点B到达的相应分段，并且因此看到B→A分段中的RTT值非常低。对于 A->B 段，您将测量真实的 RTT，因为在查看来自 A 的段和来自 b 的相应 ACK 之间将发生“真实”往返。
如果您在节点 b 上进行捕获，情况将会相反，如果您在中间某个位置进行捕获，“真实”RTT 将大约为 A->B + B->A 之和。
Summary: Make sure you look at the RTT for the correct half of the conversation, depending on where you made the capture
This answer explains that tcptrace uses the difference between timestamps of the data segment and that of the ACK that acknowledges it to calculate RTT. This means that the RTT calculation will depend on where you are capturing the trace
For example, if you are capturing packets on node A, you will see A's ACK almost immediately after you see the corresponding segment arriving from node B and thus see a very low value for RTT in the B->A segments. For A->B segments you will be measuring the real RTT as a 'real' round-trip will have occurred between seeing the segment from A and the corresponding ACK from b.
If you made the capture on node b the situation would be reversed, and if you made the capture somewhere in the middle the 'true' RTT would be approximately the sum of A->B + B->A.
RTT 计算不是在发送方节点进行的。它们可能是在路径上的某个点制作的。 a→b和b→a不一定是在发送方和接收方节点之间。
它可以是这样的
S--A--------->R其中 S 是发送者，R 是接收者，A 是 S 和 R 之间的某个点。 ;b可以代表从A到R的RTT，而b→a可以代表从A到S的RTT。The RTT calculations are not made at the sender node. They could have been made at a point along the path. The a->b and b->a is not necessarily between the sender and receiver nodes.
It can be something like this
S--A--------->Rwhere S is Sender and R is receiver and A is some point between S and R. a->b can represent the RTT from A to R while b->a can represent RTT from A to S.