Pertanyaan Berapa latensi jaringan "tipikal" untuk pantai timur-barat AS?


Saat ini kami sedang memutuskan apakah akan memindahkan pusat data kami dari pantai barat ke pantai timur.

Namun, saya melihat beberapa nomor latensi yang mengganggu dari lokasi pantai barat saya ke pantai timur. Berikut ini hasil contoh, mengambil file logo .png kecil di Google Chrome dan menggunakan alat dev untuk melihat berapa lama permintaan akan mengambil:

  • Pantai barat ke pantai timur:
    215 ms latency, waktu transfer 46 ms, 261 ms total
  • Pantai barat ke pantai barat:
    114 ms latency, waktu transfer 41 ms, total 155 ms

Masuk akal bahwa Corvallis, ATAU secara geografis lebih dekat dengan lokasi saya di Berkeley, CA jadi saya berharap koneksi menjadi sedikit lebih cepat .. tapi saya melihat peningkatan latensi + 100ms ketika saya melakukan tes yang sama ke NYC server Kelihatannya .. berlebihan bagiku. Khususnya sejak waktu yang dihabiskan untuk mentransfer data aktual hanya meningkat 10%, namun latensi meningkat 100%!

Itu terasa ... salah ... bagiku.

Saya menemukan beberapa tautan di sini yang bermanfaat (melalui Google tidak kurang!) ...

... tapi tidak ada yang otoritatif.

Jadi, apakah ini normal? Itu tidak terasa normal. Apa latensi "umum" yang saya harapkan ketika memindahkan paket jaringan dari pantai timur <-> pantai barat Amerika Serikat?


99
2018-04-30 11:26




Pengukuran apa pun di seluruh Jaringan yang Anda kendalikan tampaknya tidak berguna. Terlalu sering dalam jenis diskusi Jaringan tampaknya kita lupa ada komponen temporal yang terkait dengan setiap paket. Jika Anda menjalankan tes berulang-ulang 24 x 7 dan tiba pada suatu kesimpulan itu adalah satu hal. Jika Anda menjalankan tes dua kali maka saya sarankan Anda menjalankannya lagi. Dan bagi mereka yang menganjurkan penggunaan ping sebagai ukuran kinerja, tidak. Di setiap jaringan utama yang pernah saya kerjakan, kami mengatur lalu lintas ICMP ke prioritas terendah. Ping hanya berarti satu hal, dan tidak;) tentang kinerja. - dbasnett
Dari tempat saya tinggal, Kota Jefferson, MO, waktunya sama. - dbasnett
Sebagai catatan samping: cahaya itu sendiri membutuhkan waktu ~ 14 mil untuk melakukan perjalanan dari NY ke SF dalam garis lurus (mempertimbangkan serat sepanjang jalan). - Shadok
Cahaya dalam serat bergerak dengan faktor kecepatan 0,67 (setara dengan indeks bias) ~ 201.000 km / s, jadi setidaknya 20 ms. - Zac67


Jawaban:


Kecepatan cahaya:
  Anda tidak akan mengalahkan kecepatan cahaya sebagai titik akademis yang menarik. Link ini berhasil Stanford ke Boston pada ~ 40ms waktu terbaik yang mungkin. Ketika orang ini melakukan perhitungan, dia memutuskan internet beroperasi sekitar "dalam faktor dua kecepatan cahaya", jadi ada sekitar ~ 85ms waktu transfer.

Ukuran Jendela TCP:
Jika Anda mengalami masalah kecepatan transfer, Anda mungkin perlu meningkatkan ukuran tcp jendela penerima. Anda mungkin juga perlu mengaktifkan penskalaan jendela jika ini adalah koneksi bandwidth tinggi dengan latensi tinggi (Disebut "Long Fat Pipe"). Jadi jika Anda mentransfer file besar, Anda harus memiliki jendela penerima yang cukup besar untuk mengisi pipa tanpa harus menunggu pembaruan jendela. Saya pergi ke beberapa detail tentang bagaimana menghitung itu dalam jawaban saya Tuning an Elephant.

Geografi dan Latensi:
Titik kegagalan beberapa CDN (Content Distribtuion Networks) adalah bahwa mereka menyamakan latensi dan geografi. Google melakukan banyak penelitian dengan jaringan mereka dan menemukan kekurangan dalam hal ini, mereka mempublikasikan hasilnya di kertas putih Bergerak di Luar Informasi Jalur End-to-End untuk Mengoptimalkan Kinerja CDN:

