Soru Doğu batı kıyısı ABD için ne kadar ağ gecikmesi “tipik” dir?


Şu anda veri merkezimizi batı sahilinden doğu kıyısına taşıyacağımıza karar vermeye çalışıyoruz.

Ancak, batı sahilimden doğu kıyısına kadar bazı rahatsız edici gecikme sayıları görüyorum. İşte örnek bir sonuç, Google Chrome'da küçük bir .png logo dosyası alıp isteğin ne kadar sürdüğünü görmek için dev araçlarını kullanarak:

  • Batı sahillerinden doğu kıyısına:
    215 ms gecikme süresi, 46 ms aktarım süresi, 261 ms toplam
  • Batı Kıyısındaki Batı Kıyısı:
    114 ms gecikme süresi, 41 ms aktarım süresi, toplam 155 ms

O Corvallis mantıklı VEYA Berkeley konumuma coğrafi yakın, CA yüzden bağlantısı biraz daha hızlı olmasını bekliyoruz .. ama NYC aynı testi gerçekleştirirken I + 100ms gecikme bir artış görüyorum sunucusu. Bu bana .. aşırı geliyor. Özellikle gerçek verileri transfer etmek için harcanan zaman sadece% 10 arttı, ancak gecikme% 100 arttı!

Bu bana ... yanlış geliyor.

