Milloin käyttäisit WebSocketeja, SSE:tä tai long-pollingia tavallisen HTTP:n sijaan?

Question

IT Interview Practice · Accepted Answer

Tavallinen HTTP on **pyyntö/vastaus**: asiakas kysyy, palvelin vastaa, valmis. Se sopii huonosti **reaaliaikaisiin** ominaisuuksiin (chat, live-dashboardit, ilmoitukset, yhteismuokkaus), joissa *palvelimen* täytyy työntää dataa aina kun sillä on jotain uutta. Vaihtoehdot ovat tapoja kiertää HTTP:n asiakasaloitteinen malli, monimutkaisuuden kirjolla:

```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** on kaikkialla toimiva varamalli: asiakas tekee normaalin pyynnön, jonka palvelin pitää auki kunnes sillä on dataa, minkä jälkeen asiakas heti pyytää uudelleen. Se approksimoi työntöä tavallisen HTTP:n yli mutta tuhlaa pyyntösyklin viestiä kohti ja lisää latenssia.

**SSE (Server-Sent Events)** on kevyt, standardoitu **yksisuuntainen** virta (palvelin → asiakas) yhden pitkäikäisen HTTP-vastauksen yli. Se on ihanteellinen kun vain palvelin työntää — live-syötteet, ilmoitukset, edistyminen, LLM-tokenien striimaus. Se on yksinkertainen, toimii tavallisen HTTP/2:n yli (ei erikoisinfrastruktuuria) ja yhdistää uudelleen automaattisesti. Rajoite: se on yksisuuntainen ja vain tekstiä.

**WebSockets** päivittää yksittäisen HTTP-yhteyden pysyväksi, **full-duplex** TCP-kanavaksi, jossa molemmat osapuolet lähettävät milloin tahansa minimaalisella viestikohtaisella yleisrasitteella. Käytä sitä aidosti kaksisuuntaiseen, matalan latenssin vuorovaikutukseen: chat, moninpelit, yhteismuokkaimet, kaupankäynti. Hinta on operatiivinen — se on tilallinen yhteys, jota varten proxyt, kuormantasaajat ja autoscalerit on konfiguroitava, ja sinun on rakennettava uudelleenyhdistys, heartbeatit ja backpressure itse.

**Nyrkkisääntö:** oletuksena tavallinen HTTP; käytä **SSE:tä** palvelin→asiakas-striimaukseen; tartu **WebSocketeihin** vain kun todella tarvitset kaksisuuntaista reaaliaikaa; pidä **long-polling** universaalina varamallina.

## Miksi se on tärkeää

Reaaliaikaisen kuljetuksen valinta on klassinen senior-suunnittelupäätös, jossa naiivi vastaus ("käytä vain WebSocketeja kaikkeen") on yleensä väärä. Haastattelijat haluavat nähdä, että sovitat työkalun *viestintämalliin* — yksisuuntainen vs kaksisuuntainen, latenssitarpeet, viestien määrä — ja että punnitset tilallisten, pitkäikäisten yhteyksien **operatiivisen kustannuksen**: sticky-istunnot, skaalaus, proxyjen timeoutit ja uudelleenyhdistyslogiikka. Sen tunnistaminen, että SSE usein kattaa "palvelin työntää päivityksiä" yksinkertaisemmin kuin WebSockets, ja että long-polling on yhä vankka varamalli, kertoo todellisesta tuotantokokemuksesta sen sijaan että tarttuisi näyttävimpään vaihtoehtoon.

Miksi se on tärkeää

Aiheeseen liittyvät kysymykset