Transportlaget

Svar: Nettverkslaget (IP) gir logisk kommunikasjon mellom verter — IP-adresser identifiserer maskiner. Transportlaget gir logisk kommunikasjon mellom prosesser — portnumre identifiserer applikasjoner på samme maskin.

Hvorfor: En vert kjører mange prosesser samtidig (nettleser, e-post, Spotify), og IP-laget kan bare levere pakken til riktig hus. Transportlaget er Ann og Bill som tar imot posten i hvert hus og deler den ut til riktig søsken. Transportlaget kan legge til pålitelighet og rekkefølge over IP, men kan ikke trylle frem garantier for forsinkelse eller båndbredde — de krever støtte i selve nettet.

Svar: Transportlaget kan tilby pålitelig levering, rekkefølge-garanti, flytkontroll og metningskontroll (TCP), eller minimal tilstandsløs levering (UDP). Det kan ikke garantere lav forsinkelse eller spesifikk båndbredde — uansett protokoll.

Hvorfor: Forsinkelse og båndbredde bestemmes av selve nettverket — av lenker, ruter-kø, og IP-lagets «best effort»-leveranse. Transportlaget kan legge til pålitelighet ved å kompensere for IP (med ACKs, retransmisjon, sekvensnumre), men det kan ikke trylle frem ressurser nettet ikke har. En videosamtale over en treg lenke vil hakke uansett om du bruker TCP eller UDP.

Svar: En UDP-socket identifiseres av et 2-tuppel (dest-IP, dest-port). En TCP-socket identifiseres av et 4-tuppel (kilde-IP, kilde-port, dest-IP, dest-port).

Hvorfor det betyr noe: To UDP-pakker fra ulike klienter til samme dest-port havner i samme socket — UDP bryr seg ikke om hvor de kom fra. For TCP havner de derimot i forskjellige sockets, fordi 4-tuppelet er unikt per forbindelse. Dette er hvorfor en webserver kan ha hundrevis av samtidige TCP-forbindelser, alle på port 80, og holde dem adskilt.

Svar: UDP-headeren er 8 byte og har fire 16-bits felt: source port, dest port, length (header + data) og checksum.

Hvorfor velge UDP: Ingen håndtrykk (sparer en RTT), ingen tilstand (servere håndterer flere klienter), liten header (8 vs. 20+ byte for TCP), og ingen metningskontroll (applikasjonen sender så fort den vil). Det gjør UDP perfekt for DNS, SNMP, sanntidsmedia og HTTP/3 (som bygger pålitelighet selv oppå UDP via QUIC).

Svar: Avsender behandler segmentet (header + data + pseudo-header fra IP) som en sekvens av 16-bits ord, summerer dem med one's complement-addisjon (carry ut fra bit 15 legges tilbake i bit 0), og lagrer one's complement av summen i checksum-feltet. Mottaker gjør samme regnestykke; hvis sjekksummen ikke stemmer, forkastes segmentet.

Svakhet: Sjekksummen oppdager nesten alltid enkelt-bit-feil, men hvis to bits flipper på «motsatt» måte kan de nulle ut hverandre uten å endre summen. Sjekksummen gir altså rimelig sjanse for å oppdage feil, ikke garanti. One's complement velges fordi addisjonen er rekkefølgeuavhengig — enkel å implementere.

Svar: rdt 2.0 brukte ACK/NAK over en kanal med bitfeil — men hadde ingen plan for at selve ACK/NAK-pakken kan bli korrupt. Da vet ikke avsender om mottaker faktisk fikk dataene, og en blind retransmisjon ville skapt udetekterbare duplikater. rdt 2.1 løser dette ved å stemple hver pakke med et sekvensnummer (0/1 holder for stop-and-wait): mottaker oppdager duplikat og kaster det, men sender ACK uansett.

Hvorfor det er nok med 0/1: Med kun én pakke utestående om gangen kan ikke avsender og mottaker komme mer enn ett skritt ut av sync. Sekvensnumre er den minimale ekstra informasjonen som lar de to sidene skille «ny pakke» fra «retransmisjon av forrige».

Svar: rdt 2.2 fjerner NAK helt. I stedet sender mottakeren alltid en ACK — men med sekvensnummeret til den siste korrekt mottatte pakken. Får avsender en ACK med «feil» seq# (en duplikat-ACK), tolker hun det som et NAK og retransmitterer.

