Long Polling: apa itu, cara kerja dan di mana digunakan

Apa itu Long Polling

Long Polling adalah pola interaksi dalam arsitektur klien-server di mana klien memulai permintaan HTTP, dan server menunda pengiriman respons hingga data baru muncul atau waktu tertentu habis. Setelah menerima respons, klien segera mengirim permintaan berikutnya, menciptakan efek koneksi berkelanjutan.

Teknik Long Polling muncul sebagai pengembangan evolusioner dari Short Polling untuk mengurangi jumlah permintaan HTTP kosong. Dalam polling tradisional, klien mengirim permintaan setiap N detik, dan server merespons bahkan saat tidak ada data baru. Dalam Long Polling, server menggunakan mekanisme penahanan koneksi, yang secara radikal mengurangi volume lalu lintas yang tidak berguna.

Sejarah Long Polling

Sebelum munculnya WebSocket pada tahun 2011, Long Polling adalah metode utama organisasi real-time di web. Perusahaan seperti Facebook dan Gmail menggunakan teknik ini untuk chat dan notifikasi mereka di awal tahun 2010-an. Menurut penelitian High Performance Browser Networking (Grigorik, 2013), Long Polling memproses hingga 95% dari semua koneksi real-time di aplikasi web besar pada periode tersebut.

Prinsip Dasar Long Polling

Klien mengirim permintaan HTTP standar ke server. Server setelah menerima permintaan tidak segera mengembalikan respons — menempatkan permintaan dalam antrian tunggu. Ketika peristiwa terjadi di server (pesan baru, perubahan data), server membentuk respons dan mengirimkannya ke klien. Klien setelah menerima respons segera membuat permintaan Long Polling baru, dan siklus berulang.

Cara Kerja Long Polling

Long Polling bekerja mengikuti urutan langkah berikut. Klien mengirim permintaan HTTP GET ke endpoint server. Server setelah menerima permintaan memeriksa ketersediaan data baru di antrian peristiwa. Jika tidak ada data, server menahan permintaan dalam status menunggu, tanpa segera mengirim respons. Mekanisme penahanan tergantung pada implementasi server — paling sering digunakan pemrosesan asinkron dengan callback atau arsitektur berbasis peristiwa.

Ketika peristiwa terjadi di sisi server (misalnya, pengguna mengirim pesan di chat), server membentuk respons HTTP dengan body berisi data tersebut dan mengakhiri koneksi. Klien menerima respons, memproses data, dan segera memulai permintaan baru. Jika selama waktu tunggu data tidak muncul, server mengirim respons kosong setelah waktu habis, dan klien juga membuat ulang koneksi. Timeout biasanya 30-60 detik untuk keseimbangan antara beban dan latensi.

Time-out dan Manajemen Koneksi

Parameter kunci konfigurasi Long Polling adalah time-out tunggu. Time-out terlalu pendek (kurang dari 10 detik) menyebabkan peningkatan jumlah permintaan, mendekatkan teknik ke Short Polling. Terlalu panjang (lebih dari 120 detik) dapat menyebabkan putusnya koneksi oleh proxy perantara dan load balancer. Nilai yang disarankan untuk sebagian besar skenario adalah 30-45 detik.

Penanganan Banyak Peristiwa

Jika beberapa peristiwa terjadi di server selama satu permintaan Long Polling, server harus mengirimkan semuanya dalam satu respons atau mengatur antrian peristiwa di sisi klien. Untuk ini digunakan buffering peristiwa: server mengumpulkan peristiwa yang terjadi selama penahanan permintaan dan mengirimkannya sebagai array data di body respons.

Contoh Implementasi Long Polling di JavaScript

Mari kita lihat implementasi sederhana Long Polling di sisi klien menggunakan Fetch API modern. Fungsi klien mengirim permintaan dan memanggil dirinya sendiri secara rekursif setelah menerima respons.

async function longPoll(url) {
    try {
        const response = await fetch(url);
        const data = await response.json();

        handleData(data);
        longPoll(url);
    } catch (error) {
        console.error("Kesalahan Long Polling", error);
        setTimeout(() => longPoll(url), 3000);
    }
}

function handleData(data) {
    if (data.events && data.events.length > 0) {
        data.events.forEach(event => {
            console.log("Peristiwa baru:", event);
        });
    }
}

longPoll("/api/events");

Kode ini membuat loop Long Polling tak terbatas: setelah menerima respons, fungsi segera mengirim permintaan baru. Saat terjadi error koneksi, penundaan tiga detik diatur sebelum percobaan ulang untuk menghindari beban longsor pada server.

Implementasi Server di Node.js

Di sisi server, permintaan harus ditahan hingga peristiwa muncul atau waktu habis. Contoh implementasi menggunakan EventEmitter di Node.js mendemonstrasikan mekanisme ini.

