Kdaj bi uporabili WebSockets, SSE ali long-polling namesto navadnega HTTP?

Question

IT Interview Practice · Accepted Answer

Navadni HTTP je **zahtevek/odgovor**: odjemalec vpraša, strežnik odgovori, konec. To se slabo prilega **real-time** funkcijam (klepet, nadzorne plošče v živo, obvestila, sodelovalno urejanje), kjer mora *strežnik* potisniti podatke, kadar koli ima kaj novega. Možnosti so načini, kako zaobiti model HTTP, ki ga sproža odjemalec, po spektru zapletenosti:

```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** je rezervna možnost, ki deluje povsod: odjemalec pošlje navaden zahtevek, ki ga strežnik drži odprtega, dokler nima podatkov, nato odjemalec takoj znova zahteva. Približa potiskanje prek navadnega HTTP, a zapravi cikel zahtevka na sporočilo in doda zakasnitev.

**SSE (Server-Sent Events)** je lahek, standardiziran **enosmerni** tok (strežnik → odjemalec) prek enega dolgoživega odgovora HTTP. Idealen je, kadar potiska le strežnik — viri v živo, obvestila, napredek, pretakanje žetonov LLM. Je preprost, teče prek navadnega HTTP/2 (brez posebne infrastrukture) in se samodejno znova poveže. Omejitev: je enosmeren in samo besedilen.

**WebSockets** nadgradi eno povezavo HTTP v trajen, **full-duplex** kanal TCP, kjer obe strani pošiljata kadar koli z minimalnim overheadom na sporočilo. Uporabite ga za resnično dvosmerno interakcijo z nizko zakasnitvijo: klepet, večigralske igre, sodelovalni urejevalniki, trgovanje. Cena je operativna — je povezava s stanjem, za katero morajo biti nastavljeni proxyji, load balancerji in autoscalerji, sami pa morate zgraditi ponovno povezovanje, srčne utripe (heartbeats) in protipritisk (backpressure).

**Pravilo palca:** privzeto uporabljajte navaden HTTP; za pretakanje strežnik→odjemalec uporabite **SSE**; po **WebSockets** posezite le, ko resnično potrebujete dvosmerni real-time; **long-polling** obdržite kot univerzalno rezervno možnost.

## Zakaj je to pomembno

Izbira real-time transporta je klasična senior odločitev o zasnovi, kjer je naivni odgovor (»kar za vse uporabi WebSockets«) običajno napačen. Izpraševalci želijo videti, da orodje uskladite z *vzorcem komunikacije* — enosmerno proti dvosmerno, potrebe po zakasnitvi, količina sporočil — in da pretehtate **operativni strošek** povezav s stanjem in dolgo življenjsko dobo: sticky seje, skaliranje, proxy timeouti in logika ponovnega povezovanja. Prepoznavanje, da SSE pogosto pokrije »strežnik potiska posodobitve« bolj preprosto kot WebSockets in da long-polling ostaja robustna rezervna možnost, kaže na resnično produkcijsko izkušnjo namesto poseganja po najbolj bleščeči možnosti.

Zakaj je to pomembno

Povezana vprašanja