Почему время в оба конца отличается от двух тестовых?

Question

Я написал один клиент http put (используйте libcurl libarary), чтобы поместить файл на сервер apache webdav, а также использовать tcpdump для захвата пакета на стороне сервера, а затем использовать tcptrace (www.tcptrace.org) для анализа файла дампа, ниже результат: Хост а является на стороне клиента, хост-Ь на стороне сервера:

a->b:        b->a: 
    total packets:  152120   total packets:  151974  
    ack pkts sent:  152120   ack pkts sent:  151974  
    pure acks sent:   120   pure acks sent:  151854  
    sack pkts sent:   0   sack pkts sent:   0  
    dsack pkts sent:   0   dsack pkts sent:   0  
    max sack blks/ack:   0   max sack blks/ack:   0  
    unique bytes sent: 3532149672   unique bytes sent:  30420  
    actual data pkts:  152000   actual data pkts:  120  
    actual data bytes: 3532149672   actual data bytes:  30420  
    rexmt data pkts:   0   rexmt data pkts:   0  
    rexmt data bytes:   0   rexmt data bytes:   0  
    zwnd probe pkts:   0   zwnd probe pkts:   0  
    zwnd probe bytes:   0   zwnd probe bytes:   0  
    outoforder pkts:   0   outoforder pkts:   0  
    pushed data pkts:  3341   pushed data pkts:  120  
    SYN/FIN pkts sent:  0/0   SYN/FIN pkts sent:  0/0  
    req 1323 ws/ts:   N/Y   req 1323 ws/ts:   N/Y  
    urgent data pkts:   0 pkts  urgent data pkts:   0 pkts 
    urgent data bytes:   0 bytes  urgent data bytes:   0 bytes 
    mss requested:    0 bytes  mss requested:    0 bytes 
    max segm size:   31856 bytes  max segm size:   482 bytes 
    min segm size:   216 bytes  min segm size:   25 bytes 
    avg segm size:   23237 bytes  avg segm size:   253 bytes 
    max win adv:    125 bytes  max win adv:   5402 bytes 
    min win adv:    125 bytes  min win adv:   5402 bytes 
    zero win adv:    0 times  zero win adv:    0 times 
    avg win adv:    125 bytes  avg win adv:   5402 bytes 
    initial window:  15928 bytes  initial window:   0 bytes 
    initial window:   1 pkts  initial window:   0 pkts 
    ttl stream length:  NA   ttl stream length:  NA  
    missed data:    NA   missed data:    NA  
    truncated data:   0 bytes  truncated data:   0 bytes 
    truncated packets:   0 pkts  truncated packets:   0 pkts 
    data xmit time:  151.297 secs  data xmit time:  150.696 secs 
    idletime max:  44571.3 ms  idletime max:  44571.3 ms 
    throughput:   23345867 Bps  throughput:    201 Bps 

    RTT samples:   151915   RTT samples:    120  
    RTT min:     0.0 ms  RTT min:     0.1 ms 
    RTT max:     0.3 ms  RTT max:    40.1 ms 
    RTT avg:     0.0 ms  RTT avg:    19.9 ms 
    RTT stdev:    0.0 ms  RTT stdev:    19.8 ms 

    RTT from 3WHS:   0.0 ms  RTT from 3WHS:   0.0 ms 

    RTT full_sz smpls:  74427   RTT full_sz smpls:  60  
    RTT full_sz min:   0.0 ms  RTT full_sz min:  39.1 ms 
    RTT full_sz max:   0.3 ms  RTT full_sz max:  40.1 ms 
    RTT full_sz avg:   0.0 ms  RTT full_sz avg:  39.6 ms 
    RTT full_sz stdev:  0.0 ms  RTT full_sz stdev:  0.3 ms 

    post-loss acks:   0   post-loss acks:   0  
    segs cum acked:   89   segs cum acked:   0  
    duplicate acks:   0   duplicate acks:   0  
    triple dupacks:   0   triple dupacks:   0  
    max # retrans:    0   max # retrans:    0  
    min retr time:   0.0 ms  min retr time:   0.0 ms 
    max retr time:   0.0 ms  max retr time:   0.0 ms 
    avg retr time:   0.0 ms  avg retr time:   0.0 ms 
    sdv retr time:   0.0 ms  sdv retr time:   0.0 ms 

в соответствии результат выше, RTT от клиента к серверу мала, но на стороне сервера в сторону клиента является большой. Может ли кто-нибудь помочь объяснить это от меня?

Answer 1

Во-первых, host b отправил очень мало данных (очень небольшой размер выборки). Во-вторых, я подозреваю, что host a имеет асимметричное подключение к Интернету (например, 10 МБ/1 МБ).

Answer 2

Поскольку это

unique bytes sent: 3532149672   unique bytes sent:  30420  
actual data pkts:  152000   actual data pkts:  120  
actual data bytes: 3532149672   actual data bytes:  30420 

а-> Ь посылает непрерывный поток данных, который обеспечивает буферы заполняются и вещи получить толкнул.

b-> a отправляет только несколько снимков и т. Д., Практически ничего не делая, так что в результате все что-то остается в буфере на некоторое время (несколько мс).

В дополнение к этому, RTT - время в оба конца. Пришло время, когда приложение ставит очередь на отправку пакета и при получении соответствующего ответа. Поскольку хост на а занят толканием данных и, вероятно, заполняет свои собственные буферы, для получения подтверждения от небольшого количества дополнительных накладных расходов потребуется что-то из b.