Tune TCP Buffer Linux: Cara Cepat Fix Latency 2026

Gila sih, kemarin aku baru nemu kenapa satu server client kok rasanya ‘nggremet’ banget. Ping-nya normal, 5 ms. CPU aman, RAM aman, disk aman. Tapi pas transfer data, download file, atau buka aplikasi web yang butuh data gede, kerasa banget lambatnya. Dua hari muter-muter nyari jawaban, terus nemu biang keroknya: TCP buffer yang kecil banget. Sumpah, ini ngubah cara aku troubleshoot network dari sekarang.

Dan bagian paling seru, ini bukan kasus langka. Banyak server di luar sana ngalamin hal yang sama tanpa sadar. Gejalanya halus banget, jadi sering disalahin ke hardware, ke bandwidth provider, bahkan ke code aplikasi. Padahal fix-nya cuma beberapa baris sysctl. Gak perlu ganti VPS, gak perlu pindah provider. Monggo, kita mulai dari awal biar kamu paham, terus bisa praktekin sendiri.

Masalahnya begini. TCP itu cara kerjanya pakai semacam jendela (window) buat ngirim data. Jendela ini nentuin berapa banyak data yang boleh dikirim sebelum nunggu konfirmasi dari sisi penerima. Kalau jendelanya kecil, bayangin antrean di kasir swalayan yang cuma bisa layani satu-dua orang tiap beberapa detik. Orangnya banyak, pintunya sempit, mau gimana lagi. Nah, ukuran jendela ini di Linux diatur oleh parameter yang disebut TCP buffer, lebih tepatnya receive buffer (rmem) untuk data yang masuk dan send buffer (wmem) untuk data yang keluar. Default-nya di mayoritas distro itu konservatif, karena dibuat untuk jaman mesin lawas yang RAM-nya cuma 512 MB.

Dampaknya ke user akhir kerasa banget. Download file 200 MB dari server jadi makan waktu dua kali lipat. Web app yang backend-nya mindahin data gede jadi nge-lag. API yang narik data 50 MB jadi ngantri lama. Dan yang paling nyebelin, masalah ini gak keliatan di CPU load, gak keliatan di RAM usage, bahkan gak keliatan di network error counter. Makanya banyak yang salah diagnosa: udah upgrade VPS, udah tambah RAM, udah ganti provider, tetep aja sama. Padahal akar masalahnya cuma di kernel setting.

Terus kenapa kok bisa? Ada tiga biang kerok utama. Pertama, default TCP buffer yang kecil. Di kebanyakan kernel modern, nilai maksimum tcp_rmem cuma di sekitar 6 MB, dan kalau TCP window scaling-nya mati, jendela maksimum cuma 64 KB. Kedua, TCP autotuning sebenarnya aktif, tapi dia cuma bisa manuver di dalam batas maksimum itu. Kalau batasnya kecil, hasilnya otomatis kecil juga. Ketiga, server yang berada di belakang link dengan latency tinggi (RTT di atas 50-80 ms) butuh buffer yang lebih gede lagi. Di sinilah konsep Bandwidth-Delay Product (BDP) masuk, dan dari hasil audit di puluhan server, kebanyakan buffer-nya jauh di bawah BDP. Nah, ini nih biang kerok utama yang bikin throughput mentok di angka yang bikin geregetan.

Langkah 1: Cek Dulu Kondisi TCP Buffer di Server Kamu

Sebelum main ubah, kita lihat dulu kondisi asli server. Command di bawah ini bakal nampilin nilai receive buffer, send buffer, dan batas maksimumnya. Catat baik-baik angkanya, biar nanti bisa dibandingin sebelum dan sesudah tuning.

sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem
sysctl net.core.rmem_max net.core.wmem_max

Output-nya kira-kira begini:

net.ipv4.tcp_rmem = 4096    131072  6291456
net.ipv4.tcp_wmem = 4096    16384   4194304
net.core.rmem_max = 212992
net.core.wmem_max = 212992

