mengapa mtr jauh lebih cepat daripada traceroute?

Di mtrhalaman manual, terbaca:

mtr menggabungkan fungsionalitas program traceroute dan ping dalam satu alat diagnostik jaringan

Saya menggunakan mtrbanyak, dan menemukan bahwa itu jauh lebih cepat daripada traceroute. Secara naluriah, mtrberikan saya jawabannya secara langsung, sambil traceroutedaftarkan setiap alamat ip setiap detik. Di komputer saya sendiri, saya menggunakan time mtr www.google.comdan time traceroute www.google.com, hasilnya adalah 21.9s VS 6.1s.

Pertanyaannya adalah mengapa? Karena mtr = ping + traceroute, bukankah itu berarti lebih lambat atau setidaknya sama dengan traceroute.

Adakah yang bisa memberi saya jawaban yang masuk akal dan terperinci?

Paralelisme adalah alasan utama untuk variasi dalam kecepatan alat ini. Faktor lain yang berkontribusi adalah berapa lama mereka menunggu jawaban sebelum hop dianggap tidak merespons. Jika reverse DNS dilakukan, Anda harus menunggu juga. Perintah traceroute biasa menjadi jauh lebih cepat, jika Anda menonaktifkan DNS terbalik.

Perbedaan penting lainnya, yang saya tidak lihat disebutkan, adalah bagaimana dua alat membuat output. Traceroute menghasilkan output secara berurutan dari atas ke bawah. Mtr membuat output dengan cara yang berbeda, di mana mtr dapat kembali dan memperbarui output pada baris sebelumnya.

Ini berarti mtr dapat menampilkan output segera setelah tersedia, karena jika nanti balasan menyebabkan output tidak akurat, mtr dapat kembali dan memperbaruinya. Karena traceroute tidak dapat kembali dan memperbarui output, ia harus menunggu sampai akhirnya memutuskan apa yang akan ditampilkan.

Misalnya, jika hop nomor 2 tidak merespons (yang merupakan gejala yang saya lihat pada beberapa ISP), traceroute akan menampilkan hop nomor 1 dan kemudian menunggu sebentar sebelum menampilkan hop nomor 2 dan 3. Meskipun balasan dari nomor hop 3 telah tiba dan tidak ditampilkan karena traceroute masih menunggu balasan dari hop nomor 2. Mtr tidak memiliki batasan itu dan dapat menampilkan balasan dari hop nomor 3 dan masih kembali untuk menampilkan balasan dari hop nomor 2, jika tiba nanti.

Terlalu banyak paralelisme dapat menyebabkan output menjadi tidak akurat. Dalam beberapa skenario ada batasan untuk berapa banyak paket Anda bisa mendapatkan balasan. Mengirim lebih banyak paket dalam kasus-kasus tersebut tidak akan mempercepat proses, namun akan menyebabkan lebih banyak paket yang hilang, karena Anda mendapatkan jumlah balasan yang sama dengan lebih banyak paket yang dikirim.

Salah satu contohnya adalah ketika lompatan pada rute tidak membalas permintaan ARP. Biasanya paket pertama akan memicu permintaan ARP, dan jika lebih banyak paket tiba sebelum permintaan ARP habis, hanya paket terakhir dari yang akan disangga dan mendapatkan balasan.

Perbedaan lainnya adalah berapa banyak hop tanpa respons akan ditampilkan sebelum alat berhenti menampilkan lebih banyak hop. Saya telah melihat perintah traceroute terus sebanyak hop yang diminta (30 secara default), sedangkan perintah mtr akan berhenti segera setelah melewati lima hop tanpa tanggapan.

Perintah traceroute mengirimkan 3 probe per hop jika Anda membatasi ke 1 probe -q 1maka hasilnya menjadi sebanding

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

Saya berharap perbedaan utama antara pengujian yang sebanding terkait dengan waktu kueri DNS dan perbedaan jalur. Anda akan perhatikan bahwa traceroute saya lebih cepat daripada mtr tetapi ini tidak selalu terjadi.

Saya kira ini berasal dari cara pelacakan rute diterapkan. traceroutemengirim setidaknya 3 paket untuk setiap hop di rute ke tujuan, secara berurutan.

mtr temukan hop di rute terlebih dahulu, dan kemudian kirim paket ke setiap node secara paralel.

Tampaknya juga bagi saya bahwa ada perbedaan dalam cara mtrmenangani hop tidak menanggapi ping / probe; itu mengabaikan kemudian lebih cepat daripada tracerouteyang tampaknya mengirim 3 paket sepanjang waktu, bahkan jika upaya pertama gagal mendapatkan respons.

Alasan utama adalah cara traceroute berjalan. Ia mengirim paket UDP (atau ICMP pada windows) dengan TTL satu ke host pertama, dan ketika menerima balasan timeout (atau melewati batas waktu internal), ia kemudian menghasilkan paket berikutnya untuk host berikutnya dengan TTL dua, dan seterusnya (menambahkan satu ke TTL untuk setiap host). Jadi total waktu traceroute mencakup pengiriman dan penerimaan paket untuk setiap host, secara berurutan,.

mtr, setelah menentukan jalur yang diambil paket, mengirimkan semua paket ICMP ECHO secara paralel.