Tại sao mtr nhanh hơn traceroute?

Trong mtrtrang man, nó ghi:

mtr kết hợp chức năng của các chương trình traceroute và ping trong một công cụ chẩn đoán mạng duy nhất

Tôi sử dụng mtrrất nhiều, và thấy rằng nó nhanh hơn nhiều traceroute. Theo bản năng, mtrcho tôi câu trả lời rõ ràng, trong khi tracerouteliệt kê từng địa chỉ IP mỗi giây. Tại máy tính của riêng tôi, tôi đã sử dụng time mtr www.google.comvà time traceroute www.google.com, kết quả là 21,9 giây VS 6.1s.

Câu hỏi là tại sao? Vì mtr = ping + traceroute, điều đó không có nghĩa là nó chậm hơn hoặc ít nhất là giống như traceroute.

Bất cứ ai có thể cho tôi một câu trả lời hợp lý và chi tiết?

Song song là một lý do chính cho sự thay đổi tốc độ của các công cụ này. Một yếu tố đóng góp khác là họ chờ đợi câu trả lời trong bao lâu trước khi hop được coi là không phản hồi. Nếu DNS ngược được thực hiện, bạn cũng phải chờ điều đó. Lệnh traceroute đơn giản sẽ nhanh hơn nhiều, nếu bạn tắt DNS ngược.

Một sự khác biệt quan trọng khác, mà tôi không thấy được đề cập, là cách hai công cụ kết xuất đầu ra. Traceroute tạo đầu ra theo thứ tự từ trên xuống. Mtr biểu hiện đầu ra theo một cách khác, trong đó mtr có thể quay lại và cập nhật đầu ra trên các dòng trước đó.

Điều này có nghĩa là mtr có thể hiển thị đầu ra ngay khi có sẵn, bởi vì nếu trả lời sau đó khiến đầu ra đó không chính xác, mtr có thể quay lại và cập nhật nó. Vì traceroute không thể quay lại và cập nhật đầu ra, nó phải đợi cho đến khi cuối cùng nó quyết định những gì nó sẽ hiển thị.

Ví dụ: nếu hop số 2 không phản hồi (đó là triệu chứng tôi đã thấy trên nhiều ISP), traceroute sẽ hiển thị hop số 1 và sau đó đợi một lúc trước khi nó hiển thị hop số 2 và 3. Mặc dù phản hồi từ số hop 3 đã đến, nó không được hiển thị vì traceroute vẫn đang chờ trả lời từ hop số 2. Mtr không có hạn chế đó và có thể hiển thị trả lời từ hop số 3 và vẫn quay lại để hiển thị trả lời từ hop số 2, nếu nó đến sau

Quá nhiều song song có thể làm cho đầu ra trở nên không chính xác. Trong một số trường hợp, có giới hạn về số lượng gói bạn có thể nhận được trả lời. Gửi nhiều gói hơn trong các trường hợp đó sẽ không tăng tốc quá trình, tuy nhiên nó sẽ gây ra nhiều gói bị mất hơn, vì bạn nhận được cùng số lượng trả lời với nhiều gói được gửi.

Một ví dụ về điều này là khi một bước nhảy trên tuyến không trả lời các yêu cầu ARP. Thông thường gói đầu tiên sẽ kích hoạt yêu cầu ARP và nếu nhiều gói đến trước khi hết yêu cầu ARP, chỉ gói cuối cùng trong số đó sẽ được đệm và nhận được phản hồi.

Một sự khác biệt nữa là có bao nhiêu bước nhảy không có phản hồi sẽ được hiển thị trước khi công cụ dừng hiển thị nhiều bước nhảy hơn. Tôi đã thấy lệnh traceroute tiếp tục cho nhiều bước nhảy theo yêu cầu (30 theo mặc định), trong khi lệnh mtr sẽ dừng ngay khi nó vượt qua năm bước nhảy mà không có phản hồi.

Lệnh traceroute đang gửi 3 đầu dò trên mỗi hop nếu bạn giới hạn ở 1 đầu dò -q 1thì kết quả sẽ tương đương

time mtr -r -c 1 google.com
.
.
.
real    0m2.640s
user    0m0.003s
sys     0m0.018s


time traceroute6 -q 1 google.com
.
.
.
real    0m0.445s
user    0m0.006s
sys     0m0.007s

Tôi hy vọng sự khác biệt chính giữa các thử nghiệm so sánh có liên quan đến thời gian truy vấn DNS và sự khác biệt đường dẫn. Bạn sẽ lưu ý rằng traceroute của tôi nhanh hơn mtr nhưng điều này không phải lúc nào cũng đúng.

Tôi cho rằng điều này đến từ cách thực hiện theo dõi lộ trình. tracerouteđã gửi ít nhất 3 gói cho mỗi bước nhảy trong tuyến đến đích, theo tuần tự.

mtr khám phá các bước nhảy trong tuyến trước, sau đó gửi gói đến từng nút song song.

Dường như với tôi cũng có một sự khác biệt trong cách mtrxử lý hop không phản ứng với ping / thăm dò; nó bỏ qua sau đó nhanh hơn traceroutedường như gửi 3 gói của nó mọi lúc, ngay cả khi những lần thử đầu tiên không nhận được phản hồi.

Lý do chính là cách traceroute chạy. Nó sẽ gửi một gói UDP (hoặc ICMP trên windows) với một TTL cho máy chủ đầu tiên và khi nhận được phản hồi hết thời gian chờ (hoặc nó vượt qua thời gian chờ bên trong), sau đó nó sẽ tạo gói tiếp theo cho máy chủ tiếp theo có TTL của hai, v.v. (thêm một vào TTL cho mỗi máy chủ). Vì vậy, tổng thời gian của traceroute bao gồm việc gửi và nhận gói cho mỗi máy chủ, theo tuần tự ,.

mtr, sau khi xác định đường dẫn các gói đi, gửi song song tất cả các gói ICMP ECHO.