Øvingseksamen 2

Riktig svar: B

Innkapsling går nedover lagene: applikasjonsdataen (HTTP-meldingen) blir TCP-segment når TCP-headeren legges på, deretter IP-pakke når IP-headeren legges på, og til slutt Ethernet-ramme når MAC-headeren og fottegnet (FCS) legges på.

Hvert lag legger sin egen header utenpå dataenheten fra laget over (payload). Hos mottakeren skjer det motsatte — hvert lag fjerner sin header og leverer payload til neste lag.

Pensum: Kap. 1 — Lagdelt arkitektur og innkapsling

Riktig svar: D — 50 Mbps

For en serie av linker er ende-til-ende gjennomstrømning bestemt av flaskehals-linken — den linken med lavest kapasitet: min(100, 50, 200) = 50 Mbps.

Linkene er ikke parallelle, så kapasitetene summeres ikke. Pakker må passere hver link i tur og orden, og den tregeste linken setter grensen for hele stien.

Pensum: Kap. 1 — Gjennomstrømning og flaskehalslink

Riktig svar: B

Med persistent connections holdes TCP-forbindelsen åpen etter første forespørsel — påfølgende objekter kan hentes uten ny handshake. Med pipelining kan klienten sende flere forespørsler i strøm uten å vente på svar mellom hver, noe som reduserer total tid betydelig.

A og D beskriver non-persistent HTTP (HTTP/1.0-standard, hvor hver objektnedlasting krevde sin egen TCP-handshake). C er feil — HTTP/1.x kjører over TCP.

Pensum: Kap. 2 — HTTP persistent vs. non-persistent

Riktig svar: D

En autoritativ DNS-server er den serveren som har den definitive informasjonen om et domene — den som "eier sannheten" om hvilke IP-adresser navnene i domenet peker til. NTNU drifter sine egne DNS-servere og er autoritative for navn under ntnu.no.

DNS-roten kjenner kun TLD-serverne. TLD-serveren for .no peker videre til NTNUs autoritative server. Den lokale DNS-serveren cacher svar og fungerer som mellomledd, men er ikke autoritativ.

Pensum: Kap. 2 — DNS-hierarkiet

Riktig svar: B — 1500

TCP bruker kumulative ACK: feltet "Acknowledgment number" inneholder sekvensnummeret for neste byte mottakeren forventer. Hvis byte 1000–1499 nettopp er mottatt, er neste forventede byte 1500, så ACK-verdien er 1500.

Dette er en vanlig feil — mange tror ACK-verdien er sekvensnummeret til den siste mottatte byten. Det er sekvensnummeret til den neste forventede.

Pensum: Kap. 3 — TCP sekvens- og kvitteringsnummer

Riktig svar: B

I slow start økes cwnd med 1 MSS for hver ACK som mottas. Siden hele cwnd vanligvis kvitteres innenfor én RTT, fører dette til en eksponentiell vekst — cwnd dobles per RTT.

C beskriver congestion avoidance-fasen, hvor cwnd økes med 1 MSS per RTT (lineær vekst). A skjer ved en triple-duplicate ACK i TCP Reno (cwnd halveres). Slow start startes på nytt med cwnd = 1 MSS ved en timeout.

Pensum: Kap. 3 — TCP metningskontroll, slow start og congestion avoidance

Riktig svar: B

IPv4-adresserommet (2³² ≈ 4,3 milliarder) ble offisielt brukt opp i 2011 hos IANA. IPv6 utvider til 128 bit (2¹²⁸ ≈ 3,4 × 10³⁸) — nok adresser til at hver kvadratmillimeter på jordoverflaten kan ha milliarder.

A er feil — IPv6-headeren er faktisk lengre (40 byte fast) enn typisk IPv4-header (20 byte). C er feil — IPv4 og IPv6 er ikke direkte interoperable; tunneling og dual-stack-løsninger trengs i overgangen.

Pensum: Kap. 4 — IPv6

Riktig svar: B

En NAT-ruter har én (eller få) offentlig IPv4-adresse på WAN-siden og bruker en privat adresseblokk (typisk 192.168.0.0/16 eller 10.0.0.0/8) på LAN-siden. NAT-tabellen mapper kombinasjoner av (intern IP, intern port) ↔ (ekstern IP, ekstern port). Når en pakke går ut, oversettes kildeadresse og kildeport; når svaret kommer tilbake, slås det opp i tabellen og pakken videresendes til riktig intern enhet.

NAT bidrar til å spare IPv4-adresser, men bryter prinsippet om end-to-end adressering og kompliserer protokoller som forventer å se ekte IP-adresser.

Pensum: Kap. 4 — NAT

Riktig svar: B

