"TCP itu andal, UDP nggak." Benar, dan hampir nggak berguna waktu Anda sedang menghadapi jaringan yang bermasalah.
Yang lebih berguna: tahu apa yang benar-benar dikerjakan keduanya, dan gejala apa yang muncul kalau jalurnya nggak sehat.
Yang dikerjakan TCP
TCP memulai dengan jabat tangan — kedua sisi sepakat dulu sebelum ada data yang dikirim. Setiap potongan data diberi nomor urut, dan penerima memberi tahu apa saja yang sudah sampai.
Kalau ada yang hilang, dikirim ulang. Kalau urutannya kacau, disusun ulang sebelum diserahkan ke aplikasi.
Hasilnya: data yang sampai selalu utuh dan berurutan. Harganya: waktu.
Yang dikerjakan UDP
Kirim, selesai. Nggak ada jabat tangan, nggak ada nomor urut, nggak ada pengiriman ulang. Kalau hilang, ya hilang.
Hasilnya: nggak ada yang menunggu. Harganya: aplikasi harus siap menerima data yang bolong.
Yang menentukan pilihan bukan keandalan
Pertanyaannya bukan "mau andal atau nggak" — semua orang mau andal. Pertanyaannya: buat aplikasi ini, mana yang lebih buruk — data yang bolong atau data yang telat?
Kirim berkas: bolong nggak bisa ditolerir sama sekali, telat sedikit nggak apa-apa. TCP.
Panggilan suara: telat itu fatal. Kalau satu potongan suara hilang lalu dikirim ulang, dia datang setelah percakapan sudah lewat — nggak ada gunanya, malah merusak. Hilangnya sedikit justru bisa disamarkan telinga. UDP.
| Layanan | Yang dipakai |
|---|---|
| Web biasa | TCP 80 dan 443 |
| Web dengan HTTP/3 | UDP 443 |
| DNS | UDP 53, pindah ke TCP untuk jawaban besar |
| Suara dan video call | UDP |
| WireGuard | UDP |
| SSTP | TCP |
| Game online | UDP |
Empat hal yang terasa di lapangan
1. Packet loss kecil menghancurkan TCP jauh lebih parah daripada dugaan. Kehilangan satu persen kedengarannya sepele. Tapi TCP nggak cuma mengirim ulang yang hilang — dia juga menganggap kehilangan itu tanda jaringan padat, lalu mengecilkan kecepatan kirimnya. Jalur dengan loss satu persen bisa kehilangan sebagian besar throughput-nya. Duduk perkaranya di jalur 100 Mbps kok terasa 8 Mbps, dan angkanya bisa dicoba di Kalkulator Throughput TCP.
2. UDP nggak peduli loss, tapi sangat peduli jitter. Suara putus-putus padahal ping bagus itu gejala khas: yang salah bukan latency melainkan selisih antar paket yang datang. Diuraikan di ping bagus tapi VoIP putus-putus.
3. Memblokir UDP 443 mematikan HTTP/3 tanpa Anda sadari. Sebagian besar situs besar sekarang mencoba UDP 443 lebih dulu. Kalau firewall Anda membuang UDP tanpa membalas, browser menunggu dulu sebelum kembali ke TCP — dan hasilnya situs terasa lambat di jaringan Anda saja. Kalau memang mau memblokir, blokir dengan reject, bukan drop.
Ini juga yang bikin pemblokiran aplikasi sering gagal separuh jalan; contohnya di blokir TikTok dan YouTube di MikroTik yang masih bisa dibuka.
4. Aturan firewall yang cuma menyebut TCP akan melewatkan hal-hal tak terduga. Kalau Anda menutup sebuah layanan tapi lupa protokolnya juga jalan di UDP, layanan itu tetap terbuka. Periksa dua-duanya. Pencari Nomor Port menampilkan port beserta protokolnya, jadi kelihatan mana yang punya dua pintu.
Daftar port yang sebaiknya nggak pernah terbuka ke internet ada di port mana yang tidak boleh dibuka.