Eksamensforberedelse · TTM4100

Må kunne

Tema og oppgavetyper som har gått igjen på de fem siste eksamenene (Eks 1–5) — det du absolutt bør sitte med på ryggmargen før du går inn i eksamenslokalet. Frekvensanalysen er gjort på alle fem sett, og du finner «vedd som nesten er gratis» (4–5 av 5) markert øverst i hver seksjon. Wireshark-spørsmål er ikke med i år, så de er deprioritert her.

Flashcards · må kunne

Drill det essensielle

Disse korta dekker akkurat de tingene som har dukket opp på flere eksamener. Klikk for å snu — bruk ← / → for å bla, mellomrom for å snu, R for å shuffle.

Spørsmål

Klikk eller mellomrom for å vise svar

Svar

1 / 1

Hva er forskjellen mellom ruting og videresending?

Svar: Videresending (forwarding) er den lokale handlingen i én ruter — å flytte en pakke fra inn-lenke til riktig ut-lenke ved oppslag i videresendingstabellen. Ruting er den globale prosessen som bestemmer ende-til-ende-stiene som pakkene skal følge gjennom nettverket.

Hvorfor: Forwarding skjer per pakke, i nanosekunder, basert på en allerede-utfyllt tabell. Routing kjører i bakgrunnen via protokoller (OSPF, BGP) og fyller tabellen. Ett ord hver: lokal vs global.
Hvilke tjenester gir UDP applikasjonen — og hvilke gir den ikke?

Gir: Best effort-levering (datagrammer kan tapes, omrokkeres, dupliseres) og portbasert multipleksing. Lite header-overhead, ingen oppkobling.

Gir IKKE: Pålitelighet, flytkontroll, overbelastningskontroll, gjennomstrømningsgaranti, sanntidslevering.

Hvorfor det testes: Klassisk multiple choice — sjekk av med «best effort» og kryss av alt som ikke er garantier (ingen flow control, ingen congestion control, ingen real-time, ingen throughput-garanti).
Hvilke tjenester gir TCP som UDP ikke gir?

Svar: Pålitelig, in-order bytestrøm (gjenoverføring ved tap), flytkontroll (mottakers vindu hindrer overfylt mottaksbuffer) og overbelastningskontroll (tilpasser sendetempo til nettverkets kapasitet).

Hvorfor: TCP gir ikke båndbreddegaranti eller sanntidsgaranti — det er en typisk feilkrysslapp på eksamen. Pass på forskjellen mellom flow control (mellom to endepunkter) og congestion control (mot nettverket).
Forklar flytkontroll i TCP når mottaker leser saktere enn avsender sender.

Svar: Mottaker annonserer fritt buffer-rom i feltet rwnd i hvert ACK. Avsender holder utestående usendte data ≤ rwnd, slik at mottaksbufferet aldri renner over. Hvis applikasjonen henger etter (f.eks. 600 Mbps lese-rate, 1 Gbps sender), krymper rwnd til 0 og avsender stopper.

Hvorfor: Forveksles ofte med congestion control. Nøkkelsetningen: «mottaker tømmer bufferet sitt for sakte» → flytkontroll.
Hva er ende-til-ende-forsinkelsen for én pakke gjennom én store-and-forward-svitsj med rater R₁ og R₂?

Svar: L/R₁ + L/R₂ — pakken må fullstendig mottas av svitsjen før den kan begynne å sendes ut.

Hvorfor: Standard formel som sjeldent kommer alene — ofte utvidet til (N+P−1)·L/R for P pakker gjennom N like rutere (pipelining).
Hvor mange symmetriske nøkler trengs hvis N personer skal kommunisere parvis?

Svar: N(N−1)/2.

Hvorfor: Hvert par må dele én unik nøkkel. Antall par er kombinasjonen «N velg 2» = N(N−1)/2. Dette er motivasjonen for offentlig nøkkel: med PKI trenger N personer bare 2N nøkler totalt (én privat + én offentlig per person).
Hva er NAT, og hva endres på vei ut av et NAT-grensesnitt?

Svar: NAT bytter ut kilde-IP (privat, f.eks. 10.0.0.1) og kildeport med ruterens offentlige IP og en ny port valgt av NAT-en. Destinasjons-IP og -port er uendret. På vei inn gjøres motsatt oversettelse.

Hvorfor: På eksamen får du gjerne en NAT-tabell og skal fylle inn (kilde-IP, kilde-port, dest-IP, dest-port) på utsiden av NAT (punkt D). Husk: bare kildesiden endres på utgående retning.
Gitt IP 192.168.1.108 og maske /30, hva er subnett-adressen?

Svar: 192.168.1.108. /30 = maske 255.255.255.252. AND med 108 = 01101100, og 252 = 11111100 → 01101100 = 108. Så hele oktetten beholdes.

Hvorfor: «Subnett-adresse» er IP AND maske. Tren på /28, /29, /30 — kommer i flere varianter på eksamen.
Du har 208.27.1.0/22 og må lage minst 12 subnett. Hvor mange brukbare verter per subnett?

Svar: 62. /22 har 10 vertsbits. For å få ≥12 subnett trengs 4 nett-bits (2⁴=16 ≥ 12), så maska blir /26 og hver vertsdel har 6 bits → 2⁶ − 2 = 62 brukbare adresser (trekk fra nettverk- og broadcastadresse).

Hvorfor: Klassisk subnetting-oppgave. Husk «−2»-regelen for «brukbare verter».
Hva er broadcast-adressen til 172.18.16.0/21?

Svar: 172.18.23.255. /21 betyr at de tre nett-bitsene i tredje oktett er fastlåst. Området starter på 16 (00010|000) og rekker 8 verdier i tredje oktett (16–23). Broadcast = siste adresse → 172.18.23.255.
Hvilket felt finnes kun i IPv6-headeren?

Svar: Flow label. IPv4 har ikke flow label. (TTL/hop limit, version, source/dest finnes i begge — IPv6 har bare lengre adresser.)

Annet IPv6 fjernet: Header checksum, fragmenteringsfelt, header length og options finnes ikke i IPv6-headeren.
3 fakta om ICMP du må kunne.
Svar:
1. ICMP brukes av verter og rutere for å utveksle nettverksnivå-informasjon (feil/diagnose).
2. ICMP-meldinger bæres direkte i IP-datagrammer — ikke i UDP/TCP og ikke på «port 86».
3. «TTL expired»-meldinger brukes av traceroute.
Vanlig felle: ICMP er ikke en transportprotokoll.
3 fakta om DHCP du må kunne.
Svar:
1. 4-stegs prosess: Discover → Offer → Request → ACK.
2. Bruker UDP som transport — ikke TCP.
3. Kan tildele IP, subnett-maske, default gateway og DNS-server.
Felle: «DHCP brukes til å rute datapakker» er feil. DHCP = konfigurasjon, ikke ruting.
Hva betyr Internetts «best effort»-tjenestemodell?

Svar: Ingen garantier — verken levering, leveringstid, rekkefølge eller minimum båndbredde. Nettet gjør sitt beste, men kan droppe, omrokkere eller forsinke pakker uten å si fra.

Hvorfor: All «kvalitet» (pålitelighet, ordning) må bygges på toppen — det er det TCP gjør.
Hovedformålet med en brannmur?

Svar: Å blokkere uautorisert tilgang til/fra nettet (filtrering på pakkenivå basert på regler).

Felle: «Krypterer data» er feil — det er TLS/IPsec sin jobb. «Tilbyr VPN» er en bonus, ikke hovedformålet.
Cæsar-cipher med k=7: kod ordet «Protect».

Svar: Skift hver bokstav 7 plasser fram. P→W, r→y, o→v, t→a, e→l, c→j, t→a → «Wyvalja».

Hvorfor: Sett opp et alfabet (A=0, B=1, …) og bruk (x + 7) mod 26. Vis utregningen på besvarelsen — det gir delpoeng selv ved regnefeil.
Hva er RTS/CTS for, og hvilket problem løser det?

Svar: RTS (Request To Send) fra avsender og CTS (Clear To Send) fra mottaker reserverer kanalen før selve datarammen sendes. Når naboer hører CTS, holder de seg stille.

Problem: Skjult terminal. To avsendere som ikke hører hverandre, kan begge sende til samme mottaker og skape kollisjon. CTS treffer alle innen mottakers rekkevidde og forhindrer dette.
Klassifiser: TDM, FDM, CDMA, ALOHA, CSMA/CD, token ring.

Kanalpartisjonering: TDM, FDM, CDMA (FDMA).

Tilfeldig tilgang: ALOHA (pure + slotted), CSMA, CSMA/CD, CSMA/CA, Ethernet.

Taking turns: Token ring, FDDI, Bluetooth (polling).

Hvorfor: Tre-veis klassifisering kommer som drag-and-drop på Del I.
Hva er forskjellen pure og slotted ALOHA?

Svar: Pure ALOHA — send hver gang du har data, ingen synkronisering. Slotted ALOHA — start sending kun ved begynnelsen av et tids-slot. Maks effektivitet: pure ≈ 18 %, slotted ≈ 37 % (≈ 1/(2e) vs 1/e).

Hvorfor: Slotted halverer kollisjons-vinduet → dobler effektiviteten.
Svitsj vs ruter — på hvilket lag, og hvilke adresser?

Svar: Svitsj opererer på lenkelaget (lag 2) og videresender basert på MAC-adresser. Ruter opererer på nettverkslaget (lag 3) og videresender basert på IP-adresser.

Felle: «Svitsjer kobler sammen ulike nett, rutere kobler enheter innen ett nett» — feil, det er motsatt.
2D-paritet: hva kan den oppdage og rette?

Svar: Kan oppdage og rette én bitfeil (rad og kolonne med feil paritet peker rett på bitten). Kan oppdage, men ikke rette, mange to-bits feil. Generelt: ikke alle to-bits feil oppdages.
Hva angir Trudy (angriper) kan gjøre i en kommunikasjonskanal?

Svar: Avlytte (sniffing) kontroll- og datameldinger, endre innhold, sette inn nye meldinger, og slette meldinger. Dvs. alt — derfor trengs kryptografi (konfidensialitet) og integritetsmekanismer (hash/MAC).
Hvorfor brukes ofte HTTP-streaming over TCP framfor UDP-streaming?

Svar: (1) Mange brannmurer blokkerer UDP, men slipper HTTP/TCP gjennom. (2) UDP har ingen retransmisjon eller ordning — gir høyere feilrate. (3) HTTP gjenbruker eksisterende web-infrastruktur (CDN, caching).

