Show HN: Bagaimana komputer mencapai server saya?

 (how-did-i-get-here.net)
4 poin oleh GN⁺ 2023-12-06 | 1 komentar | Bagikan ke WhatsApp
  • Saat pengunjung membuka situs web, server menjalankan traceroute ke IP publik, lalu menampilkan secara real time seperti teks rute yang dilalui paket melewati router dan jaringan
  • Tool internal ktr meningkatkan nilai TTL paket ICMP, mengumpulkan respons galat dari tiap hop, sekaligus menanyakan informasi jaringan per hop
  • Pembaruan layar diimplementasikan bukan dengan JavaScript, melainkan dengan terus mengalirkan HTML dan CSS ke respons HTTP yang tetap terbuka, sehingga hasil muncul secara bertahap selama halaman dimuat
  • Rute yang ditampilkan adalah reverse traceroute dari server ke IP pengunjung yang dibalik, sehingga karena perbedaan routing dua arah, rute itu mungkin tidak sepenuhnya sama dengan rute sebenarnya
  • Rute internet terbentuk dari BGP peering antar autonomous system (AS) dan propagasi tabel routing, dan trafik bergerak mengikuti jaringan-jaringan yang saling terhubung

Traceroute personal yang dibuat setiap kali Anda mengakses

  • Teks hijau di bagian atas halaman bukan contoh yang sudah disimpan sebelumnya, melainkan traceroute yang dibuat spontan untuk pengunjung saat situs web dimuat
  • Traceroute menunjukkan perjalanan komputer pengunjung, atau paket, mencapai server yang meng-host situs web ini melalui internet
  • Contoh rute dimulai dari router pengunjung, melewati jaringan ISP, melintasi beberapa jaringan, lalu masuk ke jaringan internal Hetzner sebelum mencapai server
    • Router pertama mungkin tidak merespons ping, dan ini umum terjadi jika berada di balik router publik atau VPN
    • Di tengah rute bisa muncul (no response), dan tidak semua server selalu merespons
  • Nama seperti core3.sto.hetzner.com adalah hasil reverse DNS lookup terhadap IP 213.239.252.74 yang muncul dari traceroute, lalu diubah menjadi nama yang mudah dibaca manusia
    • Nama reverse DNS terutama ada untuk memudahkan debugging, dan sering kali tidak dipetakan kembali ke IP aslinya

ktr dan traceroute berbasis ICMP

  • Implementasi situs web menggunakan program traceroute internal ktr
    • Kode sumber situs juga tersedia di GitHub
    • ktr men-streaming hasil secara real time sambil sekaligus mengambil informasi tiap hop
  • Dalam routing internet, komputer atau router yang memproses paket memilih perangkat penerus berikutnya, dan proses ini berlanjut hingga mencapai router yang dapat mengirim langsung ke tujuan
  • Implementasi ktr menggunakan ICMP
    • ICMP adalah protokol yang dirancang untuk mengirim informasi diagnostik di internet
    • Hampir semua perangkat yang terhubung ke internet mendukung ICMP
  • Field TTL(time to live) pada paket ICMP bukan waktu nyata, melainkan nilai hitung mundur
    • Setiap kali router meneruskan paket ICMP, router harus mengurangi TTL sebesar 1
    • Ketika TTL menjadi 0, router berhenti meneruskan paket dan mengirim pesan galat ke IP asal bahwa jumlah hop maksimum telah tercapai
  • Traceroute mengirim paket ICMP dengan TTL yang meningkat bertahap seperti 1, 2, 3, lalu mengumpulkan respons galat yang kembali dari tiap hop
    • Paket galat berisi informasi diagnostik seperti alamat IP perangkat yang mengirim galat
    • Dengan cara ini, rute perkiraan paket melintasi internet dapat ditelusuri

Tampilan yang terlihat real time tanpa JavaScript

  • Halaman tetap berfungsi bahkan saat JavaScript dinonaktifkan
    • Dari sudut pandang browser, situs web tampak dimuat secara perlahan
    • Bagi pengguna, traceroute tampak muncul secara real time
  • Saat diakses, server menerima permintaan HTTP dari alamat IP pengunjung, lalu segera menjalankan traceroute ke IP tersebut
  • Server terlebih dahulu mengirim bagian awal respons HTTP lalu mempertahankan koneksi tetap terbuka
    • ktr mengirim pembaruan traceroute ke server
    • Server merender HTML terkait dan mengirimkannya ke komputer pengunjung
    • Setelah traceroute selesai, server mengirim sisa teks dan konten situs web, lalu menutup koneksi
  • Alasan baris traceroute terlihat diperbarui secara bertahap dari bagian atas, bukan dari bawah, adalah penyisipan blok CSS
    • Pada dasarnya, halaman web hanya bisa dimuat ke arah depan
    • Setiap kali tampilan traceroute diperbarui, CSS yang menyembunyikan tampilan sebelumnya juga disisipkan
    • Karena browser merender CSS saat proses loading, layar tampak seperti diedit seiring waktu

