Semua lalu lintas web bergerak di atas dua protokol transport yang menawarkan janji berbeda: TCP menjamin setiap byte tiba secara berurutan, sedangkan UDP mengirim pesan tanpa jaminan apa pun. Topik ini membedah cara kedua protokol bekerja, menghitung harga keandalan pada tautan yang hilang paket, dan menempatkan UDP pada desain sistem modern. Setelah membacanya, pemilihan transport untuk kebutuhan streaming, yaitu pengiriman media berkelanjutan, kueri, dan komunikasi antarlayanan, memiliki dasar yang jelas.
TCP: kanal byte yang andal dan berurutan#
TCP (Transmission Control Protocol) menyediakan kanal byte yang andal, berurutan, dan dua arah antara dua titik ujung. Sebelum data pertama terkirim, kedua sisi menjalankan handshake tiga langkah, yaitu klien mengirim SYN, server membalas SYN-ACK, dan klien menutupnya dengan ACK. Prosedur ini menyepakati nomor urut awal dan memastikan kedua arah siap mengirim, dengan biaya satu RTT (round-trip time) sebelum byte aplikasi yang pertama.
Setelah koneksi berjalan, TCP menomori setiap byte dan menuntut ACK untuk setiap segmen yang diterima. Segmen yang tidak dibalas ACK dalam batas waktu dikirim ulang, sehingga aplikasi tidak pernah melihat paket yang hilang atau tertukar urutannya. TCP juga mengatur laju kiriman melalui flow control agar penerima tidak kehabisan penyangga, serta congestion control agar jaringan tidak dibanjiri ketika kemacetan terdeteksi. Semua jaminan ini menyimpan state, yaitu data koneksi yang tersimpan, pada kedua sisi, dan tabel koneksi itulah yang harus dijaga server untuk setiap klien.
UDP: datagram tanpa jaminan#
UDP (User Datagram Protocol) mengirim datagram, yaitu pesan kecil yang berdiri sendiri tanpa koneksi, tanpa nomor urut, dan tanpa pengiriman ulang. Satu-satunya pemeriksaan yang disediakan adalah checksum untuk menangkap kerusakan isi, dan datagram yang rusak atau hilang dibuang tanpa kabar. Header UDP hanya delapan byte, sedangkan header TCP dua puluh byte atau lebih, sehingga setiap datagram lebih ringan dibawa oleh jaringan.
Tanpa koneksi, server tidak menyimpan state apa pun untuk menerima datagram, sehingga satu proses yang sama dapat melayani ribuan pengirim sekaligus. Datagram juga dapat dikirim ke banyak tujuan sekaligus melalui broadcast dan multicast, yaitu pengiriman ke banyak penerima dalam satu kali kirim, sesuatu yang tidak dimungkinkan oleh TCP. Kebebasan itu dibayar oleh aplikasi: apabila keandalan dibutuhkan, aplikasi harus membangun nomor urut, ACK, dan retransmisinya sendiri.
Perbandingan TCP dan UDP#
Tabel berikut merangkum perbedaan kedua protokol pada aspek-aspek yang paling sering menjadi penentu keputusan desain.
| Aspek | TCP | UDP |
|---|---|---|
| Bentuk komunikasi | Kanal byte bersambung | Datagram terpisah |
| Jaminan pengiriman | Ada, paket hilang dikirim ulang | Tidak ada |
| Pengurutan | Dijaga dengan nomor urut | Tidak dijamin |
| Biaya sebelum data pertama | Handshake satu RTT | Langsung kirim |
| Ukuran header | 20 byte atau lebih | 8 byte |
| State di server | Tabel koneksi per klien | Tanpa state koneksi |
| Pola pengiriman | Satu lawan satu | Satu lawan satu, broadcast, multicast |
| Penggunaan lazim | Web, API, transfer berkas | DNS, streaming media, game daring |
Perbedaan yang paling menentukan bagi desain bukan kecepatan, melainkan letak tanggung jawab keandalan. TCP menanggung semuanya di dalam protokolnya, sedangkan UDP menyerahkannya kepada aplikasi. Karena itu pilihan TCP atau UDP jarang berdiri sendiri, dan yang sebenarnya dipilih adalah tumpukan jaminan yang dibutuhkan aplikasi beserta protokol yang menyediakannya dengan biaya paling pas.
Simulasi keandalan dan harganya#
Keandalan TCP dibayar dengan waktu. Skrip berikut menyimulasikan pengiriman 10 paket pada kanal yang menghilangkan 20% paket dengan model stop-and-wait, yaitu konfirmasi satu paket ditunggu sebelum paket berikutnya dikirim. Kedua protokol melewati kanal yang sama, sehingga perbedaannya murni berasal dari cara merespons paket yang hilang. Angka acaknya dibekukan agar keluaran dapat direproduksi, dan skrip dijalankan dengan python3 simulasi-paket.py.
# Simulasi pengiriman 10 paket pada tautan yang menghilangkan 20% paket.
# Model: stop-and-wait, satu paket ditunggu ACK-nya sebelum paket berikutnya.
# Kedua protokol melewati kanal yang sama; TCP mengirim ulang paket yang
# hilang, UDP hanya mengirim sekali tanpa menunggu kabar.
import random
random.seed(2) # angka acak dibekukan agar keluaran dapat direproduksi
N_PAKET = 10
PELUANG_HILANG = 0.2
RTT = 40 # ms, waktu tunggu satu percobaan pengiriman
# Karakter kanal: jumlah percobaan yang dibutuhkan agar tiap paket sampai
percobaan_kanal = []
for _ in range(N_PAKET):
usaha = 1
while random.random() < PELUANG_HILANG:
usaha += 1
percobaan_kanal.append(usaha)
# UDP hanya melakukan percobaan pertama, lalu berpindah ke paket berikutnya
hilang_udp = sum(1 for usaha in percobaan_kanal if usaha > 1)
waktu_udp = N_PAKET * RTT
# TCP menunggu ACK dan mengulang sampai setiap paket terkonfirmasi
waktu_tcp = sum(percobaan_kanal) * RTT
retransmisi = sum(percobaan_kanal) - N_PAKET
for nomor, usaha in enumerate(percobaan_kanal, start=1):
if usaha == 1:
print(f"Paket {nomor:>2}: kanal mengantarkan pada percobaan pertama")
else:
print(f"Paket {nomor:>2}: kanal menghilangkan {usaha - 1} kali sebelum sampai")
print(f"TCP: {N_PAKET} dari {N_PAKET} paket sampai, {retransmisi} retransmisi, waktu {waktu_tcp} ms")
print(f"UDP: {N_PAKET - hilang_udp} dari {N_PAKET} paket sampai, {hilang_udp} paket hilang permanen, waktu {waktu_udp} ms")Paket 1: kanal mengantarkan pada percobaan pertama
Paket 2: kanal mengantarkan pada percobaan pertama
Paket 3: kanal menghilangkan 2 kali sebelum sampai
Paket 4: kanal mengantarkan pada percobaan pertama
Paket 5: kanal mengantarkan pada percobaan pertama
Paket 6: kanal mengantarkan pada percobaan pertama
Paket 7: kanal mengantarkan pada percobaan pertama
Paket 8: kanal mengantarkan pada percobaan pertama
Paket 9: kanal mengantarkan pada percobaan pertama
Paket 10: kanal menghilangkan 1 kali sebelum sampai
TCP: 10 dari 10 paket sampai, 3 retransmisi, waktu 520 ms
UDP: 8 dari 10 paket sampai, 2 paket hilang permanen, waktu 400 msPada kanal yang sama, TCP menyelesaikan 10 paket dengan 3 retransmisi sehingga waktunya memanjang dari 400 ms menjadi 520 ms, sedangkan UDP selesai lebih cepat tetapi kehilangan 2 paket secara permanen. Untuk transfer berkas, dua paket yang hilang berarti data rusak dan harus dikirim ulang, sehingga keandalan TCP lebih murah daripada kerugiannya. Untuk panggilan video, paket yang tiba setelah 120 ms penundaan retransmisi sudah tidak berguna, sehingga kehilangan kecil lebih dapat diterima daripada keterlambatan.
Posisi UDP pada desain modern#
UDP menjadi dasar generasi protokol web terbaru karena kebebasannya dapat dibentuk ulang oleh aplikasi. Protokol QUIC, yang menjadi dasar HTTP/3, berjalan di atas UDP sambil membangun sendiri keandalan, enkripsi TLS 1.3, dan multiplexing aliran, yaitu banyak aliran berbagi satu koneksi. Dengan membangunnya di atas UDP, aliran yang satu tidak menahan aliran lain ketika paket hilang, kelemahan yang masih melekat pada HTTP/2 di atas TCP. QUIC juga membawa pengenal koneksi (connection ID) sehingga perangkat yang berpindah dari Wi-Fi ke jaringan seluler dapat melanjutkan koneksi tanpa membangunnya dari nol.
Di luar QUIC, UDP dipilih ketika keterlambatan lebih mahal daripada kehilangan. Kueri DNS dilayani melalui satu datagram UDP dengan TCP sebagai cadangan bagi respons yang besar. Panggilan dan konferensi video memakai UDP karena bingkai yang tiba terlambat tidak lagi bermanfaat, sedangkan game daring memakainya agar setiap keadaan terbaru terkirim secepat mungkin. Live streaming dengan latensi rendah mengikuti pola yang sama, dan keandalan selektif ditambal pada lapisan aplikasi bila diperlukan.
Memilih UDP bukan berarti menolak keandalan, melainkan memindahkannya ke tempat yang lebih tepat. Protokol di atas UDP bebas menentukan jaminan per aliran, yaitu data kontrol dibuat andal, sedangkan data media dikirim sekali dan dibiarkan lewat bila hilang. Fleksibilitas ini tidak dapat ditawarkan TCP karena jaminannya berlaku seragam untuk seluruh kanal.
Kesalahan umum#
Tiga kesalahan berikut muncul ketika pertimbangan untung-rugi (tradeoff) kedua protokol dibaca terlalu sederhana.
- Menganggap UDP selalu lebih cepat. Kecepatan UDP berasal dari jaminan yang tidak dibayarkan, bukan dari pipa yang lebih lebar, sehingga aplikasi yang menuntut keandalan tetap harus membangun retransmisi sendiri beserta biayanya.
- Mengirim data yang tidak boleh hilang melalui UDP tanpa lapisan keandalan. Datagram yang hilang tidak pernah dilaporkan, sehingga kerusakan baru ketahuan ketika data dipakai.
- Membandingkan kedua protokol hanya dari throughput, yaitu jumlah data yang terkirim per satuan waktu. Latensi koneksi pertama, jumlah state di server, dan perilaku saat kehilangan paket sering lebih menentukan daripada lebar pipa.
Ringkasan#
- TCP menukar handshake, state koneksi, dan retransmisi dengan kanal byte yang andal dan berurutan, sedangkan UDP menukar seluruh jaminan itu dengan header 8 byte dan tanpa koneksi.
- Pada kanal yang hilang paket, keandalan dibayar dengan retransmisi yang menambah RTT, sedangkan kehilangan yang dibiarkan menambah risiko kerusakan data.
- QUIC dan HTTP/3 memakai UDP sebagai fondasi agar keandalan dan multiplexing dapat dibangun ulang tanpa menunggu perubahan pada TCP.
- Pemilihan transport mengikuti letak tanggung jawab keandalan, bukan sekadar angka throughput.
Referensi#
- Transmission Control Protocol (RFC 9293) — IETF — Spesifikasi TCP saat ini, mencakup handshake, nomor urut, dan retransmisi.
- User Datagram Protocol (RFC 768) — IETF — Spesifikasi UDP yang tetap pendek sejak 1980.
- QUIC: A UDP-Based Multiplexed and Secure Transport (RFC 9000) — IETF — Spesifikasi QUIC sebagai transport di atas UDP.