Hvorfor likevel UDP iblant: sanntid (VoIP, spill) der lavere latency er viktigere enn pålitelighet.
Beregn Internet checksum over to 16-bits ord — hva er stegene?
Svar:
1. Summer ordene som vanlig binær addisjon.
2. Hvis det er carry ut av 16. bit, legg den tilbake nederst (carry-wrap / 1's complement-sum).
3. Ta 1's complement (snu alle bits) — det er checksum.
Hvorfor: Brukes i TCP/UDP/IP-headere. Mottaker summerer alt inkludert checksum og skal få bare 1-ere.
Hva får klienten tilbake i en DNS Resource Record?
Svar: En RR har formatet (Name, Value, Type, TTL):
- A: Name = hostname, Value = IPv4.
- AAAA: IPv6-adresse.
- NS: Name = domene, Value = autoritativ navneserver.
- CNAME: Name = alias, Value = kanonisk hostname.
- MX: Name = domene, Value = mail-server.
Transport: Kjører primært over UDP (port 53), men kan bruke TCP for store svar / soneoverføring.
Antall TCP-sockets på en webserver med 5 aktive forbindelser på port 80?

Svar: 6 sockets — én lyttende «welcoming socket» som accept() kjører på, pluss én ny socket per aktive klient (5 stk).

Hvorfor: Hver TCP-forbindelse identifiseres unikt av 4-tuple (kilde-IP, kilde-port, dest-IP, dest-port). Selv om alle bruker server-port 80, har de ulik klient-IP/port og får hver sin socket.
Hva er typisk hovedfordel med web-cache i et institusjonsnett?

Svar: (1) Lavere forsinkelse for klienten (cache er nær). (2) Lavere båndbreddebruk på lenken inn til institusjonen. (3) Selv ikke-cachede objekter får lavere snitt-forsinkelse fordi opplinken er mindre overbelastet.
Seks pakker ankommer ulike noder ved t = 0,1; 1,4; 1,8; 3,2; 3,3; 4,1. Hver transmisjon tar 1 t.u., propagering = 0,2 t.u. Med CSMA uten CD, hvilke pakker lykkes (kommer fram før t = 5)?

Svar: Pakke 1 (t=0,1) og pakke 4 (t=3,2) lykkes. Pakkene 2 og 3 kolliderer (begge starter før den andres signal har nådd dem — diff < 0,2). Pakke 5 lytter, hører pakke 4 → utsetter til etter t=5. Pakke 6 starter på t=4,1 mens pakke 4s signal fortsatt ikke har rukket alle (4,2) — den «hører ledig», sender, men kolliderer ute i nettet.

Metode: En sender hvis kanalen virker ledig. Men signalet bruker 0,2 t.u. på å nå naboene. Pakker som starter innen 0,2 etter en annen → kollisjon. Pakker som starter når en nabos transmisjon allerede har nådd dem → utsettes (etter t=5).

Felle: Selv ren CSMA kan kollidere — propageringsforsinkelse er årsaken. Tegn alltid linjene 0,2 lange.
Seks pakker ankommer ulike noder ved t = 0,1; 0,8; 1,35; 2,6; 3,9; 4,2. Hver transmisjon tar 1 t.u., propagering = 0,2. Med CSMA/CD, hvilke pakker lykkes før t = 5?

Svar: Pakke 1 (t=0,1), pakke 4 (t=2,6) og pakke 5 (t=3,9) lykkes. Pakkene 2 (t=0,8) og 3 (t=1,35) kolliderer med pakke 1 (signalet fra 1 har nådd dem ved hhv. 0,3 og 0,3 — kanal er opptatt). Med CD avbryter de straks de oppdager kollisjonen (men siste bit bruker 0,2 å nå alle). Pakke 6 (t=4,2) starter mens pakke 5 fortsatt sender → utsettes etter t=5.

CD vs ikke-CD: Med CD slipper kolliderende noder å sende hele rammen ferdig — de avbryter umiddelbart. Det sparer tid, men siste bit bruker fortsatt 0,2 t.u. på å nå alle.
Fire trådløse noder på linje: A–B–C–D. Hver hører bare sine direkte naboer (A↔B, B↔C, C↔D). Slik at A kun når B; B når A og C; C når B og D; D når kun C. Hver datapakke kvitteres med en ACK-pakke (én slot). Hva er maks rate fra C til A?

Svar: 0,25 meldinger/slot (én melding hver fjerde slot). Stien for én melding: slot 1: C→B, slot 2: B→A, slot 3: A→B ACK, slot 4: B→C ACK. Først da kan C sende neste.

Uten ACK: 0,5 meldinger/slot — slot 1: C→B; slot 2: B→A og samtidig kan ny C→B starte; rytmen tillater 1 melding hver 2. slot.
Fire trådløse noder på linje: A–B–C–D. A når kun B, B når A og C, C når B og D, D når kun C. Uten ACK: hva er kombinert rate for samtidig A→B og D→C?

Svar: 2 meldinger/slot — begge sendinger kan skje samtidig.

Hvorfor: A når bare B, D når bare C. B hører ikke D (utenfor B sin rekkevidde), C hører ikke A → ingen interferens. Hver flyt klarer 1 melding/slot.

Kontrast — A→B + C→D: Bare 1 msg/slot. Når C sender, hører B også C (B er nabo til C) og kolliderer med signalet fra A. Må veksle slot for slot.
Klient-server filfordeling: 10 Gbit fil, 100 peers, server 1 Gbps, hver peer 200 Mbps. Minimum tid?
Svar: 1000 s. Formel: D = max(N·F/u_s, F/d_min).
- Server-sending: 100 · 10 Gbit / 1 Gbps = 1000 s.
- Tregeste peer-nedlasting: 10 Gbit / 200 Mbps = 50 s.
Maksen er 1000 s — server er flaskehalsen. (Eks 2 Q1.2.5).
Forklar protokollkjeden når du kobler PC i Ethernet og sender e-post fra Outlook.
Svar (rekkefølge):
1. Lenkelag opp + DHCP (UDP) → får IP, default gateway, DNS-server.
2. ARP for å finne MAC til default gateway.
3. DNS (UDP) for å slå opp mail-server.
4. SMTP (TCP, port 25/587) til NTNU mail-server, som videre bruker SMTP til mottakers domene.
5. Mottaker leser via HTTPS (web-mail) eller IMAP (klient).
Hvorfor: Eks 3 hadde dette som 15-poengsoppgave. Husk å nevne lag og protokoll for hvert steg.
Hvilken transport bruker DNS, DHCP, SMTP, HTTP, HTTPS?
- DNS: primært UDP (53), TCP for store svar / soneoverføring.
- DHCP: UDP (67/68).
- SMTP: TCP (25, eller 465/587 for submit).
- HTTP: TCP (80).
- HTTPS: TCP (443) — HTTP over TLS.
- POP3 / IMAP: TCP (110 / 143).
- SSH / FTP / Telnet: TCP (22 / 21 / 23).
Tommel-fingerregel: alt som krever pålitelighet (e-post, web, fil, pålogging) bruker TCP. UDP brukes der pålitelighet ikke er strengt nødvendig (DNS-spørringer, DHCP-konfigurasjon, sanntid).
Hvilket lag tilhører ARP, ICMP, IP, TCP, HTTP?
- HTTP: applikasjonslag.
- TCP / UDP: transportlag.
- IP / ICMP: nettverkslag (ICMP bæres i IP, men er likevel nettverkslag).
- ARP: teknisk lenkelag — brukes for å koble IP-adresse til MAC-adresse.
- Ethernet, Wi-Fi (802.11): lenkelag.
Felle: ICMP er ikke transport (selv om mange tror det).
Privat vs offentlig IP — hvilke blokker er privat?
- 10.0.0.0/8 — klasse A privat (16 millioner adresser).
- 172.16.0.0/12 — klasse B privat.
- 192.168.0.0/16 — klasse C privat (typisk hjemmenett).
- 127.0.0.0/8 — loopback (alltid 127.0.0.1).
- 169.254.0.0/16 — link-local (når DHCP feiler).
Hvorfor: Privat-blokker rutes ikke på offentlig internett — de krever NAT for å nå ut.
Subnett-maskering — hva er masken til /28? Hvor mange brukbare verter?

/28-maske: 255.255.255.240 (siste oktett er 11110000).

Brukbare verter: 2⁴ − 2 = 14.

Generelt for /x: verts-bits = 32 − x. Brukbare = 2^(32−x) − 2 (trekk fra nett-adresse og broadcast-adresse).

Tabell å pugge: /24=254, /25=126, /26=62, /27=30, /28=14, /29=6, /30=2.
HTTP-metoder & statuskoder — kjenner du forskjell på 3xx, 4xx, 5xx?
Metoder: GET (hent), POST (send/skap), PUT (last opp), DELETE (slett), HEAD (bare headere).

Statuskode-klasser:
- 1xx — informasjon.
- 2xx — suksess (200 OK).
- 3xx — omdirigering (301 Moved, 304 Not Modified).
- 4xx — klientfeil (400 Bad Request, 404 Not Found).
- 5xx — serverfeil (500, 503).
Symmetrisk vs offentlig nøkkel — kort forskjell.

Symmetrisk: Én delt hemmelig nøkkel brukes til både kryptering og dekryptering (AES, DES). Rask, men nøkkeldistribusjon er problemet.

Offentlig nøkkel: Nøkkelpar (offentlig + privat). Kryptér med offentlig, dekrypter med privat (RSA). Løser nøkkeldistribusjon, men er ~1000× tregere.

I praksis: Bruk public key for å utveksle en symmetrisk session key (TLS-handshake), så symmetric for selve dataene.
En pakke på 8000 bits sendes over en lenke med rate 100 Mbps. Hva er transmisjonsforsinkelsen?

Svar: d_trans = L/R = 8000 / 100·10⁶ = 8·10⁻⁵ s = 80 µs.

Husk: L i bits, R i bits/s. Vanlig felle: pakkestørrelse er ofte oppgitt i byte — gang med 8 først.
To hosts er koblet via én svitsj med store-and-forward. Begge lenker er 100 Mbps. Pakken er 10 000 bits. Hva er total forsinkelse (uten kø, prosessering, propagering)?

Svar: L/R₁ + L/R₂ = 10 000/10⁸ + 10 000/10⁸ = 100 µs + 100 µs = 200 µs.

Hvorfor ikke L/(R₁+R₂): Svitsjen må motta hele pakken før den kan sende den videre — derfor adderes L/R per lenke, ikke deles.

Generelt for N lenker med samme R: N · L/R.
P pakker sendes back-to-back gjennom N store-and-forward-rutere (= N+1 lenker, men formel bruker N). Alle lenker har rate R, hver pakke L bits. Hva er minimum ende-til-ende-tid?

Svar: (N + P − 1) · L/R.

Hvorfor: Første pakke bruker N · L/R for å nå destinasjonen. Deretter ankommer hver av de neste (P−1) pakkene én L/R senere — pipelining. Trekk: ikke gang sammen, det er ikke N·P·L/R.

Spesialtilfelle: P=1 → N·L/R. N=1 → P·L/R.
Klient → ruter → server. Begge lenker 1000 byte/s. Klienten sender én 3000-byte-pakke. Ruteren bruker cut-through: starter sending etter 80 byte er mottatt. Hva er total ende-til-ende-forsinkelse (uten propagering)?

Svar: 3000/1000 + 80/1000 = 3,08 s.

Hvorfor: Klienten bruker 3 s på å sende ut hele pakken. Ruteren venter bare til 80 byte er mottatt (= 0,08 s) før den begynner å sende videre. Mens klienten fortsatt sender resten, sender ruteren parallelt — dermed har ruteren bare 80 byte ekstra forsinkelse fram til siste bit er ute hos serveren.
3 servere sender til 3 mottakere over en delt midt-lenke R = 200 Mbps med separate aksess-lenker R_S = 25 Mbps og R_C = 50 Mbps. Pakken er 1000 bits, propagering 100 µs per lenke. Hva er total ende-til-ende-forsinkelse for én pakke (med 3 hopp)?

Svar: L/R_S + L/R + L/R_C + 3·100µs = 40 + 5 + 20 + 300 = 365 µs.

Trinn: Server → midt-lenke: 1000/25Mbps = 40 µs. Midt-lenke: 1000/200Mbps = 5 µs. Til klient: 1000/50Mbps = 20 µs. Tre lenker propagering: 3·100 = 300 µs.
En sender deler en lenke R₁ = 200 Mbps rettferdig mellom to TCP-flows. Hver mottaker har aksess på 25 Mbps. Maksimal gjennomstrømning per flow?

Svar: 25 Mbps per flow.

Hvorfor: R₁ deler 200/2 = 100 Mbps per flow, men aksesslenken på 25 Mbps er flaskehalsen. Min(100, 25) = 25. Total trafikk på R₁ blir 50 Mbps — den deles ikke fullt ut.
Distribuér en fil F = 10 Gbit til N = 100 klienter via klient-server. Server uplink u_s = 1 Gbps, hver klient nedlasting d_i = 200 Mbps. Minimum tid?

Svar: 1000 s. Formel: D = max(N·F/u_s, F/d_min).

Server: 100·10 / 1 = 1000 s. Klient: 10 / 0,2 = 50 s. Maks = 1000.

Hvorfor: Server må sende F til hver klient → samlet N·F bits ut. Hver klient kan ikke laste raskere enn d_i. Tregeste vinner.
Gitt IP 192.168.2.108 og maske /29 (255.255.255.248). Hva er subnett-adressen?

Svar: 192.168.2.104.

Regn: 108 = 01101100. /29 → siste 3 bits er host. Bit-AND med 248 = 11111000 → 01101000 = 104.

Range: 104–111 (subnet 104, broadcast 111, brukbare 105–110 = 6 verter).
Gitt IP 192.168.3.108 og maske /28 (255.255.255.240). Hva er subnett-adressen?

Svar: 192.168.3.96.

Regn: 108 = 01101100. /28 → siste 4 bits er host. Bit-AND med 240 = 11110000 → 01100000 = 96.

Range: 96–111 (broadcast 111, brukbare 97–110 = 14 verter).
I subnettet 223.1.3.0/29: hvilke av disse adressene kan ikke brukes av en vert? a) 223.1.3.6 b) 223.1.3.2 c) 223.1.3.16 d) 223.1.2.6 e) 223.1.3.7
Ikke brukbare: c, d, e.
- 223.1.3.16 — utenfor /29-blokken (denne dekker 0–7).
- 223.1.2.6 — feil subnett (annen tredje oktett).
- 223.1.3.7 — broadcast-adresse for blokken.
- 223.1.3.0 hadde også vært ugyldig (nettverksadresse).
Brukbare: 223.1.3.1–6 (6 stk = 2³−2).
Du tildeles 214.97.250.0/23. Hvilke av disse er gyldige /24-subnett innenfor blokken? a) 214.97.245/24 b) 214.97.250/24 c) 214.97.251/24 d) 214.97.254/24

Svar: b og c.

Hvorfor: /23 dekker 2 påfølgende /24-blokker. 250 i tredje oktett er 11111010; /23 maskerer av siste bit → blokken inneholder 250 og 251. Andre verdier (245, 254) ligger utenfor.

Tips: Finn alltid området /23 dekker først (her: 250–251) før du sjekker hver kandidat.
Hva er broadcast-adressen til 10.0.32.0/19?

Svar: 10.0.63.255.

Regn: /19 → 13 vertsbits. Tredje oktett: 32 = 00100000. Maska har de første 3 bitene fastlåst → blokken dekker 32–63 i tredje oktett. Broadcast = siste adresse → 10.0.63.255.

Generelt: Broadcast = subnet-adresse OR (NOT maske).
Du har 200.23.16.0/20 og må splitte i 8 like store undernett. Hva blir prefix-lengden, og hvor mange brukbare verter per nett?

Svar: /23, og 510 brukbare verter per nett.

Regn: 8 nett krever 3 ekstra bits → 20 + 3 = /23. Vertsbits = 32 − 23 = 9 → 2⁹ − 2 = 510.

Mal: «k nett» krever ⌈log₂ k⌉ ekstra bits. «n brukbare verter» krever ⌈log₂(n+2)⌉ vertsbits.
Pugg tabellen: brukbare verter per /x for x = 24, 25, 26, 27, 28, 29, 30.
Formel: 2^(32−x) − 2.
- /24 → 254
- /25 → 126
- /26 → 62
- /27 → 30
- /28 → 14
- /29 → 6
- /30 → 2
Felle: Glem ikke −2 (nettverksadresse + broadcast).
En webserver har 5 aktive TCP-forbindelser mot port 80 (ingen som åpnes/lukkes). Hvor mange TCP-sockets totalt?

Svar: 6 sockets.

Hvorfor: 1 lyttende «velkomstsokkel» som accept() kjører på, pluss 1 ny socket per klient. Hver TCP-socket identifiseres av 4-tuple (kilde-IP, kilde-port, dest-IP, dest-port) — alle 5 deler dest-port 80 men har ulik kilde.
En UDP-server har én forhåndsdefinert port. Tre klienter (A, B, C) sender hver sin UDP-pakke til serveren. Minst hvor mange sockets på serveren?

Svar: 1 socket.

Hvorfor: UDP-server har én socket bundet til portnummeret. Datagrammer fra alle klienter kommer inn på samme socket. Kontrast TCP, som lager ny socket per klient via accept().

Demultiplekseringsnøkkel: UDP = (dest-IP, dest-port). TCP = full 4-tuple.
Hva lager socket(AF_INET, SOCK_STREAM), og hva lager socket(AF_INET, SOCK_DGRAM)?
Svar:
- SOCK_STREAM → TCP-socket: pålitelig in-order bytestrøm.
- SOCK_DGRAM → UDP-socket: upålitelig datagram-overføring.
Konsekvenser: TCP-server: listen() / accept() — accept() lager ny socket per klient. UDP-server: sendto() / recvfrom() — én socket, må angi dest IP+port per pakke (eller bruke connect()).
Hva gjør connect() på en klient-TCP-socket, og hva er fordelen?

Svar: Binder klient-socketen til serverens (IP, port) og initierer 3-veis håndtrykk.

Fordel: Etter connect() kan klienten bruke send()/recv() uten å spesifisere destinasjon hver gang — socketen «vet» hvem den snakker med.

Kontrast UDP: Klient må normalt bruke sendto(buf, ip, port) per pakke (men kan også «koble til» en UDP-socket).
En lenkelagsramme har tre headere H1 (ytterst), H2, H3 (innerst), og bæres fra vert til ruter. Hvilket lag tilhører hver header?
Svar:
- H1 = lenkelag (ytterst — svøper alt på vei over kabelen).
- H2 = nettverkslag (IP-headeren).
- H3 = transportlag (TCP/UDP-headeren).
Hvorfor: Enkapsuleringen skjer ovenfra og ned. Når en applikasjonsmelding går ned protokollstabelen, legger transport (4) sin header først, så nettverk (3), så lenkelag (2). Den ytterste på linja er den som ble lagt til sist.
Hva betyr enkapsulering?

Svar: Å ta data fra laget over, legge på en passende header (og evt. trailer) for det aktuelle laget, og legge alt sammen i payload-feltet til den nye «pakken» på dette laget.

Felle på eksamen: Det er ikke «summen av byte for sjekksum», ikke «navneoppslag i DNS», ikke «timer for retransmisjon». Det er å «pakke inn» med header.
Én setning hver: Hva er forwarding, og hva er routing?

Forwarding (videresending): Den lokale handlingen i én ruter — flytt pakken fra inn-lenke til riktig ut-lenke via tabelloppslag.

Routing (ruting): Den globale prosessen som bestemmer ende-til-ende-stiene gjennom nettverket.

Felle: Definisjonene er ofte byttet om i multiple choice — sjekk hvilken som sier lokal og hvilken som sier global.
Cæsar-cipher med k=7: dekod meldingen «Jhlzhy».

Svar: «Caesar». Skift hver bokstav 7 plasser tilbake: J→C, h→a, l→e, z→s, h→a, y→r.

Metode: Dekoding er kryptering med −k (eller +(26−k)). Ved k=7: skift +19 framover ↔ skift −7 (samme).
Cæsar-cipher: hva er generell metode for kryptering med offset k og dekryptering, og hvor mange mulige nøkler finnes?

Kryptér: for hver bokstav x, beregn (x + k) mod 26 (med a=0).

Dekrypter: beregn (y − k) mod 26, eller ekvivalent (y + (26−k)) mod 26.

Antall nøkler: bare 25 (k = 1 … 25; k = 0 og k = 26 gir klartekst). Brute force tar < 1 sekund.

Hvorfor det er svakt: bokstavfrekvens-statistikk avslører språket umiddelbart selv uten brute force.
Cæsar-cipher med k=3: kod ordet «Hello».

Svar: «Khoor». H→K, e→h, l→o, l→o, o→r.

Hvorfor det er svakt: Bare 25 mulige nøkler — brute force på sekunder. Pluss bokstavfrekvens-statistikk avslører språket umiddelbart.
10 personer skal kommunisere parvis hemmelig med symmetrisk kryptografi. Hvor mange nøkler totalt?

Svar: 10·9/2 = 45 nøkler.

Sammenlign med public key: 10 personer × 1 nøkkelpar = 10 par (= 20 nøkler totalt). Skalerer mye bedre: O(N) vs O(N²).
2D-paritet: kan den oppdage 1 bitfeil? 2 bitfeil? Kan den rette 1 bitfeil?
Svar:
- 1 bitfeil: oppdage + rette (raden og kolonnen med feil paritet peker på bitten).
- 2 bitfeil: kan oppdage mange tilfeller, men kan ikke alltid rette. Noen 2-bits-mønstre er heller ikke oppdagbare.
- Generelt: 1D-paritet oppdager bare oddetall bitfeil og kan ikke rette.
Hvilke tre påstander om web-cache er korrekte? a) Reduserer ikke snitt-forsinkelse b) Reduserer bare for cachede objekter c) Kan redusere snittet for alle objekter, også ikke-cachede d) Øker trafikken inn til klienten

Riktig: c — kan redusere snitt for alle objekter.

Hvorfor c er sant: Cache reduserer trafikk på opplinken til ISP-en. Mindre trafikk → lavere kø-forsinkelse → også ikke-cachede objekter kommer raskere fram.

Hvorfor de andre er feil: a — den reduserer både snitt og total trafikk. b — feil; alle objekter nyter godt. d — feil retning; cache reduserer innkommende trafikk.
Tre fordeler med web-cache i et institusjonsnett.
1. Lavere klient-forsinkelse — cachede objekter hentes lokalt.
2. Mindre båndbredde inn — institusjonens opplink avlastes.
3. Lavere snitt for alle — også ikke-cachede objekter (mindre opplink-køforsinkelse).
Hva er kun-HTTP (ikke SMTP) av disse? a) ASCII command/response b) Mest «pull» c) Persistent forbindelse for flere objekter d) CRLF som meldingsslutt e) Server-port 80 f) Port 25

Kun HTTP: b (pull), c (multi-objekt på én forbindelse), e (port 80).

Felles: a (begge er ASCII), d (begge bruker CRLF for header-slutt).

Kun SMTP: f (port 25), og «push»-modellen.

Hvorfor det er pull vs push: Klienten henter objekter via HTTP GET. SMTP dytter meldingen fra avsenders mailserver til mottakers mailserver.
Format og innhold av en DNS Resource Record (RR)?
Format: (name, value, type, TTL).

