Konsep Jaringan dan Model Client-Server

Sebagian besar program C++ yang kita temui di dunia nyata tidak berjalan sendirian: alat baris perintah mengambil data dari API, layanan latar menerima perintah dari mesin lain, dan game mengirim status pemain ke server. Semua percakapan itu berlangsung di atas fondasi yang sama — alamat IP, port, dan protokol transport. Sebelum kita menulis satu baris kode socket, kita perlu memahami peta besar ini agar setiap panggilan API pada chapter berikutnya punya makna yang jelas. Chapter ini sengaja berisi konsep dan tabel rujukan tanpa kode C++; program pertama kita muncul pada Chapter TCP Socket dengan POSIX Socket API. Chapter C++ dan Networking di section Interoperabilitas dan Ecosystem sebelumnya sudah menunjukkan siklus hidup socket secara singkat; chapter ini menata dasar konsepnya secara utuh.

Alamat IP dan Port: Peran Masing-masing #

Alamat IP mengidentifikasi sebuah perangkat di dalam jaringan. IPv4 memakai alamat 32-bit yang ditulis sebagai empat angka 0-255 yang dipisah titik, misalnya 203.0.113.10; IPv6 memakai alamat 128-bit yang ditulis dalam heksadesimal berkelompok, misalnya 2001:db8::1. Ketika program kita mengirim data, sistem operasi menempelkan alamat IP tujuan agar perangkat keras jaringan tahu ke perangkat mana data harus dibawa.

Perangkat yang sama bisa menjalankan banyak program jaringan sekaligus — browser, server database, dan game dapat aktif bersamaan. Di sinilah port berperan: port adalah bilangan 16-bit (0-65535) yang menunjuk program atau layanan tertentu pada perangkat tersebut. Jadi alamat IP menjawab pertanyaan “ke perangkat mana”, sedangkan port menjawab “ke program mana pada perangkat itu”. Pasangan IP:port mengidentifikasi satu ujung percakapan (endpoint), dan dua socket yang saling terhubung masing-masing dibaca dari sudut pandangnya sendiri: 203.0.113.10:443 di sisi server berhadapan dengan 192.0.2.55:51820 di sisi client.

Rentang port dibagi tiga menurut konvensi IANA. Port 0-1023 disebut well-known ports dan dipakai layanan standar; mengikat rentang ini biasanya memerlukan hak istimewa administrator. Port 1024-49151 adalah registered ports untuk aplikasi tertentu. Port sisanya (49151-65535) adalah rentang dynamic atau ephemeral — di Linux, rentang bawaannya biasanya 32768-60999 dan bisa dilihat pada berkas /proc/sys/net/ipv4/ip_local_port_range. Server mendengarkan pada port tetap yang dikenal client, sementara sistem operasi memberi client port ephemeral sementara untuk sisi kirinya.

TCP vs UDP: Keandalan versus Kecepatan #

Lapisan transport menyediakan dua pilihan utama dengan janji yang berbeda. TCP (Transmission Control Protocol) adalah transport berorientasi koneksi: sebelum satu byte data bertukar, kedua sisi melakukan three-way handshake (paket SYN, SYN-ACK, lalu ACK) untuk membuka koneksi. Setelah koneksi berdiri, TCP menjamin data tiba utuh dan berurutan — pengirim dan penerima memakai nomor urut, penerima mengirim acknowledgment, dan bagian yang tidak dikonfirmasi dikirim ulang otomatis. Konsekuensinya ada dua: overhead lebih besar (header minimal 20 byte plus mekanisme pengiriman ulang) dan data terlihat sebagai aliran byte tanpa batas pesan — dua pengiriman send() bisa tiba digabung, atau satu pengiriman tiba terpecah.

UDP (User Datagram Protocol) adalah kebalikannya: tanpa koneksi dan tanpa janji. Setiap pesan — disebut datagram — dikirim langsung ke alamat tujuan tanpa handshake, dan setiap datagram berdiri sendiri dengan batas pesan yang terjaga. UDP tidak menjamin datagram tiba, tidak menjamin urutan, dan bisa menduplikasi; sebagai gantinya, header-nya hanya 8 byte dan latensinya lebih kecil karena tidak ada proses pembukaan koneksi maupun pengiriman ulang.

