Du sitter på campus, kobler til NTNU-WiFi, åpner nettleseren og skriver ntnu.no. På under ett sekund ser du forsiden. Men hva skjedde egentlig — steg for steg, lag for lag?
Før noe annet kan skje, må laptopen koble seg til nettet — trådløst.
Du åpner laptopen på campus. WiFi-kortet scanner etter aksesspunkter ved å sende Probe Requests på ulike kanaler, og finner NTNU sitt nett. Det som følger er en presis dans av meldinger mellom laptopen og aksesspunktet — autentisering, assosiering, og til slutt en DHCP-utveksling for å få en IP-adresse.
DHCP gir deg fire viktige ting: en IP-adresse (f.eks. 10.22.14.87), en subnettmaske (f.eks. 255.255.255.0, som forteller at alle med prefiks 10.22.14.x er på samme lokalnett), adressen til default gateway (ruteren som videresender alt utenfor subnettet), og adressen til en DNS-server. Merk at 10.22.14.87 er en privat IP-adresse (RFC 1918) — den fungerer bare internt på campus. Når trafikken skal ut på Internett, må en NAT-ruter (Network Address Translation) oversette den private adressen til en offentlig IP-adresse.
En WiFi-ramme (802.11) har en mer kompleks header enn Ethernet — den inneholder fire adressefelt (ikke to) fordi trafikken må rutes gjennom aksesspunktet. Feltene inkluderer Frame Control (type og subtype), Duration (for NAV/virtuell carrier sensing), Adresse 1–4 (avsender, mottaker, AP, og ev. mesh-noder), Sequence Control (for reassembly), og til slutt FCS (CRC-sjekk).
CSMA/CA — kollisjonsunngåelse — betyr at laptopen lytter før den sender. Hvis kanalen er opptatt, venter den en tilfeldig backoff-tid. Etter sending venter den på en ACK fra AP-et. Ingen ACK? Prøv igjen. Dette er forskjellig fra Ethernet sin CSMA/CD (collision detection), fordi trådløse enheter ikke kan lytte mens de sender — de kan ikke oppdage kollisjoner, bare unngå dem.
Adressen 10.22.14.87 er en privat RFC 1918-adresse — den er ikke rutbar på Internett. Tre adresseblokker er reservert for privat bruk: 10.0.0.0/8, 172.16.0.0/12, og 192.168.0.0/16. Hundrevis av organisasjoner kan bruke de samme adressene internt uten konflikt.
Når pakken din forlater campus-nettverket, gjør NAT-ruteren en oversettelse: den erstatter din private kilde-IP og kildeport med sin egen offentlige IP-adresse og en ny portnummer. Ruteren husker denne mappingen i en NAT-tabell, slik at svar kan sendes tilbake til riktig intern maskin. NAT er en av grunnene til at IPv4 med sine 4,3 milliarder adresser fortsatt fungerer trass i milliarder av tilkoblede enheter.
Et klassisk problem med trådløse nettverk: to enheter (A og C) kan begge nå aksesspunktet (B), men kan ikke høre hverandre fordi de er for langt fra hverandre. Begge tror kanalen er ledig, sender samtidig, og pakkene kolliderer ved AP-et. Dette kalles hidden terminal-problemet.
Løsningen er RTS/CTS (Request to Send / Clear to Send): senderen ber først om tillatelse med en kort RTS-melding. AP-et svarer med CTS som alle i nærheten hører — og de vet da at de må vente. Dette legger til overhead, men eliminerer kollisjoner fra skjulte terminaler.
Nettleseren vet ikke hvor ntnu.no bor. DNS oversetter navnet til en IP-adresse.
Nettleseren kaller operativsystemets resolver-funksjon (getaddrinfo), som sender en DNS-spørring via UDP port 53 til den lokale DNS-resolveren (konfigurert via DHCP i steg 1). Hvorfor UDP og ikke TCP? Fordi en DNS-spørring er liten (typisk under 512 bytes), den trenger ikke pålitelig levering (prøv bare igjen hvis den ikke kommer), og UDP slipper overhead med forbindelsesoppsett.
Resolveren gjør et iterativt oppslag: den spør rot-serveren om .no, TLD-serveren om ntnu.no, og til slutt den autoritative serveren for selve IP-adressen. I et iterativt oppslag gjør resolveren alt arbeidet — serverne svarer bare «spør heller den». Alternativt kunne resolveren bedt om et rekursivt oppslag, der rot-serveren selv kontakter TLD-serveren, som kontakter den autoritative serveren, og svaret bringes hele veien tilbake. I praksis gjør de fleste resolvere iterative oppslag.
Et viktig poeng: DNS cacher aggressivt. Hvis noen på campus nylig har besøkt ntnu.no, har resolveren svaret i cachen og kan svare umiddelbart uten å kontakte noen andre servere. Selv operativsystemet og nettleseren har egne DNS-cacher. TTL (Time To Live) i DNS-svaret bestemmer hvor lenge cachede svar er gyldige.
En DNS-melding er bare 12 bytes header + spørsmålsseksjonen. Headeren inneholder en transaksjons-ID (for å matche svar med spørsmål), flagg (QR, RD, RA), og tellere for de fire seksjonene: Questions, Answers, Authority, Additional.
De viktigste record-typene: A (IPv4-adresse), AAAA (IPv6-adresse), CNAME (alias — f.eks. www.ntnu.no → ntnu.no), MX (e-postserver for domenet), og NS (autoritativ navneserver for domenet). Hvert svar har en TTL som forteller hvor lenge det kan caches — typisk 300–3600 sekunder.
DNS ble designet uten sikkerhet. En angriper kan utnytte dette med DNS cache poisoning: den sender et falskt svar til resolveren med riktig transaksjons-ID før det ekte svaret ankommer. Nå peker ntnu.no til angriperens server — og resolveren cacher det falske svaret.
Løsningen er DNSSEC (DNS Security Extensions), som legger til digitale signaturer på DNS-svar slik at resolveren kan verifisere at svaret virkelig kom fra den autoritative serveren. I tillegg bruker moderne systemer DNS over HTTPS (DoH) eller DNS over TLS (DoT) for å kryptere selve DNS-trafikken, slik at ingen på nettverket kan se hvilke domener du slår opp.
Nå kjenner vi IP-adressen. Før data kan flyte, må en TCP-forbindelse opprettes.
TCP bruker et three-way handshake for å synkronisere sekvensnumre og bekrefte at begge sider er klare. Begge sider går gjennom definerte tilstander: klienten fra CLOSED → SYN_SENT → ESTABLISHED, serveren fra LISTEN → SYN_RCVD → ESTABLISHED. Ingenting av dette er synlig for deg — nettleseren gjør det automatisk bak kulissene.
Under håndtrykket forhandler partene også viktige parametre: MSS (Maximum Segment Size, typisk 1460 bytes for Ethernet), window scaling (som tillater mottak-vinduer større enn 64 KB), og eventuelt SACK (Selective Acknowledgment, som lar mottakeren fortelle senderen nøyaktig hvilke segmenter den mangler). Startsekvensnumrene er tilfeldige — ikke for kryptografisk sikkerhet, men for å hindre at gamle segmenter fra en tidligere forbindelse feiltolkes som gyldige i en ny.
SYN-pakken inneholder: Source Port (tilfeldig, f.eks. 49152), Dest Port (443 for HTTPS), Sequence Number (tilfeldig startverdi), SYN-flagget satt, og Receive Window (bufferstørrelse). I TCP-headeren er det også plass til Options-feltet der MSS, window scaling og SACK annonseres. Serveren svarer med SYN-ACK: eget sekvensnummer + acknowledgment av klientens sekvensnummer + 1.
Hele håndtrykket tar én RTT (round-trip time) — typisk 10–50 ms innenfor Norge. TCP-headeren er minimum 20 bytes (5 × 32-bit ord), men med options kan den vokse til 60 bytes.
TCP-håndtrykket har en sårbarhet: serveren allokerer ressurser (minne for forbindelsestilstand) allerede ved SYN-ACK, altså før klienten har bekreftet med ACK. En angriper kan utnytte dette med et SYN flood-angrep: send tusenvis av SYN-pakker med falske avsender-IP-er. Serveren svarer med SYN-ACK til adresser som aldri responderer, og alle ventende «halvåpne» forbindelser bruker opp serverens ressurser.
Forsvaret er SYN cookies: i stedet for å lagre tilstand ved SYN-ACK, koder serveren all nødvendig informasjon inn i sekvensnummeret selv. Bare når den endelige ACK-en kommer, allokeres ressurser — og serveren kan verifisere at ACK-en er gyldig uten å ha lagret noe.
TCP-forbindelsen er oppe, men all data ville gått i klartekst. TLS løser det.
Siden du bruker HTTPS (port 443), starter nettleseren en TLS-handshake oppå TCP-forbindelsen. TLS gir tre av de fire sikkerhetsegenskapene: konfidensialitet (data er kryptert), autentisering (vi verifiserer at serveren virkelig er ntnu.no), og meldingsintegritet (data kan ikke endres underveis uten at vi oppdager det). Resultatet er en kryptert tunnel der ingen — hverken nettverket, ISP-en, eller noen på det samme WiFi-nettet — kan lese eller manipulere innholdet.
Kryptografien bruker to forskjellige teknikker: asymmetrisk kryptografi (offentlig/privat nøkkelpar) for å autentisere serveren og utveksle nøkler, og symmetrisk kryptografi (felles hemmelig nøkkel, f.eks. AES) for selve datakrypteringen — fordi symmetrisk er tusenvis av ganger raskere.
Sertifikatet fra ntnu.no inneholder: domenenavnet, serverens offentlige nøkkel, utsteder (CA), gyldighetstid, og en digital signatur fra CA-en. Signaturen beviser at CA-en har verifisert at ntnu.no virkelig kontrollerer dette domenet.
Nettleseren verifiserer via en sertifikatkjede (chain of trust): server-sertifikatet er signert av en mellom-CA, som er signert av en rot-CA som nettleseren har innebygd tillit til. Hvis kjeden er gyldig helt opp til en betrodd rot-CA, er vi trygge.
Nøkkelutvekslingen bruker Diffie-Hellman (ECDHE): begge sider genererer en felles hemmelighet uten å sende den over nettet. Denne brukes til å utlede symmetriske sesjonsnøkler (AES) som krypterer all videre trafikk. I tillegg genereres en MAC-nøkkel (Message Authentication Code) som sikrer integritet — mottakeren kan verifisere at ingen har endret meldingen underveis.
TLS 1.2 krever 2 RTT for handshaken: én for ServerHello og sertifikat, én for nøkkelutveksling og Finished. TLS 1.3 reduserer dette til 1 RTT ved å kombinere nøkkelutveksling med ClientHello — klienten sender sine Diffie-Hellman-parametre allerede i første melding.
TLS 1.3 støtter også 0-RTT resumption: hvis du har besøkt ntnu.no før, kan nettleseren sende kryptert data allerede i første melding ved å bruke en lagret sesjonsnøkkel. Prisen er at 0-RTT-data kan replays — en angriper kan sende den samme meldingen på nytt — men for idempotente operasjoner (som GET) er dette akseptabelt.
TLS 1.3 fjernet også alle usikre krypteringsalgoritmer (RC4, DES, CBC-modus) og krever forward secrecy: selv om serverens private nøkkel kompromitteres i fremtiden, kan ikke tidligere sessjoner dekrypteres fordi Diffie-Hellman-nøklene var midlertidige.
Kryptert tunnel er klar. Nettleseren sender endelig forespørselen om nettsiden.
Inne i TLS-tunnelen sender nettleseren en HTTP GET-forespørsel. HTTP er en tilstandsløs protokoll — serveren husker ingenting mellom forespørsler. Det er ren tekst — men kryptert av TLS, så ingen utenfor kan lese den. Headerne forteller serveren hva vi vil ha, hvem vi er, og hva vi aksepterer.
HTTP definerer flere metoder: GET (hent en ressurs), POST (send data til serveren, f.eks. skjema), HEAD (hent bare headerne, ikke innholdet), og PUT/DELETE (opprett/slett ressurser). For å laste en nettside bruker vi GET. Forbindelsen er persistent (HTTP/1.1 Connection: keep-alive), noe som betyr at vi kan sende mange forespørsler over samme TCP-forbindelse i stedet for å betale TCP-oppsett for hver enkelt ressurs.
HTTP/1.1: Én forespørsel om gangen per TCP-forbindelse (head-of-line blocking). Løses delvis med flere parallelle forbindelser. Persistent connection og pipelining var forbedringer, men pipelining ble sjelden brukt i praksis.
HTTP/2: Multipleksing — mange forespørsler over samme TCP-forbindelse via streams. Binært format i stedet for tekst. Header-komprimering (HPACK). Server push: serveren kan sende ressurser proaktivt før klienten ber om dem. Men: ett TCP-pakketap blokkerer alle strømmer.
HTTP/3 (QUIC): Kjører over UDP i stedet for TCP. Bygger inn TLS 1.3, har 0-RTT resumption, og unngår head-of-line blocking også på transportnivå — hvert stream har sin egen feilhåndtering.
HTTP er tilstandsløst, men mange nettsteder trenger å gjenkjenne deg mellom forespørsler (innlogging, handlekurv, preferanser). Løsningen er cookies. Ved første besøk sender serveren et Set-Cookie: id=abc123-hode. Nettleseren lagrer cookien og sender den automatisk med alle fremtidige forespørsler til samme domene: Cookie: id=abc123.
Serveren bruker cookien til å slå opp sesjonstilstand i sin database. Fire komponenter spiller sammen: Set-Cookie-hode i svaret, Cookie-hode i forespørslene, cookie-fil på klientmaskinen, og database på serveren.
Cookies brukes også til sporing: tredjeparts-cookies (satt av andre domener enn det du besøker) kan følge deg på tvers av nettsteder og bygge en detaljert profil av surfingen din.
Hvis du hadde besøkt ntnu.no nylig, ville nettleseren (eller en proxy-cache) allerede hatt en kopi av siden. I stedet for å hente alt på nytt, sender cachen en betinget GET med headeren If-Modified-Since: <dato>. Hvis innholdet ikke er endret, svarer serveren med 304 Not Modified — en liten melding helt uten innhold — og cachen serverer sin lagrede kopi.
Web-cacher gir to store fordeler: raskere responstid (cachen er ofte nærmere enn serveren) og mindre trafikk på aksesslinken (populært innhold lastes bare ned én gang).
HTTP-meldingen pakkes lag for lag, og finner veien gjennom nettverket ruter for ruter.
Nå skjer den virkelige magien. HTTP-forespørselen — som bare er bytes — pakkes først inn i et TCP-segment, deretter i et IP-datagram, og til slutt i en Ethernet-ramme (eller en WiFi-ramme på den trådløse linken). Denne «russiske dukker»-prosessen kalles enkapsulering. Hvert lag ser bare sin egen header — innholdet er «bare data» fra lagets perspektiv.
Men før Ethernet-rammen kan sendes, må laptopen vite MAC-adressen til neste hopp. Destinasjons-IP-en (129.241.160.100) er utenfor vårt subnett (10.22.14.0/24), så pakken må til default gateway. Laptopen bruker ARP (Address Resolution Protocol) for å finne gatewayens MAC-adresse: den sender en ARP-forespørsel som broadcast («Hvem har IP 10.22.14.1?»), og gatewayen svarer med sin MAC-adresse. Svaret lagres i en ARP-tabell slik at fremtidige pakker ikke trenger ny ARP-forespørsel.
Når en ruter mottar et datagram, slår den opp destinasjons-IP-en i sin forwarding table. Den matcher mot det lengste prefixet (mest spesifikke ruten). Eksempel: Destinasjon 129.241.56.78 matcher både 129.241.0.0/16 og 129.241.56.0/24 — ruteren velger /24 fordi den er mer spesifikk.
For hvert hopp: IP-headeren forblir nesten uendret, men TTL (Time To Live) dekrementeres med 1. Hvis TTL når 0, droppes pakken og ruteren sender en ICMP Time Exceeded-melding tilbake til avsenderen — dette er mekanismen traceroute bruker for å kartlegge ruten. IP-headeren inneholder også et Protocol-felt (6 = TCP, 17 = UDP) og en Header Checksum som reberegnes i hver ruter fordi TTL endres.
For hvert hopp skrives Ethernet-headeren om — ny avsender-MAC og ny mottaker-MAC. ARP brukes for å finne MAC-adressen til neste hopp.
Før pakken når den første ruteren, passerer den typisk en Ethernet-svitsj. En svitsj opererer på lag 2 og videresender rammer basert på MAC-adresser, ikke IP-adresser. Den vedlikeholder en svitsj-tabell (MAC-adressetabell) som mapper MAC-adresser til porter.
Svitsjen lærer tabellen selv: når en ramme ankommer en port, lagrer den avsender-MAC-en. Når en ramme skal videresendes og destinasjons-MAC-en finnes i tabellen, sendes den bare til riktig port (selektiv videresending). Hvis den ikke finnes, floder svitsjen rammen til alle porter unntatt inngangsport — akkurat som en hub, men bare for ukjente adresser.
Svitsjer er transparente — endesystemene vet ikke at de finnes. De krever ingen konfigurasjon og bygger opp tabellen automatisk. Dette kalles selvlæring.
Ethernet-rammens FCS (Frame Check Sequence) er en CRC-32-sjekksum (Cyclic Redundancy Check). Senderen beregner CRC over hele rammen og legger resultatet i FCS-feltet. Mottakeren gjør samme beregning og sammenligner — hvis de ikke matcher, forkastes rammen stille.
CRC er langt kraftigere enn en enkel sjekksum. Den kan oppdage alle burst-feil opptil 32 bit, alle enkelt- og dobbelt-bit-feil, og alle feil med et odde antall flippede bits. Men den kan ikke rette feil — rammen forkastes, og det er opp til TCP å oppdage tapet og sende segmentet på nytt.
Serveren sender nettsiden tilbake — potensielt hundrevis av TCP-segmenter, styrt av congestion control.
Serveren svarer med 200 OK og HTML-innholdet, pluss headere som Content-Type: text/html, Content-Length, og kanskje et Set-Cookie-hode. Andre vanlige statuskoder: 301 (permanent omdirigering), 304 (ikke endret — for betinget GET), 404 (ikke funnet), og 505 (HTTP-versjon ikke støttet).
Men en nettside er for stor for én pakke — den deles opp i mange TCP-segmenter. TCP styrer overføringen med to parallelle mekanismer: flow control (hindrer senderen i å overvelde mottakerens buffer — styrt av rwnd, receive window) og congestion control (hindrer senderen i å overvelde nettverket — styrt av cwnd, congestion window). Sendevinduet er alltid min(cwnd, rwnd).
Slow start: cwnd starter på 1 MSS. For hver ACK dobles vinduet — eksponentiell vekst. Ved ssthresh (slow start threshold) bytter TCP til congestion avoidance: lineær vekst (+1 MSS per RTT). Hele prinsippet kalles AIMD — Additive Increase, Multiplicative Decrease.
Pakketap oppdages på to måter: (1) 3 duplikat-ACK-er: mottakeren sender samme ACK gjentatte ganger fordi den mangler et segment. TCP Reno halverer cwnd og fortsetter (fast recovery). (2) Timeout: ingen ACK i det hele tatt. cwnd settes tilbake til 1 MSS, ssthresh halveres, og ny slow start. TCP bruker kumulative ACK-er: en ACK for bytenummer N bekrefter alle bytes opp til N.
TCP CUBIC (standard i Linux) forbedrer Reno ved å bruke en kubisk funksjon for vinduvekst — den vokser raskt tilbake til nivået der forrige tap skjedde, og deretter forsiktig videre. QUIC forbedrer ytterligere med per-strøm flow control.
Flow control forhindrer at senderen overvelder mottakerens buffer. Mottakeren annonserer sin ledige bufferplass i Receive Window-feltet (rwnd) i hver ACK. Senderen sørger for å aldri ha mer ubekreftede data i flukt enn rwnd tillater.
Hvis mottakerens buffer er full (rwnd = 0), stopper senderen. Men for å unngå deadlock sender den periodisk probe-segmenter (med 1 byte data) slik at mottakeren kan svare med en oppdatert rwnd når plass frigjøres.
Alle bytes er mottatt, HTML parses, og du ser ntnu.no. Alt dette tok under ett sekund.
Nettleseren har nå mottatt all HTML. Den parser dokumentet, oppdager referanser til CSS, JavaScript og bilder, og starter nye HTTP-forespørsler for hver ressurs (over samme TCP/TLS-forbindelse, takket være HTTP/2-multipleksing). Når nok er lastet, rendrer nettleseren siden — og du ser NTNU-forsiden.
Når du lukker fanen eller nettleseren er ferdig, avsluttes TCP-forbindelsen med en 4-veis lukking: klienten sender FIN, serveren bekrefter med ACK, serveren sender sin egen FIN, og klienten bekrefter med ACK. Klienten går deretter inn i TIME_WAIT-tilstand i 2 × MSL (Maximum Segment Lifetime, typisk 60 sekunder) for å sikre at den siste ACK-en kommer frem og at forsinkede segmenter fra den gamle forbindelsen ikke forstyrrer en eventuell ny forbindelse på samme porter.
Her er en typisk tidsfordeling for hele reisen fra Enter til ferdig side:
Du trykket Enter og fikk en nettside. Bak kulissene deltok WiFi (kap 7), DHCP (kap 4), NAT (kap 4), DNS (kap 2), TCP (kap 3), TLS (kap 8), HTTP (kap 2), IP-ruting (kap 4–5), Ethernet/ARP (kap 6), svitsjer (kap 6), og congestion control (kap 3). Hvert lag gjorde sin jobb uavhengig, og sammen leverte de en sømløs opplevelse. Det er kraften i lagdeling.
Hvorfor bruker DNS normalt UDP i stedet for TCP?
Hva er forskjellen mellom flow control (rwnd) og congestion control (cwnd)?
Hva skjer med Ethernet-headeren og IP-headeren når en pakke passerer gjennom en ruter?
Hvorfor bruker TLS både asymmetrisk og symmetrisk kryptografi?