Vanlige typer:
- A: name = hostname, value = IPv4-adresse.
- AAAA: IPv6-adresse.
- NS: name = domene, value = autoritativ navneserver.
- CNAME: name = alias, value = kanonisk hostname.
- MX: name = domene, value = mailserver.
Transport: Vanligvis UDP port 53; TCP for store svar / soneoverføringer.
Sant eller usant: «DNS kan kun kjøre over UDP».

Svar: Usant. DNS bruker primært UDP (lite overhead, små svar), men kan bruke TCP — spesielt ved store svar (over 512 bytes) og ved sone-overføring mellom navneservere.
Hvilke 4 ting kan en host lære via DHCP når den kobler til et nytt nett?
1. Egen IP-adresse.
2. Subnett-maske.
3. Adressen til default gateway (første ruter).
4. Adressen til DNS-server.
Protokoll: 4 steg — Discover → Offer → Request → ACK. UDP (klient port 68, server port 67), ikke TCP.

Felle: «DHCP er for ruting» er feil — det er for konfigurasjon.
Hvilke 4 handlinger kan en aktiv inntrenger Trudy utføre på en kommunikasjonskanal?
1. Avlytte kontroll- og datameldinger (sniffing).
2. Endre innholdet i meldinger.
3. Sette inn nye meldinger (replay/forge).
4. Slette meldinger underveis.
Konsekvens: Derfor trengs både kryptering (konfidensialitet) og integritetsmekanismer (hash/MAC) og autentisering. Kryptering alene løser ikke endring/sletting.
Hvilke 4 er ønskede egenskaper ved sikker kommunikasjon? a) Konfidensialitet b) Høy båndbredde c) Meldingintegritet d) Autentisering e) Operasjonell sikkerhet f) Nettverksredundans

Riktig: a, c, d, e.

Felle: Båndbredde og redundans hører til ytelse/oppetid, ikke sikkerhet. CIA-triaden + autentisering er kjerneegenskapene.
Hvilke påstander om ICMP er sanne? Krysser du a, b, c, d, eller e? a) Brukes av host og rutere for nettverksinfo b) Bæres direkte i IP c) Markerer bits i IP-headeren d) TTL-expired brukes av traceroute e) Bæres i UDP port 86

Sanne: a, b, d.

Felle: c — ICMP er separate meldinger, ikke flagg i IP-headeren. e — ICMP er ikke i UDP/TCP og bruker ikke portnumre.
Hvilke garantier gir Internetts best-effort-tjenestemodell? Kryss av: a) Levering b) Leveringstid c) In-order til transport d) Minimum båndbredde e) Ingen garantier i det hele tatt

Riktig: e — best effort betyr ingen garantier på noen av dem.

Hvorfor: Internetts IP-lag er bevisst minimalt: pakker kan tapes, omrokkeres, dupliseres eller forsinkes uten varsel. All kvalitet bygges på toppen (TCP gir pålitelighet og ordning).
Hvilke felter finnes kun i IPv6? Kryss av: a) 128-bits adresser b) Version c) TTL/hop limit d) Header checksum e) Flow label f) Header length g) Options

Kun IPv6: a (128-bits adresser), e (flow label).

Felles: b (version), c (TTL / hop limit), upper-layer protocol (next header).

Fjernet i IPv6: d (header checksum), f (header length), g (options) — fragmenteringsfelt er også fjernet.
Hvilke tjenester gir UDP? Kryss av: a) Throughput-garanti b) Loss-free c) Flow control d) Real-time e) Best effort f) Congestion control

Riktig: kun e (best effort). UDP gir ingen av a, b, c, d, f.

Hvorfor: UDP er minimal — bare port-multipleksing og en valgfri sjekksum oppå IP. All «kvalitet» må applikasjonen bygge selv.
Hvilke tjenester gir TCP? Kryss av: a) Throughput-garanti b) Loss-free (pålitelig) c) Flow control d) Real-time e) Best effort f) Congestion control

Riktig: b, c, f.

Hvorfor ikke a/d: TCP gir ikke båndbreddegaranti og ingen sanntidsgaranti — den passer raten til nettverkets kapasitet, ikke applikasjonens behov.

e: Best effort er en egenskap til nettverkslaget (IP), ikke transportlaget.
Hvorfor er HTTP-streaming over TCP mer populært enn UDP-streaming? Kryss av riktige: a) UDP er forbindelsesløs b) UDP mangler retransmisjon → høyere feilrate c) UDP gir lavere latency uten håndtrykk d) Brannmurer blokkerer ofte UDP, slipper HTTP gjennom

Riktig (grunner for HTTP/TCP): b og d.

Forklaring av c: Sant at UDP kan gi lavere latency, men det er en grunn til å velge UDP, ikke HTTP/TCP. Spørsmålet handler om hvorfor HTTP/TCP likevel dominerer.

Eksamensvinkel: Den klassiske begrunnelsen er at brannmurer slipper HTTP/443 gjennom, og at HTTP gjenbruker eksisterende web-infrastruktur (CDN, caching).
I TCPs cwnd-utvikling: når er TCP i slow start, og når er den i congestion avoidance?

Slow start: Eksponentiell vekst — cwnd dobler per RTT. Inntrer (1) ved oppstart med cwnd = 1 MSS, og (2) etter en timeout (cwnd resettes til 1, ssthresh = cwnd/2). Avsluttes når cwnd ≥ ssthresh.

Congestion avoidance (AIMD): Lineær vekst — cwnd øker med 1 MSS per RTT. Inntrer når cwnd ≥ ssthresh.

Triple duplikat-ACK: Reno halverer cwnd og går rett i AIMD; Tahoe resetter til 1 og går i slow start.
NAT: en intern host 10.0.0.1:3345 sender til 128.119.40.186:80. NAT-ruteren har ekstern IP 138.76.29.7 og oversetter til kildeport 5001. Hva er (kilde-IP, kilde-port, dest-IP, dest-port) på utsiden (punkt D)?

Svar: kilde-IP = 138.76.29.7, kilde-port = 5001, dest-IP = 128.119.40.186, dest-port = 80.

Hvorfor: NAT bytter bare kilde-IP og kilde-port på vei ut. Destinasjon er uendret. På vei inn igjen reverseres oversettelsen via NAT-tabellen.
Forwarding-tabell: 11001000 00010111 00010*** ******** → port 0; 11001000 00010111 00011000 ******** → port 1; 11001000 00010111 00011*** ******** → port 2; alt annet → port 3. Hvilken port for adressen 11001000 00010111 00011000 00001101?

Svar: Port 1.

Regn: Adressen matcher port 1 (24 bits eksakt) og port 2 (21 bits). Lengste prefiks vinner → port 1.

Generell regel: Test alltid hvert prefiks i tabellen, velg den med flest matchende bits.
Klassifiser hver protokoll som kanalpartisjonering, random access eller taking turns: Bluetooth, Ethernet (CSMA/CD), CDMA, Slotted ALOHA, FDDI, FDMA.
- Kanalpartisjonering: CDMA, FDMA.
- Random access: Ethernet (CSMA/CD), Slotted ALOHA.
- Taking turns: Bluetooth (polling fra master), FDDI (token ring).
Mnemonisk: Partisjonering = «alle får sitt rom». Random = «kjør og se». Taking turns = «vent på din tur».
Hva er hovedformålet til en brannmur? a) Kryptere data b) Blokkere uautorisert tilgang c) Tilby VPN d) Overvåke ytelse

Svar: b — blokkere uautorisert tilgang via filtrering på pakkenivå.

Felle: Kryptering (a) er TLS/IPsec sin jobb. VPN (c) er en bonus, ikke hovedformålet. Ytelsesovervåkning (d) er IDS/SNMP.
Beregn Internet checksum over to 16-bit ord: 11110101 11010011 og 10110011 01000100.
Svar: 10101001 00011000 — som er 1's complement av summen.

Stegene:
1. Summer: 1111010111010011 + 1011001101000100 = (1)1010100100010111 — en carry ut.
2. Carry-wrap: legg den oppe-rullede 1-en tilbake til lavest bit: 1010100100010111 + 1 = 1010100100011000.
3. 1's complement (snu alle bits): 0101011011100111.
(Resultatet stemmer med svaralternativet «01010110 11100111» fra eksamen.)
Maks effektivitet: pure ALOHA vs slotted ALOHA?

Pure ALOHA: 1/(2e) ≈ 18,4 %.

Slotted ALOHA: 1/e ≈ 36,8 % — eksakt dobbelt så mye.

Hvorfor 2×: I pure er sårbarhetsvinduet 2T (kan kollidere både med pakker som har startet før og som starter etter). I slotted halveres det til T ved tids-synkronisering.
Sant eller usant: «Svitsjer kobler ulike nett, rutere kobler enheter innen ett nett».

Svar: Usant — det er motsatt.

Riktig: Svitsjer (lag 2) kobler enheter innen ett LAN/subnett basert på MAC-adresser. Rutere (lag 3) kobler ulike nett basert på IP-adresser og slår opp i forwarding-tabeller.

Felle på eksamen: Denne formuleringen kommer ofte som distraktor.
Hva er forskjellen på ServerSocket og ConnectionSocket (TCP)?

ServerSocket: Den åpne lytte-porten (åpen for alle) som klienter sender oppkoblingsforespørsel til.

ConnectionSocket: En ny socket som serveren oppretter for én spesifikk TCP-forbindelse. Brukes under hele forbindelsens varighet for kommunikasjon med én klient.

Felle: «Server-socket bruker UDP, connection-socket bruker TCP» — feil, begge er TCP. Skillet er lytte vs per-forbindelse.
Hva er hovedoppgaven til DNS, og hvilke to fundamentale komponenter består den av?
Hovedoppgave: Directory service som oversetter hostnames (mennesker) til IP-adresser (rutere).

To komponenter:
1. En distribuert database implementert som et hierarki av DNS-tjenere.
2. En applikasjonslags-protokoll som lar hosts spørre databasen.
Gi en kort oversikt over DNS-server-hierarkiet (3 nivåer).
1. Root-tjenere: 13 stk på Internett, hver er egentlig et nett av replikerte tjenere (sikkerhet, redundans).
2. Top-Level Domain (TLD)-tjenere: Ansvar for toppdomener — com, org, net, edu, gov, no, uk, fr m.fl.
3. Autoritative DNS-tjenere: Hver organisasjon med offentlig nettsted/mail må ha autoritative records som mapper hostnames til IP. Drives selv (typisk primary + secondary backup) eller hos tjenesteleverandør.
Du setter opp en ny web-tjener med eget domenenavn. Hvordan kommer informasjonen inn i DNS?
1. Bruk en registrar som først sjekker at domenet er ledig.
2. Du oppgir navn + IP til primary og secondary autoritative DNS-tjenere.
3. Registraren legger inn nødvendig info i de relevante TLD-tjenerne (én NS-record + én A-record per autoritativ tjener).
4. Du legger selv inn A-record for web-tjeneren og MX-record for mail-tjeneren i dine egne autoritative DNS-tjenere.
1400 KB fil sendes over et linjesvitsjet nett. Oppsett tar 300 ms. 5 lenker, hver 1 Mbps. Minimum tid?

Svar: 11,5 sekunder.

Regn: Ende-til-ende-kretsen er en dedikert «leiet linje» — overføringen tar samme tid uansett antall lenker så lenge raten er den samme: 1400·1024·8 / 1·10⁶ ≈ 11,2 s. (Skikkelig 1400·8/1 = 11,2 s ved 1 KB = 1000 byte.)

Pluss 300 ms oppsettstid: 0,3 + 11,2 = 11,5 s.

Felle: Linjesvitsj ≠ pakkesvitsj — du legger ikke til L/R per lenke (ingen store-and-forward).
Inneholder et TCP-segment IP-adresser som en del av nyttelasten?

Svar: Nei.

Hvorfor: Nyttelasten i et TCP-segment kommer fra applikasjonslaget. IP-adresser legges til i nettverkslaget, der TCP-segmentet selv er nyttelasten.
Er det forskjell på hvordan sjekksum er implementert i TCP- vs UDP-segmenter?