Burada yardımcı olan birkaç bağlantı buldum (Google'dan daha az değil!) ...

... ama hiçbir şey yetkili değil.

Yani bu normal mi? Normal hissetmiyor. ABD'nin batı kıyısı doğu sahilinden batı paketlerini taşırken beklemem gereken "tipik" gecikme nedir?


99
2018-04-30 11:26


Menşei


Kontrol etmediğiniz Ağlardaki tüm ölçümler neredeyse anlamsız görünüyor. Bu tür Ağ tartışmalarında sıklıkla, her paketle ilişkili geçici bir bileşen olduğunu unutuyoruz. Eğer testi tekrar tekrar 24 x 7 çalıştırdıysanız ve bir sonuca varıncaya kadar bir sonuca varmış olursunuz. Testi iki kez çalıştırdıysan, biraz daha çalıştırmanı öneririm. Ve ping'in performansın bir ölçüsü olarak kullanımını savunanlar için, yapma. Üzerinde çalıştığım her büyük ağda ICMP trafiğini en düşük önceliğe ayarladık. Ping, sadece bir şey anlamına gelir, ve performansla ilgili değildir; - dbasnett
Yaşadığım yerden Jefferson City, MO, zamanlar benzer. - dbasnett
Bir yan not olarak: Işığın kendisi, UV'den SF'ye düz bir çizgide (lifleri tamamen dikkate alarak) seyahat etmek için ~ 14ms alır. - Shadok
Elyafdaki ışık, hız faktörü .67 (kırılma indisine eşdeğer) ~ 201.000 km / s, yani en az 20 ms'dir. - Zac67


Cevaplar:


Işık hızı:
  Işık hızını ilginç bir akademik nokta olarak geçmiyorsunuz. Bu bağlantı Stanford'dan Boston'a mümkün olan en iyi zamanda ~ 40ms çalışır. Bu kişi hesaplamayı yaptığında, internetin "ışık hızının iki katından biri" ile yaklaşık olarak çalıştığına karar verdi, dolayısıyla yaklaşık 85 ms'lik aktarım süresi vardır.

TCP Pencere Boyutu:
Aktarım hızı sorunları yaşıyorsanız, alıcı pencere tcp boyutunu artırmanız gerekebilir. Bu, yüksek bir gecikmeyle yüksek bant genişliği bağlantısıysa ("Uzun Yağ Borusu" olarak adlandırılır) pencere ölçeklemeyi etkinleştirmeniz gerekebilir. Dolayısıyla, büyük bir dosya aktarıyorsanız, pencere güncellemelerini beklemek zorunda kalmadan boruyu doldurmak için yeterince büyük bir alım penceresine sahip olmanız gerekir. Cevabımda bunu nasıl hesaplayacağımı biraz detaylandırdım. Bir fil ayarlama.

Coğrafya ve Gecikme:
Bazı CDN'lerin (İçerik Dağıtımı Ağları) başarısızlığı, gecikmeyi ve coğrafyayı denkleştirmeleridir. Google, ağlarıyla çok fazla araştırma yaptı ve bu konudaki kusurları buldu ve sonuçları beyaz kağıtta yayınladı. CDN Performansını Optimize Etmek için Uçtan Uca Yol Bilgilerinin Ötesine Geçme:

İlk olarak, çoğu müşteri olmasına rağmen   coğrafi olarak yakınlardaki CDN tarafından sunulan   düğüm, istemcilerin büyük bir kısmı   deneyim gecikmeleri birkaç onlarca   diğer istemcilerden daha yüksek milisaniye   aynı bölgede. İkincisi, bulduk   bu bekleme gecikmeleri genellikle geçersiz kılınır   Etkileşen bir müşterinin faydaları   Yakındaki bir sunucu ile.

BGP Akranları:
Ayrıca, BGP (temel internet yönlendirme protokolü) ve ISP'lerin meslektaşları nasıl seçtiğini incelerseniz, genellikle finans ve politika hakkında daha fazla bilgi edinirsiniz, bu yüzden ISS'nize bağlı olarak belirli coğrafi bölgelere her zaman 'en iyi' rotayı alamazsınız. . IP'nizin, diğer ISS'lere (Otonom Sistemler) nasıl bağlı olduğunu görebilirsiniz. cam yönlendirici. Ayrıca kullanabilirsiniz özel whois hizmeti:

whois -h v4-peer.whois.cymru.com "69.59.196.212"
PEER_AS | IP               | AS Name
25899   | 69.59.196.212    | LSNET - LS Networks
32869   | 69.59.196.212    | SILVERSTAR-NET - Silver Star Telecom, LLC

Aynı zamanda bu gibi bir gui aracıyla peerings olarak keşfetmek için eğlenceli linkrankSize etrafınızdaki internetin resmini veriyor.


108
2018-04-30 12:03



katılıyorum, karga uçar gibi ışık hızı, muhtemelen yapabileceğiniz en iyisidir. Bu arada mükemmel bir cevap, tam da aradığım şey bu. Teşekkür ederim. - Jeff Atwood
Merak için gerçek matematik: 3000 mi / c = 16.1ms - tylerl
Bir vakumda bir foton, ekvatoru yaklaşık olarak 134 ms'de hareket ettirebilir. Camdaki aynı foton yaklaşık 200 ms sürer. 3.000 millik bir lif parçası 24 ms'dir. herhangi bir cihaz olmadan gecikme. - dbasnett
Bu bana hatırlatıyor 500 Mile E-postası Örneği. - bahamat


Bu site Doğu / Batı Kıyısı arasındaki 70-80 ms arası gecikme önerisi tipiktir (örneğin San Francisco'dan New York'a).

Trans-Atlantik Yolu
NY 78 Londra
Yıkama 87 Frankfurt
Trans-Pasifik Yolu
SF 147 Hong Kong
Trans-ABD Yolu
SF 72 NY

network latency by world city pairs

Benim zamanlamalarım (Londra, İngiltere'deyim, bu yüzden Batı kıyılarım doğudan daha yüksek). Bu sitenin değerini destekliyor gibi görünen bir 74ms gecikme farkı alıyorum.

NY - 108ms latency, 61ms transfer, 169 total
OR - 182ms latency, 71ms transfer, 253 total

Bunlar Google Chrome araçları kullanılarak ölçülmüştür.


41
2018-04-30 11:45



havalı grafik! NY'den SF'ye şu anda 71 ms Bunun üzerine haklısınız - bundan daha iyisini yapamayız. - Jeff Atwood
Teşekkürler. Bana çok yardımcı oldu. Bu, dünyanın farklı yerleri arasındaki ağ gecikmesini aramak için başka bir kaynaktır - dotcom-monitor.com/WebTools/network_latency.aspx - Sajib Mahmood


Mümkünse önce ICMP ile ölçün. ICMP testleri genellikle çok küçük bir yükü varsayılan olarak kullanır, üç yollu bir el sıkışma kullanmaz ve HTTP gibi yığında başka bir uygulama ile etkileşime girmez. Durum ne olursa olsun, HTTP sonuçlarının ICMP sonuçları ile karıştırılmaması son derece önemlidir. Onlar elma ve portakaldır.

Tarafından gidiyor Rich Adams'ın cevabı ve kullanarak site önerdiği gibi, AT & T'nin omurgasında, ICMP trafiğinin SF ve NY uç noktaları arasında hareket etmesinin 72 ms sürdüğünü görebiliyorsunuz. Bu adil bir numaradır, ancak bunun AT & T tarafından tamamen kontrol edilen bir ağda olduğunu unutmamalısınız. Ev veya ofis ağınıza geçişi hesaba katmaz.

Kaynak ağınızdan careers.stackoverflow.com'a karşı bir ping yaparsanız, 72 ms (belki +/- 20 ms) çok uzak olmayan bir şey görmelisiniz. Eğer durum buysa, muhtemelen ikiniz arasındaki ağ yolunun iyi olduğunu ve normal aralıklar içinde çalıştığını varsayabilirsiniz. Değilse, panik yapmayın ve birkaç yerden ölçün. ISS'niz olabilir.

Bunu kabul ettiğinizde, bir sonraki adım, uygulama katmanını ele almak ve HTTP taleplerinizle gördüğünüz ek yükle ilgili bir sorun olup olmadığını belirlemek. Bu uygulama, donanım, işletim sistemi ve uygulama yığını nedeniyle uygulamadan uygulamaya değişebilir, ancak hem Doğu hem de Batı sahillerinde kabaca aynı ekipmana sahip olduğunuzdan, Doğu sahili kullanıcılarının Batı sahili sunucularını yakalamalarına ve Batı sahili kullanıcılarının Doğu'ya çarpmasını sağlayabilirsiniz. sahil. Her iki site de uygun şekilde yapılandırılmışsa, tüm sayıların daha az eşit olmasını ve dolayısıyla gördüğünüz şeyin kaba için oldukça fazla olduğunu göstermeyi beklerdim.

Bu HTTP süreleri geniş bir varyansa sahipse, daha yavaş performans gösteren sitede bir yapılandırma sorunu varsa şaşırmam.

Şimdi, bu noktaya geldiğinizde, bu sayıların hiç azaltılamayacağını görmek için uygulama tarafında biraz daha agresif optimizasyon yapmaya çalışabilirsiniz. Örneğin, IIS 7 kullanıyorsanız, önbelleğe alma yeteneklerinden, vb. Faydalanıyor musunuz? Belki orada bir şey kazanabilirsin belki de. TCP pencereleri gibi düşük seviyeli öğelerin düzeltilmesi söz konusu olduğunda, Stack Overflow gibi bir şey için çok fazla etkiye sahip olacağını çok şüpheliyim. Ama hey - bunu denemeden ve ölçene kadar bilmeyeceksin.


10
2018-04-30 17:34





Buradaki cevaplardan bazıları açıklamaları için ping ve traceroute kullanıyor. Bu araçların yerleri vardır, ancak ağ performans ölçümü için güvenilir değildirler.

Özellikle, (en azından bazı) Juniper yönlendiriciler, ICMP olaylarının yönlendiricinin kontrol düzlemine işlenmesini sağlar. Bu özellikle bir omurga yönlendiricisinde yönlendirme düzleminden daha yavaştır.

ICMP yanıtının bir yönlendiricinin gerçek yönlendirme performansından çok daha yavaş olabileceği başka durumlar da vardır. Örneğin, CPU kapasitesinin% 99'unda olan tüm yazılım yönlendiricisini (özel iletme donanımı yok) düşünün, ancak hala trafiği düzgün şekilde hareket ettiriyor. Traceroute yanıtlarını işlemek veya trafiği yönlendirmek için çok fazla döngü harcamanızı ister misiniz? Yani yanıtı işlemek süper düşük önceliklidir.

Sonuç olarak, ping / traceroute size mantıklı üst sınır - işler en azından o kadar hızlı gidiyor - ama gerçek trafiğin ne kadar hızlı gittiğini söylemiyorlar.

Herhangi bir olayda -

İşte Michigan Üniversitesi'nden (merkezi ABD) Stanford'a (ABD'nin batı kıyısı) bir örnek traceroute. (Washington, DC'den (doğu yakası ABD), "yanlış" yönde 500 mil yol kat eder.)

% traceroute -w 2 www.stanford.edu
traceroute to www-v6.stanford.edu (171.67.215.200), 64 hops max, 52 byte packets
 1  * * *
 2  * * *
 3  v-vfw-cc-clusta-l3-outside.r-seb.umnet.umich.edu (141.211.81.130)  3.808 ms  4.225 ms  2.223 ms
 4  l3-bseb-rseb.r-bin-seb.umnet.umich.edu (192.12.80.131)  1.372 ms  1.281 ms  1.485 ms
 5  l3-barb-bseb-1.r-bin-arbl.umnet.umich.edu (192.12.80.8)  1.784 ms  0.874 ms  0.900 ms
 6  v-bin-arbl-i2-wsu5.wsu5.mich.net (192.12.80.69)  2.443 ms  2.412 ms  2.957 ms
 7  v0x1004.rtr.wash.net.internet2.edu (192.122.183.10)  107.269 ms  61.849 ms  47.859 ms
 8  ae-8.10.rtr.atla.net.internet2.edu (64.57.28.6)  28.267 ms  28.756 ms  28.938 ms
 9  xe-1-0-0.0.rtr.hous.net.internet2.edu (64.57.28.112)  52.075 ms  52.156 ms  88.596 ms
10  * * ge-6-1-0.0.rtr.losa.net.internet2.edu (64.57.28.96)  496.838 ms
11  hpr-lax-hpr--i2-newnet.cenic.net (137.164.26.133)  76.537 ms  78.948 ms  75.010 ms
12  svl-hpr2--lax-hpr2-10g.cenic.net (137.164.25.38)  82.151 ms  82.304 ms  82.208 ms
13  hpr-stanford--svl-hpr2-10ge.cenic.net (137.164.27.62)  82.504 ms  82.295 ms  82.884 ms
14  boundarya-rtr.stanford.edu (171.66.0.34)  82.859 ms  82.888 ms  82.930 ms
15  * * *
16  * * *
17  www-v6.stanford.edu (171.67.215.200)  83.136 ms  83.288 ms  83.089 ms

Özellikle, traceroute arasındaki zaman farkını not edin. yıkama yönlendirici ve atla yönlendirici (7 ve 8 numaralı). ağ yolu ilk önce yıkamak ve sonra atla gider. Yıkama cevap vermek için 50-100ms alır, atla yaklaşık 28ms alır. Açıkça, atla daha uzaktadır, ancak traceroute sonuçları daha yakın olduğunu göstermektedir.

Görmek http://www.internet2.edu/performance/ Ağ ölçümünde birçok bilgi için. (feragatname, internet2 için çalışıyordum). Ayrıca bakınız: https://fasterdata.es.net/

Özgün soruya özel bir ilgi eklemek için ... Gördüğünüz gibi, 83 ms'lik bir gidiş-dönüş ping zamanım vardı, bu yüzden ağın en azından bu kadar hızlı geçebileceğini biliyoruz.

Bu traceroute üzerinde yaptığım araştırma ve eğitim ağı yolunun bir meta internet yolundan daha hızlı olabileceğini unutmayın. Ar-Ge ağları genellikle bağlantılarını aşırı derecede geliştirir, bu da her yönlendiricinin arabelleğe alınmasını olanaksız hale getirir. Ayrıca, gerçek trafiğin açık bir şekilde temsil edilmesine rağmen, kıyıdan sahile daha uzun olan uzun fiziksel yola dikkat edin.

michigan-> washington, dc-> atlanta-> houston-> los angeles-> stanford


7
2017-08-15 15:46





Tutarlı farklılıklar görüyorum ve ben Norveç'te oturuyorum:

serverfault       careers
  509ms            282ms
  511ms            304ms
  488ms            295ms
  480ms            274ms
  498ms            278ms

Bu, Google Chrome'un kaynak görünümünü kullanmanın bilimsel olarak doğru ve kanıtlanmış yöntemi ile ölçülmüş ve her bir bağlantıyı tekrar tekrar yenilemiştir.

Traceroute to serverfault

Tracing route to serverfault.com [69.59.196.212]
over a maximum of 30 hops:

  1    <1 ms     1 ms    <1 ms  81.27.47.1
  2     2 ms     1 ms     1 ms  qos-1.webhuset.no [81.27.32.17]
  3     1 ms     1 ms     1 ms  81.27.32.10
  4     1 ms     2 ms     1 ms  201.82-134-26.bkkb.no [82.134.26.201]
  5    14 ms    14 ms    14 ms  193.28.236.253
  6    13 ms    13 ms    14 ms  TenGigabitEthernet8-4.ar1.OSL2.gblx.net [64.209.94.125]
  7    22 ms    21 ms    21 ms  te7-1-10G.ar3.cph1.gblx.net [67.16.161.93]
  8    21 ms    20 ms    20 ms  sprint-1.ar3.CPH1.gblx.net [64.212.107.18]
  9    21 ms    21 ms    20 ms  sl-bb20-cop-15-0-0.sprintlink.net [80.77.64.33]
 10   107 ms   107 ms   107 ms  144.232.24.12
 11   107 ms   106 ms   105 ms  sl-bb20-msq-15-0-0.sprintlink.net [144.232.9.109]
 12   106 ms   106 ms   107 ms  sl-crs2-nyc-0-2-5-0.sprintlink.net [144.232.20.75]
 13   129 ms   135 ms   134 ms  sl-crs2-chi-0-15-0-0.sprintlink.net [144.232.24.208]
 14   183 ms   183 ms   184 ms  sl-crs2-chi-0-10-3-0.sprintlink.net [144.232.20.85]
 15   189 ms   189 ms   189 ms  sl-gw12-sea-2-0-0.sprintlink.net [144.232.6.120]
 16   193 ms   189 ms   189 ms  204.181.35.194
 17   181 ms   181 ms   180 ms  core2-gi61-to-core1-gi63.silverstartelecom.com [74.85.240.14]
 18   182 ms   182 ms   182 ms  sst-6509b-gi51-2-gsr2-gi63.silverstartelecom.com [74.85.242.6]
 19   195 ms   195 ms   194 ms  sst-6509-peak-p2p-gi13.silverstartelecom.com [12.111.189.106]
 20   197 ms   197 ms   197 ms  ge-0-0-2-cvo-br1.peak.org [69.59.218.2]
 21   188 ms   187 ms   189 ms  ge-1-0-0-cvo-core2.peak.org [69.59.218.193]
 22   198 ms   198 ms   198 ms  vlan5-cvo-colo2.peak.org [69.59.218.226]
 23   198 ms   197 ms   197 ms  stackoverflow.com [69.59.196.212]

Trace complete.

Kariyer için Traceroute

Tracing route to careers.stackoverflow.com [64.34.80.176]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  81.27.47.1
  2     2 ms     1 ms    <1 ms  qos-1.webhuset.no [81.27.32.17]
  3     1 ms     1 ms     1 ms  81.27.32.10
  4     1 ms     1 ms     2 ms  201.82-134-26.bkkb.no [82.134.26.201]
  5    12 ms    13 ms    13 ms  193.28.236.253
  6    13 ms    14 ms    14 ms  TenGigabitEthernet8-4.ar1.OSL2.gblx.net [64.209.94.125]
  7    21 ms    21 ms    21 ms  ge7-1-10G.ar1.ARN3.gblx.net [67.17.109.89]
  8    21 ms    20 ms    20 ms  tiscali-1.ar1.ARN3.gblx.net [64.208.110.130]
  9   116 ms   117 ms   122 ms  xe-4-2-0.nyc20.ip4.tinet.net [89.149.184.142]
 10   121 ms   122 ms   121 ms  peer1-gw.ip4.tinet.net [77.67.70.194]
 11     *        *        *     Request timed out.

Ne yazık ki, şimdi bir döngüye girmeye başlıyor ya da 30 atlamaya kadar yıldız ve zaman aşımı yapmaya devam ediyor ve bitiyor.

Not, traceroutes başlangıçta zamanlamalardan farklı bir ana bilgisayardan geliyor, barındırılan sunucumun yürütmesi için RDP'ye gerekiyordu.


6
2018-04-30 11:43



sağda, doğu kıyısı veri merkezinin Avrupalı ​​seyircilerimiz için daha dostane olması bekleniyor - ABD'nin genişliğini geçmek için + 200 ms sürdüğünüzü görüyorsunuz. Diğer cevaplara göre sadece ~ 80ms olmalı? - Jeff Atwood
200ms civarında tutarlı gibi gözüküyor, 20-30 kez şimdi yenilemeye başladım (aynı zamanda değil), ve serverfault sitesi 200 ms civarında geziniyor gibi görünüyor. . Bir traceroute denedim, ama her şeyden yıldızlarla geliyor, bu yüzden IT yöneticilerimiz bir şeyi engellediler. - Lasse Vågsæther Karlsen


Doğu ve Batı kıyıları arasında iyi ölçülmüş bağlantılar üzerinde iyi 80-90ms gecikme görüyorum.

Gecikme kazandığınızı görmek ilginç olurdu - katman dört traceroute (lft) gibi bir araç deneyin. Şanslar, "son mil" (yani, yerel geniş bant sağlayıcınızdaki) üzerinde bir çok şey kazanıyor.

Aktarım süresinin sadece çok az etkilenmiş olması beklenir - paket kaybı ve titreşim, iki konum arasındaki transfer süresi farklarını araştırırken bakmak için daha yararlı ölçümlerdir.


2
2018-04-30 11:42





Sadece eğlence için, Avrupa'daki online oyun Lineage 2 NA sürümünü oynadığımda:

Response time to east coast servers: ~110-120ms
Response time to west coast servers: ~190-220ms

Fark, internetin tahmin edilemez doğası göz önünde bulundurularak, 100 ms'ye kadar olan bir nedenin varlığını destekliyor gibi görünüyor.

Takdir edilen Chrome yenileme testini kullanarak, yaklaşık 130ms'lik farklı belge yükleme süresi elde ediyorum.


2
2018-04-30 12:52





Buradaki herkesin gerçekten iyi bir noktası var. ve kendi POV'larında doğrular.

Ve burada gerçek bir cevap yoktur, çünkü burada çok fazla değişken var, verilen her cevap yüzlerce değişkenden birini değiştirerek her zaman yanlış kanıtlanabilir.

72ms NY ila SF gecikme süresi gibi bir paketin bir taşıyıcının PoP'den PoP'ye olan gecikme süresidir. Bu, bazılarının burada tıkanıklık, paket kaybı, hizmet kalitesi, sipariş paketleri veya paket boyutu veya PoP'un PoP'un mükemmel dünyası arasında yeniden yönlendirilmesiyle ilgili diğer önemli noktaları dikkate almaz. .

Ve sonra, bu değişkenin çok daha akıcı bir şey haline geldiği iki şehir içinde PoP'tan son mil (genellikle bir kaç mil) eklediğinizde, mantıklı tahmin yeteneğinden katlanarak yükselmeye başlarsınız!

Örnek olarak, bir iş günü boyunca NY şehri ve SF arasında bir test yaptım. Bunu bir günde yaptım, dünyanın her tarafında trafikte bir artışa neden olacak büyük bir "olay" yoktu. Yani belki bu bugünün dünyasında ortalama değildi! Ama yine de benim testimdi. Aslında bu dönemde bir iş yerinden diğerine ve her kıyıdaki normal iş saatlerinde ölçtüm.

Aynı zamanda, web üzerindeki devre sağlayıcı sayılarını da izledim.

Sonuçlar, iş yerlerinin kapıdan kapıya 88 ve 100 ms arasında bir gecikme sayısıydı. Bu, herhangi bir ofis ağı gecikme sayısı içermiyordu.

Servis sağlayıcı ağları gecikme süresi 70 ila 80 ms arasındaydı. Son mil gecikmesi anlamı 18 ila 30 ms arasında değişebilirdi. İki ortam arasındaki kesin zirveleri ve alçakları ilişkilendirmedim.


2
2017-09-09 15:43





NYC Zamanlamaları:

NY     OR
109ms  271ms
72ms   227ms
30ms   225ms
33ms   114ms
34ms   224ms

Chrome'u bir konut bağlantısında kullanma.

Newark, New Jersey'deki bir veri merkezindeki bir VPS'den lft kullanarak:

terracidal ~ # lft careers.stackoverflow.com -V
Layer Four Traceroute (LFT) version 3.0
Using device eth0, members.linode.com (97.107.139.108):53
TTL LFT trace to 64.34.80.176:80/tcp
 1  207.192.75.2 0.4/0.5ms
 2  vlan804.tbr2.mmu.nac.net (209.123.10.13) 0.4/0.3ms
 3  0.e1-1.tbr2.tl9.nac.net (209.123.10.78) 1.3/1.5ms
 4  nyiix.Peer1.net (198.32.160.65) 1.4/1.4ms
 5  oc48-po3-0.nyc-75bre-dis-1.peer1.net (216.187.115.134) 1.6/1.5ms
 6  216.187.115.145 2.7/2.2ms
 7  64.34.60.28 2.3/1.8ms
 8  [target open] 64.34.80.176:80 2.5ms

terracidal ~ # lft serverfault.com -V
Layer Four Traceroute (LFT) version 3.0
Using device eth0, members.linode.com (97.107.139.108):53
TTL LFT trace to stackoverflow.com (69.59.196.212):80/tcp
 1  207.192.75.2 36.4/0.6ms
 2  vlan803.tbr1.mmu.nac.net (209.123.10.29) 0.4/0.4ms
 3  0.e1-1.tbr1.tl9.nac.net (209.123.10.102) 1.3/1.4ms
 4  nyk-b3-link.telia.net (213.248.99.89) 1.6/1.4ms
 5  nyk-bb2-link.telia.net (80.91.250.94) 1.9/84.8ms
 6  nyk-b5-link.telia.net (80.91.253.106) 1.7/1.7ms
 7  192.205.34.53 2.1/2.1ms
 8  cr1.n54ny.ip.att.net (12.122.81.106) 83.5/83.6ms
 9  cr2.cgcil.ip.att.net (12.122.1.2) 82.7/83.1ms
10  cr2.st6wa.ip.att.net (12.122.31.130) 83.4/83.5ms
11  cr2.ptdor.ip.att.net (12.122.30.149) 82.7/82.7ms
12  gar1.ptdor.ip.att.net (12.123.157.65) 82.2/82.3ms
13  12.118.177.74 82.9/82.8ms
14  sst-6509b-gi51-2-gsr2-gi63.silverstartelecom.com (74.85.242.6) 84.1/84.0ms
15  sst-6509-peak-p2p-gi13.silverstartelecom.com (12.111.189.106) 83.3/83.4ms
16  ge-0-0-2-cvo-br1.peak.org (69.59.218.2) 86.3/86.2ms
**  [neglected] no reply packets received from TTLs 17 through 18
19  [target closed] stackoverflow.com (69.59.196.212):80 86.3/86.3ms

1
2018-04-30 12:10