Belajar WebSocket - Handshake & Connection Lifecycle

#Pendahuluan

Semua koneksi WebSocket dimulai dari sesuatu yang biasa: sebuah request HTTP. Episode 3 membedah detik-detik awal itu — opening handshake — lalu mengikuti perjalanan koneksi hingga penutupan.

Kalian akan memahami mengapa handshake wajib ada, bagaimana server membuktikan bahwa dia memahami protokol WebSocket, empat state yang dilalui koneksi, anatomi frame yang membawa data, serta mekanisme ping dan pong yang menjaga koneksi tetap hidup. Ini semua adalah detail yang membuat aplikasi WebSocket kalian berperilaku benar di production.

#Opening Handshake

#Request Upgrade dari Klien

Saat browser atau klien membuka koneksi WebSocket, yang terkirim pertama adalah request HTTP dengan header khusus. Perhatikan header berikut:

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

Header Upgrade: websocket memberi tahu server bahwa klien ingin berpindah protokol, dan Sec-WebSocket-Key adalah nonce acak yang akan dipakai server untuk membuktikan pemahamannya terhadap RFC 6455.

#Response 101 Switching Protocols

Jika server menerima, dia mengembalikan:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Status 101 Switching Protocols menandakan koneksi beralih dari HTTP ke WebSocket. Kunci dari proses ini ada di header Sec-WebSocket-Accept: nilainya bukan sembarangan, melainkan hasil perhitungan dari Sec-WebSocket-Key.

#Kalkulasi Sec-WebSocket-Accept

Server menggabungkan key yang diterima dengan GUID standar, lalu meng-hash-nya:

Kalkulasi Sec-WebSocket-Accept

const crypto = require("crypto");
 
function buatAccept(key) {
  const GUID = "258EAFA5-E914-47DA-95CA-C5AB0DC85B11";
  const hash = crypto.createHash("sha1").update(key + GUID).digest("base64");
  return hash;
}
 
const accept = buatAccept("dGhlIHNhbXBsZSBub25jZQ==");
console.log(accept);

Rumus crypto.createHash("sha1") ini membuktikan bahwa server benar-benar memahami protokol. Jika klien tidak menerima Sec-WebSocket-Accept yang sesuai, koneksi dianggap gagal.

#Negosiasi Protokol dan Extension

Dua header opsional juga bisa ikut dalam handshake:

• Sec-WebSocket-Protocol: daftar subprotokol yang diminta klien, server memilih salah satu.
• Sec-WebSocket-Extensions: misalnya permessage-deflate untuk kompresi pesan.

#Connection States

#Empat State Resmi

WebSocket mendefinisikan empat state koneksi. Di browser, kalian membacanya lewat properti readyState:

• CONNECTING (0): handshake sedang berlangsung.
• OPEN (1): koneksi siap dipakai untuk bertukar pesan.
• CLOSING (2): proses penutupan sedang berjalan.
• CLOSED (3): koneksi sudah berakhir dan tidak bisa dipakai lagi.

Membaca state koneksi

const ws = new WebSocket("ws://localhost:8080");
 
console.log(ws.readyState); // 0 = CONNECTING
 
ws.onopen = () => {
  console.log(ws.readyState); // 1 = OPEN
};

new WebSocket("ws://localhost:8080") langsung membuka handshake secara otomatis. Perhatikan transisi state: dari 0 ke 1 setelah onopen, dan menuju 2 lalu 3 saat penutupan dimulai.

#Struktur Frame

#Anatomi Sebuah Frame

Setelah handshake, semua data dikirim dalam frame. Setiap frame dimulai dengan header kecil yang berisi:

• FIN: menandai frame terakhir dari sebuah pesan.
• RSV: bit cadangan, dipakai untuk extension seperti kompresi.
• opcode: tipe frame — text, binary, close, ping, atau pong.
• MASK: penanda bahwa payload di-mask (wajib untuk klien ke server).
• Payload length: panjang data, 7 bit, 16 bit, atau 64 bit.

#Aturan Masking

Aturan penting dalam RFC 6455: semua frame dari klien ke server wajib di-mask, sementara server ke klien tidak. Masking mencegah cache poisoning pada proxy lama yang salah menafsirkan frame.

#Lifecycle Koneksi dan Heartbeat

#Siklus Hidup Koneksi

Satu koneksi WebSocket melalui fase:

1. Establishment: handshake berhasil, state menjadi OPEN.
2. Message exchange: pertukaran frame text atau binary.
3. Heartbeat: ping dan pong menjaga koneksi tetap hidup melewati proxy.
4. Closure: close frame dikirim, state menjadi CLOSED.

#Close Frame

Penutupan tidak asal putus. Salah satu sisi mengirim close frame dengan kode dan alasan:

Menutup koneksi dengan kode

ws.close(1000, "selesai");

Kode 1000 berarti normal closure. Kode lain yang umum: 1001 going away, 1006 koneksi abnormal tanpa close frame, dan 1009 pesan terlalu besar. Memakai ws.close(1000, "selesai") dengan alasan yang jelas membantu debugging di production.

#Heartbeat dengan Ping dan Pong

Karena koneksi bisa diam terlalu lama, server rutin mengirim ping dan klien wajib membalas pong. Ini adalah deteksi dini koneksi mati yang di episode 11 akan kita bangun menjadi sistem heartbeat lengkap dengan timeout.

#Penutup

Episode 3 membedah mekanisme di balik setiap koneksi WebSocket: handshake HTTP yang di-upgrade, kalkulasi Sec-WebSocket-Accept, empat state koneksi, struktur frame dengan aturan masking, close frame, dan heartbeat ping/pong.

Inti yang harus dibawa pulang:

• Koneksi WebSocket lahir dari request HTTP dengan header Upgrade.
• Server membuktikan pemahaman protokol lewat Sec-WebSocket-Accept.
• Koneksi melewati state CONNECTING, OPEN, CLOSING, dan CLOSED.
• Frame membawa opcode, mask, dan panjang payload.
• Klien wajib mem-mask frame; server tidak.
• Ping dan pong menjaga koneksi tetap hidup dan mendeteksi koneksi mati.

Di episode 4 selanjutnya kita akan naik ke permukaan: native WebSocket API di browser — membuat instance WebSocket, empat event handler, method send dan close, serta properti readyState dan bufferedAmount. Kalian akan mulai menulis kode klien yang nyata.