Traceroute neden ping'ten daha uzun sürüyor?

16

Bunu nasıl açıklayabilirim?

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.

Ortalama süre şöyle olmalı: 1 + 7 + 108 + 2 + 1 + 1 + 2 + 1 + 1 + 2 + 2 + 33 + 34 + 34 + 35 + 34 + 34 + 35 + 34, ki bu çok daha büyük 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 
— splattne
kaynak
3
Bu soruya çok kötü cevaplar. Hepiniz bana bir bakıma youtube.com/watch?v=SXmv8quf_xM
— Tom O'Connor

Yanıtlar:

16

Tüm bu numaraları bir araya getiremezsiniz. Bu, google yolundaki atlamaların her birine ping zamanı. Böylece, yolun her ayağı gittikçe uzaklaşıyor ve değişen ping süreleri görüyorsunuz. Tracert'teki (34 ms) son ping süresine ve ping'i (34 ms) verdiğinizde aldığınız süreye bakarsanız, bunlar aynıdır. Tracert programı ping'ten daha yavaş değildir.

Bir traceroute'un nasıl çalıştığını okumanızı öneririm:
http://en.wikipedia.org/wiki/Traceroute

— einstiien
kaynak
Öyle değil farther and farther away.
Ne demek istediğini anlamıyorum. Traceroute'ta listelenen her IP adresi, sizinle google arasındaki bir sonraki yönlendiricinin adresidir. "Mantıksal" ağ topolojisinde, listede ilerledikçe bunlar daha da uzaklaşır. Ayrıca, çoğunlukla coğrafi konumunuzdan fiziksel olarak uzaklaşırlar. Bu her zaman doğru olmasa da, bazen rotalar haritanın etrafında "gereksiz yere" atlıyor gibi görünüyor. Ama benim açımdan fiziksel mesafenin ve çoklu atlamaların ping süresini arttırdığı.
— einstiien
Rotadaki her düğüme ping atmayı deneyin. Aynı toplamı (kabaca) bulmalısınız.
— Chris Nava
1
Belki PHP yanlış stackoverflow sitesinde ve araçlarla üzerindedir uzak oysa fiziksel mesafeye atıfta ayrıca ağ mesafe için daha uygundur? english.stackexchange.com
— dunxd
12

Ping'i New York'tan San Francisco'ya bir sürüş gibi görebilirsiniz. Diyelim, 200 saat diyelim (İsviçre'den im ve ABD'deki mesafelere aşina değilim)

Ancak Sürücü San Francisco'da olduğunu söylemek için New York'a geri dönmeli. Saate bir bakıyorsunuz ve şimdi mesafe için 400 saat sürdüğünü hesaplıyorsunuz. Şimdi Ping bunu yapıyor. Traceroute'un yaptığı: Şoförünüze New York'tan San Franciso'ya gitmesi gerektiğini söyleyin ve her kavşağa geldiğinde geri gelip size adını söylemelidir. Bu yüzden yolda ve ilk birkaç kavşak New York'ta. Bu yüzden size geri dönüp size kavşak adını söyleyerek oldukça hızlı. Ama daha da uzaklaşınca sana dönmesi daha uzun sürecek. ve bunun gibi...

Bu yüzden tüm sürüş saatlerini sayarsanız, tüm kavşakları rapor etmek için San Francisco'ya gitmek zorunda olduğundan çok daha uzun sürebilirdi. Umarım bu sizin için bazı şeyleri temizler ...

— Bona
kaynak
2
Daha iyi bir benzetme, her birine New York'a gitmelerini söyleyen 30 sürücü göndermenizdir, ancak her biri dönüp ilk kavşakta, ikinci kavşakta, üçüncü kavşakta vb. otuz kavşağa kadar olan yol (SF ve NY arasında 30'dan az olması umuduyla).
— Jed Daniels
0

Aslında PING'in ağ üzerinden DNS ve diğer Ağın cihazına bir ICMP isteği göndermesinden kaynaklanmaktadır.

Ancak, Traceroute gerçekten kısa bir TTL ile çok sayıda paquet gönderir.

