Øvingseksamen 5

Riktig svar: C

Throughput måler alle bits som passerer et målepunkt — inkludert TCP/IP-headere, retransmisjoner og kontrolltrafikk. Goodput er den delen som faktisk er nyttig applikasjonsdata. Hvis 10 % av trafikken er retransmisjoner og headere, kan throughput være 100 Mbps mens goodput er ca. 90 Mbps.

Skillet er viktig når man vurderer effektiv ytelse for brukeren — en lenke kan ha høy throughput, men dårlig goodput hvis mye båndbredde brukes på pakker som må sendes på nytt.

Pensum: Kap. 1 — Gjennomstrømning

Riktig svar: B

Når bufferen er full, må ruteren forkaste en pakke — typisk den siste som kom inn (tail drop), eller en eldre etter mer avanserte køstrategier (f.eks. RED). Dette er hva man kaller pakketap pga. overbelastning.

Rutere selv signaliserer ikke retransmisjoner; det er endesystemet (TCP) som senere oppdager tapet og sender på nytt. UDP-applikasjoner har ingen automatisk retransmisjon og må selv håndtere tap.

Pensum: Kap. 1 — Køforsinkelse og pakketap

Riktig svar: B — 301 Moved Permanently

HTTP-statuskoder er gruppert i klasser etter første siffer:

• 2xx Suksess (200 OK, 204 No Content)
• 3xx Omdirigering (301 Moved Permanently, 302 Found)
• 4xx Klientfeil (400 Bad Request, 404 Not Found)
• 5xx Serverfeil (500 Internal Server Error, 503 Service Unavailable)

Ved 301 setter serveren også en Location-header med ny URL, og klienten henter siden på nytt fra det nye stedet.

Pensum: Kap. 2 — HTTP-meldingsformat

Riktig svar: C

Klienten (eller en web-cache) som tidligere har lastet ned et objekt har lagret «Last-Modified»-tidsstemplet. Ved neste forespørsel sender den If-Modified-Since: <dato> i headeren. Dersom serverens kopi ikke er endret siden den datoen, svarer serveren med en kort 304 Not Modified-melding (uten objektets innhold). Klienten bruker da den cachede kopien.

Dette sparer mye båndbredde for store, sjelden endrede objekter (bilder, CSS, scripts).

Pensum: Kap. 2 — HTTP og web-caching

Riktig svar: C

Den karakteristiske egenskapen ved P2P er selvskalerbarhet: hver ny peer som blir med, gir både økt etterspørsel (trenger data) og økt kapasitet (kan tilby data til andre). Nettverkets totale kapasitet vokser proporsjonalt med antall deltakere.

Klient-server-arkitekturen er begrenset av serverens opplastningskapasitet — flere klienter gir mer last uten å øke kapasiteten.

Pensum: Kap. 2 — Nettverksapplikasjoner

Riktig svar: C

MSS er den maksimale mengden applikasjonsdata i ett TCP-segment. Den velges typisk slik at hele IP-pakken (TCP-segment + TCP-header + IP-header) får plass i én lenke-ramme uten fragmentering. For Ethernet med MTU = 1500 byte gir det MSS ≈ 1460 byte (1500 − 20 IP − 20 TCP).

Merk: MSS er ikke det samme som TCP-vinduet (rwnd/cwnd). Vinduet sier hvor mye data som kan være underveis; MSS sier hvor mye per segment.

Pensum: Kap. 3 — TCP-segmentstruktur

Riktig svar: B

I rdt 2.0 antok man at ACK/NAK ikke kunne bli korrupt. Men når ACK selv kan bli skadet (rdt 2.1), oppstår tvetydighet: senderen vet ikke om mottakeren fikk pakken eller ikke. Løsningen er alternating bit — sekvensnummer 0 og 1. Mottakeren kan dermed se om en pakke er en ny pakke (annet sekvensnummer enn forrige) eller et duplikat (samme sekvensnummer som forrige).

Stop-and-Wait med alternating bit er nettopp rdt 3.0 utvidet til også å håndtere tap (med timer + retransmisjon).

Pensum: Kap. 3 — Pålitelig dataoverføring (rdt)

Riktig svar: D — 172.32.4.10

RFC 1918 definerer tre private adresseblokker:

• 10.0.0.0/8 (10.0.0.0 – 10.255.255.255)
• 172.16.0.0/12 (172.16.0.0 – 172.31.255.255)
• 192.168.0.0/16 (192.168.0.0 – 192.168.255.255)

