WebSocket adalah protokol komunikasi full-duplex yang memungkinkan komunikasi dua arah antara client (misalnya browser) dan server melalui satu koneksi TCP. Berbeda dengan HTTP, yang bersifat request-response, WebSocket memungkinkan data dikirim dan diterima secara real-time tanpa harus membuat koneksi baru untuk setiap pesan.
Tahapan Pengiriman dan Penerimaan Data
a. Handshake
Sebelum komunikasi data berlangsung, WebSocket melakukan handshake menggunakan HTTP/HTTPS:
- Client mengirim HTTP
GETrequest dengan headerUpgrade: websocket. - Server merespons dengan status 101 Switching Protocols jika menerima upgrade.
- Setelah handshake berhasil, koneksi TCP tetap terbuka dan siap untuk pertukaran data real-time.
Contoh header handshake:
Client → Server:
GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Server → Client:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
b. Pengiriman Data
Setelah handshake:
- Data dikirim dalam bentuk frame, bukan request HTTP biasa.
Frame memiliki opcode untuk menandai tipe pesan:
0x1→ Text0x2→ Binary0x8→ Close0x9→ Ping0xA→ Pong
- Frame juga bisa di-fragment, sehingga pesan panjang bisa dibagi menjadi beberapa frame.
Proses pengiriman data (client → server):
- Client mengemas data menjadi frame (misal, text frame).
- Frame tersebut bisa di-mask (selalu di-mask dari client ke server, agar aman dari proxy).
- Server menerima frame, membuka mask, dan membaca isi data.
c. Penerimaan Data
- Server membaca frame yang diterima dari TCP stream.
- Menginterpretasikan frame berdasarkan opcode.
- Jika frame merupakan fragmented message, server akan menggabungkan beberapa frame hingga menjadi pesan lengkap.
- Setelah itu, server dapat memproses data (misal: menyimpan, membroadcast ke client lain, dll).
d. Keep-Alive dan Ping-Pong
- Untuk memastikan koneksi tetap hidup, server atau client bisa mengirim
pingframe. - Penerima wajib membalas dengan
pong. - Jika tidak ada respons dalam waktu tertentu, koneksi bisa dianggap mati.
e. Menutup Koneksi
- Close frame (
0x8) digunakan untuk menutup koneksi dengan elegan. - Frame ini bisa membawa kode status (misal 1000 = normal closure).
- Setelah frame close diterima dan dibalas, koneksi TCP ditutup.
Kelebihan WebSocket dalam Pengiriman/Penerimaan Data
- Real-time: tidak perlu request HTTP berulang.
- Full-duplex: data bisa mengalir dua arah secara bersamaan.
- Efisien: hanya ada overhead kecil setelah handshake.
Diagram Alur WebSocket: Handshake → Data → Close
Client Server
| |
| 1. HTTP Handshake Request |
|------------------------------------------------->|
| GET /chat HTTP/1.1 |
| Upgrade: websocket |
| Connection: Upgrade |
| Sec-WebSocket-Key: ... |
| |
| |
| 2. HTTP Handshake Response |
|<-------------------------------------------------|
| HTTP/1.1 101 Switching Protocols |
| Upgrade: websocket |
| Connection: Upgrade |
| Sec-WebSocket-Accept: ... |
| |
|*** WebSocket connection established *** |
| |
| 3. Data Transmission (Full-duplex) |
| Text/Binary Frame 1 |
|------------------------------------------------->|
| |
| Text/Binary Frame 2 (server can send anytime) |
|<-------------------------------------------------|
| Text/Binary Frame 3 |
|------------------------------------------------->|
| ... |
| |
| 4. Ping / Pong (keep-alive) |
| Ping |
|------------------------------------------------->|
| Pong |
|<-------------------------------------------------|
| |
| 5. Close Connection (graceful termination) |
| Close Frame (1000 - Normal Closure) |
|------------------------------------------------->|
| Close Frame (acknowledge) |
|<-------------------------------------------------|
| TCP Connection Closed |
Penjelasan Visual
- Handshake: Mengubah protokol HTTP biasa menjadi WebSocket (Upgrade header).
Data Transmission: Setelah koneksi terbuka, data bisa mengalir dua arah.
- Client dan server mengirim frames yang dapat berupa teks, binary, ping/pong, atau close.
- Client selalu masking frame, server tidak.
- Ping/Pong: Memastikan koneksi masih hidup.
- Close Frame: Mengakhiri koneksi dengan kode status yang jelas.
Struktur Frame WebSocket (versi dasar)
Setiap frame WebSocket memiliki header dan payload. Header terdiri dari beberapa field penting:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len | Extended payload length |
|I|S|S|S| (4) |A| (7) | (16/64) |
|N|V|V|V| |S| | |
| |1|2|3| |K| | |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
| Masking-key (32-bit) if MASK set |
+---------------------------------------------------------------+
| Payload Data |
+---------------------------------------------------------------+
Keterangan field:
| Field | Panjang | Fungsi |
|---|---|---|
| FIN | 1 bit | 1 = frame terakhir dari pesan, 0 = masih ada fragment |
| RSV1-3 | 1 bit tiap bit | Biasanya 0, digunakan untuk ekstensi (compression dll) |
| Opcode | 4 bit | Tipe frame: 0=continuation, 1=text, 2=binary, 8=close, 9=ping, A=pong |
| MASK | 1 bit | 1=payload di-mask (client → server), 0=tidak di-mask (server → client) |
| Payload length | 7 bit | Jika ≤125, panjang payload; 126=pakai 16-bit extended length; 127=pakai 64-bit extended length |
| Masking key | 32 bit | Hanya jika MASK=1, digunakan untuk men-decode payload |
| Payload data | variable | Data sebenarnya (di-decode dengan masking key jika MASK=1) |
Contoh Frame WebSocket (Text “Hi”)
Misal client mengirim teks “Hi” ke server:
Teks “Hi” dalam ASCII →
H=0x48, i=0x69Client harus masking payload dengan random 32-bit key, misal
0x37FA213DPayload di-mask byte per byte:
Masked byte[i] = Original byte[i] XOR Masking key[i % 4]- H (0x48) XOR 0x37 = 0x7F
- i (0x69) XOR 0xFA = 0x93
- → payload yang dikirim: 0x7F 0x93
Frame header (FIN=1, Opcode=1, MASK=1, Payload len=2):
1000 0001 = 0x81 (FIN=1, Opcode=text)
1000 0010 = 0x82 (MASK=1, Payload len=2)
- Frame lengkap (hex):
0x81 0x82 0x37 0xFA 0x21 0x3D 0x7F 0x93
Server menerima, membaca header, tahu MASK=1 → de-mask dengan key 0x37FA213D → dapat payload asli Hi.
Alur Pengiriman & Penerimaan “Bit-Level”
Client TCP Stream -> Header (FIN, Opcode, MASK, len) -> Masking Key -> Payload (masked)
Server TCP Stream -> Baca Header -> Check MASK -> Unmask Payload -> Proses data
- Untuk frame panjang, server bisa menerima beberapa frame fragmented, kemudian menggabungkan sampai FIN=1.
- Ping/pong dan close frame juga dikodekan sama, cuma opcode berbeda.
Kalau mau, saya bisa buatkan diagram visual lengkap “TCP → Frame → Payload → Server” dengan contoh byte nyata untuk beberapa frame berurutan, termasuk text dan binary, supaya alurnya benar-benar jelas dari sisi client ke server dan sebaliknya.
Apakah mau saya buatkan diagram byte-level itu juga?
Posting Komentar
0Komentar