Aturan memilihnya sederhana: pakai TCP bila data harus utuh dan berurutan (dokumen, berkas, transaksi), dan pakai UDP bila kesegaran data lebih penting daripada kelengkapannya atau bila overhead harus serendah mungkin.

Socket sebagai API Sistem Operasi #

Program aplikasi tidak pernah menyentuh kartu jaringan atau driver secara langsung; semua lalu lintas dikelola kernel melalui network stack. Antarmuka yang kita pakai dari C++ adalah socket API — warisan BSD sockets (4.2BSD, 1983) yang dibakukan POSIX dan hingga hari ini menjadi lapisan paling bawah yang dipakai hampir semua library jaringan, termasuk asio. API ini berupa keluarga fungsi C: socket(), bind(), listen(), accept(), connect(), send(), recv(), dan close(), yang kita bahas satu per satu pada dua chapter berikutnya.

Dari sudut pandang program, sebuah socket hanyalah file descriptor — bilangan kecil yang menunjuk sumber daya kernel, satu keluarga dengan descriptor berkas dan pipa. Kita membuatnya, memakainya untuk bertukar data, lalu melepasnya dengan close(). Karena tiap koneksi memakai satu descriptor, server yang melayani ribuan koneksi pada dasarnya mengelola ribuan descriptor — dan melupakan close() berarti membocorkan sumber daya kernel, sejajar dengan lupa menutup berkas.

Kernel juga mengelola buffer untuk setiap socket. Ketika program memanggil send(), data disalin dari memori program ke buffer kirim milik kernel, lalu panggilan segera kembali; pengiriman aktual ke jaringan adalah urusan kernel. Sebaliknya, recv() mengambil data dari buffer terima; bila buffer kosong pada socket TCP, program menunggu (blocking) sampai data datang. Untuk TCP, kernel pula yang menyusun ulang byte agar berurutan dan meminta pengiriman ulang bagian yang hilang — semua mekanisme keandalan Chapter sebelumnya terjadi di dalam kernel, tidak di kode kita.

Model Client-Server #

Peran program jaringan hampir selalu asimetris. Server bersifat pasif: ia mengikat (bind) sebuah alamat dan port tetap, lalu menunggu koneksi datang. Client bersifat aktif: ia mengambil inisiatif, memanggil connect() menuju alamat server yang sudah diketahui. Ketidaksetaraan ini menjelaskan pembagian port pada bagian awal chapter: server memakai port tetap yang mudah diingat (misalnya 443), sedangkan client cukup diberi port ephemeral sementara karena tidak ada seorang pun yang perlu menghubunginya lebih dulu. Satu server biasanya melayani banyak client sekaligus; cara menangani banyak koneksi itu kita singgung di akhir section ini.

Diagram di atas membaca alur satu sesi client-server. Client mengambil inisiatif lewat connect() menuju alamat dan port server; di sisi server, accept() menerima koneksi tersebut dan — ini detail penting — mengembalikan socket baru yang mewakili koneksi itu, sementara socket asli tetap bertugas mendengarkan client berikutnya. Kedua sisi kemudian bertukar data secara dua arah sampai salah satu memutus untuk menutup koneksi dengan close().

Peta Protokol Umum #

Protokol aplikasi bertumpu di atas salah satu transport. Mengetahui pasangan protokol-transport-port standar membantu kita membaca pesan kesalahan jaringan dan merancang protokol sendiri:

Pembagian transport pada tabel di atas konsisten dengan analisis kita sejauh ini. HTTP dan SSH berjalan di TCP karena halaman dan sesi terminal harus tiba utuh serta berurutan. DNS justru memilih UDP untuk kueri biasa: pertanyaannya kecil, polanya satu permintaan-satu balasan, dan tanpa handshake respons terasa seketika; bila respons lebih besar dari satu datagram, server menandainya terpotong dan klien mengulang kueri yang sama lewat TCP.

Dengan peta ini kita siap turun ke level API. Chapter berikutnya memakai POSIX Socket API untuk membangun server dan client TCP sungguhan — mulai dari socket(), bind(), listen(), sampai accept() dan connect() — lalu Chapter ketiga menutup dasar-dasar dengan UDP dan datagram.

Rujukan resmi: ip(7) — Linux man-pages , tcp(7) — Linux man-pages , udp(7) — Linux man-pages .