Batasan reverse traceroute

  • Rute yang ditampilkan halaman tidak sepenuhnya sama dengan “rute yang ditempuh paket pengunjung untuk mencapai server”
  • Untuk menghitung rute sebenarnya, traceroute harus bisa dijalankan dari komputer pengunjung ke server
  • Implementasi ini menjalankan traceroute dari server ke komputer pengunjung, lalu membalik hasilnya untuk ditampilkan
    • Karena itu traceroute di bagian atas tampak dimuat dalam urutan terbalik
  • Reverse traceroute mengorbankan sebagian akurasi
    • Jika paket bergerak ke arah sebaliknya, tiap perangkat dapat mengambil keputusan routing yang berbeda
    • Jika satu perangkat saja mengambil keputusan berbeda, rute setelahnya bisa berubah
  • Meski begitu, rutenya kira-kira mirip, dan perbedaannya kemungkinan terutama sebatas router tertentu mana yang melihat paket

Autonomous system dan lookup WHOIS

  • “Jaringan” yang muncul di traceroute mengacu pada autonomous system (AS)
    • AS adalah kumpulan router dan server yang saling terhubung secara privat
    • Umumnya dimiliki oleh perusahaan yang sama
  • Pemilik AS memilih AS lain mana yang akan dihubungkan, sehingga menentukan bentuk internet
    • Trafik internet bergerak melewati AS-AS yang memiliki perjanjian peering satu sama lain
  • Internet tampak seperti jaringan terbuka, tetapi pada kenyataannya merupakan jaringan dari jaringan-jaringan yang dimiliki perusahaan, dengan akses dan kontrol yang dipengaruhi transaksi finansial dan prosedur birokratis
  • Jika menginginkan autonomous system sendiri, Anda dapat mengajukan ASN ke salah satu dari lima Regional Internet Registry (RIR)
    • Tanpa dukungan perusahaan atau titik koneksi internet yang memadai, permohonan sulit diterima
    • Angka seperti AS4766 pada traceroute adalah ASN
  • ktr menggunakan protokol WHOIS untuk mendapatkan informasi AS yang memiliki tiap IP hop
    • Berbagai organisasi melacak AS mana yang mencakup alamat IP tertentu
    • Banyak organisasi menyediakan lookup ASN melalui WHOIS
  • PeeringDB juga digunakan untuk mengidentifikasi informasi perusahaan
    • PeeringDB memiliki informasi tentang sekitar 1/3 dari seluruh autonomous system
    • Hasil lookup dan ratusan baris pernyataan if digunakan bersama untuk membuat deskripsi lintasan jaringan
  • Spesifikasi protokol WHOIS hampir tidak menetapkan struktur
    • Spesifikasi itu hanya menetapkan kira-kira bahwa setelah membuat koneksi TCP dan mengirim hal yang ingin dicari, server mengembalikan informasi lalu menutup koneksi
    • Struktur respons WHOIS yang sebenarnya lebih mirip konvensi yang dibuat administrator server, dan nama field yang dibutuhkan pun bisa berbeda seperti origin dan originas
    • Parser ktr lebih mirip cara manusia membaca hasil WHOIS dan mencari ASN yang dibutuhkan daripada parser yang ketat

Cara BGP membentuk rute internet

  • Router di batas jaringan menentukan ke jaringan mana paket berikutnya akan dikirim, dan proses yang sama berlanjut sampai mencapai jaringan tempat perangkat tujuan berada
  • Router batas seperti ini saling bertukar informasi jaringan yang dapat dijangkau melalui Border Gateway Protocol(BGP)
    • BGP adalah protokol yang membentuk wujud internet
    • Pengguna biasa tidak dapat berbicara BGP secara langsung
  • Versi awal BGP dijelaskan dalam RFC 1105 yang diterbitkan oleh engineer Cisco dan IBM pada 1989
    • Setelah pesan sebagian dikirim pada prototipe ARPANET tahun 1969, berbagai universitas, lembaga pemerintah, dan perusahaan mulai membangun jaringan mereka sendiri dan saling menghubungkannya
    • Pada 1990, BGP v2 dirilis
    • Pada 1994, BGP v4 ditetapkan sebagai RFC 1654
    • BGP v4 direvisi dan ditambal pada 1995 dan 2006, dan masih digunakan untuk pemilihan rute antarjaringan yang saling terhubung di internet modern

