Tutorial & How-to

Arti bytes, time, dan TTL di Hasil Ping

Sampul artikel: 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:

BagianUkuran
isi data32 byte
header ICMP8 byte
header IP20 byte
header Ethernet14 byte
pemeriksa galat (FCS)4 byte
total di kabel78 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:

Tujuanrtt rata-rataTTL diterima
9.9.9.9 (Quad9)0,453 ms61
1.1.1.1 (Cloudflare)0,645 ms60
8.8.8.8 (Google)11,722 ms120
208.67.222.222 (OpenDNS)11,527 ms58

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 awalDipakai olehArti kalau Anda terima 114
64Linux, Android, sebagian besar routertidak mungkin, 114 lebih besar dari 64
128Windows14 hop
255perangkat jaringan besartidak 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.

Tim Netvora

Menulis di Netvora Blog. Punya pertanyaan teknis soal artikel ini? Kirim ke info@netvora.co.id.