Hvorfor TCP bruker dette: TCP kan ikke ha en separat NAK-meldingstype uten å komplisere protokollen — alt skal uansett bæres i samme segment-format. Ved å bruke duplikat-ACK som tap-signal får man feildeteksjon «gratis» i den vanlige ACK-strømmen. Det er nettopp dette som danner grunnlaget for fast retransmit: tre duplikat-ACKer = retransmitter umiddelbart.

Svar: rdt 3.0 utvider rdt 2.2 til en kanal som også kan miste pakker (data eller ACK forsvinner sporløst). Løsningen er en countdown-timer hos avsender — ved timeout retransmitteres pakken.

Fire scenarier håndteres riktig: (a) ingen tap — vanlig drift; (b) datapakke tapt — timeout utløser retransmisjon; (c) ACK tapt — timeout utløser retransmisjon, mottaker oppdager duplikat via seq# og kaster det, men ACKer likevel; (d) for tidlig timeout — avsender retransmitterer unødvendig, mottaker kaster duplikat. Hvorfor det fungerer: sekvensnumrene fra rdt 2.1/2.2 håndterer alle duplikatene timeren kan skape. Protokollen er korrekt, men katastrofalt treg — derav behovet for pipelining.

Svar: Senderens utnyttelse er U = (L/R) / (RTT + L/R).

Eksempel (rdt 3.0): 1 Gbps lenke, RTT = 30 ms, pakker på 8000 bit. Da er L/R = 8 µs og U = 8 µs / 30 008 µs ≈ 0,00027 — 0,027 %. 99,97 % av tiden står senderen og venter.

Hvorfor: Stop-and-wait holder kun én pakke i flyt om gangen; resten av rør-volumet (bandwidth-delay product) ligger ubrukt. Det er protokollen, ikke nettverket, som er flaskehalsen. Løsningen er pipelining.

Svar: Pipelining lar avsender ha flere ubekreftede pakker i nettet samtidig — «fyller røret» i stedet for å vente på ACK mellom hver pakke.

Krav: (1) Sekvensnummer-rommet må være større, fordi flere pakker kan være i flyt samtidig. (2) Avsender må buffre alle ubekreftede pakker for mulig retransmisjon. (3) Mottaker kan trenge å buffre out-of-order pakker. (4) Det må finnes regler for hva som retransmitteres ved tap. Dette gir to hovedstrategier: Go-Back-N og Selective Repeat.

Svar: GBN bruker kumulative ACKs — ACK(n) bekrefter alt opp til og med pakke n — og én retransmisjons-timer for eldste ubekreftede pakke. Mottakeren godtar bare in-order pakker; out-of-order kastes og siste in-order ACK gjentas. Ved timeout retransmitterer avsender hele vinduet fra eldste ubekreftede pakke og fremover.

Hvorfor designet sånn: Mottakeren slipper å buffre noe — billig og enkelt. Prisen betales på sendersiden: ett tap utløser potensielt mange unødvendige retransmisjoner. Det fungerer godt på lavfeil-lenker, men sløser båndbredde når feilraten øker.

Svar: SR bruker individuell ACK per pakke (ikke kumulativ), én timer per ubekreftet pakke, og mottakeren buffrer out-of-order pakker. Ved timeout retransmitteres bare den ene tapte pakken.