const express = require("express");
const EventEmitter = require("events");
const app = express();

const eventBus = new EventEmitter();

app.get("/api/events", (req, res) => {
    const timeout = setTimeout(() => {
        res.json({ events: [] });
    }, 30000);

    eventBus.once("new-event", (data) => {
        clearTimeout(timeout);
        res.json({ events: [data] });
    });
});

app.post("/api/events", (req, res) => {
    eventBus.emit("new-event", req.body);
    res.send({ status: "ok" });
});

app.listen(3000);

Bagian server menggunakan EventEmitter untuk memberi tahu koneksi Long Polling yang menunggu saat data baru muncul. Setelah mencapai time-out 30 detik, server mengembalikan array peristiwa kosong, dan klien membuat permintaan baru.

Kapan Long Polling Digunakan

Long Polling digunakan dalam skenario yang memerlukan pengiriman data real-time, tetapi penggunaan WebSocket tidak mungkin karena alasan teknis atau infrastruktur. Kasus paling umum — proxy perusahaan dan firewall yang memblokir koneksi WebSocket, serta lingkungan dengan dukungan protokol terbatas di sisi server.

• Chat dan messenger — Long Polling memastikan pengiriman pesan di versi web messenger yang bekerja melalui HTTP tanpa WebSocket.
• Panel monitoring — sistem real-time untuk metrik DevOps, log, dan alert di mana aktualitas data dengan latensi 1-5 detik penting.
• Notifikasi — pengiriman notifikasi di browser tanpa menggunakan Service Workers dan Push API.
• Feed aktivitas — media sosial dan feed berita dengan pembaruan konten otomatis saat muncul entri baru.
• Kerja kolaboratif — editor seperti Google Docs dengan sinkronisasi dasar perubahan antar pengguna.

Faktor kunci pemilihan Long Polling adalah kompatibilitas mundur. Semua klien dan server HTTP mendukung metode ini, menjadikannya solusi universal untuk real-time tanpa dependensi tambahan. Menurut HTTP Archive (2024), sekitar 8% dari semua situs web terus menggunakan Long Polling untuk fungsionalitas dasar real-time.

Long Polling vs Short Polling

Long Polling dan Short Polling menyelesaikan tugas yang sama — pengiriman data dari server ke klien — tetapi secara fundamental berbeda dalam mekanisme dan efisiensi. Short Polling menggunakan interval polling tetap, di mana klien mengirim permintaan HTTP pada interval waktu yang sama terlepas dari apakah data baru muncul di server.

Short Polling lebih sederhana dalam implementasi, tetapi menghasilkan beban yang jauh lebih besar pada server dan jaringan pada frekuensi pembaruan data yang sama. Jika diperlukan latensi kurang dari 5 detik, Short Polling menghasilkan puluhan permintaan per menit, sementara Long Polling menggunakan satu permintaan per peristiwa atau time-out. Untuk aplikasi dengan peristiwa jarang, Long Polling jauh lebih efisien dalam hal lalu lintas.

Long Polling vs WebSocket

WebSocket adalah protokol real-time dua arah penuh yang bekerja di atas TCP setelah jabat tangan HTTP awal. Berbeda dengan Long Polling, WebSocket membangun satu koneksi permanen dan memungkinkan server mengirim data ke klien kapan saja tanpa membuat permintaan HTTP baru.

Pilihan antara Long Polling dan WebSocket tergantung pada beberapa faktor. Kompatibilitas: Long Polling bekerja melalui semua proxy dan firewall, WebSocket dapat diblokir oleh jaringan perusahaan. Kinerja: WebSocket memiliki overhead lebih kecil (2 byte per frame dibandingkan header HTTP lengkap), yang kritis pada frekuensi pesan tinggi. Skalabilitas: Long Polling membutuhkan lebih banyak sumber daya di sisi server karena menahan banyak koneksi, WebSocket menggunakan koneksi tetap per sesi.

• Long Polling — pilihan terbaik untuk aplikasi dengan frekuensi peristiwa rendah (1-10 peristiwa per menit), infrastruktur terbatas, atau kebutuhan mendukung browser lama.
• WebSocket — solusi optimal untuk aplikasi real-time dengan beban tinggi (data bursa, game online, editor kolaboratif) dengan ratusan pesan per detik.
• Pendekatan hybrid — beberapa aplikasi menggunakan Long Polling sebagai fallback untuk klien yang tidak mendukung WebSocket, dengan peralihan protokol otomatis.

Menurut Mozilla Developer Network (2024), WebSocket didukung oleh semua browser modern sejak versi 2011-2015, tetapi proxy perusahaan (misalnya Symantec Blue Coat) terus memblokirnya di 15-20% jaringan korporat, yang mempertahankan relevansi Long Polling sebagai solusi fallback.