Mengapa traceroute lebih lama dari ping?

16

Bagaimana cara menjelaskan ini?

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.

Jadi waktu rata-rata seharusnya: 1 + 7 + 108 + 2 + 1 + 1 + 2 + 1 + 1 + 2 + 2 + 33 + 34 + 34 + 35 + 34 + 34 + 35 + 34, yang jauh lebih besar dari 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

— percikan
sumber

3

Begitu banyak jawaban buruk pada pertanyaan ini. Anda semua mengingatkan saya, dengan cara, youtube.com/watch?v=SXmv8quf_xM

— Tom O'Connor

16

Anda tidak bisa menambahkan bersama semua angka-angka itu. Itu adalah waktu ping ke setiap hop di jalur ke google. Jadi secara alami setiap kaki dari jalur semakin jauh dan semakin jauh dan Anda melihat waktu ping yang berbeda-beda. Jika Anda melihat waktu ping terakhir di tracert (34 ms) dan waktu yang Anda terima saat Anda mengeluarkan ping (34ms) ini adalah sama. Program tracert tidak lebih lambat dari ping.

Saya sarankan membaca tentang cara kerja traceroute:
http://en.wikipedia.org/wiki/Traceroute

— einstiien
sumber

Bukan itu farther and farther away.

Saya tidak mengerti maksud Anda. Setiap alamat IP yang tercantum pada traceroute adalah alamat router berikutnya yang sejalan antara Anda dan google. Dalam topologi jaringan "logis" ini semakin jauh saat Anda maju ke bawah daftar. Juga, sebagian besar, mereka semakin jauh dari lokasi geografis Anda. Meskipun ini tidak selalu benar karena kadang-kadang rute tampaknya melompat di sekitar peta "tidak perlu". Tetapi poin saya adalah jarak fisik dan banyak hop meningkatkan waktu ping.

— einstiien

Coba ping setiap node di rute. Anda harus menghasilkan total yang sama (kurang-lebih).

— Chris Nava

1

Mungkin PHP berada di situs stackoverflow yang salah, dan berarti lebih jauh mengacu pada jarak fisik sedangkan lebih jauh lebih sesuai untuk jarak jaringan? english.stackexchange.com

— dunxd

12

Anda dapat melihat ping seperti berkendara dari New York ke San Francisco. Dibutuhkan, katakanlah 200 jam (saya dari swiss dan tidak terbiasa dengan jarak di AS)

Tetapi Pengemudi harus kembali ke New York untuk memberi tahu Anda bahwa dia ada di San Francisco. Anda melihat ke arloji dan sekarang Anda menghitung bahwa dia mengambil 400 jam untuk jarak. Nah, itu yang dilakukan Ping. Apa yang dilakukan Traceroute adalah: Memberitahu Pengemudi Anda bahwa ia harus berkendara dari New York ke San Franciso dan setiap kali ia datang di perempatan, ia harus kembali dan memberi tahu Anda nama itu. Jadi dia dalam perjalanan dan beberapa persimpangan jalan pertama di New York. Jadi dia cukup cepat dengan mengemudi kembali ke Anda dan memberi tahu Anda nama persimpangan. Tetapi ketika dia semakin jauh, dia akan membutuhkan waktu lebih lama untuk kembali kepada Anda. dan seterusnya...

Jadi, jika Anda menghitung semua jam mengemudi ia dalam perjalanan, ia akan membutuhkan waktu lebih lama melaporkan semua persimpangan daripada jika ia hanya harus mengemudi ke San Francisco. Semoga ini membersihkan beberapa hal untuk Anda ...

— Bona
sumber

2

Analogi yang lebih baik adalah bahwa Anda mengirim 30 pengemudi, menyuruh mereka masing-masing untuk pergi ke New York, tetapi masing-masing dari mereka harus berbalik dan kembali di persimpangan pertama, persimpangan kedua, persimpangan ketiga, dan seterusnya, semua jalan hingga tiga puluh persimpangan (berharap bahwa ada kurang dari 30 antara SF dan NY).

— Jed Daniels

0

