Tại sao traceroute mất nhiều thời gian hơn ping?

16

Làm thế nào để giải thích điều này?

C:\Documents and Settings\Administrator>tracert google.com

Tracing route to google.com [64.233.189.104]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.0.1
  2     7 ms    <1 ms    <1 ms  reserve.cableplus.com.cn [218.242.223.209]
  3   108 ms   135 ms   163 ms  211.154.70.10
  4     *        *        *     Request timed out.
  5     2 ms     *        1 ms  211.154.64.114
  6     1 ms     1 ms     1 ms  211.154.72.185
  7     1 ms     1 ms     1 ms  202.96.222.77
  8     2 ms     1 ms     2 ms  61.152.81.145
  9     1 ms     2 ms     1 ms  61.152.86.54
 10     1 ms     1 ms     1 ms  202.97.33.238
 11     2 ms     2 ms     2 ms  202.97.33.54
 12     2 ms     1 ms     2 ms  202.97.33.5
 13    33 ms    33 ms    33 ms  202.97.61.50
 14    34 ms    34 ms    34 ms  202.97.62.214
 15    34 ms   186 ms    37 ms  209.85.241.56
 16    35 ms    35 ms    44 ms  66.249.94.34
 17    34 ms    34 ms    34 ms  hkg01s01-in-f104.1e100.net [64.233.189.104]

Trace complete.

Vì vậy, thời gian trung bình nên là: 1 + 7 + 108 + 2 + 1 + 1 + 2 + 1 + 1 + 2 + 2 + 33 + 34 + 34 + 35 + 34 + 34 + 35 + 34, lớn hơn rất nhiều ping

C:\Documents and Settings\Administrator>ping google.com

Pinging google.com [64.233.189.104] with 32 bytes of data:

Reply from 64.233.189.104: bytes=32 time=34ms TTL=241
Reply from 64.233.189.104: bytes=32 time=34ms TTL=241
Reply from 64.233.189.104: bytes=32 time=34ms TTL=241
Reply from 64.233.189.104: bytes=32 time=34ms TTL=241

Ping statistics for 64.233.189.104:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 34ms, Maximum = 34ms, Average = 34ms

ping networking

— mảnh vụn
nguồn

3

Vì vậy, nhiều câu trả lời xấu về câu hỏi này. Theo một cách nào đó, tất cả các bạn đều nhắc tôi về youtube.com/watch?v=SXmv8quf_xM

— Tom O'Connor

16

Bạn không thể chỉ cần thêm tất cả những con số đó. Đó là thời gian ping đến từng bước nhảy trên đường dẫn tới google. Vì vậy, tự nhiên mỗi chân của con đường ngày càng xa hơn và bạn thấy thời gian ping khác nhau. Nếu bạn nhìn vào thời gian ping cuối cùng trong tracert (34 ms) và thời gian bạn nhận được khi bạn phát hành ping (34ms) thì đây là như nhau. Chương trình tracert không chậm hơn ping.

Tôi sẽ đề nghị đọc về cách hoạt động của một traceroute:
http://en.wikipedia.org/wiki/Traceroute

— einstiien
nguồn

Không phải vậy farther and farther away.

Tôi không hiểu ý của bạn. Mỗi địa chỉ IP được liệt kê trên traceroute là địa chỉ của bộ định tuyến tiếp theo nằm giữa bạn và google. Trong cấu trúc liên kết mạng "hợp lý", chúng sẽ đi xa hơn khi bạn tiến xuống danh sách. Ngoài ra, đối với hầu hết các phần, họ sẽ cách xa vị trí địa lý của bạn. Mặc dù điều này không phải lúc nào cũng đúng vì đôi khi các tuyến dường như nhảy quanh bản đồ "không cần thiết". Nhưng quan điểm của tôi là khoảng cách vật lý và nhiều bước nhảy làm tăng thời gian ping.

— einstiien

Hãy thử ping từng nút trong tuyến đường. Bạn nên đưa ra tổng số tương tự (đại khái).

— Chris Nava

1

Có lẽ PHP đang ở trên trang web stackoverflow sai và có nghĩa là xa hơn đề cập đến khoảng cách vật lý trong khi hơn nữa là phù hợp hơn với khoảng cách mạng? english.stackexchange.com

— dunxd

12

Bạn có thể thấy ping giống như một ổ đĩa từ New York đến San Francisco. Phải mất 200 giờ (tôi đến từ Thụy Sĩ và không quen với khoảng cách ở Mỹ)

Nhưng Người lái xe phải quay lại New York để nói với bạn rằng anh ta đang ở San Francisco. Bạn nhìn vào đồng hồ và bây giờ bạn tính rằng anh ấy đã mất 400 giờ cho khoảng cách. Bây giờ đó là những gì Ping làm. Những gì Traceroute làm là: Nói với tài xế của bạn rằng anh ta nên lái xe từ New York đến San Franciso và mỗi khi anh ta đi qua ngã tư, anh ta nên quay lại và nói cho bạn biết tên của nó. Vì vậy, anh ấy đang trên đường và một vài ngã tư đầu tiên là ở New York. Vì vậy, anh ta khá nhanh với việc lái xe trở lại với bạn và cho bạn biết tên của ngã tư. Nhưng khi anh ấy tiến xa hơn, anh ấy sẽ mất nhiều thời gian hơn để quay lại với bạn. và như thế...