Www.google.com adresine koltuğunuzdan katılmaya çalıştığınızda, traceroute www.google.com'a TTL değeri 1 olarak ayarlanmış bir paquet gönderdi ve ilk karşılaşma ağının cihazından bir yanıt bekleyin.

Ardından, Traceroute ilk ağın cihazının IP'sini ekranınızda görüntüler ve sonra aynı şeyi yapar, ancak bu sefer bir TTL 2'ye ayarlanmış vb.

Sonunda, Traceroute yaklaşık yarım kez daha bekledi, çünkü her gönderimde bir ağ cihazının cevabını bekliyor.

— Dr I
kaynak
0

Traceroute size her zaman hedefin ortalamasını söyler, bir zaman birikimi değil, yani sizin durumunuzda pingve ile 34 ms'dir traceroute.

Traceroute önerdiğiniz şeyi yapsaydı, çıktısı oldukça okunamaz olurdu.

Yalnızca hedefin yanıt süresiyle ilgileniyorsanız ping, oldukça yeterlidir, traceroutehedefe giden yolda bir şeyde hata ayıklamanız gerektiğinde içindir. Dahası, sizinle hedef arasındaki tüm atlama yönlendiricilerdir ve çoğu zaman yönlendiricilerin ne yapacağına, yani ilk yol paketlerine ve ardından ping veya traceroute'a (yani ilk duruma, bir icmp echo replyve ikinci durumda, a icmp time exceeded) yanıtlar ve daha yavaş yanıtlar (hiç cevap verdiklerinde)

— mat
kaynak
0

Gelecek nesiller için, doğru cevapların hiçbiri çok açık olmadığı için ...

-

Traceroute'ta gösterilen her zaman, MAKİNENİZDEN (veya traceroute yapan makine ...) BU ÖZEL NODE TOPLAM ZAMAN'dır.

Başka bir deyişle, 2. düğümde gösterilen zaman, düğüm 1 ve 2 arasında geçen zaman değil, kaynak, birinci düğüm ve ikinci düğüm arasındaki toplam süredir.

Ortalama olarak, her bir düğümde gösterilen zamanlar, o belirli düğüme "doğrudan" ping atmak için alacağınız zamanlarla kabaca eşleşmelidir (gerçekte bir izden daha doğrudan değildir ... genellikle aynı yolu takip edecektir. internette).