Pertama, meskipun sebagian besar klien   dilayani oleh CDN secara geografis di dekatnya   node, sebagian besar klien   mengalami latensi beberapa puluh   milidetik lebih tinggi dari klien lain   di wilayah yang sama. Kedua, kami temukan   bahwa penundaan antrean sering kali menimpa   manfaat dari klien yang berinteraksi   dengan server terdekat.

Peerings BGP:
Juga jika Anda mulai mempelajari BGP (protokol routing internet inti) dan bagaimana ISP memilih peering, Anda akan menemukan lebih sering tentang keuangan dan politik, sehingga Anda mungkin tidak selalu mendapatkan rute 'terbaik' ke lokasi geografis tertentu tergantung pada ISP Anda. . Anda dapat melihat bagaimana IP Anda terhubung ke ISP lain (Sistem Otonom) menggunakan mencari router kaca. Anda juga bisa menggunakan layanan whois khusus:

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

Ini juga menyenangkan untuk mengeksplorasi ini sebagai rekan dengan alat gui seperti linkrank, ini memberi Anda gambaran tentang internet di sekitar Anda.


108
2018-04-30 12:03



setuju, kecepatan cahaya saat burung gagak terbang adalah yang terbaik yang bisa Anda lakukan. Jawaban yang luar biasa bagus, itulah yang saya cari. Terima kasih. - Jeff Atwood
Untuk yang penasaran matematika yang sebenarnya adalah: 3000 mi / c = 16.1ms - tylerl
Dalam ruang hampa, foton dapat melakukan perjalanan khatulistiwa dalam kira-kira 134 ms. Foton yang sama dalam gelas akan memakan waktu sekitar 200 mdtk. Sepotong 3.000 mil serat memiliki 24 ms. penundaan tanpa perangkat apa pun. - dbasnett
Ini mengingatkan saya pada Kasus Email 500 Mil. - bahamat


Situs ini akan menyarankan sekitar 70-80ms latensi antara pantai Timur / Barat AS adalah khas (San Francisco ke New York misalnya).

Jalur Trans-Atlantik
NY 78 London
Cuci 87 Frankfurt
Jalur Trans-Pasifik
SF 147 Hong Kong
Jalur Trans-AS
SF 72 NY

network latency by world city pairs

Inilah timing saya (saya berada di London, Inggris, jadi kali pantai Barat saya lebih tinggi dari Timur). Saya mendapatkan perbedaan latensi 74ms, yang tampaknya mendukung nilai dari situs itu.

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

Ini diukur menggunakan alat dev Google Chrome.


41
2018-04-30 11:45



grafik keren! NY ke SF saat ini 71 ms di atasnya, jadi Anda benar - kami tidak bisa berharap untuk melakukan lebih baik dari itu. - Jeff Atwood
Terima kasih. Itu sangat membantu saya. Ini adalah sumber lain untuk mencari latensi jaringan di antara berbagai tempat di dunia - dotcom-monitor.com/WebTools/network_latency.aspx - Sajib Mahmood


Mengukur dengan ICMP terlebih dahulu jika keadaan memungkinkan. Tes ICMP biasanya menggunakan payload yang sangat kecil secara default, tidak menggunakan jabat tangan tiga arah, dan tidak perlu berinteraksi dengan aplikasi lain di tumpukan seperti yang dilakukan HTTP. Apapun masalahnya, sangat penting bahwa hasil HTTP tidak ikut campur dengan hasil ICMP. Mereka adalah apel dan jeruk.

Pergi dengan jawaban Rich Adams dan menggunakan situs bahwa ia merekomendasikan, Anda dapat melihat bahwa pada tulang punggung AT & T, dibutuhkan 72 ms untuk lalu lintas ICMP untuk bergerak antara titik akhir SF dan NY mereka. Itu adalah angka yang lumayan untuk dilalui, tetapi Anda harus ingat bahwa ini ada di jaringan yang sepenuhnya dikontrol oleh AT & T. Itu tidak memperhitungkan transisi ke jaringan rumah atau kantor Anda.

Jika Anda melakukan ping terhadap careers.stackoverflow.com dari jaringan sumber Anda, Anda akan melihat sesuatu yang tidak terlalu jauh dari 72 ms (mungkin +/- 20 ms). Jika itu kasusnya, maka Anda mungkin bisa berasumsi bahwa jalur jaringan antara Anda berdua baik-baik saja dan berjalan dalam rentang normal. Jika tidak, jangan panik dan ukur dari beberapa tempat lain. Bisa jadi ISP Anda.

