TCP, UDP, dan port

Nomor port terdiri atas 16 bit, jadi berkisar dari 0 sampai 65535. Server web yang memakai HTTPS mendengarkan di port 443.

Dua teka-teki dulu. Dalam panggilan video, satu potongan kecil suara temanmu hilang di jalan. Haruskah aplikasimu memintanya lagi? Sekarang kamu sedang mengunduh berkas PR, dan satu potongan berkas itu hilang. Pertanyaan yang sama. Putuskan keduanya sebelum lanjut membaca.

Dua potongan hilang, dua jawaban berbeda

Jika kamu menjawab tidak untuk panggilan dan ya untuk berkas, kamu sudah memilih di antara dua transport. Potongan suara yang tiba setengah detik terlambat tidak berguna. Percakapan sudah berlanjut, jadi lebih baik melewati potongan itu dan memutar yang berikutnya. Berkas yang kehilangan satu potongan rusak, jadi potongan itu layak ditunggu. Internet punya transport untuk masing-masing kasus: TCP menunggu dan mengirim ulang, UDP mengirim lalu lanjut. Namun sebelum keduanya bisa membantu, paket harus sampai ke program yang tepat.

Program mana yang menerima paket: port

Alamat IP membawa paket ke komputer yang tepat. Namun satu komputer menjalankan banyak program sekaligus: peramban dengan beberapa tab, aplikasi obrolan, aplikasi musik. Header TCP dan UDP sama-sama membawa port sumber dan port tujuan, masing-masing bilangan 16 bit dari 0 sampai 65535, dan port menyatakan untuk program mana sebuah paket. Program server mendengarkan di port yang disepakati: 80 untuk HTTP biasa, 443 untuk HTTPS, 53 untuk DNS, 25 untuk email antarserver. RFC 6335 membagi rentangnya menjadi port sistem 0 sampai 1023, port pengguna 1024 sampai 49151, dan port dinamis 49152 sampai 65535. Komputermu memilih port sumber sementara untuk setiap percakapan, sering dari rentang dinamis. Alamat dan port bersama-sama, seperti 198.51.100.20:443, menyebut satu ujung percakapan dengan tepat.

TCP mencentang setiap byte

TCP (RFC 9293) mengubah aliran paket yang tidak andal menjadi sesuatu seperti saluran telepon untuk byte. Pertama, kedua pihak membangun koneksi dengan jabat tangan tiga arah: klien mengirim SYN, server menjawab SYN-ACK, dan klien membalas ACK. Sejak itu setiap byte punya nomor urut. Penerima mengirim tanda terima (ACK) yang menyatakan sejauh mana ia sudah menerima, dan menaruh kembali potongan yang tidak berurutan ke tempatnya. Jika pengirim tidak menerima ACK dalam batas waktu, ia mengirim datanya lagi. RFC 6298 menetapkan batas waktu pertama 1 detik lalu menyesuaikannya dengan waktu perjalanan bolak-balik yang terukur. TCP juga melambat saat mendeteksi kehilangan, agar satu tautan yang sibuk tidak kebanjiran.

UDP mengirim lalu lanjut

UDP (RFC 768, 1980) melakukan jauh lebih sedikit. Header-nya hanya 8 byte: dua port, panjang, dan checksum. Tidak ada jabat tangan, tidak ada nomor urut, dan tidak ada pengiriman ulang. Untuk panggilan video di teka-teki pertama, itu tepat sekali. Pertanyaan DNS yang pendek juga memakai UDP, karena satu pertanyaan dan satu jawaban lebih cepat tanpa jabat tangan. QUIC, transport di bawah HTTP/3, berjalan di atas UDP dan membangun pengiriman ulangnya sendiri di atasnya.

Empat angka memisahkan dua tab

Empat angka bersama-sama mengenali satu koneksi TCP: alamat sumber, port sumber, alamat tujuan, dan port tujuan. Begitulah server di port 443 bisa berkomunikasi dengan ribuan peramban sekaligus tanpa tertukar, dan begitulah laptopmu memisahkan dua tab di situs yang sama, karena koneksi setiap tab memakai port sumber yang berbeda. Ketuk sebuah paket di simulator dan baca header-nya. Sebelum router rumah, sumbernya 192.168.0.12 port 51000. Sesudahnya, NAT telah mengubah kedua angka itu, dan router mengingat penggantiannya agar balasan kembali ke tab yang tepat.