Sadece "gecikme başlangıcı" diye bir şey olduğunu unutmayın. Herhangi bir gecikmenin kaynağını bulmanın en doğru yolu, bir toplu iş dosyası (Windows'daysanız) kullanarak tekrarda bir izleme yolu çalıştırmak ve herhangi bir zamanda yüksek sayıya sahip en yakın (en düşük numaralı) düğümü bulmaktır.

-

Toplu iş dosyası için not defterini açın ve şu 3 satırı yazın:

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

Sonra "Trace.bat" olarak kaydedin, ancak kaydetmeden önce kaydet iletişim kutusundaki dosya türünü "tüm dosyalar" olarak değiştirdiğinizden emin olun, aksi halde metin dosyası olarak kaydedilecektir.

Açıldığında, sürekli olarak traceroutes (google'a) çalıştırılır. Pencereyi seçerken ctrl + c tuşlarına basarak durdurabilirsiniz.

-

Elbette, "www.google.com" u istediğiniz adresle değiştirerek traceroute'u çalıştırdığı yeri değiştirebilirsiniz.

Çözülmüş ana bilgisayar adlarını görmek istiyorsanız "-d" seçeneğini de kaldırabilirsiniz, ancak bu, her düğüm için bir DNS sunucusundan adı geçen ana bilgisayar adlarının alınması nedeniyle traceroute'un daha uzun sürmesini sağlar (ancak gerçek sonuçları kendileri DEĞİL DEĞİLDİR) ).

Son olarak, yüksek sürelere sahip bir düğüm bulursanız ve sorun çıkmadan önce başka bir düğüm olması durumunda söz konusu düğümde izlemeler çalıştırmak istiyorsanız, "www.google.com" adresini söz konusu düğümün ip adresine veya ana makine adına değiştirebilirsiniz, VEYA aramak için kaç düğüm belirtmek için -h seçeneğini kullanabilirsiniz, yani ...

:start
tracert -d -h 5 www.google.com
goto start
— Laike Endaril
kaynak
Önemli bir not, bir düğümün ICMP ile yanıt vermesidir, ancak bir yönlendiricinin birincil amacı paketleri yönlendirmektir ve ICMP yanıtları oluşturmak, yaptığı şeyin listesinin çok altındadır. Bir yönlendirici yönlendirilecek ve zaman geldiğinde ICMP mesajlarını göndermeye başlayacaktır. Bu nedenle ara süre tam yoldan daha uzun olabilir; ara yönlendirici uç düğümden çok daha yoğun olabilir.
— Ron Maupin
Evet, ICMP'nin QOS önceliği genellikle daha düşüktür, ancak bir traceroute çalıştırdığınızda çoğu zaman, bunun nedeni bir sorunun zaten mevcut olması (bir oyunda gecikme ani veya kötü ping geçirmeniz) ve bahsettiğiniz belirli düğümdür ( meşgul olan) aradığınız darboğazdır.
— Laike Endaril
QoS önceliğini kastetmiyorum, demek istediğim cihazın kendisi bir ICMP yanıtı oluşturuyor. Düğüm, orijinal düğüm zaman aşımına uğramadan önce ICMP iletisi göndermeye çalışmak için paketleri meşgul etmek için çok meşgul olabilir. Bir yönlendirici, ICMP mesajı göndermeye karar vermeden önce paketleri yönlendirecektir. Bunun QoS ile bir ilgisi yok.
— Ron Maupin
QoS çok gevşek bir şekilde tanımlanmış bir terimdir ve ekstra dikkat gerektiren faaliyetleri (bir yanıt paketi oluşturmak) hariç, aynı kaynak kümesini kullanan tüm etkinlikleri içerdiğini düşünüyorum. Her iki durumda da, bu, söz konusu yönlendiricinin çok ağır bir yük altında olduğu ve sorunlara neden olduğu gerçeğini değiştirmez, bu nedenle bir traceroute'tan yüksek süreler, sorunlarınızın yattığı yerler için hala iyi bir göstergedir ... ICMP'nizden daha yüksek önceliğe, ancak normal trafiğinizden daha düşük bir önceliğe sahip büyük miktarda trafik olası istisnası.
— Laike Endaril
-1

Tracert UDP paketleri kullandığından ping gibi ICMP paketleri kullanır. Linux altında, traceroute -IICMP traceroute yapma seçeneği vardır.

Testinizde google'a bağlanma süresi traceroute ve ping: 34ms'de aynıdır. Ortadaki tüm yönlendiricilerin cevaplamak için kendi zamanları vardır, ancak son aktarım süresini etkilemez.

http://en.wikipedia.org/wiki/Traceroute Traceroute'taki tüm açıklamaları

— Dom
kaynak
3
Aslında, Windows'ta, tracertLinux'un aksine, varsayılan olarak ICMP kullanır traceroute.
— phoebus
tracert, ICMP dönemini kullanır. ICMP IP protokolü 1, UDP
— 17'dir
@dbasnett Başlangıçta, traceroute giden paketleri UDP olarak gönderdi ve dönüş paketleri elbette ICMP TTL iletilerini aştı. Windows ve şimdi diğer traceroute programları gidenler için ICMP yankı istek paketlerini kullanmaktadır. Tipik olarak insanlar UDP traceroute veya ICMP traceroute'a atıfta bulunduklarında, atıfta bulundukları bu giden paketlerdir, çünkü BOTH mekanizmaları ICMP TTL'ye dayanır, rota boyunca atlamalardan geri gönderilen iletileri aştı.
— Jed Daniels
-1

Traceroute'unuzu, genellikle başarısız olan ters dns aramasını devre dışı bırakarak artırabilirsiniz: tracert -d www.google.com

— Mathieu Chateau
kaynak
Bu gidiş dönüş sürelerini daha hızlı yapmaz. Ancak, DNS aramaları yapmadığı için sonuçları ekranınıza döndürmeyi hızlandırır.
— Jed Daniels
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.