websocketrealtimechatMahir4 mnt baca

WebSocket: Telepon Dua Arah untuk Web

Memahami cara kerja WebSocket: handshake upgrade, komunikasi dua arah, dan contoh chat real-time.

Telepon vs SMS

HTTP biasa seperti SMS: kirim pesan, tunggu balasan, koneksi putus setiap kali. WebSocket seperti telepon: sekali tersambung, kedua pihak bisa bicara kapan pun tanpa menutup dan membuka sambungan baru. Inilah fondasi chat real-time, game multiplayer, dan dashboard live.

Kenapa WebSocket perlu (HTTP tidak cukup)

Dengan HTTP murni, server tidak bisa "menelepon" klien duluan; klien harus bertanya terus (polling) yang boros. WebSocket membuka SATU koneksi TCP yang bertahan lama dan dua arah. Setelah tersambung, overhead per pesan sangat kecil, dan server bisa mendorong data kapan pun (notifikasi, update harga saham).

Contoh 1: handshake upgrade

Koneksi dimulai sebagai HTTP biasa, lalu "di-upgrade":

http
GET /chat HTTP/1.1
Host: toko.contoh.id
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
http
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade

Status 101 berarti "oke, mulai sekarang kita bicara protokol WebSocket." Setelah ini, HTTP selesai bertugas; pesan berikutnya memakai frame WebSocket yang ringan.

Contoh 2: chat sederhana di browser

javascript
const ws = new WebSocket("wss://toko.contoh.id/chat");

ws.onopen = function() {
  ws.send(JSON.stringify({ user: "Omni", pesan: "Halo!" }));
};

ws.onmessage = function(event) {
  const data = JSON.parse(event.data);
  tampilkanPesan(data.user, data.pesan);
};

ws.onclose = function() {
  console.log("Koneksi putus, coba sambung ulang...");
};

Perhatikan wss:// (versi aman, seperti https). Event onmessage dipicu kapan pun server mengirim data, tanpa polling.

Kesalahan umum

Salah: memakai WebSocket untuk request-response biasa. Overkill: koneksi persisten butuh resource server. Yang benar: WebSocket hanya untuk kebutuhan real-time dua arah.

Salah: tidak menangani putus sambungan. Koneksi bisa putus kapan pun (pindah jaringan). Yang benar: implementasikan reconnect dengan backoff + heartbeat (ping/pong).

Salah: tidak autentikasi koneksi WebSocket. Mengira "tidak terlihat" berarti aman. Yang benar: verifikasi token saat handshake (query param atau header).

Salah: lupa pakai wss di production. ws polos tanpa enkripsi. Yang benar: selalu wss:// di production.

Heartbeat: menjaga koneksi tetap hidup

Proxy dan load balancer suka memutus koneksi yang "diam" terlalu lama. Solusinya adalah heartbeat: pesan ping/pong berkala.

javascript
// Kirim ping tiap 30 detik
setInterval(function() {
  if (ws.readyState === WebSocket.OPEN) {
    ws.send(JSON.stringify({ tipe: "ping" }));
  }
}, 30000);

// Server menjawab pong; kalau 2x tidak ada jawaban, reconnect

Tanpa heartbeat, user yang idle 5 menit tiba-tiba tidak menerima pesan tanpa tahu koneksinya sudah mati. Dengan heartbeat + auto-reconnect, WebSocket terasa selalu tersambung.

Catatan teknis: Untuk banyak kasus, pertimbangkan alternatif managed seperti Socket.IO (fallback otomatis), Pusher, atau Ably sebelum mengelola server WebSocket sendiri. Scaling WebSocket (banyak server) butuh pub/sub seperti Redis.

Tantangan

Putuskan: WebSocket atau polling?

Untuk tiap kasus, pilih WebSocket, SSE, atau polling biasa + alasan:

  1. Aplikasi chat 1-on-1.
  2. Notifikasi harga saham yang update tiap detik (satu arah).
  3. Form pencarian dengan autocomplete.

Tulis: kasus -> pilihan -> alasan satu baris.