Dengan asumsi yang berlalu, langkah Anda berikutnya adalah mengatasi layer aplikasi dan menentukan apakah ada yang salah dengan tambahan biaya yang Anda lihat dengan permintaan HTTP Anda. Hal ini dapat bervariasi dari aplikasi ke aplikasi karena perangkat keras, OS, dan tumpukan aplikasi, tetapi karena Anda memiliki peralatan yang kurang lebih sama di kedua pantai Timur dan Barat, Anda dapat memiliki pengguna pantai Timur memukul server pantai Barat dan pengguna pantai Barat menghantam Timur pantai. Jika kedua situs dikonfigurasikan dengan benar, saya berharap untuk melihat semua angka menjadi lebih kurang sama dan karena itu menunjukkan bahwa apa yang Anda lihat cukup banyak untuk yang kasar.

Jika waktu HTTP tersebut memiliki varians yang lebar, saya tidak akan terkejut jika ada masalah konfigurasi pada situs berkinerja lebih lambat.

Sekarang, setelah Anda berada di titik ini, Anda dapat mencoba melakukan pengoptimalan yang lebih agresif di sisi aplikasi untuk melihat apakah angka-angka tersebut dapat dikurangi sama sekali. Misalnya, jika Anda menggunakan IIS 7, apakah Anda memanfaatkan kemampuan caching-nya, dll? Mungkin Anda bisa memenangkan sesuatu di sana, mungkin tidak. Ketika datang untuk mengutak-atik item tingkat rendah seperti jendela TCP, saya sangat skeptis bahwa itu akan memiliki banyak dampak untuk sesuatu seperti Stack Overflow. Tapi, hei - Anda tidak akan tahu sampai Anda mencobanya dan mengukur.


10
2018-04-30 17:34





Beberapa jawaban di sini menggunakan ping dan traceroute untuk penjelasannya. Alat-alat ini memiliki tempat mereka, tetapi mereka tidak dapat diandalkan untuk pengukuran kinerja jaringan.

Secara khusus, (setidaknya beberapa) router Juniper mengirim pemrosesan kejadian ICMP ke bidang kontrol router. Ini jauh lebih lambat daripada pesawat forwarding, terutama di router backbone.

Ada situasi lain di mana respons ICMP dapat jauh lebih lambat daripada kinerja penerusan router yang sebenarnya. Sebagai contoh, bayangkan router semua perangkat lunak (tidak ada perangkat keras forwarding khusus) yang pada 99% dari kapasitas CPU, tetapi masih bergerak baik lalu lintas. Apakah Anda ingin menghabiskan banyak siklus memproses tanggapan traceroute, atau meneruskan lalu lintas? Jadi memproses respon adalah prioritas yang sangat rendah.

Akibatnya, ping / traceroute memberi Anda alasan batas atas - semuanya berjalan secepat itu - tetapi mereka tidak benar-benar memberi tahu Anda seberapa cepat lalu lintas yang sebenarnya terjadi.

Dalam acara apa pun -

Berikut ini contoh traceroute dari University of Michigan (AS tengah) ke Stanford (pantai barat AS). (Ini terjadi melalui Washington, DC (pantai timur AS), yang berjarak 500 mil dalam arah "salah".)

% 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

Secara khusus, perhatikan perbedaan waktu antara hasil traceroute dari mencuci router dan atla router (hop 7 & 8). jalur jaringan pergi pertama untuk mencuci dan kemudian ke atla. mencuci membutuhkan waktu 50-100ms untuk merespon, atla memakan waktu sekitar 28ms. Jelas atla lebih jauh, tetapi hasil traceroute menunjukkan bahwa itu lebih dekat.

Lihat http://www.internet2.edu/performance/ untuk banyak info tentang pengukuran jaringan. (disclaimer, saya dulu bekerja untuk internet2). Juga lihat: https://fasterdata.es.net/

Untuk menambahkan beberapa relevansi khusus ke pertanyaan awal ... Seperti yang Anda lihat, saya memiliki waktu ping-pergi 83 ms untuk stanford, jadi kami tahu jaringan dapat berjalan setidaknya secepat ini.

Perhatikan bahwa jalur jaringan penelitian & pendidikan yang saya ambil pada traceroute ini kemungkinan akan lebih cepat daripada jalur internet komoditas. Jaringan R & E umumnya overprovision koneksi mereka, yang membuat buffering di setiap router tidak mungkin. Juga, catat jalur fisik yang panjang, lebih lama dari pantai ke pantai, meskipun jelas mewakili lalu lintas yang sebenarnya.

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


7
2017-08-15 15:46





Saya melihat perbedaan yang konsisten, dan saya duduk di Norwegia:

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

Ini diukur dengan metode akurat dan terbukti secara ilmiah menggunakan tampilan sumber daya Google Chrome dan hanya berulang kali menyegarkan setiap tautan.

