När skulle du använda WebSockets, SSE eller long-polling istället för vanlig HTTP?

Question

IT Interview Practice · Accepted Answer

Vanlig HTTP är **request/response**: klienten frågar, servern svarar, klart. Det passar dåligt för **realtidsfunktioner** (chatt, live-dashboards, notifieringar, samarbetsredigering) där *servern* behöver pusha data närhelst den har något nytt. Alternativen är sätt att komma runt HTTP:s klientinitierade modell, längs ett spektrum av komplexitet:

```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** är fallback:en som fungerar överallt: klienten gör en normal request som servern håller öppen tills den har data, sedan gör klienten omedelbart en ny request. Det efterliknar push över vanlig HTTP men slösar en request-cykel per meddelande och lägger till latens.

**SSE (Server-Sent Events)** är en lättviktig, standardiserad **envägs**-ström (server → klient) över ett enda långlivat HTTP-svar. Det är idealiskt när endast servern pushar — live-flöden, notifieringar, förlopp, strömmande LLM-tokens. Det är enkelt, körs över vanlig HTTP/2 (ingen särskild infrastruktur) och återansluter automatiskt. Begränsningen: det är enkelriktat och endast text.

**WebSockets** uppgraderar en enda HTTP-anslutning till en beständig, **full-duplex** TCP-kanal där båda sidor skickar när som helst med minimal overhead per meddelande. Använd det för genuint dubbelriktad interaktion med låg latens: chatt, multiplayer-spel, samarbetsredigerare, trading. Kostnaden är operationell — det är en stateful anslutning som proxyer, load balancers och autoscalers måste konfigureras för, och du måste själv bygga återanslutning, heartbeats och backpressure.

**Tumregel:** utgå från vanlig HTTP; använd **SSE** för strömning server→klient; ta till **WebSockets** endast när du verkligen behöver dubbelriktad realtid; behåll **long-polling** som den universella fallback:en.

## Varför det är viktigt

Att välja ett realtidstransport är ett klassiskt seniort designbeslut där det naiva svaret ("använd bara WebSockets för allt") oftast är fel. Intervjuare vill se att du matchar verktyget mot *kommunikationsmönstret* — enkelriktat kontra dubbelriktat, latensbehov, meddelandevolym — och att du väger in den **operationella kostnaden** för stateful, långlivade anslutningar: sticky sessions, skalning, proxy-timeouts och återanslutningslogik. Att inse att SSE ofta täcker "servern pushar uppdateringar" enklare än WebSockets, och att long-polling förblir en robust fallback, signalerar verklig produktionserfarenhet snarare än att gripa efter det flashigaste alternativet.

Varför det är viktigt

Relaterade frågor