Kada naudotumėte WebSockets, SSE ar long-polling vietoj paprasto HTTP?

Question

IT Interview Practice · Accepted Answer

Paprastas HTTP yra **request/response**: klientas klausia, serveris atsako, baigta. Tai prastai tinka **real-time** funkcijoms (pokalbiams, gyvoms dashboard'oms, pranešimams, bendram redagavimui), kur *serveris* turi stumti duomenis, kai tik turi ką nors naujo. Variantai yra būdai apeiti HTTP kliento inicijuojamą modelį, sudėtingumo spektru:

```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** yra atsarginis variantas, veikiantis visur: klientas daro įprastą užklausą, kurią serveris laiko atvirą, kol turi duomenų, tada klientas iškart vėl užklausia. Jis imituoja push per paprastą HTTP, bet švaisto užklausos ciklą kiekvienai žinutei ir prideda delsą.

**SSE (Server-Sent Events)** yra lengvas, standartizuotas **vienpusis** srautas (serveris → klientas) per vieną ilgai gyvenantį HTTP atsakymą. Jis idealus, kai stumia tik serveris — gyvi srautai, pranešimai, progresas, streaming LLM token'ai. Jis paprastas, veikia per įprastą HTTP/2 (jokios specialios infrastruktūros) ir automatiškai persijungia. Riba: jis vienpusis ir tik tekstinis.

**WebSockets** pakelia vieną HTTP jungtį į pastovų, **full-duplex** TCP kanalą, kur abi pusės siunčia bet kada su minimalia pridėtine našta kiekvienai žinutei. Naudokite tikrai dvipusiam, mažos delsos ryšiui: pokalbiams, multiplayer žaidimams, bendriems redaktoriams, prekybai. Kaina yra eksploatacinė — tai stateful jungtis, kuriai proxy, load balancer'iai ir autoscaler'iai turi būti sukonfigūruoti, o persijungimą, heartbeat'us ir backpressure turite sukurti patys.

**Nykščio taisyklė:** pagal numatymą naudokite paprastą HTTP; naudokite **SSE** serveris→klientas srautui; griebkitės **WebSockets** tik tada, kai tikrai reikia dvipusio real-time; laikykite **long-polling** kaip universalų atsarginį variantą.

## Kodėl tai svarbu

Real-time transporto pasirinkimas yra klasikinis senior dizaino sprendimas, kur naivus atsakymas („tiesiog naudok WebSockets viskam") paprastai yra neteisingas. Apklausėjai nori matyti, kad derinate įrankį prie *ryšio modelio* — vienpusis vs. dvipusis, delsos poreikiai, žinučių kiekis — ir kad pasveriate stateful, ilgai gyvenančių jungčių **eksploatacinę kainą**: sticky session'us, mastelio keitimą, proxy timeout'us ir persijungimo logiką. Suvokimas, kad SSE dažnai dengia „serveris stumia atnaujinimus" paprasčiau nei WebSockets, ir kad long-polling lieka tvirtu atsarginiu variantu, rodo realią production patirtį, o ne griebimąsi ryškiausio varianto.

Kodėl tai svarbu

Susiję klausimai