gpt4 book ai didi

tcp - 使用tcptrace计算RTT

转载 作者:可可西里 更新时间:2023-11-01 02:32:47 27 4
gpt4 key购买 nike

对于下面附加的 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 的计算方式在幕后发生了一些我不确定的事情。

最佳答案

总结:确保您查看对话正确一半的 RTT,具体取决于您在何处进行捕获

This answer解释说 tcptrace 使用数据段的时间戳与确认它的 ACK 的时间戳之间的差异来计算 RTT。这意味着RTT 计算将取决于您捕获跟踪的位置

例如,如果您在节点 A 上捕获数据包,您将在看到相应的数据段从节点 B 到达后几乎立即看到 A 的 ACK,因此在 B->A 数据段中看到非常低的 RTT 值。对于 A->B 段,您将测量真实的 RTT,因为在看到来自 A 的段和来自 b 的相应 ACK 之间将发生“真实”往返。

如果您在节点 b 上进行捕获,则情况会相反,如果您在中间某处进行捕获,则“真实”RTT 大约是 A->B + B->A 的总和。

关于tcp - 使用tcptrace计算RTT,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/7558117/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com