Nah, perhatiin format tiga angka di tcp_rmem: 4096 adalah nilai minimum, 131072 nilai default, dan 6291456 (6 MB) nilai maksimum. Sementara net.core.rmem_max itu adalah batas keras yang dipakai sistem. Kalau angkanya masih di kisaran 6 MB ke bawah, kamu pas di kondisi yang bikin performa mentok.

Langkah 2: Kenalan Sama Parameter Kunci

Biar gak asal tempel, aku jelasin dulu peran masing-masing. Ini penting, karena salah paham parameter itu ujung-ujungnya buang waktu doang.

Prinsipnya gini. Kalau autotuning aktif (tcp_moderate_rcvbuf=1), kernel bakal nyetel buffer secara dinamis sesuai kondisi jaringan. Tapi autotuning itu tetap menghormati nilai maksimum. Jadi kalau maksimumnya 6 MB dan BDP kamu butuh 10 MB, autotuning mentok di 6 MB. Makanya solusinya bukan matiin autotuning, tapi naikin batas maksimumnya.

Langkah 3: Hitung Kebutuhan Buffer Kamu (BDP)

Ini bagian paling menarik buatku. BDP itu rumus sederhana: berapa banyak data yang bisa ‘mengudara’ di dalam satu link dalam satu waktu. Kalau buffermu lebih kecil dari BDP, kamu pasti kena throttle. Rumusnya gini:

Contoh kasus nyata yang sering aku temuin: server di Jakarta, client di Eropa, RTT rata-rata 180 ms, bandwidth 1 Gbps. Hitungannya: 1.000.000.000 x 0,18 / 8 = 22.500.000 bytes, sekitar 21 MB. Kalau buffer maksimum kamu cuma 6 MB, udah kebayang kan hasilnya? Koneksi mentok di sekitar sepertiga dari kapasitas asli.

Langkah 4: Set Nilai Buffer (Percobaan Dulu, Baru Permanen)

Sekarang kita tes dulu tanpa bikin permanen. Nilai di bawah ini aku pakai di banyak server production dan terbukti aman untuk RAM 4 GB ke atas. Buat server yang RTT-nya panjang (di atas 100 ms), naikin nilai maksimum ke 32 MB sekalian biar gak perlu tuning dua kali.

sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
sysctl -w net.ipv4.tcp_rmem='4096 131072 16777216'
sysctl -w net.ipv4.tcp_wmem='4096 131072 16777216'
sysctl -w net.ipv4.tcp_moderate_rcvbuf=1
sysctl -w net.ipv4.tcp_slow_start_after_idle=0

Catatan penting: perubahan sysctl pakai -w ini cuma berlaku sampai server restart. Justru ini enaknya buat tes. Kalau ada yang aneh, tinggal restart server atau reload nilai default, gak ada efek permanen.

Langkah 5: Verifikasi Hasil Tuning

Jangan cuma percaya angka. Kita buktikan. Kalau belum ada iperf3, install dulu. Habis itu jalanin tes dari server kamu ke client, atau antara dua server.

iperf3 -c 203.0.113.10 -t 10 -R

Flag -R itu reverse, artinya server yang jadi target justru yang ngirim data ke kamu. Buat cek upload, hilangkan -R. Catat hasil sebelum tuning, terus tuning, terus tes lagi. Selisihnya biasanya gila-gilaan. Aku pernah lihat dari 12 Mbps jadi 180 Mbps cuma gara-gara ini. Sumpah, pengalaman yang bikin aku semangat nulis artikel ini.

Buat konfirmasi lebih dalam, bisa juga liat buffer per koneksi pakai ss:

ss -tni

Kolom rcv_space nunjukin ruang receive yang lagi dipakai. Kalau nilainya udah nyentuh angka maksimum yang kamu set, berarti buffer kepake penuh dan koneksi gak mentok lagi.

Langkah 6: Bikin Setting Permanen

Kalau hasilnya oke dan stabil, baru kita persist. Backup dulu file konfigurasinya. Kebiasaan ini harus kamu pegang di semua pekerjaan server.

