Long Polling: Kavram, Çalışma Şekli ve Kullanım Alanları

Long Polling Nedir

Long Polling, istemci-sunucu mimarisinde bir etkileşim modelidir. İstemci HTTP isteği başlatır, sunucu yeni veriler görünene veya belirtilen zaman aşımı süresi dolana kadar yanıt göndermeyi erteler. Yanıtı alan istemci hemen bir sonraki isteği göndererek sürekli bağlantı etkisi yaratır.

Long Polling tekniği, boş HTTP isteklerinin sayısını azaltmak için Short Polling'in evrimsel gelişimi olarak ortaya çıkmıştır. Geleneksel yoklamada istemci her N saniyede bir istek gönderir ve sunucu yeni veri olmasa bile yanıt verir. Long Polling'de sunucu bağlantı tutma mekanizması kullanır, bu da gereksiz trafik hacmini önemli ölçüde azaltır.

Long Polling'in Tarihçesi

2011'de WebSocket'in ortaya çıkmasından önce Long Polling, web'de gerçek zamanlı iletişim düzenlemenin ana yoluydu. Facebook ve Gmail gibi şirketler 2010'ların başında sohbet ve bildirimleri için bu tekniği kullandı. High Performance Browser Networking (Grigorik, 2013) araştırmasına göre Long Polling, o dönemde büyük web uygulamalarındaki gerçek zamanlı bağlantıların %95'ine kadarını işliyordu.

Long Polling Temel Prensibi

İstemci sunucuya standart bir HTTP isteği gönderir. İsteği alan sunucu hemen yanıt döndürmez, isteği bekleme kuyruğuna koyar. Sunucuda bir olay (yeni mesaj, veri değişikliği) gerçekleştiğinde sunucu yanıtı oluşturur ve istemciye gönderir. Yanıtı alan istemci hemen yeni bir Long Polling isteği oluşturur ve döngü tekrarlanır.

Long Polling Nasıl Çalışır

Long Polling aşağıdaki adım sırasıyla çalışır. İstemci sunucu endpoint'ine HTTP GET isteği gönderir. İsteği alan sunucu, olay kuyruğunda yeni veri olup olmadığını kontrol eder. Veri yoksa sunucu hemen yanıt göndermez, isteği bekleme durumunda tutar. Bekleme mekanizması sunucu uygulamasına bağlıdır, genellikle geri aramalarla asenkron işleme veya olay tabanlı mimari kullanılır.

Sunucu tarafında bir olay (örneğin, kullanıcı sohbete mesaj gönderdi) gerçekleştiğinde sunucu, bu verileri içeren HTTP yanıtını oluşturur ve bağlantıyı sonlandırır. İstemci yanıtı alır, verileri işler ve hemen yeni bir istek başlatır. Bekleme süresi boyunca veri görünmezse sunucu, zaman aşımı dolduğunda boş yanıt gönderir ve istemci de bağlantıyı yeniden oluşturur. Zaman aşımı genellikle yük ve gecikme arasındaki denge için 30-60 saniyedir.

Zaman Aşımları ve Bağlantı Yönetimi

Long Polling yapılandırmasının temel parametresi bekleme zaman aşımıdır. Çok kısa zaman aşımı (10 saniyeden az) istek sayısını artırarak tekniği Short Polling'e yaklaştırır. Çok uzun (120 saniyeden fazla) ara proxy'ler ve yük dengeleyiciler tarafından bağlantının kopmasına neden olabilir. Çoğu senaryo için önerilen değer 30-45 saniyedir.

Çoklu Olay İşleme

Bir Long Polling isteği sırasında sunucuda birden fazla olay gerçekleşirse sunucu tüm olayları tek bir yanıtta iletmeli veya istemci tarafında bir olay kuyruğu düzenlemelidir. Bunun için olay arabelleğe alma kullanılır: sunucu, isteğin tutulması sırasında gerçekleşen olayları biriktirir ve yanıt gövdesinde bir veri dizisi olarak iletir.

JavaScript ile Long Polling Uygulama Örneği

Modern Fetch API kullanarak istemci tarafında Long Polling'in basit bir uygulamasına bakalım. İstemci işlevi istek gönderir ve yanıtı aldıktan sonra kendini yinelemeli olarak çağırır.

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

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

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

longPoll("/api/events");

Bu kod sonsuz bir Long Polling döngüsü oluşturur: yanıt alındıktan sonra işlev hemen yeni bir istek gönderir. Bağlantı hatası durumunda, sunucuda talan yükünü önlemek için yeniden denemeden önce üç saniyelik bir gecikme ayarlanır.

Node.js Sunucu Uygulaması

Sunucu tarafında, bir olay görünene veya zaman aşımı dolana kadar isteği tutmak gerekir. Node.js'de EventEmitter kullanan bir uygulama örneği bu mekanizmayı göstermektedir.

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);

