WebSockets melawan SSE melawan Long Polling — Pilih Pola Real-Time yang Tepat Sebelum Aplikasi Chat Anda Meleleh

Anda membuat dashboard. Pengguna membutuhkan pembaruan data secara real-time. Anda memilih WebSockets — karena itu yang dilakukan oleh semua orang. Sekarang Anda sedang memperbaiki sesi yang terjebak pada jam 2 pagi karena load balancer terus mengirimkan klien ke pod yang salah. Data yang Anda kirim? Sebuah angka JSON setiap 10 detik. WebSockets terlalu berlebihan.

Ini terjadi secara terus-menerus. Pengembang memperlakukan WebSockets sebagai solusi real-time default, padahal SSE atau long polling akan lebih cepat, lebih mudah di skalakan, dan lebih murah dalam operasional. Berikut cara memilih yang benar.

Tabel Keputusan

Sebelum penjelasan mendalam, berikut perbandingan lengkapnya. Gunakan ini untuk membuat keputusan, lalu baca bagian-bagian di bawah jika Anda membutuhkan penjelasan.

Fitur	Long Polling	Server-Sent Events	WebSockets
Protokol	HTTP/2	HTTP/1.1+ (chunked)	WS (HTTP upgrade)
Arah	Klien hanya mengambil	Hanya dari server ke klien	Penuh dua arah
Dukungan browser	Semua browser	Semua modern (tidak termasuk IE11)	Semua modern
Reconnect otomatis	Manual — Anda menulis loopnya	Dibangun secara bawaan melalui EventSource	Manual atau melalui library
Tepat untuk CDN/proxy	Ya	Kebanyakan (waktu menunggu pengawasan)	TIDAK
Skalabilitas horizontal	Tidak berpengaruh, sangat sederhana	Tidak berpengaruh, sangat sederhana	Membutuhkan sesi yang tetap atau broker pub/sub
Kompleksitas infrastruktur	Rendah — HTTP biasa	Rendah — HTTP biasa	Tinggi — koneksi berpengaruh, konfigurasi LB, broker
Lag waktu	Interval polling + perjalanan balik	Real-time hampir	Real-time hampir
Cocok untuk	Pembaruan frekuensi rendah, infrastruktur lama	Dashboard, feed, notifikasi	Chat, pengeditan kolaboratif, permainan

Long Polling: Workhorse yang Tidak Menarik

Long polling bukanlah “lama” atau “salah” — itu hanya HTTP. Klien membuat permintaan, server mempertahankan permintaan tersebut sampai ada sesuatu yang perlu dikirim (atau waktu timeout terjadi), klien menerima respons dan segera membuat permintaan berikutnya. Ulangi.

Ini telah ada sebelum WebSockets diperkenalkan dan masih berjalan di jutaan aplikasi produksi. Alasannya: itu hanya HTTP. Reverse proxy, CDN, load balancer, dan pemantauan Anda semua memahaminya tanpa konfigurasi. Tidak perlu sesi tetap, tidak perlu upgrade protokol, tidak perlu infrastruktur yang menyadari WS.

Kekurangan ini memang nyata. Setiap “pembaruan” adalah satu siklus permintaan HTTP — header, beban TCP (kecuali HTTP/2), antrian permintaan di sisi server. Di bawah beban tinggi, ini menjadi mahal di sisi server. Dan batas waktu latensi adalah waktu perjalanan balik setiap polling, bukan latensi dari kejadian itu sendiri. Jika Anda memilih polling setiap 5 detik dan kejadian terjadi pada detik ke-1, pengguna menunggu 4 detik lagi.

Kapan digunakan: Sistem lama di mana menambahkan lapisan koneksi permanen tidak layak dengan perubahan infrastruktur. Pembaruan frekuensi rendah (satu kali per menit atau kurang). Lingkungan di mana SSE dihentikan oleh proxy yang terlalu ekstrem. Polling yang dikontrol secara eksplisit oleh klien — pengecekan status pekerjaan, hasil tugas asinkron.