Svar: Nei — samme type sjekksum (Internet checksum: 1's-complement-sum over 16-bit ord) brukes i begge.

Felle: «UDP har valgfri sjekksum, TCP har påkrevd» — det er bruken, ikke algoritmen, som er forskjellig.
Gi minst ett bruksområde der UDP er bedre enn TCP.
- Sanntidsapplikasjoner (VoIP, video) — tap-tolerante, men retransmisjon kommer for sent. FEC kan brukes istedet.
- Korte engangsmeldinger der oppkobling er overkill (DNS-spørringer).
- Lavere overhead, ingen oppkoblingsforsinkelse.
Forklar TCP 3-veis håndtrykk: tre steg, sekvens-/ACK-numre.
1. SYN (klient→server): SYN-bit = 1, sekvensnr = tilfeldig A.
2. SYN-ACK (server→klient): Server allokerer buffere/variabler. SYN = 1, ACK-nr = A+1, eget sekvensnr = tilfeldig B.
3. ACK (klient→server): Klient allokerer også buffere. SYN = 0, sekvensnr = A+1, ACK-nr = B+1.
Mnemonisk: Server allokerer ressurser ved steg 2 (mot SYN-flooding flytter SYN-cookies dette til etter steg 3).
Hva er flytkontroll i TCP, og hvorfor trengs den?

Svar: Mottaker styrer avsenderens sendetempo for å unngå at mottakerens buffer renner over.

Hvordan i TCP: Tellingsbasert byte-vindu. Avsender holder oversikt over sendte men ikke-bekreftede bytes. ACK-er er kumulative. Mottaker rapporterer ledig buffer i rwnd-feltet.

Vs congestion control: Flow control = mottakerens problem. Congestion control = nettverkets problem.
Nevn minst to ulike måter datapakker kan forsvinne på vei gjennom et pakkesvitsjet nett.
1. Bitfeil oppdages i ruter/svitsj → pakken kastes for å spare ressurser.
2. Bufferoverflyt ved høy last → ankommende pakker droppes.
3. Lenke-/nodefeil — brutte fiber, defekte rutere/svitsjer/repeatere/forsterkere.
4. Kollisjon i delt media (klassisk Ethernet, WiFi).
Forklar prosedyren for CRC-kode hos avsender — gitt datastreng D og generator G.
1. Legg til length(G) − 1 nuller bak D. Eks: D=101010, G=1011 (length 4) → 101010000.
2. Utfør modulo-2-divisjon (XOR) av D+nuller med G.
3. Resultatet av divisjonen brukes ikke. Resten (length G−1) = CRC-koden.
4. Send D etterfulgt av CRC istedenfor de tilføyde nullene. Eks: 101010001.
Mottaker: Deler hele streng (D + CRC) med G. Rest = 0 ⇒ feilfri overføring.
Forklar virkemåten til en linklags-svitsj. Hvordan skiller den seg fra en ruter?
Virkemåte:
- Videresender (eller filtrerer/dropper) rammer basert på MAC-adresser.
- Bruker switch-tabell: ukjent MAC → broadcast (alle utganger unntatt inn-porten). MAC peker mot inn-port → drop. Ellers → riktig port.
- Self-learning: Fyller tabellen med kilde-MAC fra mottatte rammer. Oppføringer slettes etter timeout.
- Plug-and-play / self-configuring.
Forskjell fra ruter: Svitsj opererer kun innenfor ett subnett, er transparent for hosts (har ikke egen IP/MAC), bruker MAC-adresser. Ruter har egen IP-adresse, opererer på lag 3, kobler ulike subnett.
Hva er ARP, og hvorfor er den nødvendig?

ARP = Address Resolution Protocol. Oversetter mellom IP-adresser (lag 3) og linklags-adresser (i praksis ofte Ethernet-MAC) lokalt i et subnett.

Hvorfor nødvendig: For at en host skal kunne sende en Ethernet-ramme til en annen host (eller default gateway), må den kjenne mottakerens MAC. ARP fyller hullet mellom IP og MAC.

Lagring: ARP-tabeller ligger i minne hos hver vert og hver ruter; oppføringer har timeout.
Hva er forskjellen på infrastructure mode og ad hoc mode i 802.11?

Infrastructure: Hosts er tilknyttet en basestasjon (AP) som kobler til kablet nett. AP gir DHCP, DNS, ruting osv.

Ad hoc: Ingen infrastruktur — hosts kommuniserer direkte. Hostene må selv stå for ruting, adressetildeling, DNS-lignende navneoppslag.
Hvorfor kan ikke CSMA/CD brukes i 802.11 (WiFi)?
1. Kollisjons-deteksjon krever samtidig sending og mottak. På WiFi er mottatt signal mye svakere enn eget sendt signal — kostbart å bygge maskinvare som kan oppdage kollisjoner.
2. Selv med simultan tx/rx ville ikke alle kollisjoner oppdages — pga. skjult terminal-problemet og signal-fading.
Siden CSMA/CD ikke brukes i 802.11 — hvordan vet en avsender at en dataramme er vellykket mottatt?

Svar: Mottakeren sender en eksplisitt ACK-ramme tilbake for hver mottatt dataramme. Hvis avsender ikke får ACK innen timeout, antas rammen tapt og retransmitteres.
Hovedforskjell CSMA/CD vs CSMA/CA — og hva betyr «CA»?
- CSMA/CD: Begynner å sende straks kanalen er ledig. Avbryter ved oppdaget kollisjon (CD = Collision Detection).
- CSMA/CA: Bruker en tilfeldig back-off-teller som telles ned før sending → reduserer sannsynligheten for kollisjon. Etter vellykket sending er det også et minimum «space» (IFS) som gir prioritert tilgang for ACK + andre korte kontroll-rammer (RTS/CTS).
CA = Collision Avoidance. Oppnås ikke fullt ut — to stasjoner kan fortsatt kollidere — men prosedyren gjør det mye mindre sannsynlig enn i Ethernet.
I moderne kryptografi: er algoritmen hemmelig eller kjent? Og nøkkelen?

Algoritmen: alltid antatt offentlig kjent. Sikkerheten ligger i å beskytte nøkkelen.

Symmetrisk: én nøkkel, delt mellom partene → konfidensialitet.

Offentlig nøkkel: nøkkelpar (privat + offentlig) → konfidensialitet, meldingsintegritet, digital signatur.

Historisk unntak: Symmetriske algoritmer var ofte hemmelige før (og er det fortsatt for noen militære bruksområder).
Hvordan kan public-key-kryptografi brukes direkte for digital signatur — og hva trengs i tillegg for at det virker?

Prinsipp: Avsender krypterer meldingen (eller en setning) med sin private nøkkel. Hvem som helst kan så bruke avsenders offentlige nøkkel for å verifisere at innholdet stemmer — og siden bare innehaveren av privatnøkkelen kunne lage krypteringen, er signaturen gyldig.

Krever: Du må vite med sikkerhet at den offentlige nøkkelen faktisk tilhører personen du verifiserer. Derfor trengs en betrodd tredjepart som utsteder et sertifikat som binder offentlig nøkkel til identitet.

For store meldinger: Signer hash-en av meldingen, ikke hele meldingen (effektivt).
Tre kategorier av brannmurer: hva er forskjellen?
- Traditional packet filters: Filter på alle ruter-innganger til organisasjonens nett. Beslutninger tas per pakke isolert — typisk på adresser + porter, evt. TCP ACK-bit. Implementeres som ACL.
- Stateful packet filters: Som over, men sporer i tillegg forbindelser (connection table) for mer effektiv og sikker filtrering.
- Application gateways: Applikasjonsspesifikke tjenere som all trafikk for den applikasjonen må gjennom. Ser på applikasjonsdata i tillegg til pakkefiltre — kan kreve brukernavn/passord før tilgang gis. Trenger én gateway per applikasjon (kan kjøre på samme host).
Nøkkelen: per-pakke → per-forbindelse → per-applikasjon (med applikasjonsdataforståelse).
Hovedgrunnen til at protokoll-lagdeling brukes i datanett?
Svar: Det tillater enkel re-bruk og oppdatering av komponenter i implementasjonen. Modulær struktur med klare grensesnitt mellom lag.

Feller:
- «Hindrer at ett lag dupliserer funksjonalitet under» — ikke hovedgrunnen.
- «Encapsulation er den mest effektive måten å overføre data på» — feil.
- «Holder strukturen så nettet kjører raskere» — feil; ikke en ytelsesfordel.
1 MB fil, kretskoblet nett. Oppsett 0,5 s, 2 lenker à 100 kbps. Minimum tid?
Svar: 80,5 s.

Regn: Tid = oppsettstid + L/R for hele filen.
- L/R = 10⁶ · 8 / (100·10³) = 8·10⁶/10⁵ = 80 s.
- + 0,5 s oppsett = 80,5 s.
Felle: Linjesvitsj ikke pakkesvitsj — du legger ikke på L/R per lenke.
1 MB fil pakkesvitsjet, 1000 byte/payload per pakke, 2 svitsjer mellom A og B, alle lenker 10 Mbps. Minimum tid?

Svar: 0,8008 s.

Regn: P = 1000 pakker, N = 3 lenker (A→sw1, sw1→sw2, sw2→B), L = 8000 bits.

Tid = (N + P − 1) · L/R = (3 + 1000 − 1) · 8000 / 10⁷ = 1002 · 0,0008 ≈ 0,8016 s.

Eks 5 har «2 svitsjer» = 2 hopp i pipelining-formelen avhengig av tolking — sjekk at antall lenker stemmer med tegningen.
Hvilke av disse er applikasjonslag-protokoller? ICMP · DNS · SMTP · ARP · FTP
Applikasjonslag: DNS, SMTP, FTP.

Andre lag:
- ICMP — nettverkslag (bæres i IP for feil/diagnose).
- ARP — lenkelag (oversetter IP ↔ MAC).
Hvilken protokoll har som hovedoppgave å oversette hostnames til IP-adresser?
Svar: DNS (Domain Name System).

Felle-alternativer:
- ARP — IP ↔ MAC, ikke navn.
- NAT — bytter IP/port, ikke navn.
- FTP — filoverføring.
- ICMP — feil/diagnose.
P2P-fildistribusjon: 125 MB til 100 peers. Server u_s=100 Mbps. Hver peer u_i=d_i=10 Mbps. Minimum tid?
Svar: ≈ 100 s (begrenset av tregeste peer-nedlasting).

F = 125·8 = 1000 Mbit. Formel: D = max(F/u_s, F/d_min, N·F/(u_s+Σu_i)).
- F/u_s = 1000/100 = 10 s.
- F/d_min = 1000/10 = 100 s.
- N·F/(u_s+Nu_i) = 100·1000/(100+1000) ≈ 90,9 s.
- Maks = 100 s.
Sammenlign klient-server: 100·1000/100 = 1000 s. P2P er 10× raskere her.
Host A sender to TCP-segmenter back-to-back til B. Første: seq=249, src=502, dst=80, 48 byte data. Hva er (seq, src, dst) i det andre segmentet (med 64 byte data)?

Svar: (seq=297, src=502, dst=80).

Hvorfor: Sekvensnr i andre segment = sekvensnr₁ + lengde₁ = 249 + 48 = 297. Source/dest-port byttes ikke i samme retning (A→B), så de er fortsatt 502 og 80.

Felle: Bytte src/dst (de byttes om i ACK-retningen B→A, ikke i samme retning).
Hvilke av disse er usanne? a) FTP bruker UDP. b) Både UDP og TCP er pålitelige. c) Både er forbindelsesorienterte. d) Nonpersistent HTTP kan bære to GET-meldinger på én TCP-forbindelse. e) Go-back-N tillater flere pakker uten ACK.
Usann: a, b, c, d.
- a) FTP bruker TCP, ikke UDP.
- b) UDP er ikke pålitelig.
- c) UDP er forbindelsesløs.
- d) Nonpersistent betyr én GET per TCP-forbindelse — ikke to.
- e) Sann — Go-back-N er pipelinet.
Konverter IP-adressen 193.32.216.9 til 32-bits binær.
Svar: 11000001 00100000 11011000 00001001.
- 193 = 128+64+1 → 11000001
- 32 = 32 → 00100000
- 216 = 128+64+16+8 → 11011000
- 9 = 8+1 → 00001001
Felle: Pass på 9 vs 8 i siste oktett (00001001 vs 00001000).
Du har 214.97.254.0/23 og må støtte 250 interfaces. Hvilke av disse er gyldige tildelinger? a) 214.97.253/24 b) 214.97.254/24 c) 214.97.255/24 d) 214.97.253/25 e) 214.97.254/25

Svar: b og c.

Hvorfor: /23 dekker tredje-oktett 254 og 255 (de to /24-blokkene). 253 er utenfor blokken. /25 gir bare 126 brukbare adresser — ikke nok for 250.
DHCP — sann/usann: a) Klient-server. b) Auto-tildeler IP. c) En host kan ikke få samme IP igjen. d) Avhengig av lenkelags-broadcast.

Sant: a, b, d.

Usant: c — sticky lease kan gi samme IP igjen og igjen.

Hvorfor d: DHCP Discover sendes som broadcast siden klienten ikke har IP enda.
IPv4 vs IPv6 — hvilke er sanne? a) IPv6 har større adresserom. b) IPv4 har checksum, IPv6 ikke. c) IPv6 mindre pålitelig. d) IPv6 tillater ikke fragmentering ved mellomliggende rutere. e) Begge er forbindelsesløse.

Sanne: a, b, d, e.

Usann: c — leveringsegenskapene er like (begge best-effort).

d-utdyping: I IPv6 kan kun avsenderen fragmentere (med Fragmentation extension header). Mellomliggende rutere kaster pakker som ikke passer MTU og sender ICMPv6 «Packet Too Big» tilbake.
Hvilke av disse er del av 802.11 MAC? a) CSMA/CA b) CSMA/CD c) ACK d) RTS/CTS e) DIFS

Del av 802.11 MAC: a (CSMA/CA), c (ACK), d (RTS/CTS — valgfritt), e (DIFS).

IKKE del av: b — CSMA/CD brukes ikke i WiFi (kan ikke detektere kollisjon trådløst).

DIFS = Distributed Inter-Frame Space — minimum tid stasjoner må vente etter at kanalen blir ledig før de kan sende.
Hvilke påstander om 4G og 5G er sanne? a) 5G har høyere peak-bitrate. b) 5G fysisk lag er kompatibelt med 4G. c) Begge støtter mobilitet. d) Begge har kontroll-/brukerplan-separasjon i kjernenettet.

Sanne: a, c, d.

Usann: b — 5G NR (New Radio) er et helt nytt luftgrensesnitt, ikke kompatibelt med 4G på fysisk lag.

d-utdyping: CUPS (Control and User Plane Separation) — innført i sen 4G-evolusjon (EPC), kjerne-arkitektur fra start i 5G (5GC).
Hvilke er sanne om SNR / BER / modulasjon? a) Høyere SNR → lavere BER (gitt modulasjon). b) Høyere SNR → høyere BER. c) Ved samme SNR: høyere bitrate-modulasjon → høyere BER. d) Adaptiv modulasjon & koding brukes i WiFi, 4G og 5G.

Sanne: a, c, d.

Usann: b — det er motsatt; mer signal i forhold til støy gir færre bitfeil.

d: AMC velger en mer robust (lavere bitrate) modulasjon når SNR faller, og en raskere modulasjon når SNR er godt.
10 personer, symmetrisk kryptografi, parvis hemmelig kommunikasjon. Hvor mange nøkler totalt?

Svar: 10·9/2 = 45.

Generelt: N(N−1)/2. Med public key trenger du bare 2N nøkler (1 par per person) — skalerer mye bedre.
Hvilke er ønskede egenskaper ved sikker kommunikasjon? a) Konfidensialitet b) Meldingsintegritet c) Endepunktsautentisering d) Operasjonell sikkerhet e) Public key cryptography

Riktige (egenskaper): a, b, c, d.

e er feil: Public key cryptography er et middel (en teknikk), ikke en egenskap. Det er CIA-triaden + autentisering + opsec som er egenskapene.
Meldingsintegritet — hvilke er sanne? a) Bekrefter avsenders identitet. b) Mottaker kan oppdage at meldingen er endret. c) Både checksum og hash kan brukes. d) Hash er bedre. e) Krever TCP.
Sanne: b, c, d.
- a er autentisering, ikke integritet.
- e er feil — integritet kan oppnås over UDP også.
Hvorfor hash > checksum: hash er kryptografisk (hard å konstruere kollisjoner). Checksum er bare design for uintendert bitfeil.
Hvorfor er HTTP-streaming mer populært enn UDP-streaming? Hvilke er sanne grunner? a) UDP er forbindelsesløs. b) UDP er upålitelig. c) UDP-streaming bruker klient-side bufring som forårsaker forsinkelse. d) Brannmurer blokkerer ofte UDP men slipper HTTP.

Hovedgrunner: b og d.

c er feil: Det er HTTP-streaming som typisk bruker stor bufring (TCP retransmisjon krever det). UDP-streaming har normalt mindre bufring.

a: Sant om UDP, men ikke i seg selv en grunn til å foretrekke HTTP.
Playout-buffer: Server sender blokk i ved t₀ + i·Δ. Klient starter avspilling ved t₁ + Δ. Hver blokk skal spilles av Δ etter forrige. Hvordan vurdere om blokk i rekker fram?

Regel: Blokk i rekker fram hvis ankomsttid ved klient ≤ planlagt avspillingstid for samme blokk.

Tegn tre kurver: sendekurve (start t₀, stigning Δ), ankomstkurve (faktisk, kan være forsinket/hakket), avspillingskurve (start t₁+Δ, stigning Δ).

Hver blokk i: marker punktet på ankomstkurven og se om det er på eller før avspillingskurven for samme i.

Eks 5: spør hvilke av blokk 1–7 rekker frem. Visuell oppgave — les av kurver.
Forwarding-tabell: 135.46.128.0/22 → I0; 135.46.0.0/22 → I1; 192.53.40.0/23 → I2; 192.128.0.0/13 → I3; default → I4. Hvilken interface for 135.46.129.10?

Svar: I0.

Regn: /22 betyr at de første 22 bits matcher. 135.46.128.0/22 dekker 135.46.128.0 – 135.46.131.255. 135.46.129.10 er innenfor → match. Andre prefiks matcher ikke.
Forwarding-tabell som over. Hvilken interface for 129.241.200.11?

Svar: I4 (default).

Hvorfor: 129.241 starter med 10000001 11110001. 192.128.0.0/13 starter med 11000000 1000 — første bit er 1 vs 1, andre er 0 vs 1 → ikke match. 135.46-blokkene starter med 10000111 — heller ikke match. Default-regel.
Tre nøkkelforskjeller mellom forwarding og routing?
1. Tidsskala: forwarding per pakke i nanosekunder; routing kjører i bakgrunnen i sekunder/minutter.
2. Plassering: forwarding i datapath (HW); routing i kontrollplan (SW + protokoll-utveksling).
3. Avhengighet: forwarding bruker tabellen; routing fyller tabellen via OSPF/BGP/RIP.
Andre vinkler: lokal vs global beslutning · per pakke vs per nett-tilstand · ingen kommunikasjon vs protokoll-utveksling.
HTTP responstid — non-persistent uten parallelle: side med base + 5 embedded objekter, RTT = 300 ms, R = 100 Mbps, hvert objekt 200 kbit. Total tid?

Svar: ≈ 3,61 s.

Per objekt: 2·RTT (TCP-oppsett + GET/response-RT) + L/R = 600 + 2 = 602 ms.

Total: 6 objekter · 602 ms = 3 612 ms.

Ev. legg til envegs propagering (150 ms) for siste bit hvis oppgaven krever det.
HTTP responstid — non-persistent med parallelle TCP. Side med base + 5 embedded à 200 kbit, RTT = 300 ms, R = 100 Mbps. Total tid?

Svar: ≈ 1,20 s.

Base først: 2·RTT + L/R = 602 ms. Deretter 5 parallelle: 602 ms. Totalt: 1 204 ms.

Hvorfor: 5 parallelle TCP-forbindelser kjører samtidig, så de blir ferdige etter samme 602 ms (forutsatt nok båndbredde til alle).
HTTP responstid — persistent uten pipelining. Base + 5 embedded à 200 kbit, RTT = 300 ms, R = 100 Mbps. Total tid?

Svar: ≈ 2,11 s.

1 TCP-oppsett (300 ms) + base (1·RTT + L/R = 302 ms) + 5 sekvensielle (1·RTT + L/R = 302 ms hver) = 300 + 6·302 = 2 112 ms.

Sparer (N) TCP-oppsett: persistent vinner over non-persistent uansett.
Hva er de tre målene for en brannmur?
1. All trafikk inn/ut må passere brannmuren — ingen bakdør rundt den.
2. Kun autorisert trafikk slipper igjennom — definert av en lokal sikkerhetspolicy.
3. Brannmuren selv må være motstandsdyktig mot kompromittering — herdet OS, minimum tjenester, fysisk beskyttet.
Forskjell mellom traditional (stateless) packet filter og stateful packet filter?

Stateless: Beslutning per pakke isolert. Ser bare på header-felt (IP, port, TCP-flags). Implementeres som ACL.

Stateful: Sporer i tillegg aktive forbindelser i en connection table. Kan kreve at innkommende TCP-pakker hører til en allerede etablert utgående forbindelse — fanger spoofede pakker bedre, blokkerer scanning.

Tillegg (Eks 4): Application gateway går videre — sjekker også applikasjonsdata (kan kreve username/passord). Per-app, ikke per-pakke eller per-forbindelse.
Flow control vs congestion control — tre nøkkelforskjeller?
1. Hvem styrer: mottaker styrer flow; nettverket / avsender-estimat styrer congestion.
2. Signal-mekanisme: rwnd-felt i ACK (flow) vs tap, timeout, duplikat-ACK eller ECN (congestion).
3. Hva som beskyttes: mottakerens motta-buffer (flow) vs ruterkøer / lenkebåndbredde (congestion).
Andre lag med lignende konsept: lenkelag (Stop-and-wait, sliding-window), nettverkslag (ICMP source quench / ECN). Fysisk lag har det ikke.