I en link-state-algoritme (f.eks. OSPF) flooder hver ruter informasjon om sine egne lenker til alle rutere. Hver ruter bygger en fullstendig topologi-graf og kjører Dijkstras algoritme lokalt for å finne korteste vei. Beslutninger er sentrale i den forstand at hver ruter har global oversikt.

I en distance-vector-algoritme (f.eks. RIP) kjenner ruteren kun "kostnaden til hver destinasjon via hver nabo", basert på det naboene har fortalt. Dette er en distribuert iterativ Bellman-Ford-prosess. Den krever mindre informasjon per ruter, men kan være sårbar for "count-to-infinity"-problemer.

Pensum: Kap. 5 — Rutingalgoritmer

Riktig svar: B

Preamblet (7 byte med 10101010 + 1 byte SFD-mønster) er et alternasjonsmønster som vekker mottakerens fysiske lag og lar klokken til mottakerens NIC låses til senderens bit-takt. Uten dette vil mottakeren risikere å lese bitene på feil tidspunkt.

CRC ligger i FCS-feltet på slutten av rammen. MAC-adresser ligger i sine egne felt. Standard Ethernet-rammer har ikke et eget prioritets-/QoS-felt (det finnes utvidelser, f.eks. 802.1Q-tagger, men ikke som del av basis-rammeformat).

Pensum: Kap. 6 — Ethernet-rammeformat

Riktig svar: C

En lærende svitsj vedlikeholder en switch table (MAC-tabell) som mapper MAC-adresser til porter. Hver gang en ramme ankommer, lærer svitsjen at "kilde-MAC X finnes på port Y" — dermed bygges tabellen automatisk over tid.

Når destinasjons-MAC er kjent i tabellen: svitsjen sender rammen kun ut på den porten der destinasjonen er. Dette kalles selective forwarding.

A skjer kun når destinasjons-MAC ikke er kjent (eller for broadcast).

Pensum: Kap. 6 — Lærende svitsjer

Riktig svar: B

I 802.11 sender og mottar samme antenne — typisk halv-dupleks. Senderens eget signal er flere størrelsesordener kraftigere enn et innkommende signal fra en annen stasjon, så mottakerelektronikken «overdøves» mens man sender. Det er derfor umulig å pålitelig detektere kollisjoner samtidig som man sender (CD).

I tillegg finnes problemet med "skjulte terminaler" — to stasjoner kan være utenfor hørevidde av hverandre, men begge innenfor hørevidde av samme aksesspunkt. Begge tror mediet er ledig og kolliderer hos AP.

Løsningen er collision avoidance: stasjoner venter en tilfeldig backoff selv når mediet er ledig (DIFS + tilfeldig contention window), bruker positive ACK-er for å bekrefte mottak, og kan eventuelt bruke RTS/CTS for å reservere mediet.

Pensum: Kap. 7 — CSMA/CA i 802.11

Riktig svar: B

Et sertifikat inneholder en entitets offentlige nøkkel og er signert av en CA. Klienten har CA-ens offentlige nøkkel forhåndsinstallert (i nettleserens "trust store") og kan dermed verifisere signaturen. Hvis signaturen er gyldig, kan klienten stole på at den offentlige nøkkelen i sertifikatet faktisk tilhører den listede serveren — og ikke en angriper i et MITM-scenario.

Selve krypteringen i TLS skjer med symmetriske nøkler etter handshake. Sertifikater løser det grunnleggende problemet med autentisitet av offentlige nøkler.

Pensum: Kap. 8 — TLS, sertifikater og PKI

Riktig svar: B

I DASH blir videoen kodet inn i flere bitrater (f.eks. 360p, 720p, 1080p). Serveren tilbyr en manifestfil som lister tilgjengelige chunker (typisk noen sekunder hver) for hver kvalitet. Klienten måler nedlastningshastigheten i sanntid og velger neste chunk fra den kvaliteten som passer best — høyere ved god båndbredde, lavere ved redusert.

Dette gjør at intelligensen ligger hos klienten (server-stateless), at innholdet kan distribueres via vanlige HTTP-cacher/CDN-er, og at brukeren får jevn avspilling uten frosset video selv ved varierende nettverkskvalitet.

Pensum: Kap. 9 — DASH og adaptiv streaming

a) Minimum nedlastningstid:

Ende-til-ende gjennomstrømning ≤ flaskehals = min(100, 25, 80) Mbps = 25 Mbps

Filstørrelse: 50 MB = 50 × 8 × 10⁶ = 400 × 10⁶ bits

Tid = bits / rate = 400 × 10⁶ / 25 × 10⁶ = 16 sekunder

b) Hvorfor er faktisk nedlasting tregere?