SR-dilemmaet: Hvis sekvensnummer-rommet er for lite, kan ikke mottakeren skille en helt ny pakke fra en retransmisjon av en gammel. Vinduregelen: SR krever vindusstørrelse N ≤ 2^(k−1), mens GBN tillater N ≤ 2^k − 1 (k = antall bit i seq#-feltet). SR betaler altså med halvert vindu mot mer effektiv håndtering av tap.

Svar: Sentrale felt: source/dest port (mux/demux), sequence number (32 bit, byte-offset i strømmen), ACK number (32 bit, neste forventede byte), HLen (header-lengde i 4-byte ord), flags (SYN, ACK, FIN, RST, PSH, URG, m.fl.), receive window (rwnd, 16 bit, flow control), checksum, og options (MSS, window scale, timestamps).

Hvorfor ingen payload length: Lengden utledes fra IP-laget: payload = IP_total − IP_header − TCP_header. TCP gjenbruker IP-headerens informasjon i stedet for å duplisere den.

Svar: SYN — synchronize, brukes til å initiere en forbindelse (sette sekvensnummer). ACK — segmentet inneholder en gyldig ACK-nummerverdi. FIN — finish, avsender har sendt sin siste byte og vil lukke retningen. RST — reset, abort forbindelsen umiddelbart (ofte ved feil eller forsøk på å koble til en lukket port). PSH — push, mottakerens TCP bør levere data umiddelbart til applikasjonen i stedet for å buffre. URG — urgent, peker på «hastedata» i segmentet via Urgent Pointer.

Hvorfor det er greit å kunne: Flaggene styrer hele forbindelsens livssyklus. SYN+ACK gjenkjennes som andre del av håndtrykket, FIN+ACK i lukkesekvensen, og RST forklarer hvorfor «connection refused» er øyeblikkelig — serveren svarer aktivt med RST, ikke bare timeout. PSH og URG brukes sjelden i praksis, men er en del av protokollen.

Svar: TCP behandler dataene fra applikasjonen som en kontinuerlig strøm av bytes uten meldingsgrenser. Hvis applikasjonen kaller send() tre ganger med 100 bytes hver, kan TCP sende dem som ett 300-byte segment, eller dele dem opp på en helt annen måte. UDP, derimot, bevarer meldingsgrenser: hver sendto() blir nøyaktig ett UDP-datagram hos mottakeren.

Konsekvens: Applikasjonsutvikleren må selv avgrense meldinger over TCP — typisk med en lengde-prefix (HTTP Content-Length), en avslutter (HTTP linjeskift, JSON-objektgrenser), eller en sentinel. Hvorfor TCP er designet sånn: Bytestrøm-modellen lar TCP optimalisere når den vil sende (Nagle's algorithm, MSS-fyll) uten å tenke på applikasjonens meldingsstruktur.

Svar: Senderens tre hendelser er: (1) Data fra app — bygg segment med seq=NextSeqNum, send, oppdater pekere, start timer hvis ingen aktiv. (2) Timeout — retransmitter eldste ubekreftede segment, restart timer. (3) ACK med y > SendBase — flytt SendBase fram, restart timer hvis flere ubekreftede gjenstår, ellers stopp den.

Hvorfor én timer: Den naive idéen om én timer per pakke skalerer dårlig — en travel server med tusenvis av forbindelser ville hatt millioner av aktive timere samtidig. TCP velger derfor å la timeren alltid følge eldste ubekreftede pakke (SendBase). Det er en bevisst kompromiss: enkelt og billig, men noe tregere reaksjon på tap enn Selective Repeats per-pakke-timere.

Svar: MTU (Maximum Transmission Unit) er den største rammen lenkelaget kan bære (typisk 1500 byte for Ethernet). MSS (Maximum Segment Size) er den største applikasjonsdataen som får plass i ett TCP-segment — vanligvis MSS = MTU − 20 (IP) − 20 (TCP) = 1460 byte. MSS forhandles i SYN-pakkene under håndtrykket.

Hvorfor det er viktig: Hvis MSS settes høyere enn MTU på en lenke underveis, må IP-laget fragmentere segmentet — ekstra overhead, høyere taps-sannsynlighet (én tapt fragment = hele datagrammet retransmitteres) og generelt vondt for ytelsen. Korrekt MSS holder TCP-segmenter innenfor stien.

Svar: Sekvensnummeret i et TCP-segment er offsetten i bytestrømmen til første byte i segmentets nyttelast — det teller bytes, ikke pakker. ACK-nummeret y betyr «alle bytes opp til og med byte y−1 er mottatt; jeg venter på byte y».

Hvorfor det er robust: Kumulativ ACK gjør at en tapt ACK ofte ikke betyr noe — neste ACK overstyrer den (ACK=1000 dekker alt før byte 1000, så en tidligere tapt ACK=600 spiller ingen rolle). Avsender slipper å starte timeren på nytt for hver delvis kvittering, og protokollen tåler godt tap av enkelt-ACKs.

Svar: TCP fører et glidende gjennomsnitt (EWMA) av målte RTT-er:
EstimatedRTT = (1−α) · EstimatedRTT + α · SampleRTT — typisk α = 0,125.
Og et glidende gjennomsnitt av avviket:
DevRTT = (1−β) · DevRTT + β · |SampleRTT − EstimatedRTT| — typisk β = 0,25.
Timeout: TimeoutInterval = EstimatedRTT + 4 · DevRTT.

Hvorfor 4·DevRTT: Marginen utvider seg automatisk når RTT svinger mye, og krymper når nettet er stabilt. For lav timeout → unødige retransmisjoner; for høy → seig respons på tap. EWMA gir et stabilt estimat uten å lagre alle målinger.

Svar: Når et TCP-segment kommer ut-av-rekkefølge til mottakeren, sender hun en duplikat-ACK med samme «forventet byte»-nummer som før. Etter tre duplikat-ACKer for samme byte konkluderer avsender at segmentet er tapt og retransmitterer det umiddelbart, uten å vente på timeout.

Hvorfor 3: Pakker kan komme ut-av-rekkefølge selv uten tap (ulike ruter gjennom nettet), og det vil typisk gi 1–2 duplikat-ACKer. Tre er en empirisk balanse — strengt nok til å unngå falske retransmisjoner, lavt nok til å reagere før timeout-timeren (som kan være hundretalls millisekunder) løper ut.

Svar: Flytkontroll hindrer at avsender oversvømmer mottakerens mottaksbuffer (en helt annen ting enn metningskontroll, som beskytter nettverket). Mottakeren annonserer i hver header sin ledige bufferplass — rwnd (Receive Window). Avsender holder mengden ubekreftet data i nettet ≤ rwnd.

Begrensning: rwnd-feltet er bare 16 bit, altså maks 64 KB — for lite på «long fat networks» (høy båndbredde × høy RTT). Løsningen er Window Scale-opsjonen, som forhandles i SYN-pakkene og kan skalere rwnd opp til ~1 GB. Den må med i håndtrykket; ikke senere.

Svar: (1) Klient → Server: SYN, seq=x. (2) Server → Klient: SYN+ACK, seq=y, ack=x+1. (3) Klient → Server: ACK, ack=y+1 (kan piggyback'e applikasjonsdata). Etter dette er begge sider i ESTABLISHED, og sekvensnumre er synkronisert i begge retninger.

Hvorfor tre meldinger: Toveis ville ikke kunne skille en ny SYN fra et forsinket gammelt SYN-duplikat — serveren risikerte å åpne en forbindelse alene (halvåpen, sårbar for SYN-flood) eller å akseptere gamle data som nye. Den tredje meldingen er klientens bevis på at hun lever nå og at serverens valgte startsekvensnummer er bekreftet. Tilfeldige startsekvenser hindrer i tillegg at gamle forbindelsers data forveksles med nye.

Svar: Lukking krever fire meldinger fordi TCP er full duplex og hver retning lukkes separat: (1) part A sender FIN, (2) B svarer ACK (A→B-retningen er nå lukket, B kan fortsatt sende), (3) når B er ferdig sender den FIN, (4) A svarer ACK. Etter siste ACK går A inn i TIME_WAIT og venter typisk 2 × MSL (Maximum Segment Lifetime, ofte 30 s–2 min) før porten frigis.

Hvorfor TIME_WAIT: Hvis As siste ACK forsvinner, vil B retransmittere FIN. Da må A fortsatt være tilgjengelig for å re-ACKe. Uten TIME_WAIT kunne en ny forbindelse på samme portpar fått en gammel FIN/ACK feiltolket som sin egen — TIME_WAIT garanterer at alle gamle pakker er døde før portene gjenbrukes.

Svar: CUBIC er en moderne metningskontroll-variant som lar cwnd være en kubisk funksjon av tid siden siste tap, ikke RTT som i Reno. Etter et tap husker den W_max (cwnd ved siste tap), vokser raskt langt fra W_max, sakte når den nærmer seg, og sonderer forsiktig forbi.

Hvorfor den slo Reno: Renos lineære AIMD bruker for lang tid på å gjenoppta full kapasitet etter et tap på lenker med stor BDP (bandwidth-delay product) — moderne datasenter- og fiberlenker. CUBIC når raskt opp igjen til der det ble galt sist, og er samtidig RTT-uavhengig, så den oppfører seg likere mellom korte og lange lenker. Standard i Linux fra 2006 og dominerer trafikken til store webservere.

Svar: End-to-end: endesystemene utleder selv om nettet er overbelastet, basert på indirekte signaler som tap (timeout eller dup-ACK) og økt RTT. Rutere er passive. Nettverksassistert: rutere gir endesystemene eksplisitt tilbakemelding om metning.

Hvorfor TCP er end-to-end: TCP kjører over IP, som ikke garanterer noen ruterstøtte for feedback. Ved å utlede metning fra tap alene, fungerer TCP overalt — selv gjennom rutere som ikke samarbeider. CUBIC og lignende moderne varianter er fortsatt fundamentalt end-to-end.

Svar: Senderens lov: LastByteSent − LastByteAcked ≤ min(cwnd, rwnd). Det vil si: mengden ubekreftet data i nettet kan aldri overstige det minste av congestion window (nettets toleranse) og receive window (mottakerens buffer). Senderens effektive rate er da omtrent cwnd / RTT bytes per sekund (i steady state, når rwnd ikke binder).

Hvorfor formelen er den sentrale: Hele metningskontrollen handler om å justere cwnd slik at cwnd / RTT ligger nær flaskehalsens kapasitet — «keep the pipe just full, but not fuller». For lite cwnd → ubrukt båndbredde. For stor cwnd → kø bygges opp i flaskehalsruteren, RTT øker, og til slutt kommer pakketap. cwnd er altså sender-sidens forsøk på å estimere et tall den aldri direkte kan måle.

Svar: Slow start starter med cwnd = 1 MSS. For hver mottatte ACK økes cwnd med 1 MSS, slik at cwnd dobles per RTT — eksponentiell vekst. Når cwnd ≥ ssthresh går TCP over til congestion avoidance, der cwnd vokser lineært med 1 MSS per RTT (additive increase).

Hvorfor: Slow start er ikke «slow» — den er rask, men starter veldig lavt. Idéen er å finne nettets kapasitet kjapt før vi sonderer forsiktig. ssthresh er TCPs minne om hvor det gikk galt sist (settes typisk til cwnd/2 ved tap), så neste oppstart bremser før vi treffer samme tak. Ved timeout settes cwnd = 1 MSS og slow start begynner på nytt.

Svar (AIMD): Additive Increase, Multiplicative Decrease. cwnd vokser lineært (+1 MSS per RTT) under congestion avoidance, og halveres ved tap. Dette gir det karakteristiske «sagtann»-mønsteret og konvergerer mot rettferdig deling av flaskehalsen.

Tahoe vs. Reno: Begge halverer ssthresh ved tap. Tahoe behandler alle tap likt: cwnd = 1 MSS, slow start på nytt. Reno skiller: ved 3 dup-ACK setter den ssthresh = cwnd/2, cwnd = ssthresh + 3 MSS og går rett inn i fast recovery (hopper over slow start). Ved timeout oppfører Reno seg som Tahoe. Reno kommer seg derfor mye raskere etter et enkelt tap fordi tre dup-ACK indikerer at nettet fortsatt fungerer — det er ingen grunn til å starte fra cwnd = 1.

Svar: To TCP-strømmer som deler samme flaskehals øker begge cwnd lineært (langs en 45°-linje i et 2D-plot) til de treffer kapasiteten og taper en pakke. Da halveres begges cwnd (mot origo). Repeterer man dette, konvergerer de mot lik andel R/K hver — additive increase trekker dem mot likhet, multiplicative decrease bevarer forholdet.

Når det svikter: Forutsetningene er sjeldent oppfylt i praksis. (1) Forbindelser med kortere RTT får urettferdig stor andel — de vokser fortere. (2) UDP følger ikke metningskontroll og kan ta hva den vil. (3) En nettleser med 10 parallelle TCP-forbindelser får 10× sin «rettferdige» andel. Det finnes intet «internett-politi» som tvinger fram fairness.

Svar: QUIC (RFC 9000, grunnlag for HTTP/3) flytter pålitelighet, metningskontroll, kryptering og multipleksing opp i applikasjonslaget oppå UDP. Det løser fire ting: (1) Håndtrykk: TCP+TLS = 2 RTT; QUIC kombinerer det til 1 RTT, og 0 RTT ved gjentilkobling. (2) Head-of-line blocking: i HTTP/2 over TCP blokkerer ett tap alle multipleksede forespørsler, fordi TCP er én bytestrøm. QUIC har uavhengige streams med egne seq# — tap i én stream stopper ikke de andre. (3) Mobilitet: TCP identifiserer forbindelsen via 4-tuppelet, så bytte fra Wi-Fi til mobil bryter den. QUIC bruker en connection ID som overlever IP-endring. (4) Oppdaterbarhet: TCP-stack ligger i OS-kjernen og oppdateres tregt; QUIC ligger i applikasjonen og kan rulle ut nye metningskontroll-algoritmer raskt.

Hvorfor UDP: Mellomboksene (NAT, brannmurer) på Internett godtar bare TCP og UDP. Å bygge en helt ny transportprotokoll i kjernen ville vært umulig å rulle ut globalt — å maskere QUIC som UDP er den pragmatiske utveien.