cp /etc/sysctl.conf /etc/sysctl.conf.bak
cat >> /etc/sysctl.conf << 'EOF'
# TCP buffer tuning - fix latency & throughput
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 131072 16777216
net.ipv4.tcp_wmem = 4096 131072 16777216
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_slow_start_after_idle = 0
EOF
sysctl -p

Kalau kamu pakai systemd dan lebih suka file terpisah, bisa taruh di /etc/sysctl.d/99-tcp-tuning.conf dengan isi yang sama. Hasil akhirnya sama aja.

Bonus: Kalau Latency Tetap Kerasa di Link Jauh, Coba BBR

Nah, ini sih yang paling sering bikin aku heboh. Tuning buffer aja gak cukup kalau link-nya jauhan dan lossy. Buat kasus kayak gini, BBR (Bottleneck Bandwidth and RTT) sering jadi penyelamat. BBR ini algoritma congestion control yang lebih pinter dari CUBIC, karena dia nyari tahu bandwidth bottleneck beneran daripada nambah-nambahin paket terus nunggu drop.

modprobe tcp_bbr
sysctl -w net.ipv4.tcp_congestion_control=bbr
sysctl net.ipv4.tcp_congestion_control

Kalau output-nya bbr, berarti udah aktif. Persist juga: tambahkan net.ipv4.tcp_congestion_control = bbr di /etc/sysctl.conf. Butuh kernel 4.9 ke atas, dan kebanyakan VPS modern udah di atas itu.

Eh tapi jangan salah sangka, BBR itu bukan magic buat semua kasus. Untuk koneksi LAN yang bersih, CUBIC dan BBR hampir sama aja. BBR baru kerasa bedanya di link yang RTT-nya gede atau ada packet loss. Dan satu lagi, tuning buffer ini bukan buat ngecilin ping. Latency fisik (RTT) itu ditentuin jarak dan jalur, bukan buffer. Yang tuning ini lakuin: ngilangin throttle yang bikin koneksi lambat padahal jalurnya bagus.

Tabel Troubleshooting

Pro Tips & Peringatan dari Pengalaman

• Jangan set buffer gila-gilaan buat server dengan banyak koneksi, misalnya web server publik. 16 MB x 10.000 koneksi = 160 GB. Itu kebangetan. Untuk kasus gitu, cukup naikin secukupnya dan andelin autotuning.
• Perhatikan net.ipv4.tcp_mem. Ini batas total memori yang boleh dipakai semua koneksi TCP, dihitung per halaman (biasanya 4 KB). Kalau melewati nilai ketiga, kernel bakal nolak nambahin buffer walau setting-an kamu gede.
• Tuning ini bukan pengganti monitoring. Tetep pantau load average dan resource usage biar bisa bedain antara network dan aplikasi.
• Buat server yang arah traffic-nya satu arah, kayak download server, naikin tcp_rmem aja udah cukup. Gak perlu dua-duanya.
• Kalau server kamu juga dipakai buat layanan interaktif kayak SSH atau game, jangan naikin buffer doang. Buffer gede + antrian penuh = bufferbloat, latency-nya malah memburuk. Kombinasikan dengan fq_codel atau cake di qdisc.

Kesimpulan

Intinya gini. Server yang kerasa lambat tapi semua resource normal itu kandidat kuat kena TCP buffer yang kekecilan. Cek dulu nilai sysctl-nya, hitung BDP-nya, set buffer-nya, terus verifikasi pakai iperf3. Lima langkah, gak sampai setengah jam, dan hasilnya bisa bikin kaget.

Kalau kamu pengen dalem-dalem soal sisi jaringan yang lain, ada beberapa artikel yang sejalan: 7 parameter TCP buffer buat throughput tinggi, cara cek throughput pakai iperf3, dan troubleshooting server lambat.

Gimana? Cukup menarik kan. Yuk langsung praktekin langkah-langkah di atas, mulai dari cek sysctl dulu. Kalau nemu angka yang beda sama di artikel ini, jangan panik, itu wajar — tiap distro beda default-nya. Dan nek masih ada yang ganjal, cek log kernel kamu, bandingin sama gejala yang aku sebut tadi. Gas terus, semangat! Gak sabar denger cerita hasil tuning kamu.