Server-Sent Events: Yang Diam-diam Dilupakan Orang

SSE adalah standar (HTML Living Standard) yang memungkinkan server mengirimkan aliran peristiwa teks melalui satu koneksi HTTP yang berlangsung lama. Browser secara otomatis menangani reconnection. Anda tidak perlu menulis loop reconnection — EventSource API akan menghubungkan kembali dengan ID peristiwa terakhir yang dilihat, sehingga Anda dapat melanjutkan aliran setelah gangguan jaringan.

Format jaringan sangat sederhana:

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache

id: 1
event: price-update
data: {"symbol":"BTC","price":67420}

id: 2
event: price-update
data: {"symbol":"ETH","price":3521}

Setiap peristiwa adalah teks biasa dengan opsi id, event, datadan retry field, dipisahkan oleh baris kosong. Anda dapat menguji endpoint SSE secara langsung dengan cURL — gunakan Pembuat Perintah cURL untuk membuat permintaan dengan header Accept yang tepat (text/event-stream) dan mengalirkan respons.

Di sisi klien:

const es = new EventSource('/api/events');

es.addEventListener('price-update', (e) => {
  const payload = JSON.parse(e.data);
  updateDashboard(payload);
});

es.onerror = () => {
  // EventSource will auto-reconnect. You don't need to do anything here
  // unless you want to log or update UI state.
};

SSE memiliki satu kekurangan nyata: hanya dari server ke klien. Klien tidak dapat mengirim data kembali melalui koneksi yang sama — tindakan yang diinisiasi oleh klien harus melalui permintaan HTTP biasa. Untuk kebanyakan kasus dashboard, notifikasi, dan feed, itu cukup. Anda tidak pernah menggunakan arah dari klien ke server.

Kesalahan lainnya: beberapa proxy menunda badan respons dan hanya mengalirkan setelah koneksi ditutup, yang menghancurkan aliran secara total. NGINX membutuhkan proxy_buffering off. Tier gratis Cloudflare menunda SSE. Jika infrastruktur Anda memiliki proxy penunda dan Anda tidak dapat mengonfigurasinya, SSE tidak akan bekerja dan Anda perlu menggunakan WebSockets atau long polling.

Kapan digunakan: Dashboard hidup, feed notifikasi, log aktivitas, aliran respons AI (ini tepatnya yang digunakan oleh API streaming ChatGPT), harga saham, menampilkan log deploy/build. Di mana server memiliki data untuk dikirim dan klien tidak perlu mengirim kembali.

WebSockets: Kapan Mereka Layak Digunakan

WebSockets memberikan koneksi berdua arah yang permanen melalui satu socket TCP. Setelah tangan upgrade HTTP, kedua pihak dapat mengirim pesan terstruktur kapan saja. Latensi adalah yang terendah yang bisa Anda dapatkan di jaringan — tidak ada permintaan baru per pesan, tidak ada header pada setiap frame.

Kompromi adalah bahwa mereka bersifat berpengaruh. Server harus melacak setiap koneksi yang terbuka. Ini segera menciptakan masalah pada skala besar: load balancer mengalokasikan berdasarkan koneksi (bukan permintaan), sehingga Anda perlu sesi tetap atau broker pub/sub (Redis, dll.) untuk membagikan pesan ke berbagai instance server. CDN tidak dapat meng-cache trafik WebSocket. Reverse proxy membutuhkan konfigurasi eksplisit untuk upgrade. Pemantauan harus memahami frame WS jika Anda ingin visibilitas pada level payload.

Semuanya tidak tidak bisa diatasi, tetapi memang membutuhkan kerja keras. Saat Anda memulai proyek dan mengevaluasi pilihan, “itu hanya HTTP” versus “koneksi WS berpengaruh dengan lapisan Redis pub/sub” adalah perbedaan yang signifikan dalam kompleksitas.

Payload WebSocket biasanya berupa JSON. Jika Anda sedang memperbaiki integrasi WS dan perlu memeriksa atau mengatur pesan, maka Pemformat JSON membuatnya lebih mudah untuk membaca payload yang dikompresi dari tab jaringan alat pengembangan Anda.

