Düz HTTP yerine ne zaman WebSockets, SSE veya long-polling kullanırsınız?

Question

IT Interview Practice · Accepted Answer

Düz HTTP **istek/yanıttır**: istemci sorar, sunucu yanıtlar, biter. Bu, *sunucunun* yeni bir şey olduğunda veri push etmesi gereken **gerçek zamanlı** özellikler (sohbet, canlı dashboard'lar, bildirimler, ortak düzenleme) için zayıf bir uyumdur. Seçenekler, HTTP'nin istemci-başlatmalı modelini aşmanın yollarıdır ve bir karmaşıklık yelpazesinde sıralanır:

```text
Long-polling   client ──req──▶ server ...holds... ──resp──▶ then immediately re-asks
               (near-real-time over plain HTTP; one message per held request)

SSE            client ──req──▶ server ═══stream of events═══▶ (one-way, server→client)
               (HTTP-based, text, auto-reconnect; NO client→server on same channel)

WebSocket      client ──handshake──▶ server ══full-duplex, both directions══▶
               (persistent TCP; low overhead; binary or text; you build the rest)
```

**Long-polling**, her yerde çalışan geri dönüş çözümüdür: istemci normal bir istek yapar, sunucu bunu veri gelene kadar açık tutar, sonra istemci hemen yeniden istekte bulunur. Düz HTTP üzerinde push'a yaklaşır ama mesaj başına bir istek döngüsü boşa harcar ve gecikme ekler.

**SSE (Server-Sent Events)**, tek bir uzun ömürlü HTTP response üzerinde hafif, standartlaştırılmış **tek yönlü** bir akıştır (sunucu → istemci). Yalnızca sunucunun push ettiği durumlar için idealdir — canlı feed'ler, bildirimler, ilerleme, streaming LLM token'ları. Basittir, normal HTTP/2 üzerinde çalışır (özel altyapı gerektirmez) ve otomatik yeniden bağlanır. Sınırı: tek yönlü ve yalnızca metindir.

**WebSockets**, tek bir HTTP bağlantısını kalıcı, **full-duplex** bir TCP kanalına yükseltir; burada iki taraf da minimal mesaj başına ek yükle istediği zaman gönderir. Gerçekten çift yönlü, düşük gecikmeli etkileşim için kullanın: sohbet, çok oyunculu oyunlar, ortak editörler, ticaret. Bedeli operasyoneldir — proxy'lerin, load balancer'ların ve autoscaler'ların yapılandırılması gereken stateful bir bağlantıdır ve yeniden bağlanmayı, heartbeat'leri ve backpressure'ı kendiniz inşa etmelisiniz.

**Genel kural:** varsayılan olarak düz HTTP kullanın; sunucu→istemci streaming için **SSE** kullanın; yalnızca gerçekten çift yönlü gerçek zamana ihtiyaç duyduğunuzda **WebSockets**'e başvurun; **long-polling**'i evrensel geri dönüş olarak tutun.

## Neden önemli

Bir gerçek zamanlı transport seçmek, saf yanıtın ("her şey için sadece WebSockets kullan") genellikle yanlış olduğu klasik bir senior tasarım kararıdır. Mülakat yapanlar aracı *iletişim desenine* uydurduğunuzu — tek yönlü vs çift yönlü, gecikme ihtiyaçları, mesaj hacmi — ve stateful, uzun ömürlü bağlantıların **operasyonel maliyetini** tarttığınızı görmek ister: sticky session'lar, ölçekleme, proxy timeout'ları ve yeniden bağlanma mantığı. SSE'nin "sunucu güncelleme push eder"i çoğu zaman WebSockets'ten daha basit karşıladığını ve long-polling'in sağlam bir geri dönüş olarak kaldığını fark etmek, en gösterişli seçeneğe uzanmak yerine gerçek production deneyimine işaret eder.

Neden önemli

İlgili sorular