TCP vs UDP bagi Pengembang — Kapan Protokol Sebenarnya Penting

Anda sedang membangun permainan multiplayer. Para pemain mengeluhkan lag. Anda telah mengoptimalkan kode server, mengurangi kueri database, dan latency p99 terlihat baik. Masalahnya lebih sederhana: Anda menggunakan TCP. Itu saja. Itu adalah sumber lag.

TCP dan UDP bukan hanya dua kotak pada daftar protokol — mereka mewakili keputusan yang sangat berbeda tentang apa yang akan dilakukan jaringan. Pilihan yang salah tidak hanya mengorbankan kinerja. Ia mengubah karakter kegagalan ketika sesuatu salah.

Keputusan yang dibuat oleh TCP

TCP menjanjikan Anda aliran byte yang dapat diandalkan dan terurut. Jika paket hilang, TCP akan mengirim ulang paket tersebut. Jika paket tiba dalam urutan yang salah, TCP akan mengatur ulang urutannya. Aplikasi Anda selalu melihat data yang bersih dan berurutan.

Janji tersebut mengorbankan tiga hal:

• Lag waktu handshake — TCP membutuhkan tiga tahap handshake sebelum satu byte data aplikasi bergerak. Pada jaringan dengan waktu perjalanan 50ms, Anda menghabiskan 150ms sebelum permintaan pertama bahkan dimulai.
• Penghambatan kepala baris — Ini yang membunuh permainan. Jika paket #5 hilang, TCP menahan paket #6, #7, dan #8 dalam buffer menunggu #5 dikirim ulang dan tiba. Aliran terhambat. Pembaruan posisi pemain dari 100ms yang lalu berada dalam buffer sambil jaringan memperbaikinya.
• Beban pengendalian kemacetan — Algoritma jendela kemacetan TCP (CUBIC, BBR, dll) mengurangi laju pengiriman saat mendeteksi kehilangan. Pada jaringan yang kehilangan paket, ini berarti TCP mengurangi throughput tepat saat jaringan sedang kesulitan — saat pengguna merasakannya paling parah.

Apa yang sebenarnya diberikan oleh UDP

UDP mengirim datagram dan tidak melihat kembali. Tidak ada handshake, tidak ada pengakuan, tidak ada pengiriman ulang. Jika paket hilang, maka hilang. Penerima menerima apa yang tiba, dalam urutan apa yang tiba.

Ini bukan kekurangan — ini adalah inti. Ketika Anda membutuhkan latensi yang rendah lebih dari Anda butuhkan jaminan pengiriman, UDP memungkinkan Anda membuat keputusan tersebut secara eksplisit. Logika keandalan pindah ke lapisan aplikasi, di mana Anda dapat membuat keputusan yang lebih cerdas tentang apa yang benar-benar perlu dikirim ulang.

Dalam permainan, pembaruan posisi pemain dari 50ms yang lalu tidak bernilai — Anda ingin yang terbaru. Dengan TCP, Anda akan menunda dan menunggu. Dengan UDP, Anda mengirimkan status terbaru dan melewatkan yang sudah usang. Pengalaman menjadi lebih halus bahkan di bawah kehilangan paket yang lebih besar.

TCP vs UDP: perbandingan yang benar-benar penting

Properti	TCP	UDP
Pembentukan koneksi	Tiga tahap handshake (menambahkan 1,5× RTT sebelum byte pertama)	Tidak ada — langsung dikirimkan
Jaminan pengiriman	Ya — mengirim ulang saat kehilangan terjadi	Tidak — mengirim dan lupa
Pengurutan paket	Dijaga oleh stack	Masalah Anda
Penghambatan kepala baris	Ya — satu paket yang hilang menghambat aliran	Tidak — setiap datagram independen
Pengendalian kemacetan	Dibangun secara internal (CUBIC, BBR, dll)	Tidak ada — Anda harus membuat sendiri atau melewatinya
Beban latensi biasa	150–300ms pada koneksi dingin	Sub-milidetik
Kasus penggunaan	HTTP/1.1, HTTP/2, database, transfer file, email	DNS, permainan, video langsung, HTTP/3 (QUIC)

Di mana setiap protokol sebenarnya berada

DNS berjalan di atas UDP — dan ada pelajaran di sana

Setiap permintaan DNS yang dibuat oleh aplikasi berjalan di atas UDP secara default. Permintaan ini memasukkan satu paket, respons ini memasukkan satu paket, dan Anda mendapatkan jawaban dalam satu putaran. Tidak ada beban handshake, tidak ada status yang harus dipertahankan di server.

Jika respons terlalu besar (rekaman DNSSEC, banyak A record), DNS beralih ke TCP. Namun kasus umum — pencarian hostname — adalah UDP karena keputusan ini jelas: tiga tahap handshake akan memakan waktu lebih lama daripada permintaan aktual.

Anda dapat melihat perilaku ini secara langsung dengan alat IO Tools DNS Lookup tool — masukkan domain dan lihat seberapa cepat tipe record individu teresokasi. Kecepatan itu adalah UDP yang menghilangkan seluruh putaran handshake.

Permainan: UDP adalah satu-satunya jawaban nyata

Setiap library jaringan utama permainan — Valve’s GameNetworkingSockets, Epic’s EOS transport, Unity’s UTP — dibangun di atas UDP. Alasannya adalah penghambatan kepala baris.

