Mikor használnál WebSocketet, SSE-t vagy long-pollingot a sima HTTP helyett?

Question

IT Interview Practice · Accepted Answer

A sima HTTP **request/response**: a kliens kérdez, a szerver válaszol, kész. Ez rosszul illik a **valós idejű (real-time)** funkciókhoz (chat, élő dashboardok, értesítések, kollaboratív szerkesztés), ahol a *szervernek* akkor kell adatot küldenie (push), amikor valami újja van. A lehetőségek különböző módjai annak, hogy megkerüljük a HTTP kliens-kezdeményezésű modelljét, egy komplexitási spektrum mentén:

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

A **long-polling** az a fallback, ami mindenhol működik: a kliens egy normál kérést tesz, amit a szerver nyitva tart, amíg adata nem lesz, majd a kliens azonnal újra kér. Sima HTTP fölött közelíti a push-t, de üzenetenként elpazarol egy kérés-ciklust, és latency-t ad hozzá.

Az **SSE (Server-Sent Events)** egy könnyűsúlyú, szabványosított **egyirányú** stream (szerver → kliens) egyetlen, hosszú életű HTTP-válaszon. Ideális, amikor csak a szerver push-ol — élő feed-ek, értesítések, folyamat-jelzés, streamelő LLM tokenek. Egyszerű, normál HTTP/2 fölött fut (nincs speciális infrastruktúra), és automatikusan újracsatlakozik. A korlát: egyirányú és csak szöveg.

A **WebSocket** egyetlen HTTP-kapcsolatot fejleszt egy tartós, **full-duplex** TCP-csatornává, ahol mindkét fél bármikor küldhet, minimális üzenetenkénti overheaddel. Használd valóban kétirányú, alacsony latency-jű interakcióhoz: chat, többjátékos játékok, kollaboratív szerkesztők, kereskedés (trading). Az ára üzemeltetési — egy stateful kapcsolat, amelyre a proxy-kat, load balancereket és autoscalereket konfigurálni kell, az újracsatlakozást, a heartbeat-eket és a backpressure-t pedig magadnak kell megépítened.

**Hüvelykujjszabály:** alapból sima HTTP; **SSE** a szerver→kliens streameléshez; **WebSocket**-hez csak akkor nyúlj, ha valóban kétirányú real-time kell; a **long-polling** maradjon az univerzális fallback.

## Miért fontos

Egy real-time transport kiválasztása klasszikus senior tervezési döntés, ahol a naiv válasz ("csak használj WebSocketet mindenre") általában rossz. Az interjúztatók azt akarják látni, hogy az eszközt a *kommunikációs mintához* igazítod — egyirányú vs kétirányú, latency-igények, üzenetmennyiség —, és hogy mérlegeled a stateful, hosszú életű kapcsolatok **üzemeltetési költségét**: sticky session-ök, skálázás, proxy-timeout-ok és újracsatlakozási logika. Annak felismerése, hogy az SSE gyakran egyszerűbben lefedi a "szerver frissítéseket push-ol" esetet, mint a WebSocket, és hogy a long-polling továbbra is robusztus fallback, valódi production-tapasztalatot jelez, nem pedig a leglátványosabb opció felé nyúlást.

Miért fontos

Kapcsolódó kérdések