172.32.x.x er utenfor 172.16.0.0/12 (siste private adresse er 172.31.255.255). Den er en offentlig (ruterbar) adresse.

Pensum: Kap. 4 — Private adresser og NAT

Riktig svar: B — Identification

Når en ruter fragmenterer en stor IP-pakke, kopierer den samme verdi i Identification-feltet til alle fragmentene. Mottakerens IP-stakk bruker dette feltet (sammen med kilde-IP, destinasjons-IP og protokoll) for å gruppere fragmenter som hører sammen, og rekonstruere den originale pakken via Fragment Offset-feltet.

TTL avgjør hvor mange hop pakken kan ta, Total Length er pakkens totale størrelse, og Header Checksum er en feilkontroll på selve headeren.

Pensum: Kap. 4 — IPv4-pakkeformat og fragmentering

Riktig svar: C

ICMP type 3 (Destination Unreachable) har flere underkoder. Kode 3 betyr Port Unreachable og sendes når pakken når riktig vert, men ingen prosess lytter på destinasjonsporten. Andre vanlige underkoder:

• Kode 0 — Network Unreachable
• Kode 1 — Host Unreachable
• Kode 4 — Fragmentation Needed (men DF-bit satt)

Echo Reply er svar på ping, Time Exceeded sendes ved TTL = 0 (brukes av traceroute), og Redirect ber senderen bruke en annen ruter.

Pensum: Kap. 5 — ICMP-meldingstyper

Riktig svar: B

FF:FF:FF:FF:FF:FF er Ethernets broadcast-adresse. Alle Ethernet-adaptere som mottar en ramme med denne destinasjonen, leser den inn og leverer den oppover til nettverkslaget. Switcher videresender broadcast-rammer på alle porter (unntatt den de kom inn på).

Kjente bruksområder: ARP-forespørsler («Hvem har IP X?») og DHCP-Discover sendes til broadcast-adressen fordi senderen ennå ikke kjenner mottakerens MAC.

Pensum: Kap. 6 — MAC-adressering og Ethernet

Riktig svar: B

Beacon-rammer sendes av AP-et med jevne mellomrom (typisk hvert 100. ms). De inneholder bl.a. SSID, supported rates, sikkerhetsparametere (WPA2/WPA3-info) og tidsstempler. Klientenheter bruker beacons for å oppdage tilgjengelige nettverk under passive scanning og for å holde tidssynkronisering med AP-et.

Alternativet er active scanning, der klienten selv sender Probe Request-rammer og venter på Probe Response.

Pensum: Kap. 7 — 802.11-rammer og association

Riktig svar: C — reversibilitet er det motsatte av kravet

En kryptografisk hashfunksjon skal være en-veis (irreversibel). Hvis man kunne rekonstruere meldingen fra hash-verdien, ville hashen ikke vært nyttig som «digitalt fingeravtrykk» for signering — angriperen kunne lett produsere meldinger med ønsket hash.

Kravene er:

• Pre-image-motstand (kan ikke gå fra hash til melding)
• Andre pre-image-motstand (gitt m, kan ikke finne annen m' med samme hash)
• Kollisjonsmotstand (kan ikke finne to vilkårlige meldinger med samme hash)
• Determinisme og rask å beregne

Pensum: Kap. 8 — Hashfunksjoner og digital signatur

Riktig svar: A

I en pull-CDN ber CDN-noden om innholdet fra opprinnelsesserveren første gang en bruker etterspør et objekt, og cacher det lokalt for fremtidige forespørsler. Enkel oppsett, men første bruker per region får forsinkelse.

I en push-CDN sender opprinnelsesserveren innhold til CDN-nodene på forhånd (typisk for store, viktige objekter — populære filmer, spillinstallasjoner). Krever mer planlegging og lagring, men gir lavere forsinkelse for første bruker.

Mange kommersielle CDN-er bruker en hybrid: pull som standard, push for utvalgt populært innhold.

Pensum: Kap. 9 — CDN-arkitektur

a) Linjesvitsjing:

Hver bruker reserverer 100 kbps. Antall brukere = 1 000 / 100 = 10 brukere. Når en bruker er passiv, sløser systemet hele 100 kbps som ingen kan bruke.

b) Pakkesvitsjing med 35 brukere:

Hver bruker er aktiv med sannsynlighet p = 0,1. Sannsynligheten for at nøyaktig n av N = 35 brukere er aktive samtidig er gitt ved binomialfordelingen:

P(N=n) = C(35, n) · 0,1ⁿ · 0,9³⁵⁻ⁿ

Forventet antall aktive: μ = N·p = 3,5. Lenken tåler 10 samtidige brukere før kø oppstår (10·100 kbps = 1 Mbps). Sannsynligheten for > 10 aktive samtidig er ca. 0,0004 (≈ 0,04 %), altså svært liten.

Pakkesvitsjing kan betjene 35 brukere på samme 1 Mbps-link der linjesvitsjing bare ville klart 10. Dette kalles statistisk multipleksingsgevinst.

c) Hvor er linjesvitsjing bedre?

Linjesvitsjing er bedre egnet for trafikk som er jevn (ikke bursty) og som krever garantert kapasitet og lav, konstant forsinkelse. Klassisk telefonsamtale (PSTN) er typisk: 64 kbps strøm i hele samtalens varighet, ingen tap, ingen jitter. Med pakkesvitsjing måtte man håndtere variabel forsinkelse og mulig pakketap, som er problematisk for sanntids-stemme uten ekstra mekanismer.

Pensum: Kap. 1 — Pakkesvitsjing og statistisk multipleksing

a) Tap av pakke 1:

Mottakeren ACK-er hver pakke individuelt:

• Pakke 0 mottatt → mottakeren sender ACK 0, leverer pakke 0 til applikasjonen.
• Pakke 2 mottatt før pakke 1 → mottakeren sender ACK 2, men buffrer pakke 2 (pakke 1 mangler).
• Pakke 3 mottatt → mottakeren sender ACK 3, buffrer den også.
• Pakke 1 timer ut hos sender → senderen retransmitterer kun pakke 1.
• Pakke 1 mottas → mottakeren sender ACK 1 og leverer pakke 1, 2, 3 i rekkefølge til applikasjonen.

Senderen kan i mellomtiden — siden pakke 0 er ACK-et — flytte vinduet og sende pakke 4 (men ikke videre før 1 er ACK-et).

b) Hvorfor SR krever mottaker-buffer, GBN ikke:

I GBN forkaster mottakeren alle pakker som kommer ut-av-orden — derfor trenger den ikke buffer (sender bare ACK for siste in-order-pakke). Senderen må derimot buffre alle ukvitterte pakker for å kunne retransmittere dem (Go-Back-N).

I SR tar mottakeren imot pakker ut-av-orden og buffrer dem til hullene fylles, slik at den slipper å motta alt på nytt. Begge sider trenger derfor buffer.

c) Maksimal vindusstørrelse for SR med 3-bits sekvensnumre:

For SR må vindusstørrelsen ≤ halvparten av sekvensnummerrommet. Med 8 sekvensnumre: maks vindu = 4.

Begrunnelse: Anta motstridende eksempel med vindu = 5 og sekvenser 0..7. Sender sender 0,1,2,3,4. Alle ACK-er går tapt. Sender retransmitterer 0,1,2,3,4. Hvis ACK-ene faktisk hadde nådd frem, har mottakeren allerede flyttet vinduet og venter nå på 5,6,7,0,1 — den oppfatter det første «0» fra retransmisjonen som en helt ny pakke, ikke som duplikat. Tvetydigheten unngås kun hvis vindu ≤ N/2.

Pensum: Kap. 3 — Selective Repeat

a) Problemet:

NAT-ruteren har bare én offentlig IP. Hvis ruteren bare oversetter kilde-IP, vil begge utgående pakker ha kilde 83.45.10.7:51000 — webserveren vil tro at all trafikk kommer fra samme prosess, og når svar kommer tilbake til ruteren med destinasjon 83.45.10.7:51000, kan ruteren ikke vite om svaret skal til A eller B. Det er en kollisjon i (offentlig IP, port)-rommet.

b) NAT-tabell etter oversettelse:

Intern (LAN)	Ekstern (WAN)	Destinasjon
192.168.1.10:51000	83.45.10.7:62001	140.82.121.4:443
192.168.1.20:51000	83.45.10.7:62002	140.82.121.4:443

Ved utgående pakke fra A (192.168.1.10:51000 → 140.82.121.4:443): ruteren erstatter kilde-(IP,port) med 83.45.10.7:62001, oppdaterer TCP/IP-checksums og videresender pakken. Tilsvarende for B med port 62002.

c) Inngående svar med dest 83.45.10.7:62002:

Ruteren slår opp destinasjonsporten 62002 i NAT-tabellen. Den finner at den tilhører forbindelsen fra B. Den erstatter destinasjons-(IP,port) i pakken med 192.168.1.20:51000, oppdaterer checksums, og videresender pakken til vert B på LAN-et.

Dette er essensen av NAPT (Network Address and Port Translation, også kalt PAT) — uten NAPT ville én NAT-ruter bare kunne håndtere én aktiv intern vert om gangen.

Pensum: Kap. 4 — NAT og portoversettelse

a) Blokkchiffer og modi:

En blokkchiffer (f.eks. AES-128, DES) er en symmetrisk algoritme som krypterer én blokk med fast størrelse (typisk 128 bits for AES) om gangen. For å kryptere lengre meldinger må man dele meldingen i blokker og kombinere dem med en modus:

• ECB (Electronic Codebook): hver blokk krypteres uavhengig med samme nøkkel. Like klartekstblokker gir like chifferblokker.
• CBC (Cipher Block Chaining): hver klartekstblokk XOR-es med forrige chifferblokk før kryptering. Den første blokken XOR-es med en tilfeldig initialiseringsvektor (IV).

b) ECB er usikker:

Siden like blokker gir like chifferblokker, lekker ECB strukturell informasjon. Klassisk eksempel: et bilde kryptert i ECB beholder synlige konturer fordi store flater (like piksler) gir like chifferblokker. En angriper kan også bytte om eller gjenta blokker uoppdaget. CBC løser dette fordi hver blokk avhenger av alle tidligere — selv to like meldinger gir helt ulike chifferer (med ulik IV).

c) HMAC:

HMAC (Hash-based Message Authentication Code) er en mekanisme som tar en melding og en delt hemmelig nøkkel, og produserer en kort kode (f.eks. HMAC-SHA256). Senderen sender (melding, HMAC); mottakeren beregner HMAC selv med samme nøkkel og sammenligner.

HMAC gir integritet og autentisering: en angriper som ikke har nøkkelen, kan ikke produsere en gyldig HMAC for en endret melding.

En vanlig hash alene (uten nøkkel) gir ingen autentisering: angriperen kan endre meldingen og bare beregne ny hash på den nye meldingen — mottakeren har ingen måte å skille legitimt fra manipulert.

Pensum: Kap. 8 — Symmetrisk kryptografi og MAC

a) Bitrate og pakkstørrelse:

Nettorate = 8 000 samples/s × 8 bits/sample = 64 000 bps = 64 kbps.

20 ms tale per pakke = 0,02 × 64 000 bits = 1 280 bits = 160 byte payload per RTP-pakke.

(Pluss RTP-header 12 byte, UDP-header 8 byte, IP-header 20 byte → ca. 200 byte per pakke totalt — overhead på ca. 20 %.)

b) RTP sequence number og timestamp:

Felt	Funksjon
Sequence number	Inkrementeres med 1 per pakke. Mottakeren kan oppdage tap (hull i sekvens) og levere pakker i riktig rekkefølge.
Timestamp	Indikerer tidspunktet (i sample-enheter) for første sample i payloaden. Mottakeren bruker dette til å plassere samples på riktig sted i avspillingen — uavhengig av når pakken faktisk ankom.

Sequence number alene skiller ikke mellom tap og jitter; timestamp alene gir ingen informasjon om hva som mangler. Sammen gir de full informasjon: hvilke pakker som er tapt, og når i avspillingen samples skal plasseres.

c) RTCP:

RTCP (RTP Control Protocol) er kontrollprotokollen som følger med RTP. Sender og mottakere sender periodisk Sender Reports (SR) og Receiver Reports (RR) med statistikk: pakketapsrate, jitter (variasjon i forsinkelse) og siste mottatte sequence number.

Senderen kan tilpasse seg basert på RR — f.eks. redusere bitrate hvis tap er høyt, bytte til en mer robust koding ved jitter, eller varsle brukeren om dårlig forbindelse.

d) Backup-versjon mot tap:

Ved å pakke en lavkvalitets-backup av pakke N i pakke N+1: hvis pakke N går tapt og N+1 kommer frem, kan mottakeren bruke backup-versjonen i stedet for å høre stillhet. Dette gir bedre lydkontinuitet ved enkelt-pakketap.

Kompromiss: Hver pakke blir større — økt båndbreddebruk og potensielt mer trengsel. Beskytter heller ikke mot to tapte pakker på rad. Det er en avveining mellom nettotrafikk og robusthet.

Pensum: Kap. 9 — VoIP, RTP, RTCP og loss recovery