Tjenester, multipleksing
og UDP
Hva transportlaget egentlig gjør, hvordan riktig prosess finner riktig pakke, og den enkleste protokollen som klarer seg uten garantier.
Hva transportlaget egentlig gjør
Nettverkslaget leverer pakker mellom maskiner. Transportlaget løfter kommunikasjonen ett nivå opp — til prosesser.
Forestill deg et hus der tolv barn bor. Et annet hus, på andre siden av byen, huser også tolv barn. Hver dag sender barna brev til hverandre. Postsystemet leverer konvoluttene til riktig hus — men det er Ann og Bill, et barn i hvert hus, som tar imot posten og deler den ut til riktig søsken. Postsystemet er nettverkslaget: det leverer til husadressen. Ann og Bill er transportlaget: de leverer til riktig person inni huset.
Denne analogien fanger den helt sentrale forskjellen:
| Lag | Kommunikasjon |
|---|---|
| Nettverkslaget | Logisk kommunikasjon mellom verter (hosts) — IP-adresser identifiserer maskiner. |
| Transportlaget | Logisk kommunikasjon mellom prosesser — portnumre identifiserer applikasjoner. |
Transportlaget bygger videre på nettverkslaget, men kan ikke gjøre mirakler. Nettverkslaget (IP) tilbyr en best-effort-tjeneste uten noen garantier. Transportlaget kan legge til pålitelighet og rekkefølge (TCP), men det kan ikke tvinge nettverket til å gi bedre båndbredde eller lavere forsinkelse.
Senderens og mottakerens handlinger
Transportlaget gjør konkrete ting på begge sider:
Mottar en applikasjonsmelding fra laget over. Bestemmer headerverdier (portnumre m.m.), lager et segment, og leverer segmentet ned til IP.
Mottar et segment fra IP. Sjekker headerverdiene. Trekker ut applikasjonsdataene. Demultiplekser meldingen opp til riktig socket (og dermed riktig prosess).
To transportprotokoller
Internett gir applikasjoner to valg:
| Protokoll | Egenskaper |
|---|---|
| TCP | Pålitelig, ordnet levering. Flytkontroll, metningskontroll, forbindelsesetablering. Koster tid og ressurser. |
| UDP | Upålitelig, uordnet levering. Ingen håndtrykk, ingen tilstandsinformasjon, minimal overhead. Rask og enkel. |
Hva er den fundamentale forskjellen mellom nettverkslaget og transportlaget?
Riktig pakke til riktig prosess
Kjerneoppgaven til transportlaget: samle data fra mange sockets på sendersiden, og levere dem til riktig socket på mottakersiden.
Multipleksing og demultipleksing er to sider av samme sak. Multipleksing skjer hos senderen: transportlaget samler data fra ulike applikasjonssockets, legger på transportheadere (med bl.a. portnumre), og sender segmentene nedover. Demultipleksing skjer hos mottakeren: transportlaget ser på headerinformasjonen i innkommende segmenter og leverer dataene opp til riktig socket.
Hvordan demultipleksing fungerer
Når en vert mottar et IP-datagram, inneholder det:
- Kilde-IP-adresse Hvem som sendte datagrammet.
- Destinasjons-IP Hvem som skal motta det.
- Kilde-portnummer Fra segmentheaderen — 16 bit.
- Dest.-portnummer Fra segmentheaderen — 16 bit.
Verten bruker IP-adresser og portnumre til å dirigere segmentet til riktig socket. Men hvordan dette skjer, er forskjellig for UDP og TCP.
Forbindelsesløs demultipleksing (UDP)
En UDP-socket identifiseres av bare to ting: destinasjons-IP og destinasjonsport. Konsekvensen er enkel men viktig:
Hvis to UDP-datagrammer har forskjellig kilde-IP og/eller kilde-port, men samme destinasjons-IP og -port, havner de i samme socket hos mottakeren. UDP bryr seg bare om hvor pakken skal hen, ikke hvor den kommer fra.
Forbindelsesorientert demultipleksing (TCP)
TCP gjør det annerledes. En TCP-socket identifiseres av et 4-tuppel:
kilde-IPkilde-portdestinasjons-IPdestinasjons-port
Konsekvensen: selv om tre segmenter ankommer samme server med samme destinasjons-IP og -port (f.eks. port 80), vil de bli levert til forskjellige sockets dersom de har forskjellig kilde-IP eller kilde-port. En webserver kan dermed ha hundrevis av samtidige TCP-forbindelser — alle på port 80 — og holde dem adskilt fordi hver forbindelse har en unik 4-tuppel.
To UDP-datagrammer ankommer en server. De har ulik kilde-IP, men samme destinasjons-IP og -port. Hva skjer?
Forbindelsesløs transport: UDP
UDP gjør nesten ingenting — og nettopp det er poenget. Minimalt med overhead, maksimalt med frihet.
User Datagram Protocol er den enkleste transportprotokollen på internett. Den gjør nesten ingenting utover det IP allerede gir. Ingen forbindelsesetablering, ingen tilstand, ingen garanti for levering, ingen rekkefølgegaranti, ingen flytkontroll, ingen metningskontroll. Hvert UDP-segment håndteres uavhengig av alle andre.
Hvorfor velge noe så primitivt? Fordi fravær av garantier har konkrete fordeler:
| Egenskap | Fordelen |
|---|---|
| Ingen håndtrykk | Ingen ekstra RTT for å sette opp forbindelse — data kan sendes umiddelbart. |
| Ingen tilstand | Sender og mottaker holder ingen forbindelsesinformasjon. Servere kan håndtere mange flere klienter. |
| Liten header | Bare 8 bytes overhead vs. 20+ bytes for TCP. |
| Ingen metningskontroll | Applikasjonen kan sende så fort den vil — nyttig for sanntidsapplikasjoner som tåler litt tap. |
Hvem bruker UDP?
UDP er overraskende utbredt:
- DNS — raskt oppslag uten å sette opp en forbindelse
- SNMP — nettverksovervåking der enkelhet teller
- Strømming — tapstolerant, hastighetssensitiv (dog bruker tjenester som Netflix ofte TCP)
- HTTP/3 — bygger pålitelighet og metningskontroll over UDP via QUIC
UDP-segmentets anatomi
UDP-headeren er minimalistisk — bare 8 bytes:
| Felt | Formål |
|---|---|
| Source Port | Avsenderens portnummer. Mottakeren kan bruke dette til å sende et svar tilbake. |
| Dest Port | Portnummeret segmentet skal leveres til hos mottakeren. |
| Length | Lengden på hele UDP-segmentet (header + data) i bytes. |
| Checksum | Brukes til å oppdage bit-feil i headeren eller dataene. |
Sender- og mottakerhandlinger
Mottar en applikasjonsmelding. Setter kilde- og destinasjonsport. Beregner lengde og sjekksum. Pakker alt inn i et segment og leverer det til IP.
Mottar et segment fra IP. Sjekker sjekksummen. Trekker ut applikasjonsdataene. Demultiplekser meldingen opp til riktig socket basert på destinasjonsporten.
Feildeteksjon med one's complement
Sjekksummen er UDPs eneste forsvarslinje. Den er enkel, billig, og langt fra perfekt.
Tanken bak sjekksummen er rett frem: senderen summerer alle 16-bits ord i segmentet (header + data + deler av IP-headeren), tar one's complement av summen, og legger resultatet i checksum-feltet. Mottakeren gjør samme beregning. Hvis svaret ikke stemmer, vet hun at noe har blitt endret underveis.
Steg for steg
1. Behandle innholdet som en sekvens av 16-bits heltall.
2. Summer dem med one's complement-addisjon (der en carry ut fra bit 15 legges tilbake til bit 0 — wraparound).
3. Ta one's complement av summen (inverter alle bits). Dette er sjekksummen.
Et eksempel
Si at vi adderer to 16-bits tall:
1110 0110 0110 0110
1101 0101 0101 0101
────────────────────
1 1011 1011 1011 1011 ← wraparound-carry
1011 1011 1011 1100 ← sum (etter wraparound)
0100 0100 0100 0011 ← checksum (one's complement)
Svak, men bedre enn ingenting
Sjekksummen fanger mange vanlige feil — som en enkelt bit-flip. Men den er svak: hvis to bits flipper på riktig måte, kan de «nulle ut» hverandre uten å endre summen. Sjekksummen gir ingen garanti for at dataene er uendret — den gir bare en rimelig sjanse for å oppdage feil.
Hva er en svakhet ved UDP-sjekksummen?
Med transportlagets grunnprinsipper, multipleksing/demultipleksing og UDP på plass, er neste steg å forstå hvordan vi bygger pålitelighet steg for steg: Prinsipper for pålitelig dataoverføring.