Slik er listen laget

Fem tidligere eksamener (Eks 1, Eks 2, Eks 3, Eks 4, Eks 5) ble lest gjennom og krysslest. Tema som dukket opp i flere av settene er markert som «høy frekvens». Ett sett alene er «medium». Eksamensinfoen sier at det ikke blir Wireshark-spørsmål denne gangen — den biten er deprioritert.

Kildemerking

Hvert «må kunne»-punkt under viser hvilke eksamener temaet er hentet fra. Eks1·Q1.3.4 betyr eksamen 1, oppgave 1.3.4. Filene ligger i eksamen-prep/.

5/5 Hver eneste eksamen — gratis vedd 4/5 Nesten gratis 3/5 Høy 2/5 Medium 1/5 Lav (men kan være sentralt nytt)

Frekvensanalyse · Eks 1–5

Veddet som er nesten gratis

Disse temaene har dukket opp i 4 eller alle 5 av de fem siste eksamenene. Hvis du bare har tid til å pugge én ting, så pugg disse — sannsynligheten for at de kommer igjen er svært høy.

5/5 Perfekt frekvens — kommer i hver eneste eksamen

UDP vs TCP-tjenester: hvilke tjenester gir/gir ikke hver av dem (best effort, flytkontroll, congestion, throughput-garanti). Aldri falt ut.
Forsinkelse og ende-til-ende-ytelse: L/R, store-and-forward, pipelining-formelen (N+P−1)·L/R, flaskehals/min(R₁,R₂), link-utilisering. Alltid en eller flere flervalg.
Internett-arkitektur og lagdeling: nuts-and-bolts vs tjenesteplattform, encapsulation, lagene og deres protokoller. Ofte i intro-spørsmål eller drag-and-drop.

4/5 Nesten gratis — bare ett av fem sett gikk uten

Sockets: SOCK_STREAM vs SOCK_DGRAM, antall sockets ved N klienter, ServerSocket vs ConnectionSocket. Eks 1, 2, 3, 4.
Subnetting / CIDR: maskeoperasjon, brukbare verter (2^(32−x)−2), broadcast-adresse, splitte i undernett. Eks 1, 2, 3, 5.
DNS: RR-format (Name, Value, Type, TTL), hva klienten får, transport (UDP/TCP), hierarki Root → TLD → autoritativ. Eks 2, 3, 4, 5.

3/5 Høy frekvens — kom i tre eksamener, sterke kandidater for retur

Pakke- vs linjesvitsj (Eks 2, 4, 5) — garantier, oppsettstid, ressursutnyttelse.
TCP cwnd / slow start (Eks 1, 2, 4) — graf-tolking, AIMD vs slow start.
Flow control vs congestion control (Eks 2, 3, 5) — tre forskjeller; lignende konsept på lenkelaget.
Forwarding vs routing (Eks 2, 3, 5) — tre forskjeller; lengste prefiks-match.
Svitsj vs ruter (Eks 2, 3, 4) — lag 2 vs lag 3, MAC vs IP, self-learning.
DHCP (Eks 2, 3, 5) — UDP, 4 steg, gir IP+maske+GW+DNS, sticky lease.
Sikkerhetsegenskaper (Eks 1, 2, 5) — konfidensialitet, integritet, autentisering, opsec. Ikke «høy båndbredde», ikke «public key cryptography» (det er et middel).
Symmetriske nøkler N(N−1)/2 (Eks 1, 2, 5) — pugg formelen.
2D-paritet (Eks 1, 2, 5) — detekter og rett 1-bit, detekter (ofte) 2-bit.
HTTP- vs UDP-streaming (Eks 2, 3, 5) — brannmur, retransmisjon, ordning.
Brannmur (Eks 3, 4, 5) — tre mål, tre kategorier (stateless / stateful / app gateway).

1–2/5 Husk også: nye tema fra Eks 5

Eks 5 introduserte flere tema som ikke har dukket opp før — disse er ferske, så fagstaben kan godt gjenta dem: P2P-fildistribusjon, HTTP responstid (non-persistent / parallell / persistent), IP→binær, 802.11 MAC-elementer (DIFS), 4G/5G mobilnett, video playout-buffer, protokoll-lagdeling — hvorfor. Se egen seksjon i Prediksjon 4.

Tema som går igjen

Disse er hentet fra alle fem eksamenene — de utgjør grunnstammen i pensum.

Frek.	Tema	Hva som testes	Funnet i
5/5	Internett-arkitektur	«Nuts and bolts» vs tjenesteplattform, network of networks, kapsling, lagdeling	Eks1·Q1.1.1, Eks1·Q1.1.4, Eks1·Q1.1.6, Eks2·Q1.1.4, Eks3·P2/Q2, Eks4·Q2.1a, Eks5·Q1.1.1
5/5	Forsinkelse og ytelse	L/R-formel, store-and-forward, (N+P−1)L/R, flaskehals, link-utilisering, FIFO-køforsinkelse	Eks1·Q1.1.5–9, Eks2·Q1.1.2–5, Eks2·Q1.3.4, Eks3·P2/Q2, Eks4·Q1.3, Eks5·Q1.1.2–4, Eks5·Q1.3.5
5/5	UDP vs TCP-tjenester	Best effort, flow control, congestion control — hva UDP og TCP gjør og ikke gjør; UDP-fordeler (sanntid, FEC, ingen oppkobling); FTP er TCP, ikke UDP	Eks1·Q1.2.1, Eks1·Q1.2.2, Eks2·Q1.2.4, Eks3·P1/Q3, Eks3·P1/Q13, Eks4·Q2.1c, Eks5·Q1.2.5
4/5	Sockets (UDP & TCP)	SOCK_STREAM/SOCK_DGRAM, accept(), antall sockets ved N klienter, ServerSocket vs ConnectionSocket	Eks1·Q1.2.6, Eks1·Q1.2.7, Eks2·Q1.2.3, Eks3·P2/Q4, Eks4·Q1.1
4/5	Subnetting / CIDR	Maskeoperasjon, gyldige adresser i /29, antall brukbare verter, broadcast i /21, splitte /23 til /24	Eks1·Q1.3.4, Eks2·Q1.3.1, Eks2·Q4, Eks3·P1/Q5, Eks3·P1/Q12, Eks5·Q1.3.2
4/5	DNS	UDP/TCP, RR-format, hva klienten får, hovedoppgave (directory + protokoll); DNS er applikasjonslag	Eks2·Q6, Eks3·P1/Q2, Eks4·Q1.2a, Eks5·Q1.2.1, Eks5·Q1.2.2
3/5	Pakke- vs linjesvitsj	Garantier, delay-variasjon, ressursutnyttelse, kretskobling-oppsettstid	Eks2·Q1.1.1, Eks4·Q1.3, Eks5·Q1.1.1, Eks5·Q1.1.3
3/5	TCP cwnd / slow start	Identifisere intervaller for slow start vs AIMD i graf, flytkontroll-scenario	Eks1·Q1.2.9, Eks2·Q2, Eks4·Q2.2b
3/5	Flow vs congestion control	Tre nøkkelforskjeller (hvem styres, signal, hva beskyttes); lignende konsept finnes også på lenkelaget (sliding window m.m.)	Eks2·Q2, Eks3·P1/Q3, Eks5·Q2
3/5	Forwarding vs routing — 3 forskjeller	Tidsskala (per-pakke vs sekunder), plassering (datapath vs kontrollplan), avhengighet (forwarding bruker tabellen routing fyller)	Eks2·Q1.3.5, Eks3·P2/Q1, Eks5·Q4.6
3/5	Svitsj vs ruter	Lag 2 vs lag 3, MAC vs IP, switch-tabell, self-learning, plug-and-play	Eks2·Q1.4.1, Eks3·P1/Q4(2,4,7,9), Eks4·Q3.2
3/5	DHCP	UDP, 4-stegs prosess, dynamisk IP + DNS + GW; lenkelags-broadcast brukes; kan gi samme IP hver gang (sticky lease)	Eks2·Q1.3.2, Eks3·P1/Q4(5), Eks5·Q1.3.3
3/5	2D-paritet	Detekter/rett 1-bit, detekter (ofte) 2-bit	Eks1·Q1.4.5, Eks2·Q1.4.2, Eks5·Q1.4.2
3/5	Sikkerhet — ønskede egenskaper	Konfidensialitet, integritet, autentisering, operasjonell sikkerhet (ikke «høy båndbredde», ikke «public key cryptography» som er et middel)	Eks1·Q1.4.8, Eks2·Q1.5.1, Eks5·Q1.5.1
3/5	Symmetriske nøkler	N(N−1)/2 ved N personer parvis	Eks1·Q1.4.9, Eks2·Q1.5.2, Eks5·Q1.5.2
3/5	HTTP- vs UDP-streaming	Brannmur, retransmisjon, ordning	Eks2·Q1.5.4, Eks3·P1/Q1, Eks5·Q1.5.5
3/5	Brannmur	Tre mål (all trafikk gjennom, kun autorisert, motstandsdyktig); tre kategorier (traditional / stateful / application gateway)	Eks3·P1/Q14, Eks4·Q5.3, Eks5·Q6
2/5	HTTP / web cache	GET-formål, caching-fordeler, port 80, persistent	Eks1·Q1.2.3, Eks1·Q1.2.4, Eks2·Q1.2.2
2/5	TCP/UDP-sjekksum	Samme type sjekksum i begge — 1's complement over 16-bit ord	Eks1·Q1.2.8, Eks4·Q2.1b
2/5	Longest prefix match	Velge ut-port fra forwarding-tabell	Eks1·Q1.3.3, Eks5·Q4.1–4.5
2/5	ICMP	Bæres i IP, brukes til feil/diagnose, traceroute	Eks1·Q1.3.6, Eks2·Q1.3.3
2/5	IPv4 vs IPv6	Flow label kun i IPv6; IPv4 har header checksum, IPv6 ikke; IPv6 fragmenterer ikke i mellomliggende rutere; begge er forbindelsesløse	Eks1·Q1.3.5, Eks5·Q1.3.4
2/5	ARP	Oversetter IP ↔ MAC lokalt i et subnett; ARP-tabeller i hosts og rutere	Eks4·Q3.3, Eks5·Q1.4.1
2/5	CSMA tidslinje	Bestemme hvilke pakker som lykkes ved gitt propageringstid	Eks1·Q1.4.3, Eks1·Q1.4.4, Eks3·P2/Q7
2/5	Pure / slotted ALOHA	Effektivitet (~18% vs ~37%), synkronisering	Eks1·Q1.4.2, Eks2·Q1.4.5
2/5	RTS/CTS, skjult terminal	Hva CTS gjør, hidden node-problemet	Eks1·Q1.4.6, Eks2·Q1.4.4
2/5	4-noder topologi (A–B–C–D)	Max rate C→A, A→B + D→C, A→B + C→D, og samme med ACK	Eks1·Q1.4.7, Eks2·Q5
2/5	SNR / BER / modulasjon	Lavere SNR → høyere BER, høyere bitrate-modulasjon → høyere BER ved samme SNR; adaptiv modulasjon & koding i WiFi/4G/5G	Eks2·Q1.4.3, Eks5·Q1.4.3
2/5	Trudy: avlytte/endre/slette/sette inn	Hvilke handlinger en aktiv angriper kan ta	Eks1·Q1.4.10, Eks2·Q1.5.5
2/5	Meldingsintegritet	Hash vs checksum, hvorfor hash er bedre; trenger ikke TCP — kan brukes over UDP	Eks2·Q1.5.3, Eks5·Q1.5.3
2/5	Symmetrisk vs offentlig nøkkel	Én delt vs nøkkelpar — bruk og forskjell; algoritme er kjent, nøkkel er hemmelig	Eks3·P2/Q6, Eks4·Q5.1
1/5	Protokoll-lagdeling — hvorfor	Re-bruk og oppdatering av komponenter, modularitet — ikke «raskere nett» eller «encapsulation er mest effektivt»	Eks5·Q1.1.5
1/5	HTTP-ytelse (response time) · nytt fra Eks 5	Non-persistent vs parallelle TCP vs persistent — regne ut total tid for base + N embedded	Eks5·Q5.1, Q5.2, Q5.3
1/5	P2P-fildistribusjon · nytt fra Eks 5	Min tid = max(F/u_s, F/d_min, N·F/(u_s+Σu_i)); skalerer mye bedre enn klient-server ved stor N	Eks5·Q1.2.3
1/5	Klient-server filfordeling	Min tid = max(N·F/u_s, F/d_min); server er nesten alltid flaskehals	Eks2·Q1.2.5
1/5	TCP back-to-back-segmenter · nytt fra Eks 5	Sekvensnr i andre segment = sekvensnr₁ + lengde₁. Kilde/dest-port byttes ikke i samme retning.	Eks5·Q1.2.4
1/5	HTTP vs SMTP	Push/pull, port 80 vs 25, persistent connection	Eks1·Q1.2.5
1/5	DNS-hierarki & registrering	Root → TLD → autoritative servere; registrar-prosess for nytt domene	Eks4·Q1.2b, Eks4·Q1.2c
1/5	TCP-handshake	3-veis (SYN → SYN-ACK → ACK), buffere allokeres på server før klient	Eks4·Q2.2a
1/5	Pakketap i nettet	Bitfeil, bufferoverflyt, lenke-/nodefeil, kollisjon i delt media	Eks4·Q2.3
1/5	CRC	Modulo-2-divisjon, legg til G−1 nuller, rest = CRC	Eks4·Q3.1
1/5	Internet checksum	16-bits addisjon med carry-wrap	Eks1·Q1.2.8
1/5	IP-adresse til binær · nytt fra Eks 5	Konvertere desimal punktnotasjon til 32-bits binær (oktett for oktett)	Eks5·Q1.3.1
1/5	NAT	Lese tabell, fylle inn IP/port på utsiden	Eks1·Q1.3.10
1/5	Best effort	Ingen garantier — kryss av alle «ikke garantert»	Eks1·Q1.3.7
1/5	Multiple access (klassif.)	Channel partitioning vs random access vs taking turns	Eks3·P1/Q6
1/5	CSMA/CD vs CSMA/CA	Backoff-counter, IFS, hvorfor CD ikke fungerer i WiFi, eksplisitt ACK	Eks4·Q4.2, Eks4·Q4.3
1/5	802.11 MAC-elementer · nytt fra Eks 5	CSMA/CA + ACK + RTS/CTS (valgfritt) + DIFS — ikke CSMA/CD	Eks5·Q1.4.4
1/5	Infrastructure vs ad hoc (802.11)	Med basestasjon vs uten — ad hoc krever ruting/DNS/adressering selv	Eks4·Q4.1
1/5	4G / 5G mobilnett · nytt fra Eks 5	5G > 4G peak bitrate; ikke fys-lag-kompatibel; begge støtter mobilitet; begge har kontroll-/brukerplan-separasjon i kjernenettet	Eks5·Q1.4.5
1/5	Multimedia: playout-buffer · nytt fra Eks 5	Server sender blokk i ved t₀ + iΔ; klient starter avspilling ved t₁ + Δ — hvilke blokker rekker frem i tide	Eks5·Q1.5.4
1/5	Cæsar-cipher	Beskrivelse + kode/dekode med gitt k	Eks3·P2/Q5
1/5	Digital signatur	Krypter med privat nøkkel, verifiser med offentlig; trenger sertifikat (TTP)	Eks4·Q5.2
1/5	Stor «protokollkjede»-oppgave	Fra plug-in → DHCP → DNS → SMTP → IMAP/HTTP. Lag og protokoller per steg	Eks3·P2/Q3

Må kunne — punkt for punkt

Hvert punkt har: (1) hva du må få til, (2) hvorfor det testes, og (3) hvilke eksamener du finner det i.

Kapittel 1 — Intro og ytelse

Ruting vs videresendingHøy

Eks2·Q1.3.5 · Eks3·P2/Q1

Må kunne

Forklare på én setning hver: videresending = lokal handling i én ruter (input-port → output-port via tabell). Ruting = global, distribuert prosess som beregner stiene og fyller tabellen.

Hvorfor: Klassisk forveksling. Eksamen tester med dropdown / fyll-inn der eneste forskjell er ordenes plassering. Husk: «forwarding er local, routing er global».

Beregne ende-til-ende-forsinkelseHøy

Eks1·Q1.1.5, Q1.1.8 · Eks2·Q1.1.2, Q1.1.3, Q1.1.5

Må kunne

d_trans = L / R per link.
Én svitsj store-and-forward: L/R₁ + L/R₂.
P pakker, N rutere, samme R, back-to-back: (N + P − 1) · L/R.
Cut-through (sender etter første X byte): X/R + L/R over resten — pass på enheter.
Ende-til-ende inkludert propagering: legg til d_prop per hopp.

Hvorfor: Kommer i nesten enhver Del I. Felle: glemme byte→bit (×8), eller blande maks gjennomstrømning med ende-til-ende-forsinkelse.

