※ 引述《tsubasawolfy (悠久の翼)》之銘言：
: ※ 引述《wahaha99 (此方不可長)》之銘言：
: : Ping statistics for 140.112.172.11:
: : Packets: Sent = 35, Received = 28, Lost = 7 (20% loss),
: : Approximate round trip times in milli-seconds:
: : Minimum = 30ms, Maximum = 121ms, Average = 64ms
: : 20% loss .....
: : 花生省魔術? @@
: 4 1 ms 1 ms 1 ms 140.127.160.65
: 5 11 ms 11 ms 11 ms bb-NTU-TWAREN.TANet.edu.tw [192.83.196.112]
: 6 12 ms 12 ms 13 ms 140.112.0.69
: 7 16 ms 13 ms 14 ms 140.112.0.201
: 8 * 15 ms 12 ms 140.112.0.213
: 9 18 ms 14 ms * ptt.cc [140.112.172.11]
: 10 12 ms * * ptt.cc [140.112.172.11]
: 11 12 ms 12 ms 12 ms ptt.cc [140.112.172.11]
: 三個PTT???
後面3個相同ip的情況,我想應該是這樣
因為中間的router或firewall設定的關係
icmp封包到第9個hop那個機器時，它回應一個icmp ttl time-out的封包回來
造成你本機上面跑的tracert沒有辦法正確結束trace route的工作,
因此tracert會再繼續往下trace到第10個hop...第10個hop也發生跟第9個hop
相同的情況,最後到第11個hop時,ptt主機才正確回應icmp reply封包回來...
最後才正確結束trace route的工作...
我猜第9、10個 hop，實際上並不是真正的ptt.cc這台主機?
或者是ptt主機沒錯，但firewall等其它因素造成封包到了這台時
並沒有正確回應icmp reply，而是搞錯直接把封包再往內傳
造成了icmp 封包TTL time-out....
--
這是我認為可能的情況,有錯誤請指正
--
愛情真諦:
把人者，人恆把之....
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.228.96.54