Rute BGP, peering, dan tabel routing

  • Border gateway, yaitu router di batas autonomous system, menyimpan tabel routing yang merupakan daftar semua rute BGP yang diketahuinya
  • Setiap rute BGP menentukan jalur ASN yang dapat diikuti untuk mencapai AS yang mengendalikan kumpulan alamat IP tertentu
  • Rute BGP terbentuk melalui hubungan peering antar-AS
    • Saat border gateway dari dua AS melakukan peering, trafik dapat bergerak di antara kedua router tersebut
    • Keduanya berbagi informasi rute BGP yang diketahui agar tetap mutakhir
  • Sebagai contoh, agar Router A milik AS0001 dan Router B milik AS0002 yang terhubung secara fisik dapat melakukan peering, keduanya bertukar pesan BGP untuk membuat sesi BGP
    • Router A mengetahui bahwa untuk rute BGP yang dimulai dengan AS0002, ia harus lewat Router B
    • Router B juga mengetahui informasi arah sebaliknya
  • Peer berbagi rute yang mereka ketahui melalui proses route advertisement
    • Jika Router A memberi tahu Router B semua rute yang diketahuinya, Router B menambahkan rute yang dimulai dengan AS0001 ke tabel routingnya
    • Jika peer lain milik Router A mengiklankan rute baru, Router A juga meneruskannya ke Router B
  • Saat iklan ini menyebar ke seluruh jaringan AS, setiap border gateway akhirnya mengetahui satu atau lebih AS path yang dapat mencapai IP mana pun di internet
  • Saat router mengirim paket ke IP tertentu, router mencari rute menuju AS yang mengendalikan IP tersebut di tabel routing
    • Setelah itu, router memilih rute yang “terbaik” dengan berbagai heuristik
    • Heuristik mencakup pencarian rute terpendek serta preferensi atau ketidaksukaan yang di-hardcode terhadap AS tertentu
    • Router mengirim paket ke gateway router yang melakukan peering dengan AS pertama pada rute yang dipilih

Membaca hasil traceroute dari perspektif BGP

  • AS path pada contoh traceroute adalah AS4766 → AS201011 → AS24940
  • Pada suatu titik, paket mencapai salah satu router di AS4766, dan router tersebut melakukan peering dengan router di AS201011
    • Dari tabel routing, router menentukan bahwa IP tujuan dapat dicapai melalui rute yang dimulai dengan AS201011
    • Setelah itu, paket dikirim ke router AS201011 yang terhubung
  • Beberapa hop dapat muncul bahkan di dalam ASN yang sama
    • Seperti enam hop yang melewati Hetzner Online, traceroute menampilkan bukan hanya router batas AS, melainkan semua router yang dilewati paket
  • Router internal AS dapat memprioritaskan rute internal daripada rute BGP eksternal jika mengetahui rute internal yang efisien
    • Rute internal dapat dipelajari melalui internal BGP, protokol routing internal lain, atau hardcoding
  • Kunci yang menentukan keterjangkauan internet bukan hop internal, melainkan perjanjian peering antar-AS

Bacaan terkait

