TCP Membentuk Connection Dan Menjaga Urutan Data
TCP menggunakan sequence number, acknowledgement, retransmission, dan flow control untuk menyediakan byte stream yang andal kepada aplikasi. Sebelum data aplikasi dikirim, endpoint membentuk koneksi melalui handshake. Jika segment hilang, TCP dapat mengirim ulang. Aplikasi tidak perlu mengelola urutan setiap packet secara langsung, tetapi sebagai konsekuensinya ada state dan mekanisme tambahan yang meningkatkan overhead dibanding datagram sederhana.
Flow control pada TCP melindungi receiver agar pengirim tidak mengirim data lebih cepat daripada kemampuan buffer penerima. Congestion control berbeda karena menyesuaikan laju terhadap kondisi jaringan. Kedua mekanisme bekerja bersama namun menyelesaikan masalah yang berbeda: kapasitas endpoint dan kapasitas path.
TCP juga memiliki mekanisme connection termination dan state yang perlu dipertahankan di kedua endpoint. TIME_WAIT, retransmission timeout, dan congestion window adalah contoh state yang tidak ada pada UDP dasar. State ini memberi reliability, tetapi juga menjelaskan mengapa server TCP perlu mengelola banyak koneksi secara efisien.
UDP Mengirim Datagram Dengan Overhead Yang Lebih Ringan
UDP menyediakan header sederhana dengan port, length, dan checksum. Tidak ada handshake seperti TCP, tidak ada jaminan urutan, dan tidak ada retransmission bawaan. Aplikasi dapat menambahkan reliability sendiri jika dibutuhkan atau memilih menerima kehilangan data ketika latency lebih penting. DNS klasik, streaming tertentu, game real-time, dan protokol modern dapat menggunakan UDP untuk alasan yang berbeda.
Checksum UDP wajib pada IPv6 dan digunakan untuk mendeteksi corruption pada datagram. Namun checksum tidak memberi jaminan delivery. Jika packet hilang, aplikasi tidak mendapat retransmission otomatis dari UDP. Aplikasi real-time dapat memilih mengabaikan frame yang hilang karena data lama sudah tidak berguna ketika retransmission tiba.
Kecepatan Tidak Bisa Disederhanakan Menjadi UDP Selalu Lebih Cepat
UDP memiliki overhead protokol yang lebih kecil, tetapi performa aplikasi tetap bergantung pada desain. TCP memiliki congestion control yang terus berkembang dan dapat memanfaatkan bandwidth dengan sangat baik. Sebaliknya, aplikasi UDP yang tidak mengelola congestion dapat menyebabkan performa buruk atau mengganggu jaringan. Pilihan transport harus melihat reliability, latency, ordering, loss tolerance, dan bagaimana aplikasi menangani congestion.
TCP juga dapat mengalami head-of-line blocking pada satu byte stream karena data berikutnya menunggu bagian sebelumnya yang hilang. HTTP/2 menggunakan banyak stream di atas satu koneksi TCP sehingga kehilangan packet dapat memengaruhi beberapa stream sekaligus pada level transport. QUIC memindahkan multiplexing ke atas UDP agar stream independen tidak terblokir dengan cara yang sama.
QUIC Menunjukkan Bahwa Reliability Juga Bisa Dibangun Di Atas UDP
QUIC menggunakan UDP sebagai substrate tetapi menambahkan connection management, encryption, recovery, congestion control, dan stream multiplexing pada layer di atasnya. HTTP/3 menggunakan QUIC. Contoh ini menunjukkan bahwa penggunaan UDP tidak berarti aplikasi “tanpa reliability”. UDP memberi datagram dasar, sementara protokol aplikasi dapat membangun mekanisme transport yang lebih kompleks sesuai kebutuhan.
Port number membantu sistem operasi mengarahkan traffic ke aplikasi atau socket yang tepat. TCP dan UDP memiliki namespace port sendiri, sehingga port 53 TCP dan port 53 UDP adalah endpoint transport yang berbeda. Firewall juga dapat menerapkan aturan berbeda berdasarkan protocol dan port.
Karena QUIC berjalan di user space pada banyak implementasi, evolusi algoritma transport dapat dilakukan lebih cepat dibanding menunggu perubahan stack TCP kernel. Namun UDP tetap hanya menjadi pembawa datagram; keamanan dan reliability QUIC berasal dari protokol QUIC itu sendiri.