Traceroute ke 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.

Traceroute untuk karir

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.

Sayangnya, sekarang mulai masuk ke loop atau yang lainnya dan terus memberikan bintang dan waktu hingga 30 hop dan kemudian selesai.

Catatan, traceroute berasal dari host yang berbeda dari timing di awal, saya harus RDP ke server host saya untuk mengeksekusi mereka


6
2018-04-30 11:43



benar, diharapkan bahwa pusat data pantai timur akan lebih ramah untuk khalayak Eropa kami - Anda melihat waktu sekitar + 200 mil diambil untuk melintasi lebar Amerika Serikat. Seharusnya hanya ~ 80ms per jawaban yang lain? - Jeff Atwood
Sepertinya itu konsisten di sekitar 200ms, saya telah menekan refresh sekitar 20-30 kali sekarang pada keduanya (tidak pada saat yang sama sekalipun), dan situs serverfault terlihat seperti melayang di sekitar 200ms +/- lebih dari yang lain . Saya mencoba traceroute, tetapi muncul dengan bintang dalam segala hal sehingga mungkin admin TI kami telah memblokir sesuatu. - Lasse Vågsæther Karlsen


Saya melihat sekitar 80-90ms latensi pada link yang dikelola dengan baik dan terukur dengan baik antara pantai Timur dan Barat.

Akan menarik untuk melihat di mana Anda mendapatkan latensi - cobalah alat seperti layer-four traceroute (lft). Kemungkinan banyak yang diperoleh pada "last mile" (yaitu di penyedia broadband lokal Anda).

Bahwa waktu transfer hanya sedikit berdampak diharapkan - packet loss dan jitter adalah pengukuran yang lebih berguna untuk dilihat ketika menginvestigasi perbedaan waktu transfer antara dua lokasi.


2
2018-04-30 11:42





Hanya untuk bersenang-senang, ketika saya memainkan game online Lineage 2 NA rilis dari dalam Eropa:

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

Perbedaannya tampaknya mendukung bahwa hingga 100ms adalah wajar, mengingat sifat tak terduga dari internet.

Menggunakan tes penyegaran Chrome yang diakui, saya mendapatkan waktu pemuatan dokumen yang berbeda dengan sekitar 130ms.


2
2018-04-30 12:52





semua orang di sini memiliki poin yang sangat bagus. dan benar dalam POV mereka sendiri.

Dan itu semua bermuara pada tidak ada jawaban yang benar-benar nyata di sini, karena ada begitu banyak variabel, setiap jawaban yang diberikan dapat selalu terbukti salah hanya dengan mengubah satu dari seratus variabel.

Seperti 72ms NY ke SF latency adalah latency dari PoP ke PoP dari sebuah carrier paket. Ini tidak memperhitungkan poin-poin besar lain yang telah ditunjukkan oleh beberapa orang di sini tentang kemacetan, kehilangan paket, kualitas layanan, paket rusak, atau ukuran paket, atau perutean ulang jaringan hanya antara dunia yang sempurna dari PoP hingga PoP .

Dan kemudian ketika Anda menambahkan mil terakhir (umumnya bermil-mil) dari PoP ke lokasi Anda yang sebenarnya di dalam dua kota di mana semua variabel ini menjadi jauh lebih cair, hal mulai meningkat secara eksponensial dari kemampuan menebak yang masuk akal!

Sebagai contoh, saya menjalankan tes antara kota NY dan SF pada hari kerja. Saya melakukan ini pada suatu hari tidak ada "insiden" besar yang terjadi di seluruh dunia yang akan menyebabkan lonjakan lalu lintas. Jadi mungkin ini bukan rata-rata di dunia todays! Namun meskipun demikian itu adalah uji saya. Saya benar-benar mengukur dari satu lokasi bisnis ke yang lain selama periode ini, dan selama jam kerja normal setiap pantai.

Pada saat yang sama, saya memonitor nomor penyedia sirkuit di web.

Hasilnya adalah angka latensi antara 88 dan 100 ms dari pintu ke pintu lokasi bisnis. Ini tidak termasuk nomor latensi jaringan antar kantor.

Latensi jaringan penyedia layanan berkisar antara 70 dan 80 ms. Berarti latensi mil terakhir bisa berkisar antara 18 dan 30 ms. Saya tidak mengkorelasikan puncak dan terendah yang tepat di antara dua lingkungan.


2
2017-09-09 15:43





Waktu NYC:

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

Menggunakan Chrome, pada koneksi perumahan.

Menggunakan lft dari VPS di datacenter di Newark, New Jersey:

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