WebSockets forklart: sanntidskommunikasjon for norske utviklere

Hva er WebSockets?

WebSocket er en nettverkskommunikasjonsprotokoll som etablerer en vedvarende, toveis forbindelse mellom en nettleser (klient) og en server. I motsetning til tradisjonell HTTP, der klienten alltid må starte en ny forespørsel for å få data, holder WebSocket kanalen åpen slik at begge parter kan sende meldinger når som helst.

Protokollen ble standardisert i desember 2011 gjennom RFC 6455, og støttes i dag av alle større nettlesere ifølge caniuse.com. Den starter med et HTTP-"handshake" der forbindelsen oppgraderes fra HTTP til WebSocket – deretter forsvinner overhead fra HTTP-headere og tilkoblingsoppsett ved hvert kall.

HTTP vs. WebSocket: viktige forskjeller

HTTP er en forespørsel-svar-protokoll: klienten sender en forespørsel, serveren svarer, og forbindelsen lukkes (eller gjenbrukes kort med HTTP/1.1 keep-alive). For å simulere sanntid med HTTP brukes gjerne polling (klienten spør hvert N. sekund) eller long polling (serveren holder forbindelsen åpen inntil det er noe å sende). Begge løsninger er ineffektive og gir høyere latens enn en åpen toveis-forbindelse.

Med WebSocket er scenen snudd: forbindelsen holdes åpen på ubestemt tid, og serveren kan pushe data til klienten uten at klienten trenger å spørre. Dette reduserer latens dramatisk og frigjør ressurser på server – spesielt viktig ved mange samtidige brukere.

Typiske brukstilfeller

WebSockets passer best der data endrer seg hyppig og klienten trenger umiddelbar oppdatering. Her er de vanligste brukstilfellene du vil møte i norske prosjekter:

• Chat-applikasjoner og intern meldingstjeneste (Slack-lignende løsninger)
• Live finansdata: aksjekurser, valutapriser, kryptokurser
• Multiplayer-spill og interaktive opplevelser
• Sanntidssamarbeid (Google Docs-stil redigering)
• Dashbord med live telemetri fra IoT-sensorer og industriutstyr
• Live sportsresultater og odds-oppdateringer
• Varsler og notifikasjonssystemer
• Sporingskart for logistikk og flåtestyring

Implementasjon: server-siden med Node.js

Den enkleste måten å komme i gang på er biblioteket `ws` for Node.js. Installer med `npm install ws`, og opprett deretter en WebSocket-server som lytter på en port.

En minimal server kan se slik ut, etter mønsteret i ws-bibliotekets egen dokumentasjon: du importerer `WebSocketServer` fra `ws`, oppretter `new WebSocketServer({ port: 8080 })`, og registrerer en `connection`-hendelse. Inne i denne hendelsen lytter du på `message`-hendelsen fra klienten og sender svar med `socket.send()`. For å sende til alle tilkoblede klienter itererer du over `wss.clients` og sjekker at hver klients `readyState` er `OPEN` før du sender.

I produksjon brukes gjerne socket.io, som legger til automatisk reconnect, rom-basert sending og fallback til HTTP long-polling dersom WebSocket ikke er tilgjengelig. Alternativt kan uWebSockets.js gi høyere ytelse – prosjektet oppgir selv i sine egne benchmarker at det er opptil 13 ganger raskere enn Fastify. Siden Node.js 22.4 har Node.js også et innebygd, stabilt WebSocket-klientobjekt via Undici, men det dekker foreløpig bare klientsiden – en WebSocket-server krever fortsatt et bibliotek som `ws` eller `socket.io`.

Implementasjon: klient-siden i nettleseren

Nettleseren har et innebygd WebSocket-API. Du oppretter en forbindelse med `new WebSocket("wss://api.eksempel.no/ws")`. Deretter bruker du fire hendelser, definert i WHATWG-standarden for WebSockets: `onopen` (forbindelsen er etablert), `onmessage` (melding mottatt fra server), `onerror` (feil oppstod) og `onclose` (forbindelsen ble lukket).

Husk alltid å bruke `wss://` (WebSocket Secure) i produksjon, tilsvarende hvordan HTTPS beskytter vanlig HTTP-trafikk. For Vue- og React-applikasjoner bør WebSocket-tilkoblingen opprettes i en composable eller hook og avsluttes ved unmount for å unngå minnelekkasjer.

Skalerbarhet og produksjonshensyn

Én WebSocket-forbindelse per bruker holder TCP-tilstanden åpen på serveren, og et stort antall samtidige brukere krever derfor vesentlig mer ressurser enn tradisjonell HTTP, der tilkoblinger normalt gjenbrukes kort. For å skalere horisontalt over flere serverinstanser brukes gjerne en Redis Pub/Sub-buss, etter mønsteret i Socket.IOs Redis-adapter: hver instans abonnerer på en Redis-kanal, og en melding publisert på én instans når fram til klienter koblet til alle instansene.

Administrerte tjenester som Ably, Pusher og AWS API Gateway WebSocket API tilbyr ferdigbygde løsninger der leverandøren håndterer skaleringen. For interne forretningssystemer der antall samtidige brukere er håndterbart, er en selvdriftet løsning med Node.js og Redis fortsatt et kurant valg.

Sikkerhet og norsk praksis

Alltid bruk WSS (TLS-kryptert WebSocket) i produksjon. Implementer autentisering ved handshake – enten via token i URL (ikke anbefalt, siden URL-er ofte havner i loggfiler), eller ved å sende et JWT i den første meldingen etter tilkobling. Vanlige CORS-regler gjelder ikke for WebSocket-tilkoblinger. Nettleseren sender riktignok en `Origin`-header ved handshake, men det er opp til serveren selv å validere den og avvise ukjente opphav for å hindre Cross-Site WebSocket Hijacking, ifølge MDNs veiledning for WebSocket-servere.

Et konkret eksempel på WebSocket i norsk sammenheng er børsdata: siden 2019 eies og drives Oslo Børs av Euronext, som tilbyr en WebSocket-basert Stream API for sanntids markedsdata fra sine børser – i praksis distribueres slike data via en åpen WebSocket-kanal fremfor at klienten må polle et REST-endepunkt gjentatte ganger.

Oppsummering og neste steg

WebSockets er et kraftig verktøy i enhver norsk webutviklers verktøykasse. Protokollen skinner best der data endrer seg kontinuerlig og brukeren trenger umiddelbar feedback – chat, live data, samarbeid og spill. For enkle hent-og-vis-scenarioer er vanlig HTTP fortsatt det rette valget.

Begynn med `ws`-biblioteket for en enkel proof of concept, vurder `socket.io` for robusthet i produksjon, og se på administrerte tjenester som Ably eller Pusher dersom skalerbarhet er kritisk fra dag én.