Vì vậy, nếu bạn đếm tất cả các giờ lái xe, anh ấy đang trên đường, anh ấy sẽ mất nhiều thời gian hơn để báo cáo tất cả các ngã tư so với khi anh ấy phải lái xe đến San Francisco. Hy vọng điều này sẽ làm sáng tỏ một số điều cho bạn ...

— Bona
nguồn

2

Một điều tương tự tốt hơn là bạn gửi 30 tài xế, bảo mỗi người trong số họ đi về phía New York, nhưng mỗi người trong số họ phải quay lại và quay lại ở ngã tư thứ nhất, ngã tư thứ hai, ngã tư thứ ba, v.v. cách lên đến ba mươi ngã tư (hy vọng rằng có ít hơn 30 giữa SF và NY).

— Jed Daniels

0

Trên thực tế, về cơ bản là do PING đã gửi yêu cầu ICMP qua mạng tới DNS và thiết bị của Mạng khác.

Tuy nhiên, Traceroute gửi rất nhiều paquets với một TTL thực sự ngắn.

Ví dụ khi bạn cố gắng tham gia www.google.com từ chỗ ngồi của mình, traceroute đã gửi một paquet đến www.google.com với bộ TTL thành 1 và chờ câu trả lời từ thiết bị của mạng gặp gỡ đầu tiên.

Sau đó, Traceroute hiển thị IP của thiết bị của mạng đầu tiên trên màn hình của bạn và sau đó nó sẽ thực hiện điều tương tự nhưng lần này với một bộ TTL được đặt thành 2, v.v.

Cuối cùng, Traceroute đã đợi thêm khoảng một nửa thời gian bởi vì, mỗi lần gửi, nó đang chờ câu trả lời của thiết bị mạng.

— Tiến sĩ tôi
nguồn

0

Traceroute luôn cho bạn biết trung bình đến đích, không phải là sự tích lũy của thời gian, nghĩa là, trong trường hợp của bạn, đó là 34ms với pingvà traceroute.

Nếu traceroute là để làm những gì bạn đề xuất, đầu ra của nó sẽ khá khó đọc.

Nếu bạn chỉ quan tâm đến thời gian phản hồi của điểm đến, pinglà khá đủ, traceroutelà khi bạn cần gỡ lỗi một cái gì đó trên tuyến đến đích. Hơn nữa, tất cả các bước nhảy giữa bạn và đích là các bộ định tuyến và hầu hết thời gian, các bộ định tuyến đều ưu tiên những việc cần làm, đó là các gói tuyến đầu tiên, sau đó trả lời ping hoặc theo dõi (đó là trường hợp đầu tiên, trả lời một icmp echo reply, và trong trường hợp thứ hai, một icmp time exceeded) và thường trả lời chậm hơn (khi họ trả lời tất cả)

— chiếu
nguồn

0

Đối với hậu thế, vì không có câu trả lời đúng nào rất rõ ràng ...

-

Mỗi lần được hiển thị trong traceroute là TỔNG THỜI GIAN từ MÁY CỦA BẠN (hoặc máy thực hiện theo dõi ...) đến NODE THAM GIA.

Nói cách khác, thời gian hiển thị trên nút thứ 2 không phải là thời gian được thực hiện giữa các nút 1 và 2, mà là tổng thời gian được thực hiện giữa nguồn, nút đầu tiên và nút thứ hai được đặt cùng nhau.

Vì vậy, trung bình, thời gian hiển thị trên mỗi nút gần như khớp với số lần bạn sẽ nhận được nếu bạn ping trực tiếp nút đó (không thực sự trực tiếp hơn một traceroute trong thực tế ... nó thường sẽ đi theo cùng một đường dẫn trên mạng).

Chỉ cần nhớ rằng có một thứ gọi là "lag spike". Cách chính xác nhất để tìm nguồn gốc của bất kỳ độ trễ nào là chạy theo dõi lặp lại bằng cách sử dụng tệp bó (nếu bạn đang ở trên Windows) và tìm nút gần nhất (được đánh số thấp nhất) có số lượng cao tại bất kỳ thời điểm nào.

-

Đối với tệp bó, mở notepad và nhập 3 dòng sau:

:start
tracert -d www.google.com
goto start

Sau đó lưu dưới dạng "Trace.bat" nhưng đảm bảo thay đổi loại tệp trên hộp thoại lưu thành "tất cả các tệp" trước khi lưu hoặc nó vẫn sẽ lưu dưới dạng tệp văn bản.

Khi mở, điều này sẽ liên tục chạy traceroutes (với google). Bạn có thể dừng nó bằng cách nhấn ctrl + c trong khi bạn đã chọn cửa sổ.

-

Tất nhiên, bạn có thể thay đổi nơi đang chạy traceroute bằng cách thay đổi "www.google.com" thành bất kỳ địa chỉ nào bạn cảm thấy thích.