1. TCP slow start: Senderens cwnd starter på 1 MSS og dobles per RTT til den når terskelen for congestion avoidance. Med RTT på 150 ms tar det flere sekunder før senderen når full kapasitet — særlig betydelig på små/mellomstore filer eller "fat-long" lenker.
2. Køforsinkelse og pakketap: Andre brukere kan kø opp i samme rutere; pakketap fører til retransmisjoner og reduksjon av cwnd. Med stor RTT er hver retransmisjon dyr.
3. Båndbredde-forsinkelses-produkt og rwnd: Hvis mottakerens annonserte vindu (rwnd) er for lite, eller socketens send-/mottaksbuffer er for små i forhold til BDP = kapasitet × RTT, vil senderen bli tomgangsbegrenset uavhengig av kapasiteten.
4. (Andre gyldige svar: forsinkelse i TCP-handshake, ekstra RTT for DNS-oppslag, oppstart av TLS, m.m.)

Pensum: Kap. 1 — Gjennomstrømning · Kap. 3 — TCP slow start

a) cwnd-utvikling:

1. Slow start: cwnd dobles per RTT (1 → 2 → 4 → 8 → 16). Etter 4 RTT-er når cwnd ssthresh = 16 MSS.
2. Overgang til congestion avoidance: Vekst går fra eksponentiell til lineær — cwnd øker med 1 MSS per RTT (16 → 17 → 18 → … → 24).
3. Triple duplicate ACK ved cwnd = 24 (TCP Reno — fast recovery):
   • ssthresh settes til cwnd / 2 = 12 MSS
   • cwnd settes til ssthresh = 12 MSS (multiplicative decrease)
   • Senderen fortsetter i congestion avoidance (lineær vekst) fra cwnd = 12 MSS

Ved et timeout i stedet for triple duplicate ACK ville cwnd vært satt til 1 MSS og slow start startet på nytt.

b) TCP Tahoe vs. Reno ved triple duplicate ACK:

	Tahoe	Reno
ssthresh	cwnd / 2	cwnd / 2
cwnd settes til	1 MSS (slow start fra start)	ssthresh (fast recovery / fast retransmit)
Resultat	Konservativ — full slow start	Mindre dramatisk — fortsetter i congestion avoidance

Tanken bak Reno: triple duplicate ACK betyr at noen pakker fortsatt kommer frem (mottakeren genererer ACK-er), så nettverket er ikke totalt overbelastet — full slow start er overdrevent.

c) Reduksjon ved timeout og rettferdighet:

Et timeout indikerer alvorlig metning (pakkene kommer ikke frem). TCP «backer av» kraftig — cwnd settes til 1 og slow start startes — for å gi nettverket tid til å tømmes.

Rettferdighet kommer av AIMD (Additive Increase, Multiplicative Decrease): alle TCP-flows som deler en flaskehals, øker cwnd lineært ved suksess og halverer ved tap. Over tid konvergerer flowsene mot lik andel av kapasiteten — uavhengig av når de startet.

Pensum: Kap. 3 — TCP metningskontroll, AIMD, fast retransmit/recovery

a) Prefikslengde og størrelse:

4 subnett krever 2² = 4 → 2 ekstra bits. Ny prefikslengde: /22 + 2 = /24

Hvert subnett har 2³²⁻²⁴ = 2⁸ = 256 adresser (hvorav 254 er brukbare verter, etter at nettverks- og broadcast-adresse er reservert).

b) Subnetter:

/22 dekker områder med tredje oktett 0–3 (siden 22 = 16 + 6 betyr de første 6 bits av tredje oktett er fastlåst → variasjon i de siste 2 bits, som gir 0, 1, 2, 3).

Subnett	Nettverk	Første brukbar	Siste brukbar	Broadcast
1	10.50.0.0/24	10.50.0.1	10.50.0.254	10.50.0.255
2	10.50.1.0/24	10.50.1.1	10.50.1.254	10.50.1.255
3	10.50.2.0/24	10.50.2.1	10.50.2.254	10.50.2.255
4	10.50.3.0/24	10.50.3.1	10.50.3.254	10.50.3.255

c) Longest prefix match-oppslag:

• 10.50.0.55 — matcher 10.50.0.0/24 (lengste prefiks: 24 bits) og også 10.50.0.0/22 (22 bits). Lengst vinner → port 1.
• 10.50.2.200 — matcher 10.50.0.0/22 (22) og 10.50.2.0/23 (23). Lengst → port 3.
• 10.50.3.10 — matcher 10.50.0.0/22 (22) og 10.50.2.0/23 (23, fordi /23 dekker 10.50.2.0–10.50.3.255). Lengst → port 3.
• 192.168.1.1 — matcher kun 0.0.0.0/0 → port 4 (default).

Pensum: Kap. 4 — Subnetting, longest prefix matching

a) Sammenligning Ethernet vs. 802.11:

	Ethernet (802.3)	WiFi (802.11)