1 komentar

 
GN⁺ 2023-12-06
Pendapat Hacker News

  • Halo, saya Lexi. Saya 17 tahun, dan belakangan ini minat saya adalah memahami lebih dalam bagaimana komputer bekerja lalu menunjukkannya dengan cara baru
    Beberapa bulan lalu saya merilis https://cpu.land, dan diskusi terkait ada di https://news.ycombinator.com/item?id=37062422
    Setelah cpu.land, saya merasa sangat tertekan harus membuat hasil karya besar lainnya, tapi tidak ada ide yang benar-benar menarik. Jadi sambil mencoba berbagai proyek pribadi, ketika secara kebetulan mempelajari cara kerja internet, saya akhirnya membuat dari nol program traceroute yang di-streaming secara real time ke situs web
    Saya belum pernah melihat bentuk seperti ini di web, dan karena menurut saya ini cara yang cukup baru dan keren untuk memvisualisasikan struktur internet, saya memolesnya dan membuatnya menjadi situs yang cantik
    Dalam prosesnya, saya belajar banyak hal menarik tentang BGP dan struktur internet, jadi saya menggabungkan alat traceroute itu dengan tulisan yang membagikan pengetahuan tersebut
    Saya masih terus mengutak-atiknya dan pasti ada kode yang rusak di suatu tempat, jadi kalau ada saran, saya senang mendengarnya
    Sebagai tambahan, alasan saya memakai Rust adalah karena meski saya tidak menganggap pilihan bahasa pemrograman itu sangat penting, saya ingin cepat menulis program level rendah yang andal, dan saya suka elemen dasar penanganan error di Rust

    • Kalau “belum pernah melihat yang seperti ini di web”, coba cari looking glass bgp; akan muncul hal-hal serupa
      Salah satu program CGI pertama yang saya buat hampir 30 tahun lalu adalah skrip Perl yang membungkus traceroute dan men-streaming hasilnya dengan server push
      Hal lama memang bisa terasa baru lagi, tapi penyajian situs ini tetap sangat bagus
      Sebagai catatan, IPv4 TTL secara legal memang dalam satuan detik, tetapi tidak ada router yang menghabiskan lebih dari 1 detik, dan nilai penurunan minimumnya 1, jadi secara praktis dipakai sebagai jumlah hop. Middlebox yang ingin bersembunyi bahkan kadang tidak menguranginya sama sekali
      Selain itu, traceroute Linux/Unix secara default memakai UDP ke port bernomor tinggi yang biasanya tertutup untuk paket probing, bukan ICMP, karena secara historis UDP lebih kecil kemungkinannya di-drop atau difilter dibanding ICMP
      Menanyakan cara kerja traceroute adalah salah satu pertanyaan wawancara saya, tetapi kebanyakan orang tidak tahu, dan kalaupun tahu, nilai pertanyaannya jadi berkurang. Banyak orang, seberapa pun ditanya soal TCP/IP, tidak bisa menalar dari prinsip pertama; apakah mereka tetap bisa menguraikannya menurut saya adalah pertanyaan pemecahan masalah yang masuk akal
      Contoh: https://www.bgplookingglass.com/
      https://www.oreilly.com/openbook/cgi/ch06_06.html
    • Proyek yang keren. Saya punya satu saran serius dan satu saran ringan
      Saya penasaran apakah memakai TCP atau UDP alih-alih ICMP bisa memberikan hasil yang lebih akurat. Traceroute tradisional juga punya opsi UDP, mtr [1] bisa memakai TCP atau UDP, dan tcptraceroute [2] bisa memakai TCP
      Dan ini pas sekali untuk menyelipkan kutipan Talking Heads. “And you may ask yourself, well, how did I get here?” [3]
      [1] https://github.com/traviscross/mtr
      [2] https://linux.die.net/man/1/tcptraceroute
      [3] https://en.wikipedia.org/wiki/Once_in_a_Lifetime_(Talking_He...
    • Kamu melakukan jauh lebih banyak hal keren dibanding saya saat berusia 17 tahun. Kalau kamu menikmati “I, Robot”, saya juga merekomendasikan Stories of Your Life and Others karya Ted Chiang. Film Arrival dibuat berdasarkan salah satu karya dalam kumpulan cerita pendek ini
    • Ini berguna sebagai situs yang bagus untuk menjelaskan traceroute. Sepertinya bisa saya pakai saat menjelaskan kegunaan traceroute kepada beberapa teknisi yang dilatih untuk memelihara jaringan perusahaan
      Sekarang tinggal mencari cara agar traceroute dari workstation tertentu bisa bekerja di setiap hop sampai mencapai tabel routing VPC milik instance EC2, lewat switch akses Cisco perusahaan, core switch, dan tunnel BGP menuju AWS transit gateway; setelah itu rasanya sudah bisa disebut orang jaringan
    • Keren. Saya sempat tegang karena takut sirkuit Tor terlihat
      Sayangnya terlalu banyak node yang mengabaikan paket traceroute, jadi yang terlihat hanya seolah-olah exit node saya terhubung ke Linode, lalu Linode terhubung ke komputermu
      Pada traceroute arah maju pun mirip: router merespons, server merespons, dan kalau beruntung mungkin terlihat satu node di jaringan ISP. Sisanya tertutup rapat

  • Tertulis bahwa “BGP adalah protokol yang memberi bentuk pada internet, dan tidak bisa diajak bicara langsung”, tetapi dalam praktiknya, ternyata cukup mudah bagi individu untuk mendapatkan ASN dan berbicara BGP
    Kalau membuat alat seperti ini terasa menarik, ini layak dicoba. Kalau tertarik, saya juga punya tulisan pengantar yang pernah saya buat: https://qt.ax/asn

  • Ini lebih seperti “kebalikan dari cara servermu mencapai komputer saya” daripada “cara komputer saya mencapai servermu”. Routing dua arah kemungkinan besar cukup berbeda

    • Di dalam tulisannya sebenarnya ada bagian Front to Back, Back to Front yang membahas hal ini
      Ringkasnya, menurut pengalaman saya, jaringan yang dilewati biasanya sangat mirip, dan dari arah mana pun isinya tetap relevan dan menarik
    • Pada masa bang path, menarik untuk melihat seberapa berbeda bang path milik pengirim dan bang path untuk balasan, lalu menyimpulkan perbedaan koneksi jaringan apa yang menciptakan asimetri

  • Ada makalah yang menarik terkait cara kerja traceroute. Hal yang sering terlewat oleh orang-orang di luar bidang jaringan adalah bahwa traceroute tidak harus simetris. Jalur kembalinya bisa berbeda
    https://archive.nanog.org/sites/default/files/traceroute-201...

    • Hari ini ada gangguan internet di Mesir karena masalah Telecom Egypt, dan traceroute ke tujuan yang sama melewati 8 rute berbeda
      Bisa dibilang itu dua kali lipat jumlah ECMP yang pernah kulihat di internet sejauh ini
      Lalu lintas dari kantor Kairo ke core Inggris dan lalu lintas arah sebaliknya juga menempuh rute yang berbeda. London→Cairo langsung dan masih mengalami kehilangan paket besar-besaran, tetapi Cairo→London sekarang lewat ntt dan tampaknya baik-baik saja. Kalau belum diperbaiki sampai besok, mungkin kami harus mengubah preferensi lokal
    • Jarang terjadi, tetapi jalur data itu sendiri juga bisa asimetris. Contohnya seperti satelit yang memakai uplink darat
    • Terima kasih, akan kubaca. Dualitas ini juga dibahas di tulisan tersebut

  • Disebutkan bahwa “WHOIS adalah protokol yang menarik untuk dibuat parser-nya”, tetapi dalam praktiknya hampir mustahil
    Responsnya pada dasarnya berbentuk bebas, dan server bisa saja tidak merespons. Aku juga pernah mencobanya; berdasarkan kondisi 10 tahun lalu, aku bisa membuat parser sementara yang bekerja untuk 90% alamat atau domain, tetapi sisanya tidak bisa ditangani
    Sekarang kondisinya lebih buruk, dan hampir semuanya tersembunyi di balik pelindung privasi. Mereka mengklaim melindungi PII, tetapi catatan WHOIS awalnya bukan dimaksudkan untuk memuat informasi pribadi, melainkan kontak operator jaringan
    Menurutku ini salah ICANN. ICANN dulu punya aturan bahwa jaringan harus menyediakan server WHOIS publik, tetapi tidak menegakkannya, dan sekarang aturan itu telah dibuang

    • Bukankah WHOIS seharusnya berisi email, nomor telepon, dan alamat fisik? Kalau perusahaan mungkin bukan PII, tetapi untuk WHOIS situs web pribadi, aku tidak mengerti bagaimana itu bisa dianggap bukan informasi pribadi
    • RDAP memuat sebagian informasi WHOIS dalam format JSON yang bisa dibaca mesin. Tidak semuanya, tetapi menurutku lebih baik
      Namun tidak semua pihak menjalankan server RDAP. Akan bagus kalau ICANN/IANA atau siapa pun mewajibkannya
      Informasi operator jaringan juga bisa termasuk PII. Informasiku adalah PII, dan karena aku punya nama domain, memasukkan informasiku ke WHOIS berarti memasukkan PII ke WHOIS
      Layanan perlindungan privasi hanya meneruskan semuanya kepadaku kecuali spam
      Untuk perusahaan, menurutku tidak ada alasan kuat untuk mengizinkan layanan perlindungan privasi, tetapi belum semua domain dimiliki perusahaan besar
    • Untuk bagian bahwa parser sementara bisa dibuat untuk 90% alamat atau domain tetapi sisanya sulit, bukankah sekarang AI generatif bisa membantu? Misalnya, “ini whois-nya, tolong ambil informasi yang kuinginkan”

  • Alih-alih pelacakan ICMP ECHO terpisah, kita bisa melangkah lebih jauh dengan memanfaatkan koneksi HTTP TCP yang sudah ada antara browser klien dan server web
    Dengan begitu bisa menembus NAT di sisi klien atau firewall stateful

    • Menarik. Penasaran bagaimana cara kerjanya dengan traceroute sungguhan
    • Itu disebut parasitic traceroute

  • Ada beberapa karya sebelumnya tentang reverse traceroute
    https://research.cs.washington.edu/networking/astronomy/reve...
    Makalah: http://www.cs.washington.edu/homes/ethan/papers/reverse_trac...
    Video: http://www.usenix.org/multimedia/nsdi10katz-bassett

  • Perlu juga diketahui bahwa paket dalam sesi TCP sering melewati internet melalui jalur asimetris. Berdasarkan pengalamanku, penyebab paling umum adalah aturan bisnis terkait biaya, dan kesalahan manusia
    Kalau memikirkan cara kerja IP, hal ini sendiri tidak terlalu bermasalah, tetapi bisa membuat routing lebih sulit dipahami

    • Ada anekdot menarik
      Boise State University dan University of Idaho adalah kampus di dua ujung negara bagian Idaho. UIdaho di utara dekat Spokane dan sebagian besar koneksinya datang dari Seattle, sedangkan Boise lebih dekat ke arah Salt Lake sehingga sering terhubung melalui Portland atau Salt Lake City
      Bagian tengah negara bagian di antara kedua kampus itu berupa pegunungan, jadi hampir tidak ada koneksi besar, tetapi dulu UofIdaho punya kelas jarak jauh di wilayah selatan sehingga ada satu jalur kecil
      Pada suatu waktu di akhir 90-an, engineer jaringan BSU dan engineer UofI menyadari bahwa mereka menaruh switch dan perangkat routing di gedung yang sama, lalu menghubungkan kabel Ethernet di antara keduanya
      Hasilnya bencana. Kedua jaringan mulai mengiklankan BGP satu sama lain, dan koneksi itu diumumkan ke seluruh internet. Tiba-tiba muncul lompatan yang sangat pendek antara jaringan sisi Seattle dan jaringan sisi Salt Lake City, dan jalur T1 kecil yang malang itu benar-benar jenuh
      Menariknya, itu hanya terjadi ke satu arah. Boise mengiklankan rute, tetapi Idaho tidak, sehingga lalu lintas pada dasarnya rusak hanya satu arah
      Tentu saja kabelnya dicabut, dan bertahun-tahun kemudian ketika aku bekerja di UofIdaho, sudah menjadi pengetahuan umum bahwa kedua jaringan itu sama sekali tidak boleh dihubungkan lagi. Ironisnya, saat itu aku sedang menjalankan program untuk membangun I2 di kedua universitas tersebut

  • Di perangkatku, tahap perantara antara perangkatku dan server sama sekali tidak terlihat. Sekadar referensi

    • Benar, maaf. Server cukup kewalahan karena Hacker News
      Aku sedang mengerjakannya sekarang dan berharap segera bekerja lebih baik. Sementara itu aku menaikkan timeout, jadi pemuatan akan lebih lama tetapi semestinya lebih bisa berjalan
    • Mungkin akan bekerja lebih baik kalau tidak melihat HN dari dalam data center Linode :P

  • mtr juga layak disebut. Saya memakainya jauh lebih sering daripada traceroute
    Ini membantu mendiagnosis packet loss yang terjadi sesekali, dan memungkinkan kita memahami alurnya secara rata-rata
    Tulisan APNIC ini menjelaskan lebih detail tentang mtr dan cara membaca hasilnya, serta membahas bagaimana MPLS dapat mengaburkan rute sebenarnya
    https://blog.apnic.net/2022/03/28/how-to-properly-interpret-...
    Melakukan pelacakan dengan UDP juga kadang berguna, dan perlu diketahui bahwa banyak router secara selektif menjatuhkan ICMP saat sedang mendapat beban
    Tulisan yang bagus, dan penyampaiannya juga sangat baik