Sebenarnya itu pada dasarnya karena fakta bahwa PING mengirim permintaan ICMP melalui jaringan ke DNS dan alat Jaringan lainnya.

Namun, Traceroute mengirim banyak paquets dengan TTL yang sangat singkat.

Sebagai contoh ketika Anda mencoba untuk bergabung dengan www.google.com dari tempat duduk Anda, traceroute mengirim paquet ke www.google.com dengan set TTL ke 1, dan menunggu jawaban dari alat jaringan pertemuan pertama.

Kemudian, Traceroute menampilkan IP alat jaringan pertama pada layar Anda, dan setelah itu akan membuat hal yang sama tetapi kali ini dengan set TTL ke 2 dll.

Pada akhirnya, Traceroute telah menunggu sekitar setengah kali karena, pada setiap pengiriman, ia menunggu jawaban dari alat jaringan.

— Dr I
sumber

0

Traceroute selalu memberi tahu Anda rata-rata ke tujuan, bukan akumulasi waktu, yaitu, dalam kasus Anda, 34ms dengan pingdan traceroute.

Jika traceroute melakukan apa yang Anda sarankan, hasilnya akan sangat tidak dapat dibaca.

Jika Anda hanya tertarik pada waktu respons dari tujuan, pingcukuplah, tracerouteadalah ketika Anda perlu men-debug sesuatu pada rute ke tujuan. Selain itu, semua lompatan antara Anda dan tujuan adalah router, dan sebagian besar waktu, router memiliki prioritas pada apa yang harus dilakukan, yaitu, paket rute pertama, dan kemudian menjawab ping atau traceroute (yaitu, kasus pertama, menjawab icmp echo reply, dan dalam kasus kedua, an icmp time exceeded) dan sering menjawab lebih lambat (ketika mereka menjawab sama sekali)

— tikar
sumber

0

Untuk anak cucu, karena tidak ada jawaban yang benar sangat jelas ...

-

Setiap kali yang ditunjukkan dalam traceroute adalah TOTAL TIME dari MESIN ANDA (atau mesin yang melakukan traceroute ...) ke ITULAH NOD.

Dengan kata lain, waktu yang ditunjukkan pada simpul ke-2 bukanlah waktu yang diambil antara simpul 1 dan 2, melainkan waktu total yang diambil antara sumber, simpul pertama, dan simpul kedua semuanya disatukan.

Jadi rata-rata, waktu yang ditunjukkan pada setiap node kira-kira harus sesuai dengan waktu yang akan Anda dapatkan jika Anda melakukan ping ke node tertentu "secara langsung" (itu tidak lebih langsung daripada traceroute pada kenyataannya ... biasanya akan mengikuti jalur yang sama di internet).

Hanya perlu diingat bahwa ada yang namanya "lag spike." Cara paling akurat untuk menemukan sumber lag apa pun adalah dengan menjalankan traceroute pada pengulangan menggunakan file batch (jika Anda menggunakan Windows), dan menemukan simpul terdekat (bernomor terendah) yang memiliki angka tinggi pada waktu tertentu.

-

Untuk file batch, buka notepad dan ketik 3 baris ini:

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

Kemudian simpan sebagai "Trace.bat" tetapi pastikan untuk mengubah jenis file pada dialog save ke "semua file" sebelum menyimpan atau masih akan menyimpan sebagai file teks.

Ketika dibuka, ini akan terus menjalankan traceroutes (ke google). Anda dapat menghentikannya dengan menekan ctrl + c saat jendela yang dipilih.

-

Anda dapat, tentu saja, mengubah tempat traceroute dijalankan dengan mengubah "www.google.com" ke alamat apa pun yang Anda suka.

Anda juga dapat menghapus opsi "-d" jika Anda ingin melihat nama host yang diselesaikan, tetapi ini akan membuat traceroute lebih lama karena mendapatkan nama host dari server DNS untuk setiap node (ini TIDAK mengubah hasil aktualnya sendiri namun ).