Medium access	CSMA/CD — lytt før send, oppdag kollisjon, jam og backoff	CSMA/CA — lytt før send, vent random backoff selv ved ledig medium, ingen kollisjonsdeteksjon under sending
ACK på L2	Nei — kollisjon detekteres direkte	Ja — mottakeren sender ACK etter SIFS; mangler ACK ⇒ retransmisjon
Rammeformat	Preamble + dest-MAC + src-MAC + EtherType + payload + FCS	Mer kompleks — frame control, durasjon, opptil fire MAC-adresser, sekvensnummer, payload, FCS
Halvdupleks/fullduplex	Moderne svitsjet Ethernet er fullduplex (ingen kollisjoner)	Halvdupleks per kanal
Mediepålitelighet	Lav feilrate (kobber/fiber)	Høy — interferens, fading, hindringer

Hvorfor ACK på L2 i WiFi: feilrate er mye høyere på radiomediet, og det er ineffektivt å la transportlaget retransmittere etter timeout (sekunder) når lenkelaget kan rette opp innen millisekunder.

b) Skjult terminal og RTS/CTS:

Skjult terminal-problemet oppstår når to stasjoner A og C er utenfor hverandres rekkevidde, men begge er innenfor rekkevidden til samme aksesspunkt B. Når A sender til B, hører ikke C noe og oppfatter mediet som ledig; C kan dermed begynne å sende samtidig — pakkene kolliderer hos B. Verken A eller C oppdager direkte at de "kolliderer", siden CSMA/CA ikke gjør collision detection.

RTS/CTS-løsning:

1. A sender en kort RTS-ramme til B med ønsket sendetid.
2. B svarer med en CTS-ramme som inneholder reservasjonstiden.
3. CTS-en høres av alle stasjoner innenfor B's rekkevidde — inkludert C, selv om C ikke hørte RTS-en.
4. Alle som hører CTS, holder seg stille i den annonserte tiden (NAV — Network Allocation Vector).

Slik unngås kollisjoner forårsaket av skjulte terminaler. RTS/CTS er valgfritt og brukes typisk kun for store rammer (overhead på små rammer er for høyt).

Pensum: Kap. 6 — Ethernet · Kap. 7 — 802.11, skjult terminal, RTS/CTS

a) TLS-handshake (forenklet):

1. ClientHello: Klienten sender støttede TLS-versjoner, cipher suites og en tilfeldig client nonce.
2. ServerHello + sertifikat: Serveren velger cipher suite, sender sin egen nonce og sender et X.509-sertifikat med sin offentlige nøkkel.
3. Klient verifiserer sertifikatet: ved hjelp av en kjent CA-rotnøkkel — autentiserer serveren.
4. Premaster-utveksling: Klienten genererer et "premaster secret" og sender det kryptert med serverens offentlige nøkkel (RSA-handshake), eller partene kjører en Diffie–Hellman-utveksling for å opprette et delt premaster secret.
5. Avledning av sesjonsnøkler: Begge partene utleder symmetriske krypterings-/MAC-nøkler fra premaster + nonces ved en KDF.
6. Finished-meldinger: Begge sender en MAC over alle tidligere handshake-meldinger — bekrefter at ingen har manipulert handshaken.

Etter dette krypteres all videre kommunikasjon med de symmetriske sesjonsnøklene — som er mye raskere enn asymmetrisk kryptografi.

b) Sikkerhetsegenskaper TLS gir over HTTP:

1. Konfidensialitet — payload krypteres så mellomledd ikke kan lese innholdet.
2. Integritet — MAC-sjekk avslører enhver modifikasjon underveis.
3. Autentisering av server (og evt. klient) — sertifikatkjeden gir kryptografisk bevis på identitet.

c) Hvordan CDN reduserer forsinkelse:

1. Geografisk nærhet: Innhold cacheres på CDN-noder nær brukeren, så fysisk avstand og dermed propagasjonsforsinkelse reduseres.
2. Avlasting av origin-server og bedre lokal kapasitet: CDN-nodene har høy kapasitet, så flaskehals fjernes; samtidig avlastes opprinnelses-serveren — ingen lange RTT-er over kontinenter for hvert objekt.
3. (Andre gyldige svar: TCP-slow-start "starter på nytt" på en geografisk nærmere node og får raskere oppstart; bedre inter-domain ruting via CDN-overlay.)

d) DASH + CDN:

DASH-chunker er statiske HTTP-objekter — de cacheres godt på CDN-noder. Når en bruker spiller av en video, hentes hver chunk fra nærmeste CDN-node (rask). Klienten kan adaptivt velge bitrate basert på målt kapasitet til den noden, og selv om mange seere ser samme video samtidig, treffer mesteparten av forespørslene CDN-cachen i stedet for opprinnelses-serveren.

Pensum: Kap. 8 — TLS · Kap. 9 — DASH og CDN