[問答] tracert 當中的 * Request timed out.

看板Network作者 (幼斤)時間9年前 (2016/09/15 00:02), 9年前編輯推噓1(1011)
留言12則, 5人參與, 最新討論串1/1
在家裡用桌機或手機測試tracert指令,測試網站:linux.rz.ruhr-uni-bochum.de 網路配置:桌機與手機都是在dlink分享器轄下的內網關係, 桌機---(有線)------------dlink----(有線)---hinet數據機----外網 或 手機---(無線)----開wifi的dlink----(有線)---hinet數據機----外網 桌機tracert linux.rz.ruhr-uni-bochum.de 結果: Tracing route to c4-2-8.rz.ruhr-uni-bochum.de [134.147.32.114] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 192.168.0.1 2 3 ms 3 ms 2 ms h254.s98.ts.hinet.net [168.95.98.254] 3 2 ms 3 ms 2 ms rtkz-3312.hinet.net [168.95.25.230] 4 8 ms 11 ms 11 ms tpdt-3012.hinet.net [220.128.10.142] 5 4 ms 3 ms 4 ms r4101-s2.tp.hinet.net [220.128.7.117] 6 4 ms 4 ms 4 ms r4001-s2.tp.hinet.net [220.128.11.129] 7 163 ms 142 ms 154 ms 211-72-108-61.HINET-IP.hinet.net [211.72.108 8 146 ms 159 ms 146 ms xe-7-3-3.edge1.SanJose2.Level3.net [4.59.0.2 9 296 ms 290 ms 291 ms ae-4-90.edge5.Frankfurt1.Level3.net [4.69.15 10 290 ms 290 ms 290 ms ae-4-90.edge5.Frankfurt1.Level3.net [4.69.15 11 291 ms 291 ms 291 ms 212.162.4.6 12 295 ms 296 ms 295 ms cr-dui1-hundredgige0-6-0-0.x-win.dfn.de [188 13 317 ms 323 ms 316 ms xr-boc1-te1-1.x-win.dfn.de [188.1.146.34] 14 * * * Request timed out. 15 302 ms 303 ms 303 ms rdc1-vl2.cns.ruhr-uni-bochum.de [134.147.217 16 302 ms 302 ms 302 ms c4-2-8.rz.ruhr-uni-bochum.de [134.147.32.114 Trace complete. 手機tracert linux.rz.ruhr-uni-bochum.de 結果: 如圖:http://i.imgur.com/CVEiHQy.png
幾乎與桌機一樣,只是第2個節點是 * 基本上桌機與手機都可以正常下載linux.rz.ruhr-uni-bochum.de的檔案如下 http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ 問題1:tracert 當中出現幾個 * 似乎不影響下載,還是可以下載, 例如桌機tracert第14節點也是 * 那代表下載連線路徑就由節點13跳到節點15這樣?節點14就不走了? 問題2:桌機第2個節點h254.s98.ts.hinet.net 屬於正常回應時間3ms 2ms 為何手機tracert第2個節點是 * Request timed out. ? 手機與桌機都是躲在同一個dlink分享器之後再連外出去的, tracert結果應該要一樣的呀! -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.228.111.237 ※ 文章網址: https://www.ptt.cc/bbs/Network/M.1473868955.A.C8B.html ※ 編輯: zi98btcc (61.228.111.237), 09/15/2016 10:03:23

09/15 10:22, , 1F
問題一 只是節點十四不想回應你的 icmp request 而已
09/15 10:22, 1F
原來只是不回應,是我想太多

09/15 10:26, , 2F
問題二 我猜因為 android 是 linux based
09/15 10:26, 2F

09/15 10:26, , 3F
所以它的 traceroute 是用 UDP 傳送 節點二不想回應
09/15 10:26, 3F

09/15 10:27, , 4F
不過只是我的猜測啦
09/15 10:27, 4F
traceroute這麼基本工具還有分windows版,linux版? ※ 編輯: zi98btcc (61.228.111.237), 09/15/2016 11:50:25

09/15 12:12, , 5F
其實節點不回應traceroute還滿普遍的,尤其是防火牆
09/15 12:12, 5F

09/15 13:19, , 6F
節點不回應traceroute情況真的還蠻常見的,而且有時候不回
09/15 13:19, 6F

09/15 13:21, , 7F
應並不等於未通過該節點,有時多traceroute個幾次就能看見
09/15 13:21, 7F

09/15 13:21, , 8F
回應了說
09/15 13:21, 8F

09/15 15:05, , 9F
本來就跟用戶端os有關
09/15 15:05, 9F

09/17 11:11, , 10F
不同OS確實會有差,路由器即使有接收到UDP偵測封包,也
09/17 11:11, 10F

09/17 11:12, , 11F
可能因忙碌選擇不送回ICMP封包
09/17 11:12, 11F

09/18 10:55, , 12F
所以用戶報修說traceroute 出現 * 都是參考參考就好
09/18 10:55, 12F
文章代碼(AID): #1NsNIRoB (Network)
文章代碼(AID): #1NsNIRoB (Network)