Belajar WebSocket - WebSocket Protocol: Konsep & Standar

#Pendahuluan

Setelah melihat sejarah evolusi real-time web di episode 1, sekarang waktunya membedah protokol WebSocket itu sendiri. Di episode ini kalian akan memahami standar yang menjadi dasar segala implementasi: RFC 6455.

WebSocket adalah protokol komunikasi yang menyediakan full-duplex — kedua sisi bisa mengirim data secara bersamaan melalui satu koneksi TCP yang persisten. Tidak seperti HTTP yang tiap pesan membawa header lengkap, WebSocket setelah handshake mengirim data langsung dengan overhead yang sangat kecil.

#Standar RFC 6455 dan Konsep Dasar

#Satu Protokol, Banyak Implementasi

RFC 6455 diratifikasi pada tahun 2011 dan mendefinisikan protokol WebSocket secara lengkap: handshake, framing, masking, control frame, dan prosedur penutupan. Karena standar, semua implementasi — ws di Node.js, gorilla/websocket di Go, websockets di Python — bisa saling berkomunikasi.

Ciri paling menonjol dari protokol ini:

• Full-duplex: server dan klien mengirim kapan saja, tidak bergantian.
• Satu koneksi TCP: tidak perlu koneksi baru per pesan.
• Overhead kecil: setelah handshake, setiap frame hanya punya header beberapa byte.
• Dua tipe data: text dan binary, dikontrol lewat opcode di dalam frame.

npx wscat -c ws://echo.websocket.events

Perintah npx wscat -c ws://echo.websocket.events menghubungkan kalian ke server echo publik. Ketik apa saja dan server akan memantulkan pesan yang sama — cara tercepat merasakan full-duplex tanpa menulis kode.

#Skema ws:// dan wss://

Sama seperti HTTP yang punya http:// dan https://, WebSocket punya dua skema:

• ws:// — tidak terenkripsi, dipakai di development atau jaringan tepercaya.
• wss:// — WebSocket di atas TLS, wajib di production.

ws://host:port/path
wss://host:port/path

Format ws://host:port/path di atas menunjukkan bahwa port dan path bersifat opsional — mirip URL HTTP, termasuk query string untuk membawa parameter.

#WebSocket vs Alternatif Lain

#WebSocket vs HTTP Polling

Polling (episode 1) tetap melakukan request-response berulang dengan header lengkap setiap kali. WebSocket mengirim sekali handshake lalu bercakap langsung dengan frame ringan. Untuk update yang sering, WebSocket menang telak; untuk request yang jarang dan sekali jalan, HTTP polling malah lebih simpel.

#WebSocket vs Server-Sent Events

SSE adalah koneksi HTTP panjang satu arah dengan reconnection otomatis. WebSocket dua arah dan mendukung binary. Pilihannya sederhana:

• SSE untuk notifikasi dan live feed yang hanya butuh arah server ke klien.
• WebSocket untuk chat, game, dan kolaborasi yang butuh dua arah.

#WebSocket vs HTTP/2 Server Push

HTTP/2 Server Push memungkinkan server mengirim resource sebelum diminta, tetapi dirancang untuk caching asset, bukan untuk komunikasi dua arah berkelanjutan. WebSocket tetap menjadi pilihan utama untuk pesan interaktif real-time.

#WebSocket vs HTTP/3 (QUIC)

HTTP/3 dibangun di atas QUIC yang lebih cepat dari TCP untuk multiplexing. Namun HTTP/3 tetap request-response; untuk stream bidirectional murni, teknologi masa depan bernama WebTransport lebih relevan — akan kita bahas di episode 32.

#Kapan Menggunakan WebSocket

#Use Case yang Cocok

WebSocket unggul di skenario yang menuntut pertukaran data berkelanjutan:

• Chat dan pesan instan.
• Notifikasi real-time dan live dashboard.
• Kolaborasi dokumen seperti Google Docs.
• Game multiplayer dan trading platform.
• Komunikasi perangkat IoT dan pelacakan lokasi.
• Signaling video conference.

#Kapan Jangan Menggunakan WebSocket

WebSocket bukan jawaban untuk segalanya. Hindari ketika:

• Update jarang terjadi — polling atau SSE lebih hemat.
• Kebutuhan hanya satu arah — SSE lebih sederhana.
• Ada kebutuhan state pada tiap request — REST stateless lebih cocok.
• Membutuhkan kompatibilitas proxy lama yang tidak mendukung upgrade.

#Arsitektur Koneksi WebSocket

#Dua Fase Utama

Semua koneksi WebSocket melewati dua fase besar:

1. Handshake: request HTTP yang meminta upgrade, dijawab dengan status 101.
2. Data transfer: pertukaran frame text atau binary sampai salah satu sisi menutup.

Fase handshake akan kita bedah detail di episode 3. Untuk sekarang, yang penting dipahami: fase ini hanya terjadi sekali, dan setelahnya koneksi "berubah" dari HTTP menjadi WebSocket.

#Tiga Skenario Komunikasi

Koneksi yang sudah terbentuk bisa dipakai dalam beberapa pola:

• Unicast: pesan dari server ke satu klien tertentu.
• Broadcast: server mengirim ke semua klien.
• Relay: klien A mengirim pesan yang diteruskan server ke klien B.

Pola-pola ini adalah fondasi aplikasi seperti chat. Implementasinya akan kita praktikkan mulai episode 5 dan mendalam di episode 9.

#Penutup

Episode 2 memberi kalian peta konseptual protokol WebSocket: standar RFC 6455, skema ws dan wss, serta perbandingan dengan polling, SSE, dan HTTP/2 Server Push. Kalian juga sudah tahu kapan memakai WebSocket dan kapan tidak.

Inti yang harus dibawa pulang:

• WebSocket adalah full-duplex di atas satu koneksi TCP persisten.
• Standarnya RFC 6455, jadi semua implementasi bisa saling bicara.
• wss:// adalah wajib untuk production karena memakai TLS.
• WebSocket unggul untuk update sering dan dua arah; SSE untuk satu arah.
• Gunakan WebSocket dengan alasan, bukan karena "keren".
• Arsitektur unicast, broadcast, dan relay menjadi dasar semua aplikasi.

Di episode 3 selanjutnya kita akan membedah handshake dan connection lifecycle — header Upgrade dan Sec-WebSocket-Key, kalkulasi Sec-WebSocket-Accept, empat state koneksi, struktur frame, dan mekanisme heartbeat ping dan pong. Ini adalah inti teknis yang membuat protokol ini bekerja.