Flaskehals og maks gjennomstrømningHøy

Eks1·Q1.1.7, Q1.1.9 · Eks5·Q1.1.2

Må kunne

Identifisere den minste raten på stien. Hvis K TCP-økter deler en lenke med rate R, får hver økt R/K (fair share). Sjekk så om aksesslenken (Rs eller Rc) er lavere — da er den flaskehalsen.

Klassisk Eks 5-svar: server → ruter → klient med rater R₁ og R₂. Maks gjennomstrømning = min(R₁, R₂) — ikke summen, og ikke gjennomsnittet.

Link-utilisering = faktisk rate / linkrate, oppgitt som desimal (0,xx).

Hvorfor: Eks 1 hadde tre slike rett etter hverandre. Tegn alltid en liten skisse og merk ratene før du regner.

Linjesvitsj-tid (kretskoblet)Med

Eks4·Q1.3 · Eks5·Q1.1.3

Må kunne

Total tid = oppsettstid + L/R for hele filen. Raten R er den samme over hele kretsen — du legger ikke på L/R per lenke (ingen store-and-forward).

Eks 5-eksempel: 1 MB fil, oppsett 0,5 s, 2 lenker à 100 kbps. Tid = 0,5 + (10⁶·8)/(100·10³) = 0,5 + 80 = 80,5 s.

Hvorfor: Klassisk felle: studenten regner som pakkesvitsj og legger på L/R per lenke. Linjesvitsj = dedikert «leiet linje» fra ende til ende.

Protokoll-lagdeling — hvorforMed

Eks5·Q1.1.5

Må kunne

Hovedgrunnen er at det tillater enkel re-bruk og oppdatering av komponenter i implementasjonen — modulær struktur, klare grensesnitt mellom lagene.

Feller å unngå:

«Hindrer at ett lag dupliserer funksjonalitet under» — ikke hovedgrunnen.
«Encapsulation er den mest effektive måten å overføre data på» — feil.
«Holder nettet strukturert så det kjører raskere» — feil, ikke en ytelsesfordel.

Hvorfor: Multiple choice der distraktorene er nesten-riktige formuleringer. Det er vedlikehold/modularitet som er den ekte grunnen.

Kapittel 2–3 — Applikasjon og transport

UDP- og TCP-tjenester (kryssliste)Høy

Eks1·Q1.2.1, Q1.2.2 · Eks3·P1/Q13 · Eks4·Q2.1c

Må kunne

For et «check all that apply»-spørsmål, internaliser denne tabellen:

UDP gir: Best effort, multipleksing via porter.
UDP gir IKKE: Pålitelighet, flytkontroll, congestion control, throughput-garanti, real-time-garanti.
TCP gir: Pålitelig in-order bytestrøm, flow control, congestion control.
TCP gir IKKE: Throughput-garanti, real-time-garanti.

Når UDP er bedre enn TCP: Sanntid (VoIP, video) der retransmisjon er for sent, små engangsmeldinger som DNS (slipper oppkobling), eller når FEC erstatter retransmisjon. Mindre overhead, ingen oppkoblingsforsinkelse.

Hvorfor: 6 av 6 alternativer kan markeres feil hvis du ikke er nøye. Husk: throughput-garanti finnes i ingen av dem. Eks 4 spør hvilke fordeler UDP har — bruk listen over.

Flow control vs congestion controlHøy

Eks2·Q2 · Eks3·P1/Q3 · Eks5·Q2

Må kunne

Flow control: mellom avsender og mottaker. Beskytter mottakers buffer. Styres av rwnd-feltet i ACK.

Congestion control: mellom avsender og nettverket. Beskytter rutere fra overbelastning. Styres av cwnd (slow start, AIMD).

Klassisk eksempel-spørsmål: «A sender 1 Gbps inn, B leser 600 Mbps ut — hva skjer?» Svar: rwnd → 0, sender stopper. Det er flow control, ikke congestion.

Eks 5-formulering — tre nøkkelforskjeller:

Hvem styrer: mottaker (flow) vs nettverket / avsenderens egen estimat av nettet (congestion).
Signal-mekanisme: rwnd-feltet i hver ACK (flow) vs tap, timeout, dup-ACK eller ECN (congestion).
Hva som beskyttes: mottakerens motta-buffer (flow) vs ruterkøer / lenkebåndbredde (congestion).

Eks 5 Q2.2 — finnes lignende konsepter på andre lag? Lenkelaget har det klart sterkest: hopp-for-hopp flytkontroll (Stop-and-wait, Go-back-N, sliding window-protokoller — sender venter ikke evig på mottakerens ACK). Network layer kan ha overbelastningsindikatorer (ICMP source quench historisk, ECN moderne). Fysisk lag har det ikke — der er det bare bits over et medium.

Hvorfor: Eks 2 hadde dette som åpen 6-poengsoppgave; Eks 3 hadde sann/usann «de er det samme» (svar: nei); Eks 5 ber om tre forskjeller pluss «hvilke andre lag har lignende konsept».

Sockets — antall og typerHøy

Eks1·Q1.2.6, Q1.2.7 · Eks2·Q1.2.3 · Eks3·P2/Q4 · Eks4·Q1.1

Må kunne

UDP: SOCK_DGRAM. Ingen accept(). Én socket på server kan ta i mot fra mange klienter — applikasjonen må selv sette dest-IP/port på hver send.
TCP: SOCK_STREAM. Server har én lyttende socket; accept() skaper en ny server-socket per klient.
5 klienter på TCP-port 80: 1 lyttende + 5 forbindelses-sockets = 6. Hver forbindelse identifiseres av 4-tuple.
3 klienter sender UDP til samme server-port: Server trenger bare 1 socket.
ServerSocket vs ConnectionSocket (TCP): ServerSocket = den åpne lytte-porten man sender oppkoblingsforespørsel til. ConnectionSocket = ny socket serveren oppretter for én spesifikk TCP-forbindelse, brukt under hele forbindelsens varighet.

Hvorfor: Eks 3 hadde dette som åpen 5-poengsoppgave; Eks 1 hadde flervalg på samme tema; Eks 4 spør spesifikt etter ServerSocket vs ConnectionSocket-skillet.

Klient-server filfordelingMed

Eks2·Q1.2.5

Må kunne

Minimum tid for å distribuere fil av størrelse F til N klienter:

D_cs = max(N·F / u_s, F / d_min)

u_s: server-opplastningsrate.
d_min: minste nedlastningsrate blant klientene.
Eksempel: F=10 Gbit, N=100, u_s=1 Gbps, d_i=200 Mbps. → max(100·10/1, 10/0,2) = max(1000, 50) = 1000 s.

Hvorfor: Server er som regel flaskehalsen i klient-server. P2P-formelen er mer kompleks, men dukker opp på Eks 5.

P2P-fildistribusjonMed

Eks5·Q1.2.3

Må kunne

Minimum tid med P2P-arkitektur (alle peers laster opp og ned):

D_P2P = max(F/u_s, F/d_min, N·F / (u_s + Σu_i))

Term 1 (F/u_s): server må sende ut filen minst én gang.
Term 2 (F/d_min): tregeste klient kan ikke få filen raskere enn sin egen nedlastingskapasitet.
Term 3 (N·F/(u_s + Σu_i)): den samlede opplastingskapasiteten må kunne levere N kopier av F.

Eks 5-eksempel: F = 125 MB = 1000 Mbit, N = 100, u_s = 100 Mbps, hver peer: u_i = d_i = 10 Mbps.

F/u_s = 1000/100 = 10 s.
F/d_min = 1000/10 = 100 s.
N·F/(u_s+N·u_i) = 100·1000/(100+1000) = 100 000/1100 ≈ 91 s.
Maks = 100 s.

Hvorfor P2P er bedre enn klient-server ved stor N: samlet opplastingskapasitet vokser med antall peers (Σu_i), så server slutter å være flaskehals. Sammenlign med klient-server: 100·1000/100 = 1000 s — 10× tregere.

HTTP responstid (non-persistent / parallell / persistent)Med

Eks5·Q5.1, Q5.2, Q5.3

Må kunne

For en side med base + N embedded objekter, der hvert objekt er L bits, RTT er kjent og link-rate er R:

Non-persistent, ingen parallelle: 1 TCP-oppsett (1·RTT) + henting av base (1·RTT + L/R) + N gjentakelser av (TCP-oppsett 1·RTT + henting 1·RTT + L/R) = (N+1) · (2·RTT + L/R).
Non-persistent + parallelle TCP-forbindelser: Base hentes først som over (2·RTT + L/R). Deretter åpnes N parallelle TCP-forbindelser samtidig — alle ferdige etter ytterligere (2·RTT + L/R). Totalt: 2 · (2·RTT + L/R).
Persistent uten pipelining: 1 TCP-oppsett (1·RTT) + base (1·RTT + L/R) + N sekvensielle (1·RTT + L/R). Totalt: RTT + (N+1) · (RTT + L/R).
Husk å legge til ev. propageringen for siste bit til klient. Eks 5 spesifiserte 150 ms en-vei prop.

Eks 5-tall: base + 5 embedded à 200 kbit (= L), RTT = 300 ms, R = 100 Mbps. L/R = 200·10³ / 10⁸ = 2 ms (svært lite ift RTT). Per objekt non-persistent ≈ 2·300 + 2 = 602 ms.

Q5.1 (non-persistent, sekvensielt): 6 · 602 ms ≈ 3,61 s.
Q5.2 (non-persistent, parallelt for embedded): base først (602 ms) + 5 parallelle (602 ms) ≈ 1,20 s.
Q5.3 (persistent uten pipelining): 2·RTT + L/R (base) + 5·(RTT + L/R) (resten sekvensielt) ≈ 602 + 5·302 ≈ 2,11 s.

Hvorfor: Eks 5 hadde dette som 11-poengsoppgave med tre underpunkter. Sett alltid opp formelen generelt først, så plug inn tall — det gir delpoeng selv ved regnefeil. Husk at parallelt typisk slår persistent når L/R er liten; persistent slår non-persistent uansett fordi du sparer (N) TCP-oppsett.

HTTP, GET og web-cacheMed

Eks1·Q1.2.3, Q1.2.4, Q1.2.5 · Eks2·Q1.2.2

Må kunne

HTTP GET = klient ber server om et objekt. Port 80.
Web-cache: lavere forsinkelse for klient, lavere båndbredde inn til institusjon, og lavere snitt-forsinkelse også for ikke-cachede objekter (mindre belastning på opplinken).
HTTP-only egenskaper vs SMTP: client pull, port 80, persistent. SMTP: client push (mellom mailservere), port 25, CRLF.CRLF for slutt.

Internet checksumMed

Eks1·Q1.2.8 · Eks4·Q2.1b

Må kunne

Steg: (1) summer 16-bits ord, (2) carry tilbake (carry-wrap), (3) ta 1's complement.

TCP vs UDP: Samme type sjekksum i både TCP- og UDP-segmenter — ingen forskjell.

Hvorfor: Mottaker validerer ved å summere alt + checksum og sjekke at alle bits = 1. Eks 4 spør «er det forskjell mellom TCP- og UDP-sjekksum?» — svar: nei.

TCP cwnd-graf — slow start vs AIMDMed

Eks1·Q1.2.9

Må kunne

Slow start: cwnd dobles per RTT (eksponensiell). AIMD: cwnd øker med 1 MSS per RTT (lineær). Etter timeout: cwnd → 1, slow start fra start. Etter triple dup ACK: cwnd halveres, fortsett AIMD (fast recovery).

DNS-format og transportMed

Eks2·Q6 · Eks3·P1/Q2 · Eks4·Q1.2a

Må kunne

RR = (Name, Value, Type, TTL). Type A → IPv4, NS → autoritativ navneserver, CNAME → alias, MX → mailserver. Klienten kan få: IP-adresse, mail-server, alias, autoritative servere, TTL.

Transport: UDP (oftest, port 53) — kan også bruke TCP for store svar / soneoverføring.

DNS-hovedoppgave: «Directory service» som oversetter hostnames til IP-adresser. To fundamentale komponenter: (1) en distribuert database implementert i et hierarki av DNS-tjenere, og (2) en applikasjonslags-protokoll som lar hosts spørre databasen.

DNS-server-hierarkiMed

Eks4·Q1.2b

Må kunne

Tre klasser DNS-tjenere — kort oversikt:

Root-DNS-tjenere: 13 stk på Internett (men hver er egentlig et nett av replikerte tjenere for redundans/sikkerhet).
Top-Level Domain (TLD)-tjenere: Ansvarlig for toppdomenene (com, org, net, edu, gov, no, uk, fr …).
Autoritative DNS-tjenere: Hver organisasjon med offentlige hosts (web/mail) må ha autoritative DNS-records som mapper hostnames til IP. Drives selv eller hos tjenesteleverandør (typisk primary + secondary backup).

Hvorfor: Eks 4 spør om kort oversikt over hierarkiet — de tre nivåene utenat gir nesten full pott.

Sette opp ny web-tjener i DNSMed

Eks4·Q1.2c

Må kunne

Bruk en registrar. Den sjekker at domenet er unikt (ikke i bruk).
Oppgi navn og IP til primary og secondary autoritative DNS-tjenere.
Registraren legger info inn i relevante TLD-tjenere (én NS-record + én A-record per autoritativ tjener).
Du legger selv inn A-record for web-tjeneren og MX-record for mail-tjeneren i dine autoritative DNS-tjenere.

Hvorfor: Selv om man ikke trenger å huske RR-typer for full pott på Eks 4, gir det stødigere svar — A og MX dukker opp i annen DNS-oppgave.

TCP 3-veis håndtrykkMed

Eks4·Q2.2a

Må kunne

SYN (klient → server): SYN-bit = 1, sekvensnummer = tilfeldig A.
SYN-ACK (server → klient): Server allokerer buffere/variabler. Sender SYN = 1, ACK-nummer = A+1, eget sekvensnummer = tilfeldig B.
ACK (klient → server): Klient allokerer også buffere. SYN-bit = 0, sekvensnummer = A+1, ACK-nummer = B+1.

Hvorfor: Eks 4 ber om kort oversikt — nevn de tre stegene, ressursallokering på begge sider, og at ACK-nummer = mottatt sekvens + 1. Alt annet er bonus.

Hvorfor pakker forsvinner i nettetMed

Eks4·Q2.3

Må kunne (minst 2 av 4)

Bitfeil: Pakken kastes i ruter/svitsj hvis sjekksum/CRC oppdager ikke-korrigerbare feil (sparer ressurser).
Bufferoverflyt: Ved høy last kan køer renne over → ankommende pakker droppes.
Lenke- eller nodefeil: Brutte fiber, defekte rutere/svitsjer/repeatere/forsterkere.
Kollisjoner i delt media: WiFi, klassisk Ethernet eller andre delte medier — pakkene kan kollidere og gå tapt.

Hvorfor: Lett 2-poengs spørsmål. Bare nevn to forskjellige mekanismer — ulike hovedklasser (feil, kø, fysisk, kollisjon).

Kapittel 4–5 — Nettverkslag

IP-adresse → binærMed

Eks5·Q1.3.1

Må kunne

Konverter hver av de fire oktettene uavhengig til 8-bits binær. Bruk verditabellen 128, 64, 32, 16, 8, 4, 2, 1 — sett bit = 1 der summen treffer.

Eks 5-eksempel: 193.32.216.9

193 = 128 + 64 + 1 → 11000001
32 = 32 → 00100000
216 = 128 + 64 + 16 + 8 → 11011000
9 = 8 + 1 → 00001001
Svar: 11000001 00100000 11011000 00001001

Hvorfor: Multiple choice — 4 av alternativene har subtile bit-feil (typisk i siste oktett: 8 → 00001000 vs 9 → 00001001). Tell to ganger.

Subnetting til punkt og prikkeHøy

Eks1·Q1.3.4 · Eks2·Q1.3.1, Q4 · Eks3·P1/Q5, P1/Q12 · Eks5·Q1.3.2

Må kunne

Subnett-adresse: IP AND maske (binær).
Brukbare verter i /x: 2^(32−x) − 2 (minus nett- og broadcast-adresse).
Splitt /22 i ≥12 subnett: trenger 4 nett-bits → /26, gir 2^6−2 = 62 verter per subnett.
Broadcast for /21: sett alle vertsbits = 1, f.eks. 172.18.16.0/21 → 172.18.23.255.
Adresser som ikke kan brukes i et /29: nettadresse, broadcast, adresser utenfor range, adresser med feil prefiks.

Hvorfor: Subnetting kommer i 100 % av disse eksamenene. Tren med /28, /29, /30 i hodet — det er det vanligste.

Longest prefix matchingHøy

Eks1·Q1.3.3 · Eks5·Q4.1–Q4.5

Må kunne

For hver dest-IP: finn alle prefiks i tabellen som matcher → velg det lengste. Det gir ut-porten. Hvis ingen matcher → default-regel.

Tips: konverter både IP og hver prefiks-rad til binær side om side, sammenlign topp-bits. Husk at /22 dekker 4 påfølgende /24-blokker (siste 2 bit i tredje oktett er host).