Dalam permainan FPS kompetitif, Anda mengirimkan pembaruan posisi setiap 64 tick — setiap 15ms. Jika satu paket hilang dan TCP menahan lima paket berikutnya saat menunggu pengiriman ulang, Anda memperkenalkan 75ms dari getaran tepat di saat yang salah. Dengan UDP, Anda mengirimkan pembaruan berikutnya secara langsung. Klien menginterpolasi di atas celah tersebut. Pengalaman menjadi halus.

Kode jaringan permainan yang dibangun di atas UDP biasanya mengimplementasikan keandalan selektif — nomor urutan, antrian prioritas, pengakuan selektif — tetapi hanya untuk data yang benar-benar diperlukan: pesan obrolan, pengambilan item, status pertandingan. Data posisi tidak dijamin secara desain. Bacaan usang lebih buruk daripada tidak ada bacaan sama sekali.

Streaming video: tergantung pada kasus penggunaan

Streaming langsung (Twitch, siaran olahraga) menggunakan protokol berbasis UDP — RTP, WebRTC, SRT — karena beberapa frame yang hilang dapat diterima tetapi latensi tidak dapat diterima. Anda tidak bisa menunda 30 detik dari pertandingan langsung untuk menjamin pengiriman yang halus.

VOD (Netflix, YouTube) sebenarnya menggunakan TCP, karena buffering menyembunyikan biaya tersebut. Beberapa detik buffering berarti beban pengiriman ulang TCP tidak terlihat — Anda hanya melihat pemutaran yang halus. Dampak latensi tidak penting ketika Anda menonton sesuatu yang terjadi hari kemarin.

HTTP/3 berjalan di atas UDP — dan ini mengubah kinerja web

HTTP/3 berjalan di atas QUIC, yang berjalan di atas UDP. Google membangun QUIC secara khusus untuk memperbaiki masalah penghambatan kepala baris pada lalu lintas web. Dengan HTTP/2 di atas TCP, satu paket yang hilang menghambat semua aliran yang berbagi koneksi tersebut. QUIC mengimplementasikan multiplexing aliran di lapisan transportasi dengan pengakuan independen — satu paket yang hilang hanya menghambat satu aliran, bukan semua aliran.

QUIC juga mengintegrasikan TLS ke dalam proses handshake, mengurangi pembentukan koneksi dingin menjadi satu putaran (0-RTT pada pemulihan sesi). Pada jaringan yang tidak stabil — koneksi seluler, WiFi yang macet — ini merupakan perbaikan yang bermakna. Pada tahun 2024, sekitar 30% situs web mendukung HTTP/3, dan semua browser utama mengaktifkannya secara default. Jika Anda mengatur layanan di balik Cloudflare atau CDN modern, Anda mungkin sudah menyajikan HTTP/3 tanpa harus mengatur secara eksplisit.

Pohon keputusan praktis

Ketika Anda memilih transportasi untuk protokol atau layanan baru, pertanyaannya bukan “TCP atau UDP?” — melainkan “jenis kegagalan mana yang dapat saya toleransi?”

• Setiap byte harus tiba, dalam urutan, atau operasi gagal → TCP. Upload file, koneksi ke database, panggilan API, email. Kehilangan data berarti data korup atau kesalahan parsing.
• Latensi lebih penting daripada jaminan pengiriman → UDP. Permainan, video langsung, panggilan suara, telemetri sensor. Bacaan usang lebih buruk daripada tidak ada bacaan sama sekali.
• Anda membutuhkan keduanya, per-pesan → Bangun di atas UDP dengan keandalan selektif. QUIC melakukannya. Saluran data SCTP di WebRTC melakukannya. Library seperti ENet dan GameNetworkingSockets melakukannya juga — meskipun mengimplementasikannya sendiri merupakan pekerjaan yang tidak mudah dan mudah salah jika tidak hati-hati.

Salah satu kesalahan yang perlu ditekankan: mengasumsikan bahwa “lalu lintas internal” berarti Anda dapat menggunakan UDP secara bebas. Kehilangan paket di dalam datacenter jarang terjadi tetapi tidak nol — kegagalan perangkat keras, kemacetan jaringan saat beban puncak, switch yang dikonfigurasi salah. Jika aplikasi Anda secara diam-diam menghancurkan data saat kehilangan terjadi, jaringan internal tidak akan menyelamatkan Anda.

Penutup

TCP adalah default yang tepat untuk kebanyakan kode aplikasi. Jika Anda membuat panggilan API, berkomunikasi dengan database, atau mentransfer file, jaminan TCP tepat yang Anda butuhkan dan beban overhead tidak terlihat pada skala waktu manusia.

UDP adalah pilihan yang tepat ketika latensi adalah kendala yang ketat dan aplikasi Anda dapat mengendalikan hubungan dengan keandalan. Ini adalah kumpulan masalah tertentu — permainan real-time, media langsung, protokol khusus — bukan optimasi kinerja umum yang harus dipanggil saat TCP terasa lambat.

Kesalahan sebenarnya bukan menggunakan TCP saat UDP lebih cepat. Ini adalah tidak tahu mana yang Anda pilih, atau mengapa, dan terkejut ketika mode kegagalan muncul.

Anda mungkin juga menyukai