Bạn cũng có thể xóa tùy chọn "-d" nếu bạn muốn xem tên máy chủ đã giải quyết, nhưng điều này sẽ khiến việc theo dõi mất nhiều thời gian hơn do nhận được tên máy chủ từ máy chủ DNS cho mỗi nút (tuy nhiên điều này KHÔNG thay đổi kết quả thực tế ).

Cuối cùng, nếu bạn tìm thấy một nút có thời gian cao và chỉ muốn chạy traceroutes đến nút cụ thể đó trong trường hợp nút khác trước khi nó gặp sự cố, bạn có thể thay đổi "www.google.com" thành địa chỉ IP hoặc tên máy chủ của nút đó, HOẶC bạn có thể sử dụng tùy chọn -h để chỉ định có bao nhiêu nút để tìm kiếm, tức là ...

:start
tracert -d -h 5 www.google.com
goto start

— Laike Endaril
nguồn

Một lưu ý quan trọng là một nút trả lời với ICMP, nhưng mục đích chính của bộ định tuyến là định tuyến các gói và việc tạo các phản hồi ICMP nằm xa danh sách những gì nó làm. Một bộ định tuyến sẽ định tuyến và nó sẽ đi xung quanh để gửi tin nhắn ICMP khi có thời gian. Đó là lý do tại sao thời gian trung gian có thể dài hơn đường dẫn đầy đủ; bộ định tuyến trung gian có thể bận hơn nhiều so với nút cuối.

— Ron Maupin

Có, mức độ ưu tiên QOS của ICMP thường thấp hơn, nhưng thường khi bạn đang chạy traceroute, đó là do sự cố đã xảy ra (bạn có độ trễ lag hoặc ping xấu trên trò chơi) và nút cụ thể mà bạn đã đề cập ( cái bận rộn) là nút cổ chai mà bạn đang tìm kiếm.

— Laike Endaril

Tôi không có nghĩa là ưu tiên QoS, ý tôi là chính thiết bị tạo ra phản hồi ICMP. Nút thực sự có thể quá bận rộn định tuyến các gói để đi xung quanh để gửi tin nhắn ICMP trước khi nút ban đầu hết thời gian. Một bộ định tuyến sẽ định tuyến các gói trước khi quyết định gửi tin nhắn ICMP. Điều đó không liên quan gì đến QoS.

— Ron Maupin

QoS là một thuật ngữ được xác định rất lỏng lẻo và tôi cho rằng nó bao gồm tất cả các hoạt động sử dụng cùng một bộ tài nguyên, thay vì loại trừ các hoạt động cần chú ý thêm (xây dựng gói phản hồi). Dù bằng cách nào, điều đó không làm thay đổi thực tế rằng bộ định tuyến đã nói quá tải và bị ràng buộc gây ra sự cố, do đó, thời gian cao từ một traceroute vẫn là một chỉ báo tốt cho vấn đề của bạn nằm ở đâu ... với ngoại lệ có thể có một lượng lớn lưu lượng truy cập có mức độ ưu tiên cao hơn ICMP của bạn nhưng mức độ ưu tiên thấp hơn lưu lượng truy cập bình thường của bạn.

— Laike Endaril

-1

Bởi vì tracert sử dụng các gói UDP, như ping sử dụng các gói ICMP. Trong Linux, khi có traceroute -Itùy chọn để thực hiện theo dõi ICMP.

Trong thử nghiệm của bạn, thời gian để kết nối với google là như nhau trong traceroute và ping: 34ms. Tất cả các bộ định tuyến ở giữa có thời gian riêng để trả lời nhưng không ảnh hưởng đến thời gian chuyển giao cuối cùng.

http://en.wikipedia.org/wiki/Traceroute giải thích tất cả trên Traceroute

— Nhà thờ
nguồn

3

Trên thực tế, trên Windows, tracertsử dụng ICMP theo mặc định, không giống như Linux traceroute.

— phoebus

tracert sử dụng thời kỳ ICMP. ICMP là giao thức IP 1, UDP là 17.

— dbasnett

@dbasnett Ban đầu, theo dõi các gói gửi đi dưới dạng UDP và các gói trả về tất nhiên là các tin nhắn vượt quá ICMP TTL. Windows và bây giờ các chương trình theo dõi khác sử dụng các gói yêu cầu tiếng vang ICMP cho việc gửi đi. Thông thường, khi mọi người đề cập đến UDP traceroute hoặc ICMP traceroute, đó là những gói gửi đi mà họ đang đề cập đến, vì các cơ chế BOTH dựa vào ICMP TTL vượt quá các tin nhắn gửi lại cho người gửi từ bước nhảy dọc tuyến.

— Jed Daniels

-1

Bạn có thể tăng tốc độ theo dõi của mình bằng cách vô hiệu hóa tra cứu dns ngược, thường không thành công: tracert -d www.google.com

— Lâu đài Mathieu
nguồn

Điều này không làm cho thời gian chuyến đi khứ hồi nhanh hơn. Tuy nhiên, việc trả lại kết quả trên màn hình của bạn sẽ nhanh hơn vì nó không thực hiện tra cứu DNS.

— Jed Daniels