Sunucu kısmı, yeni veri göründüğünde bekleyen Long Polling bağlantılarını haberdar etmek için EventEmitter kullanır. 30 saniyelik zaman aşımına ulaşıldığında sunucu boş bir olay dizisi döndürür ve istemci yeni bir istek oluşturur.

Long Polling Kullanım Durumları

Long Polling, gerçek zamanlı veri iletimi gerektiğinde ancak teknik veya altyapısal nedenlerle WebSocket'in kullanılamadığı senaryolarda uygulanır. En yaygın durumlar — WebSocket bağlantılarını engelleyen kurumsal proxy'ler ve güvenlik duvarları ile sunucu tarafında sınırlı protokol desteği olan ortamlardır.

• Sohbet ve Mesajlaşma — Long Polling, WebSocket olmadan HTTP üzerinden çalışan web sürümü mesajlaşma uygulamalarında mesaj teslimatını sağlar.
• Panolar — DevOps metrikleri, günlükler ve uyarılar için gerçek zamanlı sistemler, 1-5 saniye gecikmeyle veri güncelliği önemlidir.
• Bildirimler — Service Workers ve Push API olmadan tarayıcıda push benzeri bildirim teslimatı.
• Aktivite Akışları — yeni gönderiler göründüğünde içeriği otomatik olarak güncelleyen sosyal ağlar ve haber akışları.
• Ortak Çalışma — kullanıcılar arasında temel değişiklik senkronizasyonu olan Google Docs benzeri düzenleyiciler.

Long Polling seçiminde temel faktör geriye dönük uyumluluktur. Tüm HTTP istemcileri ve sunucuları bu yöntemi destekler, bu da onu ek bağımlılıklar olmadan gerçek zamanlı için evrensel bir çözüm haline getirir. HTTP Archive (2024)'e göre tüm web sitelerinin yaklaşık %8'i temel gerçek zamanlı işlevsellik için Long Polling kullanmaya devam etmektedir.

Long Polling vs Short Polling

Long Polling ve Short Polling aynı görevi — verileri sunucudan istemciye teslim etme — çözer ancak mekanizma ve verimlilik açısından temel olarak farklılık gösterir. Short Polling sabit bir yoklama aralığı kullanır; istemci, sunucuda yeni veri görünüp görünmediğine bakılmaksızın eşit aralıklarla HTTP istekleri gönderir.

Short Polling uygulaması daha basittir ancak aynı veri güncelleme sıklığında sunucu ve ağ üzerinde önemli ölçüde daha fazla yük oluşturur. 5 saniyeden az gecikme gerekiyorsa Short Polling dakikada onlarca istek üretirken Long Polling olay veya zaman aşımı başına bir istek kullanır. Seyrek olayları olan uygulamalar için Long Polling trafik açısından çok daha verimlidir.

Long Polling vs WebSocket

WebSocket, ilk HTTP el sıkışmasından sonra TCP üzerinde çalışan tam çift yönlü gerçek zamanlı bir protokoldür. Long Polling'den farklı olarak WebSocket tek bir kalıcı bağlantı kurar ve sunucunun yeni bir HTTP isteği oluşturmadan istemciye istediği zaman veri göndermesine olanak tanır.

Long Polling ve WebSocket arasındaki seçim birkaç faktöre bağlıdır. Uyumluluk: Long Polling tüm proxy'ler ve güvenlik duvarları üzerinden çalışır, WebSocket kurumsal ağlar tarafından engellenebilir. Performans: WebSocket'in ek yükü daha düşüktür (tam HTTP başlıkları yerine çerçeve başına 2 bayt), bu yüksek mesaj sıklığında kritiktir. Ölçeklenebilirlik: Long Polling, çok sayıda bağlantıyı tutma nedeniyle sunucu tarafında daha fazla kaynak gerektirir, WebSocket oturum başına sabit bağlantı kullanır.

• Long Polling — düşük olay sıklığı (dakikada 1-10 olay), sınırlı altyapı veya eski tarayıcı desteği gerektiren uygulamalar için en iyi seçimdir.
• WebSocket — yüksek yüklü gerçek zamanlı uygulamalar (borsa verileri, çevrimiçi oyunlar, ortak çalışma düzenleyicileri) için saniyede yüzlerce mesajla optimum çözümdür.
• Hibrit yaklaşım — bazı uygulamalar WebSocket'i desteklemeyen istemciler için geri dönüş olarak Long Polling kullanır ve protokolü otomatik olarak değiştirir.

Mozilla Developer Network (2024)'e göre WebSocket 2011-2015 sürümlerinden itibaren tüm modern tarayıcılar tarafından desteklenmektedir, ancak kurumsal proxy'ler (örneğin Symantec Blue Coat) kurumsal ağların %15-20'sinde bunu engellemeye devam etmektedir, bu da Long Polling'in geri dönüş çözümü olarak önemini korumasını sağlar.