Sebagian besar web bekerja seperti memesan di kasir: Anda bertanya, Anda menunggu, Anda mendapat jawaban, dan percakapan selesai. Model itu cukup untuk memuat halaman, tetapi gagal untuk aplikasi chat, ticker saham live, atau game multiplayer, di mana informasi baru bisa datang kapan saja. WebSockets menyelesaikan masalah itu dengan menjaga satu koneksi tetap terbuka sehingga kedua sisi bisa mengirim pesan begitu mereka memilikinya.
Sebuah WebSocket memulai hidupnya sebagai request HTTP biasa, lalu naik tingkat menjadi channel persisten dan full-duplex melalui satu koneksi TCP (IETF). Begitu upgrade itu berhasil, client dan server bisa bertukar pesan ke dua arah tanpa mengulang tarian request dan response. Itulah ide utamanya, dan semua hal lain dalam artikel ini adalah konsekuensinya.
Key Takeaways
WebSocket adalah koneksi persisten dan full-duplex: kedua sisi bisa mengirim kapan saja, melalui satu koneksi TCP.
Koneksi dimulai dengan handshake upgrade HTTP dan beralih ke framing pesan yang ringan begitu server menjawab 101 Switching Protocols.
Dibanding polling, WebSockets menghilangkan sebagian besar overhead request berulang, dengan frame sekecil 2 sampai 14 byte.
Server-Sent Events lebih cocok saat data hanya mengalir dari server ke client; WebSockets unggul saat kedua sisi harus berbicara.
WebSockets bersifat stateful, jadi menskalakannya butuh perencanaan lebih dibanding request HTTP yang stateless.
Apa Itu WebSocket?
Protokol WebSocket, yang distandarisasi sebagai RFC 6455 pada Desember 2011, mendefinisikan handshake pembuka yang diikuti framing pesan dasar, berlapis di atas TCP (IETF). API WebSocket di browser menjelaskannya dengan bahasa sederhana: API ini memungkinkan dibukanya sesi komunikasi interaktif dua arah antara browser dan server, dan pengiriman pesan serta penerimaan respons tanpa harus melakukan polling ke server (MDN Web Docs).
Tiga kata membawa sebagian besar maknanya:
Persisten. Koneksi tetap terbuka setelah handshake, bukan menutup setelah setiap pertukaran.
Full-duplex. Pesan bisa berjalan ke dua arah pada saat yang sama, secara independen. Client tidak harus menunggu balasan sebelum mengirim lagi, dan server tidak harus menunggu ditanya.
Ringan. Begitu koneksi terbuka, setiap pesan dibungkus frame kecil, bukan request HTTP lengkap dengan header. Framing itu sekitar 2 sampai 14 byte per pesan, dibanding overhead header HTTP yang biasanya 200 sampai 2000 byte per pertukaran (Render).
WebSockets berjalan di atas TCP pada port 80 atau 443, port yang sama dengan traffic web biasa, yang membantu koneksi ini lolos melewati jaringan yang akan memblokir port yang tidak dikenal (Ably). Varian amannya memakai skema `wss://`, sama seperti HTTPS memakai `https://`.
Jika Anda sudah membaca panduan kami tentang REST API, kontrasnya adalah intinya: REST adalah model request dan response yang rapi untuk mengambil dan mengubah resource, sementara WebSockets adalah model percakapan untuk data yang terus berubah.
Cara Kerja Handshake
Koneksi WebSocket tidak dimulai dari nol. Ia meminjam HTTP untuk perkenalan, lalu beralih protokol. Siklus hidupnya punya empat fase: handshake, open, pertukaran pesan, dan terminasi (Render).
Client meminta upgrade. Browser mengirim request HTTP dengan `Upgrade: websocket`, nonce `Sec-WebSocket-Key`, dan `Sec-WebSocket-Version: 13` (IETF). Di browser, key itu ditambahkan otomatis, sehingga kode aplikasi tidak perlu membuatnya (MDN Web Docs).
Server menerima. Server yang mendukung WebSockets menjawab `HTTP/1.1 101 Switching Protocols` dengan nilai `Sec-WebSocket-Accept` yang dihitung dari key client (IETF). Perhitungan itu membuktikan server memahami handshake, bukan menjawab sembarangan.
Koneksi terbuka. Mulai dari sini, semantik HTTP hilang. Kedua sisi bertukar frame WebSocket: frame teks, frame biner, dan frame kontrol kecil seperti ping, pong, dan close.
Kedua sisi bisa menutup. Frame close mengakhiri pertukaran dengan rapi, dan koneksi TCP di bawahnya dilepas.
Karena handshake itu HTTP, URL WebSocket dimulai dengan `ws://` atau `wss://`, dan request pertamanya tampak familier bagi proxy dan load balancer. Keakraban itu disengaja: protokol ini dirancang untuk bekerja di atas infrastruktur web yang sudah ada, bukan menuntut infrastruktur baru.
WebSockets vs Polling vs Server-Sent Events
Sebelum WebSockets, developer memalsukan perilaku realtime dengan polling. Memahami trik lama itu membuat keunggulan WebSocket menjadi konkret.
Aspek | Short polling | Long polling | Server-Sent Events (SSE) | WebSockets |
|---|---|---|---|---|
Arah | Client bertanya, server menjawab | Client bertanya, server menjawab | Hanya server ke client | Dua arah |
Cara kerja | Client bertanya dengan timer | Server menahan request sampai data tiba atau timeout tercapai | Satu stream HTTP berisi event teks | Satu socket full-duplex yang persisten |
Overhead per update | Satu request HTTP penuh setiap kali | Satu request HTTP penuh per update | Rendah, satu stream | Sangat rendah, frame sekitar 2 sampai 14 byte |
Reconnect | Manual, polling berikutnya | Manual, request berikutnya | Bawaan, dengan replay Last-Event-ID | Manual, Anda yang mengimplementasikannya |
Paling cocok untuk | Data yang jarang berubah | Update sesekali di infrastruktur lama | Feed live, notifikasi, progres | Chat, game, kolaborasi |
Short polling bertanya dengan timer, long polling menahan request sampai data tiba, SSE adalah satu stream HTTP untuk event teks dari server ke client dengan auto-reconnect bawaan, dan WebSockets adalah satu socket full-duplex yang mampu membawa data biner (Back4app). Biaya polling memburuk seiring skala: 1.000 client yang melakukan polling setiap 2 detik berarti 500 request per detik bahkan saat tidak ada yang berubah, sementara koneksi push yang sedang diam menghasilkan nol request (Back4app).
SSE layak dilihat lebih dekat karena sering kali itulah jawaban yang tepat. Dibanding WebSocket, `EventSource` bersifat satu arah, hanya server yang mengirim data, dan hanya membawa teks melalui HTTP biasa, sementara WebSocket bersifat dua arah dan membawa data biner dan teks (javascript.info). SSE juga melakukan reconnect otomatis dan mengirim `Last-Event-ID` sehingga server bisa mengirim ulang pesan yang terlewat, sesuatu yang harus diimplementasikan sendiri pada WebSocket (javascript.info).
Aturan praktisnya sederhana. Jika hanya server yang punya kabar, SSE lebih sederhana dan itu HTTP biasa, sehingga lebih cocok dengan CDN, proxy, dan server stateless. Jika client juga sering mengirim update, seperti ketikan, posisi kursor, atau gerakan game, WebSockets adalah pilihan natural. Jika update jarang dan latensi tidak penting, polling biasa atau panggilan API normal sudah cukup, dan menambah koneksi persisten adalah overengineering.
Long polling layak dikenal karena Anda masih akan menemuinya di sistem lama. Long polling menahan koneksi client tetap terbuka selama mungkin, memberikan respons hanya setelah data tersedia atau timeout tercapai, lalu client biasanya langsung mengeluarkan request lagi (WebSocket.org). Cara ini mengurangi balasan kosong dibanding short polling, tetapi setiap update tetap menghabiskan satu request HTTP baru.
Di Mana WebSockets Digunakan
Penggunaan WebSocket berkumpul di tempat latensi penting dan kedua sisi berbicara. Penggunaan realtime yang tercantum meliputi live chat, multiplayer gaming, collaborative document editing, update perangkat IoT, dan dashboard finansial (Ably). Chat, collaborative editing, live dashboard, dan multiplayer game adalah kasus yang membutuhkan pengiriman pesan di bawah 100ms (Render).
Beberapa contoh konkret memperjelas polanya:
Chat dan dukungan pelanggan. Pesan yang dikirim satu pengguna langsung muncul untuk pengguna lain tanpa ada yang me-refresh. Indikator mengetik dan tanda dibaca hanyalah pesan tambahan pada koneksi yang sama.
Editing kolaboratif. Saat beberapa orang mengedit satu dokumen, setiap ketikan atau gerakan kursor adalah pesan kecil. WebSocket.org mencantumkan beberapa orang yang mengedit dokumen yang sama secara bersamaan di antara kasus penggunaan klasik (WebSocket.org).
Dashboard live dan trading. Harga, skor, dan pembacaan sensor mengalir masuk begitu berubah. Update olahraga live dan dashboard realtime ada di daftar yang sama (WebSocket.org).
Game multiplayer. Posisi dan aksi pemain harus berpindah ke dua arah dengan delay minimal, persis seperti yang disediakan socket full-duplex.
IoT dan kontrol perangkat. Sebuah dashboard bisa menerima data sensor sekaligus mengirim perintah kembali melalui satu koneksi.
Benang merahnya bukan industrinya, melainkan bentuk datanya: sering, kecil, dua arah, dan sensitif terhadap waktu.
Trade-Off yang Jarang Disebut
WebSockets tidak gratis, dan biayanya muncul di production, bukan di demo.
Statefulness mengubah scaling. Request HTTP bisa ditangani server mana pun di balik load balancer. Koneksi WebSocket hidup di satu server spesifik selama masa hidupnya, sehingga scaling out berarti melacak server mana yang memegang koneksi mana, dan restart server memutus koneksinya. Client harus reconnect, dan kode Anda harus menanganinya.
Reconnect dan pemulihan state adalah tugas Anda. Berbeda dengan SSE, WebSockets tidak punya replay bawaan untuk pesan yang terlewat. Jika koneksi putus, client reconnect dan harus menanyakan apa yang terlewat, atau server harus mengirimnya ulang. Rancang jalur pemulihan itu sejak awal, bukan setelah pengguna melaporkan pesan yang hilang.
Proxy dan firewall bisa mengganggu. Karena handshake meng-upgrade koneksi HTTP, sebagian besar proxy modern menanganinya, tetapi proxy lama atau yang dikonfigurasi ketat bisa menutup koneksi idle atau menolak upgrade. Frame heartbeat ping dan pong menjaga koneksi idle tetap hidup dan mendeteksi koneksi yang mati.
Keamanan bekerja seperti bagian web lainnya, dengan satu langkah ekstra. Gunakan `wss://` di production agar frame terenkripsi seperti traffic HTTPS. Autentikasi tetap penting: handshake adalah request HTTP, sehingga cookie dan token bisa diperiksa di sana, tetapi server harus memverifikasinya sebelum menjawab 101, bukan setelah socket terbuka. Dan seperti channel input lainnya, isi pesan harus divalidasi, karena socket yang persisten adalah permukaan serangan yang persisten.
Tidak semua masalah bersifat realtime. Blog, halaman produk, atau form pengaturan tidak mendapat apa-apa dari socket. Pertanyaan keputusannya selalu sama: apakah data baru datang tanpa bisa diprediksi, dan apakah pengguna membutuhkannya dalam satu atau dua detik? Jika jawabannya tidak, request biasa lebih sederhana, lebih murah, dan lebih mudah di-cache.
Kapan Memilih Apa
Gunakan panduan keputusan singkat ini saat memilih transport:
Butuh update instan ke dua arah? Pilih WebSockets. Chat, game, dan alat kolaborasi ada di sini.
Hanya server yang mengirim update? Pilih Server-Sent Events. Feed live, notifikasi, dan progres build lebih sederhana lewat SSE.
Update jarang atau toleran terhadap latensi? Pilih request HTTP biasa, atau polling dengan interval longgar. Jangan membayar biaya scaling stateful untuk data yang berubah sekali dalam satu jam.
Membangun di atas infrastruktur yang tidak bisa menahan koneksi panjang? Tetaplah dengan HTTP dan polling, atau letakkan layanan realtime terkelola di depan aplikasi Anda.
WebSockets mendapat tempatnya karena cocok dengan cara aplikasi interaktif benar-benar berperilaku: orang mengetik, bergerak, bereaksi, dan berharap sisi lain langsung melihatnya. Protokol ini cukup tua untuk disebut membosankan, distandarisasi pada 2011 lewat RFC 6455 (WebSocket.org), dan didukung di semua tempat browser modern berjalan. Kebosanan yang bisa diandalkan itulah intinya. Anda tidak mengadopsi eksperimen, Anda memakai jawaban standar web untuk pertanyaan tentang bagaimana dua sisi terus berbicara.
Baca juga versi Bahasa Inggris dari artikel ini: WebSockets Explained: How Real-Time Apps Actually Work.
Frequently Asked Questions
Apakah WebSockets lebih cepat daripada HTTP?
Untuk update berulang, ya, secara dramatis. Frame WebSocket yang sudah terbentuk biayanya sekitar 2 sampai 14 byte, sementara setiap pertukaran HTTP membawa header biasanya 200 sampai 2000 byte (Render). Untuk satu request saja, HTTP sama cepatnya, dan lebih sederhana.
Apakah WebSockets menggantikan REST API?
Tidak. Keduanya saling melengkapi. Gunakan REST, yang dijelaskan dalam panduan REST API kami, untuk mengambil dan mengubah resource, dan WebSockets untuk aliran update live. Sebagian besar aplikasi nyata memakai keduanya.
Apa yang terjadi saat koneksi WebSocket putus?
Socket menutup dan client harus reconnect, biasanya dengan jeda backoff. Karena WebSockets tidak memutar ulang pesan yang terlewat secara otomatis, aplikasi Anda harus menyinkronkan ulang state setelah reconnect, misalnya dengan mengambil data terbaru lewat HTTP.
Apakah WebSockets aman?
Bisa. Gunakan `wss://` untuk enkripsi, lakukan autentikasi selama handshake HTTP sebelum menerima upgrade, dan validasi setiap pesan yang masuk. Koneksi `ws://` yang tidak terenkripsi mengekspos isi pesan seperti HTTP biasa.
Kapan sebaiknya saya memilih SSE daripada WebSockets?
Saat data mengalir satu arah, dari server ke client, dan Anda menginginkan reconnect otomatis dengan replay pesan. SSE adalah teks HTTP biasa, sehingga lebih mudah dioperasikan, dan mencakup feed live dan notifikasi dengan baik.