Kapan digunakan: Aplikasi chat (berdua arah benar-benar — setiap pesan diinisiasi oleh klien). Pengeditan kolaboratif (Figma, Google Docs — banyak klien menulis ke state bersama). Permainan multiplayer (sincronisasi state dengan frekuensi tinggi dan latensi rendah). Terminal perdagangan (latensi di bawah 100ms pada order book). Secara umum: apa pun yang membutuhkan klien mengirim data secara sering, bukan hanya menerima.

Kesalahan Skalabilitas yang Tidak Dibahas Hingga Terlambat

Long polling dan SSE bersifat tidak berpengaruh pada lapisan HTTP. Setiap permintaan dapat jatuh ke instance server mana saja. Cerita skalabilitas Anda sangat sederhana dan itu adalah keunggulan: tambahkan lebih banyak instance, selesai. Status koneksi hanya berlangsung selama koneksi HTTP terbuka, dan load balancer mengalokasikan secara bebas.

WebSockets bersifat berpengaruh. Koneksi A dari klien berada di Server 1. Ketika Anda ingin mengirim pesan ke klien A dari Server 2 (karena peristiwa berasal di sana), Server 2 harus tahu tentang koneksi tersebut. Solusi standar adalah broker pub/sub — Redis pub/sub, Kafka, atau layanan terkelola seperti Pusher atau Ably yang mengabstraksi semua ini. Anda harus membangun lapisan ini sendiri atau membayar untuknya.

Pusher mengenakan biaya $49 per bulan untuk 500 koneksi bersamaan. Ably juga memiliki harga serupa. Jika fitur real-time Anda adalah badge notifikasi yang diperbarui saat seseorang menyukai postingan Anda, itu adalah biaya besar untuk SSE yang bisa Anda jalankan secara gratis bersama API Anda.

Perubahan HTTP/2 pada Matematika Long Polling

Long polling klasik HTTP/1.1 adalah satu permintaan per koneksi per penahanan yang berlangsung. Di bawah HTTP/2, multiplexing berarti beberapa aliran di satu koneksi TCP. Beban lebih rendah. Ini bukan alasan untuk memilih long polling atas SSE, tetapi berarti kritik bahwa “biaya overhead HTTP terlalu tinggi” kurang berlaku di tahun 2024 dibandingkan tahun 2012 ketika perbandingan ini pertama kali ditulis.

Jika Anda menggunakan HTTP/2 dari ujung ke ujung (dari klien ke server, tanpa proxy yang menurunkan), long polling lebih baik dalam skalabilitas dibandingkan dengan sebagian besar benchmark yang lebih tua.

Panduan Keputusan Cepat

Berhenti membaca di sini jika kasus pengguna Anda cocok dengan salah satu dari ini secara jelas:

• Frekuensi pembaruan < 1/menit, infrastruktur lama, semantik polling sederhana: Long polling. Jangan komplekskan.
• Server mengirim data, klien sebagian besar hanya membaca, infrastruktur HTTP standar: SSE. Ini mencakup 80% dari fitur “real-time”.
• Klien mengirim data secara sering, latensi < 100ms penting, benar-benar dua arah: WebSockets. Sekarang kompleksitasnya layak.
• Anda menggunakan AI streaming (OpenAI, Anthropic, dll.): SSE — itu tepatnya yang digunakan oleh API streaming mereka.
• Permainan multiplayer atau pengeditan kolaboratif: WebSockets, atau kerangka kerja khusus (Liveblocks, PartyKit, dll.).

Jawaban default bukan WebSockets. Itu adalah SSE — sampai Anda memiliki alasan khusus bahwa itu tidak cukup. Jumlah aplikasi produksi yang benar-benar membutuhkan real-time dua arah secara penuh jauh lebih kecil daripada jumlah yang gunakan WebSockets. Celah ini adalah utang teknis yang terakumulasi di jam 2 pagi di depan konfigurasi load balancer.

Anda mungkin juga menyukai