Eks 5-tabell-felle: både 135.46.128.0/22 og 192.128.0.0/13 kan virke nær — sjekk at alle prefiks-bits stemmer, ikke bare de første.

Forwarding vs routing — 3 forskjellerHøy

Eks5·Q4.6

Må kunne

Listen tre uavhengige akser:

Tidsskala: forwarding skjer per pakke i nanosekunder; routing kjører i bakgrunnen i sekunder/minutter.
Plassering: forwarding ligger i datapath (raskt hardware-oppslag); routing ligger i kontrollplan (programvare som utveksler topologi-info).
Avhengighet: forwarding bruker tabellen; routing fyller tabellen via protokoller (OSPF, BGP).

Andre gyldige forskjeller du kan nevne: lokal vs global beslutning; per pakke vs per nett-tilstand; krever ingen kommunikasjon (forwarding) vs krever protokoll-utveksling (routing).

Hvorfor: Eks 5 spør eksplisitt om tre forskjeller. Husk: routing fyller forwarding-tabellen — uten routing-protokoller har en ruter ingen tabell å slå opp i.

NAT-tabell-utfyllingMed

Eks1·Q1.3.10

Må kunne

På utgående pakke (LAN → WAN): kilde-IP/port → byttes til ruterens offentlige IP og NAT-port. Dest-IP/port: uendret.

På innkommende pakke (WAN → LAN): omvendt — ruteren slår opp NAT-port i tabell og bytter dest til intern IP/port.

ICMP-fakta (sann/usann)Høy

Eks1·Q1.3.6 · Eks2·Q1.3.3

Må kunne

Sann: brukt av host og rutere for nettverksnivå-info.
Sann: bæres direkte i IP-datagram (ikke i UDP/TCP, ikke port 86).
Sann: TTL-expired brukes av traceroute.
Usann: «ICMP er en transportprotokoll».

DHCP-faktaMed

Eks2·Q1.3.2 · Eks3·P1/Q4(5) · Eks5·Q1.3.3

Må kunne

UDP, ikke TCP. Klient-server-protokoll. 4 steg (Discover/Offer/Request/ACK). Tildeler IP, subnettmaske, gateway, DNS. Brukes ikke til å rute datapakker.

Eks 5-detaljer:

«DHCP er en klient-server-protokoll» — sant.
«DHCP lar host få en IP-adresse automatisk» — sant.
«Det er ikke mulig at en gitt host får samme IP hver gang» — usant! En sticky lease kan gi samme IP igjen og igjen.
«DHCP er avhengig av lenkelags-broadcast for å virke» — sant (Discover-meldingen er broadcast).

IPv4 vs IPv6 — hva er nytt og hva er fjernetMed

Eks1·Q1.3.5 · Eks5·Q1.3.4

Må kunne

Nytt i IPv6: flow label, 128-bits adresser.
Fjernet i IPv6: header checksum, header length, fragmenteringsfelt, options.
I begge: TTL/hop limit, version, source/dest, upper-layer-protocol/next-header.

Eks 5-utvidelse:

«IPv6 har mye større adresserom enn IPv4» — sant.
«IPv4 har checksum-felt som hjelper ruteren å oppdage bitfeil; IPv6 har ikke» — sant.
«IPv6 er mindre pålitelig enn IPv4 i å transportere datagrammer» — usant. Begge er best-effort med tilsvarende leveringsegenskaper.
«IPv6 tillater ikke fragmentering og reassembly i mellomliggende rutere» — sant (kun avsender kan fragmentere i IPv6).
«Både IPv4 og IPv6 er forbindelsesløse» — sant.

Best effort — hva som ikke garanteresMed

Eks1·Q1.3.7

Må kunne

Ingen garantert levering, ingen leveringstid, ingen rekkefølge, ingen minimumsbåndbredde. Markér «no guarantees at all» når den er listet.

FIFO-køforsinkelseMed

Eks2·Q1.3.4 · Eks5·Q1.3.5

Må kunne

Køforsinkelse = (start-tid for transmisjon) − (ankomsttid). For Pakke i i FIFO: hvis kanalen er opptatt når Pakke i ankommer, må den vente til alle tidligere pakker er ferdig. Avles direkte på et slot-diagram.

Eks 5: figur viser pakker i ulike slot-er. For Pakke 6 spør oppgaven «hva er køforsinkelsen mellom ankomst og start av slot for transmisjon». Svar avleses ved å telle antall slot fra ankomst til start av sending.

Kapittel 6–7 — Lenkelag og trådløst

Svitsj vs ruterHøy

Eks2·Q1.4.1 · Eks3·P1/Q4(2,4,7,9) · Eks4·Q3.2

Må kunne

Svitsj: lag 2, MAC, lokal LAN. Ruter: lag 3, IP, mellom nett. ARP brukes til å finne MAC for første hopp.

Sant/usant-feller: «svitsj kobler nett, ruter kobler enheter» → feil. «Aksessrutere bruker hele IP-adressen» → sant. «Kjernrutere bruker bare nett-delen» → sant.

Linklags-svitsj — virkemåte (Eks 4):

Videresender (eller filtrerer) innkommende rammer basert på MAC-adresser.
Bruker en switch-tabell: hvis MAC ikke er i tabellen → broadcast (alle utganger unntatt der den kom fra). Hvis MAC peker mot samme port den kom fra → drop. Ellers → send til riktig port.
Self-learning: Tabellen oppdateres med kilde-MAC-adresser fra rammer som mottas. Oppføringer slettes etter en timeout — så info holdes dynamisk.
Opererer kun innenfor ett subnett. Transparent for hosts/servere — har verken MAC- eller IP-adresse selv (i motsetning til ruteren).
Plug-and-play / self-configuring — krever ingen manuell konfigurasjon.

ARPMed

Eks4·Q3.3

Må kunne

ARP = Address Resolution Protocol. Oversetter mellom IP-adresser (lag 3) og linklags-adresser (vanligvis Ethernet-MAC) lokalt i et subnett.

ARP-tabeller ligger i minne hos hver vert og hver ruter — slik at neste pakke til samme IP slipper ny ARP-spørring. Oppføringer har en timeout slik at de holdes friske.

Hvorfor: Når en host vet IP-en til neste hopp (default gateway eller en host i samme subnett) må den også vite MAC-en før Ethernet-rammen kan sendes. Uten ARP ville lag-3-til-lag-2-overgangen vært umulig.

CRC — beregne fra D og GMed

Eks4·Q3.1

Må kunne

Legg til length(G) − 1 nuller bak datastrengen D (plassholder for CRC-koden). Eks: D=101010, G=1011 → 101010000.
Utfør modulo-2-divisjon (XOR-divisjon) med generator G.
Resultatet av divisjonen brukes ikke. Resten = CRC-koden.
Send D etterfulgt av CRC-koden istedenfor de tilføyde nullene. Eks: 101010001.

Mottaker deler hele streng (D + CRC) med G — rest = 0 betyr feilfri overføring.

Hvorfor: Du må kunne forklare prosedyren verbalt; konkrete beregninger er sjeldne, men en G med length 4 og D = 6–8 bits er klassisk.

CSMA-tidslinjeHøy

Eks1·Q1.4.3, Q1.4.4 · Eks3·P2/Q7

Må kunne

Tegn ankomster på en tidslinje.
For hver pakke, sjekk om kanalen oppfattes ledig (signal nådd hit).
Med propageringstid 0,2 t.u.: pakker som starter innen 0,2 etter en annen → kollisjon.
CSMA uten CD: kolliderende pakker «brenner» hele slot. CSMA/CD: stopp ved deteksjon (men det går 0,2 ekstra før alle hører kollisjonen).
Pakker som senses busy → utsettes til etter t=5 (regneoppgave).

Hvorfor: Eksakt samme oppgaveform, bare ulike t-verdier, gjentas mellom årene. Få den i ryggmargen.

Fire-noder topologi: max rate-oppgavenHøy

Eks1·Q1.4.7 · Eks2·Q5

Må kunne

Topologi A — B — C — D der bare nabonoder hører hverandre. Hør-relasjonen: A→{B}, B→{A,C}, C→{B,D}, D→{C}. Lær disse fire svarene utenat:

C → A (uten ACK): 0,5 msg/slot — relé via B; C→B og B→A i to slot, så ny C→B kan starte ⇒ 1 melding hver 2. slot.
A→B + D→C (uten ACK): 2 msg/slot kombinert — begge kan sende samtidig. B hører A (men ikke D, fordi D bare når C). C hører D (men ikke A, fordi A bare når B). Ingen interferens.
A→B + C→D (uten ACK): 1 msg/slot kombinert — kan ikke sendes samtidig: når C sender, hører B også C (B er i Cs rekkevidde) og kolliderer med A→B. Må veksle, så hver flyt får 0,5 og total = 1.
C → A med ACK: 0,25 msg/slot — C→B, B→A, A→B ack, B→C ack. 4 slot per ende-til-ende melding.
Generelt med ACK: halverer ratene fra «uten ACK»-tilfellene over.

Hvorfor: 12 poeng på Eks 2. Tegn topologien og tell slot — sjelden poeng for «riktig svar uten begrunnelse».

Pure / slotted ALOHA-effektivitetMed

Eks1·Q1.4.2 · Eks2·Q1.4.5

Må kunne

Pure ALOHA: maks ~18 % (1/(2e)). Slotted: maks ~37 % (1/e). Slotted krever synkroniserte tidsluker — pakker starter bare på slot-grenser.

2D-paritetMed

Eks1·Q1.4.5 · Eks2·Q1.4.2

Må kunne

Detekter og rett 1-bit feil. Detekter (men ikke rett) mange 2-bit feil — men ikke alle. Even parity: legg til en bit slik at antall 1-ere er like.

RTS/CTS & skjult terminalMed

Eks1·Q1.4.6 · Eks2·Q1.4.4

Må kunne

RTS sendes av sender, CTS av mottaker. Naboer som hører CTS holder seg stille. Løser skjult terminal: når to sendere ikke hører hverandre men deler mottaker.

Sant: hidden node-problemet eksisterer fortsatt fysisk; RTS/CTS reduserer effekten. Usant: «løser exposed node-problemet helt».

802.11: Infrastructure mode vs ad hoc modeMed

Eks4·Q4.1

Må kunne

Infrastructure mode: Hosts er tilknyttet en basestasjon (AP) som kobler videre til kablet nett. AP gir DNS, DHCP, ruting via fast infrastruktur.

Ad hoc mode: Ingen infrastruktur. Hosts kommuniserer direkte med hverandre. Hosts må selv stå for ruting, adressetildeling, DNS-lignende navneoppslag, m.m.

Hvorfor: Eks 4 ber om kort forklaring av forskjellen — én setning hver er nok. Husk: ad hoc krever at hosts selv overtar tjenester som AP normalt gir.

CSMA/CD vs CSMA/CA & WiFi-ACKMed

Eks4·Q4.2, Q4.3

Må kunne

Hvorfor CSMA/CD ikke kan brukes i 802.11:

Kollisjons-deteksjon krever at man kan sende og motta samtidig. På 802.11-adapteren er det mottatte signalet svært svakt sammenlignet med eget sendt signal — det er kostbart å bygge maskinvare som kan oppdage kollisjon.
Selv med samtidig send/motta ville ikke alle kollisjoner oppdages — pga. skjult terminal-problem og fading.

Hovedforskjell CSMA/CD vs CSMA/CA:

CD (Ethernet): begynner å sende straks kanalen er ledig. Avbryter ved oppdaget kollisjon.
CA (WiFi): bruker en random back-off-teller som telles ned før sending — reduserer kollisjonssannsynlighet. Etter vellykket sending er det også et minimum «space» (IFS) som gir ACK-rammer (og korte kontrollrammer som RTS/CTS) prioritert tilgang.
CA = Collision Avoidance — oppnås ikke fullt ut (rammer fra to stasjoner kan fortsatt kollidere), men er mye mindre sannsynlig enn i Ethernet.

Ingen kollisjons-deteksjon → eksplisitt ACK: Mottaker sender en ACK-ramme tilbake for hver mottatt dataramme. Hvis avsender ikke får ACK → antas tap, retransmitter.

Hvorfor: Eks 4 har tre delspørsmål rundt dette — pugg punktene over så du kan svare alle tre direkte. RTS/CTS hører hjemme her som del av CA.

802.11 MAC-elementerMed

Eks5·Q1.4.4

Må kunne

Hva som er del av 802.11 MAC (kryss av flere):

CSMA/CA ✓ — Collision Avoidance med back-off-teller.
CSMA/CD ✗ — brukes ikke i WiFi (kan ikke detektere kollisjon trådløst).
ACK ✓ — eksplisitt kvittering for hver mottatt dataramme.
RTS/CTS ✓ — valgfritt, brukes mot skjult terminal.
DIFS (Distributed Inter-Frame Space) ✓ — minimum tid stasjoner må vente før de kan sende etter at kanalen blir ledig.

Andre IFS-er du kan se: SIFS (Short IFS) — kortest, brukes mellom data og ACK for å gi ACK prioritert tilgang. PIFS — for spesielle nodetilstander.

Hvorfor: «Hvilke av disse» med flere riktige svar. CSMA/CD er den fellen — pugg at WiFi alltid bruker CA, aldri CD.

4G og 5G mobilnettMed

Eks5·Q1.4.5

Må kunne

Sant: 5G gir høyere peak-bitrate enn 4G.
Usant: «Det fysiske laget i 5G er kompatibelt med 4G» — nei, 5G NR (New Radio) er en helt ny luftgrensesnitt.
Sant: Både 4G og 5G støtter mobilitet (handover mellom celler).
Sant: Både 4G- og 5G-kjernenett er designet for fullstendig kontroll- og brukerplan-separasjon (CUPS — Control and User Plane Separation). I 4G ble dette innført som tillegg; i 5G er det kjerne-arkitektur fra start.

Mnemonisk: peak-bitrate ↑, fysisk lag ulikt, mobilitet i begge, kontroll-/brukerplan-separasjon i begge.

SNR / BER / modulasjonMed

Eks2·Q1.4.3 · Eks5·Q1.4.3

Må kunne

Lavere SNR → høyere BER (gitt modulasjon). Ved samme SNR: høyere bitrate-modulasjon → høyere BER (mer informasjon per symbol = mer sårbart for støy).

Adaptiv modulasjon og koding brukes i WiFi, 4G og 5G — systemet velger en lavere bitrate-modulasjon (mer robust) når SNR faller, og en høyere bitrate-modulasjon når SNR er godt.

Kapittel 8–9 — Sikkerhet og multimedia

Ønskede sikkerhetsegenskaperHøy

Eks1·Q1.4.8 · Eks2·Q1.5.1

Må kunne

Konfidensialitet, integritet (meldingen ikke endret), autentisering, operasjonell sikkerhet.

Ikke kryss av: «høy båndbredde» eller «nettverksstabilitet» — det er ikke sikkerhetsegenskaper.

Antall symmetriske nøkler — N(N−1)/2Høy

Eks1·Q1.4.9 · Eks2·Q1.5.2

Må kunne

N personer parvis: N(N−1)/2 unike nøkler.

Hvorfor: Spørsmålet er nesten ordrett kopi mellom Eks 1 og Eks 2. Pugg formelen.

Trudy: hva angriperen kan gjøreHøy

Eks1·Q1.4.10 · Eks2·Q1.5.5

Må kunne

Avlytte (sniffe) kontroll- og data-meldinger; ta opp; modifisere; sette inn nye; slette. Alle alternativene som lister angrepshandlinger er som regel sanne.

Meldingsintegritet (hash vs checksum)Med

Eks2·Q1.5.3

Må kunne

Meldingsintegritet = mottaker kan oppdage at meldingen er endret. Både hash og checksum kan brukes, men hash er kryptografisk sterkere (vanskelig å konstruere kollisjoner). Trenger ikke være TCP — kan brukes over UDP.

HTTP-streaming over UDP-streamingMed

Eks2·Q1.5.4 · Eks3·P1/Q1 · Eks5·Q1.5.5

Må kunne

Brannmurer slipper ofte HTTP/TCP, blokkerer UDP.
UDP gir høyere feilrate (ingen retransmisjon, ingen ordning).
HTTP/TCP gjenbruker eksisterende infrastruktur (CDN, caching, lastbalansering).

Multimedia: distribuere innhold geografisk via CDN er bedre enn én sentral server.

Felle på Eks 5: «UDP-streaming bruker klient-side applikasjonsbufring som forårsaker forsinkelse» — feil. Det er HTTP-streaming som typisk bruker stor bufring (TCP retransmisjon krever det); UDP er normalt mindre bufret.

Playout-buffer for video-streamingMed

Eks5·Q1.5.4

Må kunne

Server sender blokk i ved tid t₀ + i·Δ. Hver blokk skal spilles av Δ tidsenheter etter forrige. Klient starter avspilling ved t₁ + Δ.

For at en blokk skal «rekke fram i tide» må: ankomsttid ved klient ≤ planlagt avspillingstid. Tegn to akser:

Sendekurve: lineær med stigning Δ per blokk, start t₀.
Ankomstkurve: faktisk ankomst (kan være forsinket, ujevn).
Avspillingskurve: lineær med stigning Δ per blokk, start t₁ + Δ.

Blokk i rekker fram hvis ankomstkurven for den blokken ligger til venstre/under avspillingskurven på samme indeks. Marker hver av de første 7 blokkene én etter én.

Hvorfor: Eks 5 viser figur og spør hvilke av blokk 1–7 som rekker fram. Sjelden ren regning — visuell oppgave hvor du leser av kurvene.

Cæsar-cipher med gitt kMed

Eks3·P2/Q5

Må kunne

Beskriv: hver bokstav skiftes k plasser i alfabetet (mod 26).
Kode med k=7: «Protect your information» → vis utregning bokstav for bokstav.
Dekode: trekk fra k (eller skift 26−k forover).

Hvorfor: 15 poeng på Eks 3. Skriv alfabetet på arket og vis utregningen — det gir delpoeng selv ved sluttfeil.

Symmetrisk vs offentlig nøkkelMed

Eks3·P2/Q6 · Eks4·Q5.1

Må kunne

Symmetrisk: én nøkkel for begge retninger; rask; problem = nøkkeldistribusjon.

Offentlig nøkkel: nøkkelpar (offentlig/privat); kryptér med offentlig, dekrypter med privat; løser distribusjon, men er tregere.

I praksis: PKI brukes for å utveksle en symmetrisk session key (slik TLS gjør).

Algoritmer er kjent — nøkler er hemmelige: I moderne kryptografi antas algoritmen alltid å være offentlig kjent. Sikkerheten ligger i å beskytte nøklene. (Historisk var symmetriske algoritmer ofte hemmelige; for noen militære bruksområder gjelder det fortsatt.) Begge systemer kan brukes for konfidensialitet; offentlig nøkkel kan også brukes for meldingsintegritet og digitale signaturer.

Digital signatur (med public key)Med

Eks4·Q5.2

Må kunne

Enkleste prinsipp: Avsender krypterer meldingen (eller en setning) med privat nøkkel. Hvem som helst kan så bruke den tilhørende offentlige nøkkelen til å dekryptere — og siden bare innehaveren av privatnøkkelen kunne ha laget krypteringen, er signaturens gyldighet bekreftet.

Minimum tillegg som kreves: En betrodd tredjepart (TTP) som utsteder et sertifikat som binder den offentlige nøkkelen til en spesifikk person/organisasjon. Uten dette vet du ikke hvem nøkkelen tilhører.

I praksis: For store meldinger signerer man hash-en (mer effektivt enn å kryptere hele meldingen).

Brannmur — tre mål & kategorierHøy

Eks3·P1/Q14 · Eks4·Q5.3 · Eks5·Q6

Må kunne

Eks 5 — tre mål for en brannmur:

All trafikk inn/ut må passere brannmuren — ingen bakdør rundt.
Kun autorisert trafikk slipper igjennom — definert av en lokal sikkerhetspolicy.
Brannmuren selv må være motstandsdyktig mot kompromittering — herdet OS, minimum tjenester, fysisk beskyttet.

«Hovedformål» (Eks 3/4-formulering): blokkere uautorisert tilgang. Ikke «kryptere data» (TLS/IPsec) eller «overvåke ytelse» (andre verktøy).

Stateless vs stateful (Eks 5 Q6.2):

Traditional (stateless) packet filter: Beslutninger tas per pakke isolert, basert på header-felt (IP, port, TCP-flags). Holder ingen historikk om tidligere pakker. Implementeres som ACL.
Stateful packet filter: Sporer i tillegg aktive forbindelser (en connection table). Kan kreve at en innkommende TCP-pakke hører til en allerede etablert utgående forbindelse — fanger spoofede pakker bedre og blokkerer scanning.

Tre kategorier (Eks 4-formulering):

Traditional packet filters: per pakke isolert (som over).
Stateful packet filters: ACL + tilstandstabell.
Application gateways: Applikasjonsspesifikke tjenere som all trafikk for den applikasjonen må gå igjennom. Beslutninger basert på applikasjonsdata i tillegg til pakkefilter — kan f.eks. kreve brukernavn/passord. Trenger én gateway per applikasjon (men kan kjøre på samme host).

Hvorfor: Eks 4 ber om alle tre kategorier, Eks 5 ber om tre mål + forskjell stateless/stateful. Pugg begge listene — de tester ulike spørsmål, ikke det samme.

Den «store oppgaven» — protokollkjede

Fra plug-in til mottatt e-postHøy

Eks3·P2/Q3 (15 poeng)

Må kunne

Lenkelaget opp — Ethernet-link aktiveres.
DHCP (UDP) — får IP, subnett-maske, default gateway, DNS-server.
ARP — finne MAC til default gateway.
DNS (UDP, kan TCP) — slå opp IP til mottakers mail-server.
TCP-handshake til SMTP-server (port 25/587).
SMTP — Outlook → NTNU mail-server → mottakers domene mail-server.
Mottaker leser via HTTPS (web-mail) eller IMAP (klient).

Hvorfor: Tester at du kobler protokoller til lag og ser helheten. Nevn alltid laget hver protokoll tilhører — det gir poeng.

Drag-and-drop / koble-typer (Del I)

Drag-and-drop minimumLav

Eks3·P1/Q8, Q9

Må kunne (rask repetisjon)

Header-rekkefølge i ramme: ytterst link (MAC) → nett (IP) → transport (TCP/UDP) → app-data innerst. Tilsvarer kapsling lag for lag.

Aksessnett ↔ hastighet: Ethernet kablet 100 Mbps–1 Gbps · 4G LTE trådløst titalls Mbps · fiber kablet opptil hundrevis Mbps–Gbps · kabel kablet titalls Mbps.

Multiple access ↔ klasseMed

Eks3·P1/Q6

Må kunne

Channel partitioning: CDMA, FDMA, TDM.
Random access: Slotted ALOHA, Ethernet CSMA/CD.
Taking turns: Bluetooth, FDDI, token ring.

TCP-klient socket-kallMed

Eks3·P1/Q10

Må kunne

Lag socket: socket(AF_INET, SOCK_STREAM).
Identifiser server: connect() binder socket til server-IP/port.
Send: trenger ikke spesifisere dest etter connect() — bruk samme socket.

UDP-varianten: SOCK_DGRAM, ingen connect, applikasjonen må sette dest i hver send.

Formler, porter & tabeller

Tall og fakta du må ha klart

Eksamen tester ofte én protokoll/maske/tabellrad — men spørsmålet kan like gjerne treffe naborutene. Pugg disse helhetlig så du ikke står og leter etter «port for IMAP» midt i flervalg.

Hva	Formel / svar
Overføringsforsinkelse (én lenke)	`L / R`
Store-and-forward over N hopp, samme R	`N · L / R`
Pipelining: P pakker, N rutere, samme R	`(N + P − 1) · L / R`
Brukbare verter i et /x-subnett	`2^(32−x) − 2`
Symmetriske nøkler, N personer parvis	`N(N−1)/2`
Offentlig-nøkkel-par for N personer	`N` par (`2N` nøkler totalt)
Slotted ALOHA maks effektivitet	`1/e ≈ 0,37` (~37 %)
Pure ALOHA maks effektivitet	`1/(2e) ≈ 0,18` (~18 %)
TCP-sockets på server med K aktive forbindelser	`K + 1` (1 lyttende + K aktive)
Klient-server filfordeling, min. tid	`max(N·F/u_s, F/d_min)`
P2P-fildistribusjon, min. tid	`max(F/u_s, F/d_min, N·F/(u_s+Σu_i))`
HTTP non-persistent, ingen parallell	`(N+1) · (2·RTT + L/R)` for base + N embedded
HTTP non-persistent, parallelle TCP	`2 · (2·RTT + L/R)`
HTTP persistent, ingen pipelining	`RTT + (N+1) · (RTT + L/R)`
4-noder C→A uten / med ACK	0,5 / 0,25 msg/slot
4-noder A→B + D→C kombinert	2 msg/slot
4-noder A→B + C→D kombinert	1 msg/slot

Portnumre — alle de vanlige

Når én portoppgave kommer, kan en hvilken som helst dukke opp. Pugg disse:

Port	Protokoll	Transport
`20 / 21`	FTP (data / kontroll)	TCP
`22`	SSH	TCP
`23`	Telnet	TCP
`25`	SMTP	TCP
`53`	DNS	UDP (TCP for store svar / soneoverføring)
`67 / 68`	DHCP (server / klient)	UDP
`80`	HTTP	TCP
`110`	POP3	TCP
`143`	IMAP	TCP
`161 / 162`	SNMP	UDP
`443`	HTTPS (HTTP over TLS)	TCP
`465 / 587`	SMTP submit (TLS / STARTTLS)	TCP
`993`	IMAPS	TCP
`995`	POP3S	TCP

Subnett-maske ↔ /x

Standardspørsmål: «hva er masken til /x» eller «hvor mange verter passer i et /x».

Prefiks	Maske	Bloksstørrelse	Brukbare verter
`/24`	`255.255.255.0`	256	254
`/25`	`255.255.255.128`	128	126
`/26`	`255.255.255.192`	64	62
`/27`	`255.255.255.224`	32	30
`/28`	`255.255.255.240`	16	14
`/29`	`255.255.255.248`	8	6
`/30`	`255.255.255.252`	4	2
`/31`	`255.255.255.254`	2	2 (point-to-point)

DNS Resource Record-typer

Hvis A-typen er på eksamen kan det like godt være CNAME eller MX.

Type	Hva «Name» peker på	Hva «Value» er
`A`	Hostname	IPv4-adresse
`AAAA`	Hostname	IPv6-adresse
`NS`	Domene	Autoritativ navneserver
`CNAME`	Alias-hostname	Kanonisk hostname
`MX`	Domene	Mailserver-hostname (med prioritet)
`PTR`	IP (revers)	Hostname

HTTP-metoder & statuskode-klasser

Metode / kode	Bruk
`GET`	Hent objekt fra server
`POST`	Send data til server (skjema, opplasting)
`PUT`	Last opp objekt til gitt URL
`DELETE`	Slett objekt
`HEAD`	Som GET, men bare headere — ikke kropp
`1xx`	Informasjon (sjeldent)
`2xx`	Suksess (200 OK)
`3xx`	Omdirigering (301, 304 Not Modified)
`4xx`	Klientfeil (400 Bad Request, 404 Not Found)
`5xx`	Serverfeil (500, 503)

IP-adresser & spesielle prefiks

Adresse / blokk	Betydning
`10.0.0.0/8`	Privat (klasse A)
`172.16.0.0/12`	Privat (klasse B)
`192.168.0.0/16`	Privat (klasse C)
`127.0.0.0/8`	Loopback (typisk 127.0.0.1)
`169.254.0.0/16`	Link-local (DHCP feilet)
`224.0.0.0/4`	Multicast
`255.255.255.255`	Limited broadcast (alle på lokalt nett)
`0.0.0.0`	«Denne maskinen» / default route

Lag og protokoller — komplett oppslag

Lag	Hovedoppgave	Typiske protokoller
Applikasjon	Tjenester for brukerprogrammer	HTTP(S), SMTP, IMAP, POP3, DNS, FTP, SSH, DHCP
Transport	End-to-end mellom prosesser	TCP, UDP
Nettverk	Pakker fra host til host	IP (v4/v6), ICMP, OSPF, BGP, ARP*
Lenke	Frame mellom direkte naboer	Ethernet, Wi-Fi (802.11), PPP
Fysisk	Bits over et medium	Kobber, fiber, radio

* ARP er teknisk på lenkelaget men brukes til å oversette mellom IP og MAC.

15-min sjekkliste

Rett før du går inn

Hvis du bare har et kvarter igjen — pugg disse.

Forsinkelser: d_trans = L/R; én svitsj S&F = L/R₁ + L/R₂; P pakker, N rutere = (N+P−1)·L/R. Husk byte → bit.
Linjesvitsj: oppsettstid + L/R for hele filen (raten er konstant over hele kretsen). Ikke pakkesvitsj-tenking!
Maks gjennomstrømning: min av ratene på stien. Server → ruter → klient: min(R₁, R₂).
UDP vs TCP: UDP = best effort + porter, ingenting mer. TCP = pålitelig + flow control + congestion control. Ingen har throughput-garanti eller real-time.
Applikasjonslag-protokoller: DNS, SMTP, FTP, HTTP, IMAP, POP3. Ikke ICMP eller ARP.
Flow vs congestion: flow = mottakers buffer (rwnd). Congestion = nettverkets kapasitet (cwnd). Ulike problemer. Lignende konsept finnes på lenkelag (sliding window).
HTTP responstid: non-persistent ≈ N·(2·RTT + L/R); parallell ≈ 2·(2·RTT + L/R); persistent uten pipelining ≈ 2·RTT + L/R + (N−1)(RTT + L/R).
P2P-fildistribusjon: max(F/u_s, F/d_min, N·F/(u_s+Σu_i)) — skalerer med antall peers.
Klient-server filfordeling: max(N·F/u_s, F/d_min) — server er nesten alltid flaskehals.
TCP back-to-back: seq i andre segment = seq₁ + lengde₁; src/dst-port byttes ikke i samme retning.
Ruting vs forwarding — 3 forskjeller: tidsskala (ns vs sek), plassering (datapath vs kontrollplan), avhengighet (forwarding bruker tabellen routing fyller).
IP til binær: hver oktett uavhengig. 193 = 11000001, 32 = 00100000, 216 = 11011000, 9 = 00001001.
Subnetting: IP AND maske → nett-adresse. Brukbare verter = 2^(32−x) − 2.
Longest prefix: velg lengste matchende prefiks i tabell. Default hvis ingen match.
NAT: bytter kilde IP/port på vei ut; uendret dest. Tabell-oppslag på vei inn.
ICMP: i IP, brukt til feil/diagnose, traceroute via TTL. Ikke transport.
DHCP: UDP, 4 steg, gir IP+maske+GW+DNS. Klient-server, bruker lenkelags-broadcast. Sticky lease kan gi samme IP igjen.
IPv4 vs IPv6: flow label kun i IPv6. IPv4 har checksum, IPv6 ikke. IPv6 fragmenterer ikke i mellomliggende rutere. Begge forbindelsesløse.
CSMA-tidslinje: propagering 0,2 → kollisjoner mellom pakker som starter < 0,2 fra hverandre.
4-noder A–B–C–D: C→A = 0,5 (uten ACK), 0,25 (med ACK). A→B + D→C = 2. A→B + C→D = 1.
802.11 MAC: CSMA/CA + ACK + RTS/CTS (valgfritt) + DIFS. Ikke CSMA/CD.
4G vs 5G: 5G > 4G peak-bitrate, fys-lag ikke kompatibelt, begge støtter mobilitet og kontroll-/brukerplan-separasjon.
SNR/BER: høyere SNR → lavere BER. Høyere bitrate-modulasjon → høyere BER ved samme SNR. Adaptiv mod & koding i WiFi/4G/5G.
Pure ALOHA: 18 %. Slotted: 37 %. Slotted krever synk.
Sikkerhet: konfidensialitet, integritet, autentisering, opsec — ikke båndbredde, ikke «public key cryptography» som er et middel.
Symmetriske nøkler: N(N−1)/2.
Meldingsintegritet: hash > checksum (kryptografisk). Trenger ikke TCP — kan brukes over UDP.
Playout-buffer: blokk i rekker fram hvis ankomsttid ≤ avspillingstid for samme blokk. Tegn kurver.
Brannmur — tre mål: all trafikk gjennom, kun autorisert, motstandsdyktig mot kompromittering.
Brannmur-typer: stateless (per pakke) / stateful (sporer forbindelse) / application gateway (per app, sjekker innhold).
Cæsar k=7: hver bokstav 7 plasser fram, mod 26. Vis utregningen.
Protokollkjede: Ethernet → DHCP → ARP → DNS → SMTP → IMAP/HTTPS. Lag-merking gir poeng.
TCP 3-veis handshake: SYN (seq=A) → SYN-ACK (seq=B, ack=A+1, server allokerer buffere) → ACK (ack=B+1, klient allokerer).
DNS-hierarki: Root (13) → TLD (com/no/uk…) → autoritative (per organisasjon).
Linklags-svitsj: Self-learning, plug-and-play, transparent (ingen IP/MAC selv), bare innenfor subnett.
ARP: IP ↔ MAC i lokalt subnett. ARP-tabell i hver host og ruter.
WiFi vs Ethernet: CSMA/CA (ikke CD) pga. signal-asymmetri + skjult terminal. Bruker eksplisitt ACK + back-off-teller.
Digital signatur: Krypter med privat nøkkel, verifiser med offentlig + sertifikat fra TTP.

Eksamensinfo

Det blir ikke Wireshark-spørsmål denne eksamen (jf. eks_info.md). Bruk derfor ikke tid på SSL-sportolking — prioriter alt over.