Расчет RTT с использованием tcptrace

Для приведенного ниже вывода 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

Итак, вопрос, который у меня есть, заключается в том, что если вы видите среднее значение RTT для a-> b и для b-> a, есть большая разница в значениях. Я не ожидаю, что они будут одинаковыми, но разница довольно большая. Я думаю, что что-то происходит за кулисами в том, как рассчитывается RTT, в чем я не уверен.


person noob    schedule 26.09.2011    source источник
comment
Я знаю, что это не связано с tcpdump, но это не позволит мне создать новый тег для tcptrace.   -  person noob    schedule 26.09.2011


Ответы (2)


Резюме: убедитесь, что вы смотрите на RTT для правильной половины разговора, в зависимости от того, где вы сделали захват

Этот ответ объясняет, что tcptrace использует разницу между временными метками сегмента данных и ACK. который подтверждает это для расчета RTT. Это означает, что вычисление RTT будет зависеть от того, где вы записываете трассировку

Например, если вы перехватываете пакеты на узле A, вы увидите ACK узла A почти сразу после того, как увидите соответствующий сегмент, прибывший от узла B, и, таким образом, увидите очень низкое значение RTT в сегментах B->A. Для сегментов A->B вы будете измерять реальный RTT, так как между просмотром сегмента из A и соответствующим ACK из b произойдет «настоящее» обращение туда и обратно.

Если бы вы сделали захват на узле b, ситуация была бы обратной, и если бы вы сделали захват где-то посередине, «истинный» RTT был бы приблизительно равен сумме A->B + B->A.

person rupello    schedule 29.09.2011

Расчеты RTT не выполняются на узле-отправителе. Они могли быть сделаны в точке на пути. a->b и b->a не обязательно находятся между узлами отправителя и получателя.

Это может быть что-то вроде этого

S--A--------->R, где S — отправитель, R — получатель, а A — некоторая точка между S и R. a->b может представлять RTT от A до R, а b->a может представлять RTT от A до S.

person SP6    schedule 30.09.2011