Terakhir, jika Anda menemukan simpul dengan waktu tinggi dan hanya ingin menjalankan traceroute ke simpul tertentu tersebut jika-kalau ada simpul lain, Anda dapat mengubah "www.google.com" menjadi alamat ip atau nama host simpul itu, ATAU Anda dapat menggunakan opsi -h untuk menentukan berapa banyak node yang akan dicari, yaitu ...

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

— Laike Endaril
sumber

Catatan penting adalah bahwa sebuah node membalas dengan ICMP, tetapi tujuan utama router adalah untuk merutekan paket, dan membuat respons ICMP jauh di bawah daftar apa yang dilakukannya. Router akan merutekan, dan akan mengirim pesan ICMP ketika ada waktu. Itulah sebabnya waktu antara bisa lebih lama dari jalur penuh; router menengah bisa jauh lebih sibuk daripada node akhir.

— Ron Maupin

Ya, prioritas QOS ICMP biasanya lebih rendah, tetapi sering kali ketika Anda menjalankan traceroute, itu karena masalah sudah ada (Anda mengalami lag spike atau bad ping pada game), dan simpul tertentu yang Anda sebutkan ( yang sibuk) adalah hambatan yang Anda cari.

— Laike Endaril

Maksud saya bukan prioritas QoS, maksud saya perangkat itu sendiri yang menciptakan respons ICMP. Node sebenarnya bisa terlalu sibuk merutekan paket untuk mengirim pesan ICMP sebelum node asli habis. Router akan merutekan paket sebelum memutuskan untuk mengirim pesan ICMP. Itu tidak ada hubungannya dengan QoS.

— Ron Maupin

QoS adalah istilah yang didefinisikan sangat longgar, dan saya menganggapnya untuk mencakup semua kegiatan yang menggunakan set sumber daya yang sama, daripada mengecualikan kegiatan yang membutuhkan perhatian ekstra (membangun paket respons). Bagaimanapun, itu tidak mengubah fakta bahwa router tersebut berada di bawah beban yang terlalu berat dan terikat untuk menyebabkan masalah, jadi waktu tinggi dari traceroute masih merupakan indikator yang baik untuk di mana masalah Anda berada ... dengan kemungkinan pengecualian dari sejumlah besar lalu lintas yang memiliki prioritas lebih tinggi dari ICMP Anda tetapi prioritas lebih rendah dari lalu lintas normal Anda.

— Laike Endaril

-1

Karena tracert menggunakan paket UDP, seperti ping menggunakan ICMP pakets. Di Linux, di mana ada traceroute -Iopsi untuk melakukan traceroute ICMP.

Dalam pengujian Anda waktu untuk terhubung ke Google adalah sama di traceroute dan ping: 34ms. Semua router di tengah memiliki waktu sendiri untuk menjawab tetapi tidak memengaruhi waktu transfer akhir.

http://en.wikipedia.org/wiki/Traceroute menjelaskan semuanya di Traceroute

— Dom
sumber

3

Sebenarnya, di Windows, tracertgunakan ICMP secara default, tidak seperti Linux traceroute.

— phoebus

tracert menggunakan periode ICMP. ICMP adalah protokol IP 1, UDP adalah 17.

— dbasnett

@ dbasnett Awalnya, traceroute mengirim paket keluar sebagai UDP, dan paket kembali tentu saja ICMP TTL melebihi pesan. Windows dan sekarang program traceroute lainnya menggunakan paket permintaan gema ICMP untuk keluar. Biasanya ketika orang merujuk traceroute UDP atau traceroute ICMP inilah paket keluar yang mereka maksudkan, karena mekanisme KEDUA mengandalkan ICMP TTL melebihi pesan yang datang kembali ke pengirim dari lompatan di sepanjang rute.

— Jed Daniels

-1

Anda dapat meningkatkan traceroute Anda dengan menonaktifkan pencarian reverse dns, yang sering gagal: tracert -d www.google.com

— Chateau Mathieu
sumber

Ini tidak membuat waktu pulang pergi lebih cepat. Namun itu membuatnya lebih cepat untuk mengembalikan hasil di layar Anda, karena tidak melakukan pencarian DNS.

— Jed Daniels