Jalur 100 Mbps Cuma Terasa 8 Mbps? Salahkan Latensi, Bukan ISP

Speedtest nunjukin 100 Mbps. Tapi narik berkas dari server kantor pusat cuma dapat 8 Mbps, konsisten, tiap hari.

ISP-nya nggak curang, dan jalurnya nggak penuh. Yang membatasi TCP-nya sendiri.

Batasnya window dibagi RTT

Satu koneksi TCP nggak pernah ngirim satu jalur penuh sekaligus. Dia ngirim sejumlah data, lalu nunggu konfirmasi sebelum ngirim lagi. Jumlah yang boleh melayang tanpa konfirmasi itu namanya window.

Rumusnya sederhana:

throughput maksimum = ukuran window / RTT

Window 64 KB dengan RTT 60 ms:

65.536 byte x 8 bit = 524.288 bit
524.288 / 0,06 detik = 8,7 Mbps

Delapan koma tujuh megabit. Persis yang Anda lihat.

Perhatikan yang tidak ada di rumus itu: lebar jalur. Naikin langganan dari 100 Mbps ke 300 Mbps nggak bakal ngubah angka ini sama sekali.

Angka yang perlu diingat

Dengan window 64 KB, inilah langit-langit satu koneksi:

Makin jauh servernya, makin kecil hasilnya — dan penurunannya sebanding dengan jarak, bukan sedikit-sedikit.

Window scaling: ada, tapi kadang dilucuti di jalan

Batas 64 KB itu warisan rancangan awal TCP. Sejak lama ada perluasan namanya window scaling yang ngizinin window jauh lebih besar, dan semua sistem modern nyalain itu secara bawaan.

Masalahnya perluasan itu dirundingin cuma sekali, di paket pertama pas koneksi dibuka. Kalau ada perangkat di tengah jalan yang ngilangin atau nggak paham opsi itu — firewall lama, sebagian perangkat NAT, middlebox operator — koneksinya balik ke batas 64 KB tanpa ada pesan error apa pun.

Gejalanya: throughput mentok di angka yang persis cocok sama hitungan 64 KB di atas, dan nggak bergerak walau semuanya dinaikin.

Kehilangan paket menghukum jauh lebih keras dari dugaan

TCP nganggep kehilangan paket sebagai tanda macet, lalu ngecilin window-nya. Di jalur berlatensi tinggi, pemulihannya lambat karena tiap penyesuaian nunggu satu RTT.

Kehilangan 0,1 persen kedengeran nggak ada apa-apanya. Di jalur 60 ms, itu bisa mangkas throughput jadi separuh atau kurang.

Makanya jalur yang "kadang cepat kadang lambat" tanpa pola sering bukan soal bandwidth sama sekali, melainkan kehilangan paket kecil yang nggak keliatan di grafik pemakaian.

Yang beneran nolong

Urut dari yang paling gampang:

1. Pakai banyak koneksi sekaligus. Batasnya per koneksi, bukan per jalur. Delapan koneksi paralel di jalur yang sama ngasih delapan kali lipat. Ini yang bikin unduhan multi-bagian dan rsync beberapa proses jauh lebih cepat daripada satu proses.
2. Naikin buffer di kedua ujung. Buffer penerima yang kekecilan bikin window nggak pernah tumbuh, walau scaling-nya nyala.
3. Ganti algoritma kontrol kemacetan. BBR jauh lebih tahan terhadap kehilangan paket kecil daripada CUBIC bawaan, dan bedanya paling terasa persis di jalur jauh.
4. Dekatkan servernya. Cermin lokal atau CDN mangkas RTT, dan RTT ada di penyebut rumus — ini satu-satunya cara naikin langit-langitnya sendiri.

Cara ngebuktiin dalam dua menit

Uji dengan satu koneksi, lalu dengan delapan:

iperf3 -c server-tujuan
iperf3 -c server-tujuan -P 8

Kalau yang delapan koneksi hasilnya jauh lebih besar, jalurnya baik-baik saja dan yang Anda temui memang batas per koneksi. Kalau dua-duanya sama-sama mentok, barulah curigai jalur atau perangkat di tengah.

Kalkulator Throughput TCP ngitung langit-langit ini dari RTT dan ukuran window Anda, sekalian nunjukin window sebesar apa yang dibutuhkan buat ngisi jalur Anda sepenuhnya.

Bacaan lanjutan: Transfer file lambat padahal bandwidth besar dan Ping bagus tapi VoIP putus-putus.