menafsirkan hasil ping


11

Saya ping yahoo.com dan saya bingung dengan hasilnya.

C:\Users\jon>ping -t yahoo.com

Pinging yahoo.com [98.138.253.109] with 32 bytes of data:
Reply from 98.138.253.109: bytes=32 time=195ms TTL=46
Reply from 98.138.253.109: bytes=32 time=230ms TTL=44
Reply from 98.138.253.109: bytes=32 time=175ms TTL=45
Reply from 98.138.253.109: bytes=32 time=208ms TTL=44
Reply from 98.138.253.109: bytes=32 time=180ms TTL=46
Reply from 98.138.253.109: bytes=32 time=206ms TTL=44
Reply from 98.138.253.109: bytes=32 time=209ms TTL=44
Reply from 98.138.253.109: bytes=32 time=173ms TTL=46
Reply from 98.138.253.109: bytes=32 time=170ms TTL=46
Reply from 98.138.253.109: bytes=32 time=224ms TTL=45
Reply from 98.138.253.109: bytes=32 time=200ms TTL=45
Reply from 98.138.253.109: bytes=32 time=172ms TTL=46
Reply from 98.138.253.109: bytes=32 time=258ms TTL=44

Saya samar-samar memahami nilai TTL sebagai jumlah lompatan yang dilalui paket untuk mencapai tujuannya, tetapi saya tidak mengerti bagaimana TTL dapat memiliki varian +/- 1 yang dramatis dalam waktu yang singkat.

Selain itu, tampaknya Yahoo menerapkan pembatasan tingkat karena ping yang gigih akan mulai menghitung waktu setelah sekitar 20 paket. Apakah ini normal? bing.com bahkan tidak membalas saya!

Saat melakukan ping google.com TTL konsisten.

Saat ping Twitter.com kadang-kadang saya mendapatkan TTL = 249, tetapi biasanya TTL-58.

Apa yang sedang terjadi? Apakah ISP saya tidak bagus atau ada penjelasan yang kurang seram?


1
ibgp load balancing oleh salah satu upstreams Anda adalah kemungkinan penyebabnya, tetapi kami memiliki informasi yang tidak cukup untuk diketahui. Anda dapat menemukannya dengan melacak ... tolong google untuk mtr dan jelajahi lebih banyak lagi
Mike Pennington

Jika Anda dapat memberikan ip sumber Anda (curl my.ip.fi ), saya dapat mencoba beberapa tempat menguntungkan untuk melihat opsi jalur pengembalian
ytti

Jawaban:


14

Kemungkinan besar ini disebabkan oleh load balancing di beberapa jaringan. Setiap ping akan mengambil jalur yang berbeda dan karenanya akan memiliki nilai TTL yang berbeda.

Saya juga membaca tentang penyedia mesin pencari melakukan hal-hal aneh dengan TTL, tetapi hanya melalui rute yang berbeda.

Nilai TTL berbeda ketika bersumber dari sistem operasi yang berbeda:

  • Windows: 128
  • Linux: 64
  • Cisco: 255
  • Solaris: 255

Dan ya, beberapa situs akan berhenti merespons ICMP setelah jangka waktu tertentu, atau ketika batas tarif tercapai. Saya percaya DNS Google pada 8.8.8.8 akhirnya berhenti setelah beberapa saat.


6

Yang lain menyebutkan skenario multipath untuk menjelaskan variasi dalam waktu tunda. Dengan tautan ECMP (Equal Cost Multi Path), Anda dapat memiliki skenario sesuai dengan output yang Anda berikan di ping ke Yahoo, di mana penundaan tersebut berubah antar hasil tetapi cukup konsisten. Jadi sepertinya traffic Anda di-hash pada dua atau tiga jalur yang sama, dengan panjang yang bervariasi (penundaan) (walaupun itu hanya spekulasi, saya tidak ada yang bisa mengatakan dengan pasti dengan informasi yang diberikan).

Selain itu, tampaknya Yahoo menerapkan pembatasan tingkat karena ping yang gigih akan mulai menghitung waktu setelah sekitar 20 paket. Apakah ini normal? bing.com bahkan tidak membalas saya!

Beberapa jaringan menyaring lalu lintas ICMP yang menurut saya sangat menjengkelkan! Sehingga bisa menjelaskan skenario "tidak ada ping sama sekali". Untuk skenario di mana Anda memiliki beberapa balasan, atau balasan terbatas, jaringan tersebut dapat mengimplementasikan teknologi seperti Cisco Plan Plan Policing (atau vendor yang setara dengan mereka).

Saat ping Twitter.com kadang-kadang saya mendapatkan TTL = 249, tetapi biasanya TTL-58.

Ketika Anda memiliki variasi hasil yang kurang stabil, rute Multi Path Biaya yang Tidak Sama dapat terjadi, atau perubahan insinyur lalu lintas karena masalah tautan di suatu tempat di jalur tersebut. Sekali lagi, tidak dapat mengatakan dengan informasi yang diberikan.


3

Perbedaan TTL pada paket-paket ini dapat dijelaskan oleh router yang membutuhkan waktu lama untuk memproses paket-paket tersebut. TTL dikurangi satu demi satu setelah setiap lompatan jika waktu melalui router kurang dari satu detik. Jika waktu yang diambil melalui router lebih besar dari TTL satu detik akan dikurangi oleh dua daripada satu.

Lihat RFC791 halaman 29:

Waktunya untuk Hidup

The time to live is set by the sender to the maximum time the
datagram is allowed to be in the internet system.  If the datagram
is in the internet system longer than the time to live, then the
datagram must be destroyed.

This field must be decreased at each point that the internet header
is processed to reflect the time spent processing the datagram.
Even if no local information is available on the time actually
spent, the field must be decremented by 1.  The time is measured in
units of seconds (i.e. the value 1 means one second).  Thus, the
maximum time to live is 255 seconds or 4.25 minutes.  Since every
module that processes a datagram must decrease the TTL by at least
one even if it process the datagram in less than a second, the TTL
must be thought of only as an upper bound on the time a datagram may
exist.  The intention is to cause undeliverable datagrams to be
discarded, and to bound the maximum datagram lifetime.

Some higher level reliable connection protocols are based on
assumptions that old duplicate datagrams will not arrive after a
certain time elapses.  The TTL is a way for such protocols to have
an assurance that their assumption is met.

2
Dengan waktu ping di bawah 300ms, ini tidak mungkin menjadi faktor dalam kasus ini, meskipun baik bagi orang untuk memahami ini juga merupakan fungsi dari TTL.
YPelajari

Saya akan sangat prihatin jika lompatan membutuhkan waktu lebih dari 1 detik untuk memproses suatu paket. Tetapi saya tidak menyadari hal ini, saya pikir bidang diubah sebagai bagian dari itu melewati prosesor, penemuan yang bagus!
Artanix

3
TTL tidak dikurangi untuk sementara dalam kehidupan nyata seperti yang disarankan RFC, ini benar-benar 'hop count', dan dinamai demikian dalam IPv6.
ytti

@ytti, benar ini memang seharusnya, tetapi beberapa perangkat akan sesuai dengan bagian RFC ini. Sementara sebagian besar perangkat arus utama tidak akan, saya telah melihat kasus sudut ini pada gigi "dari merek".
YPelajari

Saya sebenarnya telah melihatnya juga ... itulah bagaimana saya tahu tentang itu.
GerryEgan
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.