Arti bytes, time, dan TTL di Hasil Ping
Satu baris hasil ping punya empat bagian
Contoh baris dari Windows:
Reply from 103.x.x.x: bytes=32 time=83ms TTL=114
Angka 32, 83, dan 114 mengukur tiga hal yang berbeda, dan cuma satu di antaranya bicara soal kecepatan. Penjelasan di bawah memakai angka yang saya ukur sendiri dari server Netvora di Jakarta.
bytes: ukuran data yang dikirim balik
bytes=32 berarti 32 byte data ikut dikirim balik oleh tujuan. Angka ini ditentukan perangkat yang menjalankan ping, bukan oleh jaringan.
32 byte adalah bawaan di Windows. Di Linux dan macOS bawaannya 64 byte. Ukurannya bisa diubah:
:: Windows, kirim 1000 byte
ping -l 1000 8.8.8.8
:: Linux dan macOS, kirim 1000 byte
ping -s 1000 8.8.8.8
32 byte itu hanya isinya. Yang benar-benar melintas di kabel lebih besar, karena setiap lapisan menambahkan headernya sendiri:
| Bagian | Ukuran |
|---|---|
| isi data | 32 byte |
| header ICMP | 8 byte |
| header IP | 20 byte |
| header Ethernet | 14 byte |
| pemeriksa galat (FCS) | 4 byte |
| total di kabel | 78 byte |
Jadi bytes=32 bukan ukuran seluruh lalu lintas yang terpakai. Setiap ping membawa 78 byte, dan angka itu belum termasuk jeda antar-paket yang ditambahkan kartu jaringan.
time: lama perjalanan pulang pergi
time=83ms berarti paket butuh 83 milidetik untuk pergi dan kembali. Angka ini diukur dari komputer yang menjalankan ping, bukan dari router di tengah jalur.
Untuk menilai 83 ms itu cepat atau lambat, bandingkan dengan tujuan yang dipakai. Ini hasil pengukuran saya dari server di Jakarta:
| Tujuan | rtt rata-rata | TTL diterima |
|---|---|---|
| 9.9.9.9 (Quad9) | 0,453 ms | 61 |
| 1.1.1.1 (Cloudflare) | 0,645 ms | 60 |
| 8.8.8.8 (Google) | 11,722 ms | 120 |
| 208.67.222.222 (OpenDNS) | 11,527 ms | 58 |
Server Netvora punya jalur langsung ke Cloudflare dan Quad9, jadi di bawah 1 ms itu wajar di sana. Google 11 ms karena jalurnya lebih jauh. Kalau Anda menjalankan ping dari jaringan rumah, 83 ms itu angka yang normal, dan lebih besar lagi kalau lewat jaringan seluler.
Yang menentukan bukan cuma jarak. 83 ms dari Jakarta ke server di Singapura itu wajar. 83 ms ke perangkat di ruangan sebelah itu tanda ada masalah, biasanya WiFi yang padat atau kabel yang mulai rusak.
Windows menuliskan time<1ms untuk apa pun di bawah satu milidetik. Tanda kurang dari itu dipakai karena Windows tidak melaporkan angka di bawah 1 ms. Di Linux, pengukuran ke server yang sama menulis 0.125 ms.
TTL: berapa router yang sudah dilewati
TTL adalah singkatan Time To Live, tapi isinya bukan waktu. Isinya jumlah lompatan (hop) yang masih boleh dilakukan paket.
Setiap router yang dilewati mengurangi TTL satu angka. Kalau angkanya habis jadi nol, paket dibuang dan pengirimnya diberi kabar. Mekanisme ini yang mencegah paket berputar selamanya saat ada jalur yang salah.
Angka TTL yang Anda terima adalah TTL awal dikurangi jumlah hop yang sudah dilewati. Karena pengurangannya hanya terjadi di router, jumlah hop bisa dihitung.
TTL awal ditentukan sistem operasi pengirim, dan nilai yang dipakai cuma tiga:
| TTL awal | Dipakai oleh | Arti kalau Anda terima 114 |
|---|---|---|
| 64 | Linux, Android, sebagian besar router | tidak mungkin, 114 lebih besar dari 64 |
| 128 | Windows | 14 hop |
| 255 | perangkat jaringan besar | tidak mungkin, berarti 141 hop |
Jadi TTL=114 berasal dari mesin Windows yang berjarak 14 hop. Tidak ada kemungkinan lain, karena 114 lebih besar dari 64 sehingga bukan dari Linux, dan hasil 141 hop dari TTL 255 mustahil di internet hari ini.
Cara ini berguna saat menelusuri masalah. Kalau Anda tahu server tujuan itu Windows, Anda bisa memperkirakan jumlah router di antaranya tanpa menjalankan traceroute.
TTL yang berubah saat ping dijalankan berkali-kali
Kalau angka TTL berganti di tengah pengukuran, paket Anda keluar lewat jalur yang berbeda. Ini wajar pada layanan besar yang punya banyak titik lokasi seperti Cloudflare.
Pada pengukuran saya ke 1.1.1.1, TTL-nya tetap 60 selama enam balasan berturut-turut:
ttl=60 ttl=60 ttl=60 ttl=60 ttl=60 ttl=60
Artinya jalur yang dipakai tidak berubah sama sekali selama enam balasan. Kalau angkanya melompat, jalurnya berganti, dan itu bukan tanda kerusakan.
Kenapa hitungan hop bukan pengukur jarak
Jumlah hop tidak menunjukkan jarak kilometer. Satu hop bisa berarti dua router bersebelahan, bisa juga berarti kabel laut.
Ada satu sebab lagi. Router yang tidak membalas tetap dilewati dan tetap mengurangi TTL, ia hanya tidak muncul di hasil traceroute. Dari server Netvora, traceroute ke Google 8.8.8.8 hanya menjawab 5 hop sementara hitungan dari TTL menunjukkan 8 hop. Selisih tiga itu router yang diam.
Karena itu, saat membandingkan jalur, pakai hitungan dari TTL, bukan jumlah baris di traceroute.
Cara memeriksa sendiri
Di Windows:
ping 8.8.8.8
ping -t 8.8.8.8
tracert 8.8.8.8
Tanda -t membuat ping berjalan terus sampai Anda menekan Ctrl+C. Tanda tracert menampilkan setiap router yang dilewati.
Di Linux dan macOS:
ping 8.8.8.8
ping -c 10 8.8.8.8
traceroute 8.8.8.8
Di Linux, ping berjalan terus tanpa tanda. Tambahkan -c 10 supaya berhenti setelah sepuluh kali.
Yang sering disalahartikan
TTL di hasil ping bukan waktu sisa paket dalam detik. Angka 114 tidak berarti paket hidup 114 detik.
time=83ms bukan kecepatan internet Anda. Itu lama perjalanan satu paket kecil. Unduhan bisa tetap lambat meskipun ping kecil, karena penyebabnya di tempat lain, misalnya antrean di sisi server.
bytes=32 bukan ukuran paket di jaringan. Totalnya 78 byte seperti hitungan di atas.
TTL rendah bukan tanda koneksi buruk. Dalam pengukuran saya, TTL 60 ke Cloudflare itu lebih cepat daripada TTL 120 ke Google. Yang memengaruhi kecepatan adalah jalur dan kepadatan, bukan sisa hop.