Applikasjonslaget

Svar: I klient–server står en alltid-tilgjengelig tjener med fast IP og betjener mange klienter; klientene snakker aldri direkte med hverandre. I P2P finnes ingen sentral tjener — vilkårlige peers snakker direkte med hverandre, og hver peer både ber om og leverer tjenester.

Hvorfor selv-skalering: Hver ny peer som kobler seg til, bringer ikke bare ny etterspørsel inn i systemet, men også ny opplastningskapasitet. I klient–server er total opplastningskapasitet konstant lik us; i P2P vokser den med us + Σui. Det er denne effekten som gjør at store P2P-fildelingsnettverk kan skalere til svært mange samtidige nedlastere uten at én sentral ressurs blir flaskehals.

Svar: En socket er API-et — «døren» — mellom en applikasjonsprosess og transportlaget. Apputvikleren kontrollerer alt over socketen; OS styrer alt under. En mottakerprosess identifiseres med to ting: IP-adressen (hvilken vert) og portnummeret (hvilken prosess på den verten).

Hvorfor begge trengs: IP alene er ikke nok — én vert kjører ofte titalls prosesser samtidig. Tenk på IP som gateadressen og porten som leilighetsnummeret. En HTTP-server lytter typisk på port 80, en mailserver på port 25. Operativsystemet bruker porten til å rute innkommende segmenter til riktig socket og dermed riktig prosess.

Svar: En applikasjonsprotokoll definerer fire ting: (1) meldingstyper som utveksles (f.eks. forespørsel og svar), (2) meldingssyntaks — hvilke felt finnes og hvordan er de avgrenset, (3) meldingssemantikk — hva betyr verdiene i feltene, og (4) regler for når og hvordan meldinger sendes og hvordan man svarer.

Åpen vs proprietær: Åpne protokoller (HTTP, SMTP) er definert i offentlige RFC-er — hvem som helst kan lese og implementere dem, og det er nettopp derfor enhver nettleser kan snakke med enhver webserver. Proprietære protokoller (klassisk eksempel: Skype) er kontrollert av én leverandør og fungerer typisk bare i deres eget økosystem. Åpenhet er hovedgrunnen til at Internetts protokollpark har kunnet vokse organisk.

Svar: TLS (Transport Layer Security) er et lag oppå TCP som gir kryptering, dataintegritet og endepunktsautentisering. Det implementeres som biblioteker i applikasjonslaget — apper kaller TLS-funksjoner, som i sin tur snakker med TCP. Klartekst inn i en TLS-socket kommer ut igjen i klartekst på den andre siden, men over nettet har det vandret kryptert. HTTPS = HTTP over TLS, og kjører typisk på port 443 i stedet for 80.

Hvorfor det trengs: Vanlige TCP-sockets er ukrypterte. Sender du et passord over en åpen TCP-socket, vandrer det i klartekst og hvem som helst på veien kan lese det. TLS løser tre problemer på én gang: avlytting (kryptering), tukling underveis (integritet via MAC), og at du kanskje ikke snakker med den du tror (sertifikat-basert autentisering av tjeneren).

Svar: (1) Datapålitelighet — tåler appen tap? (2) Tidskrav — må data komme frem innen en viss tid? (3) Gjennomstrømning — trenger appen en minimumshastighet? (4) Sikkerhet — skal data krypteres, integritetssjekkes, autentiseres?

Hvorfor det betyr noe: Disse fire bestemmer om TCP eller UDP er riktig valg. Filoverføring tåler ingen tap (TCP), men spiller ingen rolle om det tar et halvt sekund ekstra. Internettelefoni tåler litt tap, men ikke mye forsinkelse (UDP). Streaming-video krever en viss minimumsgjennomstrømning. Først når du har skrevet ned hva appen din trenger på alle fire akser, kan du velge transporttjeneste fornuftig.

Svar: TCP gir pålitelig overføring (alle byter kommer frem i riktig rekkefølge), flytkontroll (avsender bremser hvis mottaker er treg), overbelastningskontroll (avsender bremser hvis nettet er stappet) og er forbindelsesorientert (3-veis håndtrykk før data flyter). UDP har ingenting av dette — én pakke ut, kanskje frem, kanskje ikke.

Hvorfor UDP likevel finnes: Prisen for TCP-garantiene er overhead og forsinkelse — håndhilsing før første byte, retransmisjoner ved tap, bremsing ved overbelastning. For DNS-oppslag (lite, raskt, idempotent) eller stemme-/videosamtaler (hellere droppe en pakke enn å vente) er det bedre å hoppe over alt det og leve med upålitelighet. Verken TCP eller UDP gir tidsgarantier eller minimum gjennomstrømning.

Svar: Tjeneren husker ingenting mellom forespørsler. Hver HTTP-forespørsel behandles uavhengig — som om den var den første tjeneren noen gang har sett fra denne klienten.

Hvorfor det er smart: Tilstandsløshet gjør tjenere enkle å skalere — sett mange tjenere bak en lastbalanser, og en hvilken som helst av dem kan svare på en hvilken som helst forespørsel uten å rekonstruere noen sesjon. Krasjer en tjener, kan en annen ta over umiddelbart. Cookies løser tilstandsbehovet for de applikasjonene som faktisk trenger det, uten å påtvinge kostnaden på hele protokollen — det er et opt-in-system, ikke en innebygd egenskap.

Svar: Ikke-persistent: én TCP-forbindelse per objekt. Med 9 objekter blir det 9 forbindelser, og hver koster 2 RTT (én for TCP-oppsett, én for forespørsel/svar) — totalt 18 RTT + overføringstid. Persistent: én forbindelse, mange forespørsler. Da koster det 1 RTT + 9 RTT = 10 RTT totalt (og enda mindre med pipelining).

Hvorfor det betyr så mye: Hver TCP-oppsett koster én ekstra RTT bare for å komme i gang, pluss OS-overhead for å allokere socket-tilstand. Over en høy-RTT-forbindelse (mobilnett, satellitt) er forskjellen mellom 18 og 10 RTT enorm. HTTP/1.1 gjorde persistent forbindelser til standard nettopp for å fjerne dette tapet.

Svar: En HTTP-melding er ren ASCII med tre deler: en startlinje (request line eller statuslinje), hodelinjer (navn: verdi), en blank linje, og en valgfri kropp. Forespørselens første linje er METODE URL VERSJON.

Metodene: GET ber om et objekt; eventuelle parametre legges i URL-en. POST sender data — typisk fra et webskjema — i forespørselens kropp. HEAD ber om hodet uten selve innholdet (nyttig for debugging og cacher). PUT laster opp en ny fil til en angitt URL og erstatter eventuelt eksisterende innhold der. Forskjellen mellom GET og POST er hvor data ligger (URL vs body) og semantikk: GET skal være trygg å gjenta, POST kan ha sideeffekter.

Svar:

200 OK — forespørselen lyktes; objektet følger i svaret.
301 Moved Permanently — objektet er flyttet; ny adresse oppgis i Location-headeren.
304 Not Modified — svar på betinget GET; cachen kan trygt bruke sin egen versjon.
404 Not Found — det forespurte dokumentet finnes ikke på tjeneren.

Hvorfor 1xx–5xx-systemet: Første sifferet sier kategori — 1xx informasjonell, 2xx suksess, 3xx omdirigering, 4xx klientfeil, 5xx tjenerfeil. Det lar klienten håndtere koder den aldri har sett før: en 478 vet jeg ikke betydningen av, men jeg vet det er klientens skyld. Designen er tiår gammel, men holder fortsatt fordi den er fornuftig partisjonert.

Svar: HTTP/3 bytter ut TCP med QUIC — en ny transportprotokoll bygd på UDP. QUIC gir hver strøm sin egen uavhengige feilhåndtering, slik at et pakketap i én strøm ikke blokkerer de andre.

Hvorfor: HTTP/2 fjernet hode-blokkering på applikasjonsnivå ved å multipleksere mange objekter på én TCP-forbindelse. Men det gjenstod et problem: hvis én TCP-pakke gikk tapt, måtte alle objekter vente på retransmisjonen — fordi TCP gir én ordnet bytestrøm. Det er en lavere-lags hode-blokkering. QUIC løser det ved å la hver strøm være uavhengig på transportnivå. Bygget på UDP for å kunne deployes i applikasjonen uten å måtte oppdatere kjernens TCP-stakk.

Svar: (1) Et Set-Cookie-felt i HTTP-svaret fra tjeneren, (2) et Cookie-felt i påfølgende HTTP-forespørsler fra klienten, (3) en cookie-fil på brukerens maskin (administrert av nettleseren, knyttet til domenet), og (4) en database på tjenersiden der cookien knyttes til faktisk informasjon (handlekurv, innloggingsstatus, profil).

Hvorfor det fungerer: Første besøk: tjeneren genererer en unik ID, lagrer den i sin database, og sender den tilbake i Set-Cookie. Nettleseren lagrer cookien. Neste besøk: nettleseren legger automatisk ved Cookie: 1678, og tjeneren slår opp ID-en i databasen og «kjenner igjen» brukeren. Tilstand bygges altså ovenpå en tilstandsløs protokoll, uten å endre selve protokollen.

Svar: En webcache (proxy-tjener) er en mellommann som husker tidligere svar. Klientens nettleser konfigureres til å sende forespørsler gjennom cachen; hvis cachen har objektet, leveres det umiddelbart, ellers henter cachen det fra opprinnelses-tjeneren, lagrer en kopi, og videresender. Cachen fungerer samtidig som tjener (mot klienten) og klient (mot opprinnelses-tjeneren).

Hvorfor: (1) Kortere responstid for brukeren — cachen er typisk geografisk nærmere enn opprinnelses-tjeneren. (2) Mindre trafikk på institusjonens aksesslinje, fordi populært innhold bare må lastes ned én gang og deretter serveres lokalt. For et universitet eller kontornettverk kan dette spare enorme mengder båndbredde — særlig før CDN-er ble allestedsnærværende.

Svar: Cachen sender en vanlig GET, men med headeren If-Modified-Since: <dato> der datoen er da kopien ble lagret. Tjeneren sjekker om objektet er endret etter datoen. Hvis ikke: svar 304 Not Modified uten kropp — cachen kan trygt bruke sin lagrede versjon. Hvis endret: svar 200 OK med det nye innholdet, akkurat som en vanlig GET.

Hvorfor det er elegant: I det vanlige tilfellet — innholdet er uendret — slipper man å overføre objektet i det hele tatt; bare en bitteliten 304-melding går over nettet. Cachen får verifisert at kopien er gyldig uten å sløse båndbredde. Dette er hvorfor caching og betinget GET hører tett sammen: caching gjør at objektet er der; betinget GET gjør at vi tør stole på det.

Svar: I HTTP/1.1 sender tjeneren svar i samme rekkefølge som forespørslene kom (FCFS). Hvis det første objektet er stort (en video), må alle senere objekter — selv små bilder som kunne kommet på et øyeblikk — vente bak i køen. Dette kalles head-of-line-blokkering: det fremste objektet sperrer for resten.

HTTP/2 (RFC 7540, 2015): Deler hvert objekt i mindre frames og blander rammer fra forskjellige objekter på samme TCP-forbindelse. Tjeneren kan også prioritere rammer ut fra hva klienten har bedt om. Tre små objekter får da overført sine rammer mellom rammer fra det store, og ankommer raskt mens det store fortsatt streames. HTTP/2 introduserte også server push — tjeneren sender CSS/bilder før klienten har bedt om dem.

Svar: Med fil F, N klienter, tjenerkapasitet u_s, klient-opplastning u_i, klient-nedlastning d_i:

Klient–server: Dcs = max{ NF/us , F/dmin } — første ledd vokser lineært med N (tjeneren må laste opp filen N ganger).

P2P: DP2P = max{ F/us , F/dmin , NF/(us + Σui) } — det tredje leddet vokser med N i telleren, men nevneren vokser også fordi hver ny peer bidrar med sin u_i.

Hvorfor: I klient–server eksploderer kostnaden — dobler du N, dobler du tiden. I P2P bidrar etterspørselen sin egen kapasitet, og kurven flater ut. Det er prinsippet bak skalerbarheten til store P2P-fildelingsnettverk med mange samtidige nedlastere.

Svar: DASH (Dynamic, Adaptive Streaming over HTTP) deler videoen opp i mange korte chunks (typisk noen sekunder), koder hver chunk i flere bitrater (lav, middels, høy, ultra), og publiserer en manifest-fil med URL-er. Klienten henter manifestet, måler kontinuerlig båndbredden, og bestemmer selv hvilken chunk i hvilken kvalitet den ber om.

Hvorfor klient-side: Bare klienten kjenner sin egen bufferstatus, sin egen målte gjennomstrømning, og sine egne preferanser. En tjener som skulle pushe «riktig» kvalitet, måtte ha laget feedback-mekanismer per klient — det skalerer ikke til millioner. Dum tjener + smart klient er også grunnen til at DASH kjører over vanlig HTTP og drar nytte av cacher, brannmurer og CDN-er uten endringer.

Svar: Video komprimeres ved å utnytte to typer redundans: romlig (innen ett bilde — store ensfargede flater lagres som farge + antall piksler) og tidsmessig (mellom bilder — bilde i+1 lagres som forskjell fra i). Resultatet kan være CBR (constant bit rate, fast hastighet) eller VBR (variable bit rate, varierer med scenens kompleksitet). MPEG-4 dominerer Internett.

Hvorfor buffer: Båndbredden mellom tjener og klient varierer med trengsel underveis, mens avspillingen er strikt — bilder må komme i rekkefølge og til rett tid (continuous playout constraint). Klienten begynner å laste ned før den begynner å spille av, og bygger opp et forsprang. Når nettet midlertidig blir tregt, tærer avspillingen på bufferet i stedet for å stoppe. «Buffering…» dukker opp først når bufferet er tomt og nettet samtidig ikke leverer raskt nok.

Svar: Fire grunner: (1) Det blir et enkelt kritisk feilpunkt — én feil og hele verden mister tjenesten. (2) Enorm trengsel på linkene inn til datasenteret. (3) Lang reise for hver bruker, med tilhørende latens. (4) Samme video sendes over de samme stamlinjene millioner av ganger, sløsing med båndbredde.

Hvorfor det fører til CDN: Løsningen er å lagre kopier av innholdet på mange tjenere fordelt geografisk over hele kloden, og styre hver bruker til en tjener i nærheten. Det fjerner alle fire problemene på én gang: redundans mot feil, distribuert last, kort vei til brukeren, og hver populær video lastes ned få ganger til hver region — ikke én gang per bruker fra USA.

Svar: Enter deep (Akamai-modellen): plasser CDN-tjenere helt inne i mange aksessnett, så nær brukerne som mulig — Akamai hadde rundt 240 000 tjenere i 120+ land i 2015. Bring home (Limelight-modellen): et mindre antall større klynger plassert i POP-er nær — men ikke inni — aksessnettverkene.

Når hva: Enter deep gir minimal latens og minst trafikk over Internett-kjernen, men er driftsmessig komplekst (tusenvis av lokasjoner). Velg det for latenskritisk innhold som live-video. Bring home er enklere å drifte og kostnadsstyre, men gir litt høyere latens. Velg det når noe forsinkelse er akseptabelt og driftsenkelhet teller mer. DNS-omdirigering (CNAME til CDN-domenet) er det som styrer hver bruker til riktig node uansett strategi.

Svar: Bob klikker på en lenke til http://netcinema.com/6Y7B23V. (1) Nettleseren spør lokal DNS om IP til netcinema.com. (2) Lokal DNS spør netcinemas autoritative DNS, men får tilbake en CNAME-post som peker til et navn under kingcdn.com. (3) Lokal DNS må nå spørre KingCDN sin autoritative server. (4) KingCDN-serveren ser hvor i verden Bob er (basert på avsenderen av DNS-spørsmålet) og svarer med IP til den nærmeste KingCDN-noden som har innholdet. (5) Bob åpner en HTTP-forbindelse til den noden og strømmer videoen.

Hvorfor magien fungerer: Hele DNS-akrobatikken er usynlig for Bob — han skrev netcinema.com og fikk video fra en tjener noen kilometer unna. CNAME-mekanismen er det som lar netcinema delegere navneoppløsningen til CDN-en, som er den eneste som vet hvilken node som er nærmest brukeren akkurat nå.

Svar: Netflix kjører applikasjonslogikken (kontoer, betalinger, anbefalinger) i AWS, men leverer videoen fra sitt eget CDN, Open Connect, som følger en «enter deep»-strategi: dedikerte OCA-servere plassert direkte i ISP-enes nettverk. Strategien er push — Netflix forhåndsplasserer innhold aktivt. YouTube bruker Googles eget CDN med en kombinasjon av store datasenterklynger og mindre lokasjoner, og er mer pull-basert: ikke alt forhåndsplasseres, populært innhold cacher seg ut etter etterspørsel.

OTT (Over The Top): Innholdsleverandøren bygger sin egen distribusjonsoverbygning oppå Internett, uten å eie de underliggende linjene. Internett gir bare host-til-host-transport som tjeneste — all videolagring, server-utvelgelse, CDN-koreografering og DASH-logikk skjer på applikasjonslaget hos endesystemene leverandøren kontrollerer. Begge tjenestene er OTT og bruker DASH+HTTP for selve strømmingen.

Svar: (1) User agent — klientprogrammet du bruker for å lese og skrive (Outlook, Apple Mail, Gmails webgrensesnitt). (2) E-postservere — som lagrer meldinger i en innboks for det som kommer inn og en utgående kø for det som skal sendes. (3) SMTP — protokollen som binder serverne sammen og flytter meldinger mellom dem.

Hvorfor ikke direkte: Mottakeren har sjelden maskinen sin på når avsenderen sender. Hadde Alice's user agent måttet kontakte Bob's user agent direkte, ville e-post bare fungert hvis begge maskinene var på samtidig. Mailservere er alltid på og fungerer som mellomlager — Alice's server putter meldingen i en utgående kø og leverer når Bob's server er nåbar; Bob's server lagrer meldingen i postkassen til Bob plukker den opp. Asynkron levering er hele poenget.

Svar: SMTP (RFC 5321, port 25, over TCP) er en push-protokoll i klartekst-ASCII der avsenderens mailserver dytter meldinger frem til mottakerens mailserver. Samtalen har tre faser — håndhilsing (HELO), overføring (MAIL FROM, RCPT TO, DATA) og avslutning (QUIT) — og meldingen avsluttes med CRLF.CRLF. Alt må være 7-bits ASCII, så binære vedlegg MIME-kodes.

Hvorfor egen access-protokoll: Bob skal hente posten — kanskje fra mobil, kanskje senere, kanskje fra flere enheter. Det er pull, et helt annet bruksmønster enn SMTPs push. Derfor bruker man IMAP (eller HTTPS for webmail) mellom mottakerens server og mottakerens klient. SMTP brukes kun mellom serverne (og fra avsenderens klient inn til hans egen server).

Svar: Tre faser: håndhilsing (HELO), overføring (MAIL FROM, RCPT TO, DATA) og avslutning (QUIT). Klienten skriver kommandoer i klartekst-ASCII; serveren svarer med en tresifret statuskode + kort tekst. Etter DATA sender klienten meldingen og avslutter med en linje med kun ett punktum (serveren ser etter CRLF.CRLF).

Statuskodene: 220 — server klar (åpning). 250 — OK, kommandoen lyktes. 354 — fortsett, send meldingsinnhold. 221 — lukker forbindelsen pent. Mønsteret minner om HTTPs koder, men SMTP er eldre (RFC 821 fra 1982, oppdatert til RFC 5321) og brukes fortsatt nesten uendret — et bevis på hvor godt det løste problemet sitt.

Svar: De to mail-access-protokollene som er pensum, er IMAP og HTTP(S). IMAP lar klienter synkronisere mapper, flagg og meldingsstatus mens e-posten forblir lagret på serveren. HTTP(S) brukes av webmail (Gmail, Outlook på web), der nettleseren snakker direkte med tjenestens egen webserver i stedet for med en mailprotokoll.

Hvorfor ikke SMTP: SMTP er en push-protokoll — avsender dytter meldingen frem til mottakerens server. Mottakeren skal pull-e meldingene ned (kanskje fra mobil, kanskje senere, kanskje fra flere enheter), og det er et helt annet bruksmønster. Derfor IMAP (eller HTTPS for webmail) mellom mottakerens server og hans klient, og SMTP kun mellom serverne.

Svar: SMTP-kommandoene er en del av forhandlingen mellom mailserverne — analogt med utsiden av en konvolutt: «hvem sender, hvem skal motta». RFC 822-headerne er en del av selve brevet som ligger inne i konvolutten, sammen med en blank linje og deretter brødteksten (body).

Hvorfor det betyr noe: Adressene er ofte de samme begge steder, men trenger ikke å være det. Det er nettopp dette gapet som utnyttes i visse phishing-angrep: MAIL FROM kan være en server som har tillatelse til å levere, mens From: i headeren forfalskes til å se ut som en troverdig avsender. Den som leser e-posten ser bare RFC 822-headerne; SMTP-konvolutten er mest synlig for serverne underveis.

Svar: Webmail = HTTPS fra deg til din egen server, SMTP mellom serverne, HTTPS fra mottakerens server til mottakeren. Tradisjonell e-postklient (Outlook, Apple Mail) = SMTP fra deg ut, SMTP mellom serverne, IMAP fra mottakerens server til mottakeren.

Hvorfor blandingen: Når du bruker Gmail i nettleseren, er det ikke SMTP du snakker fra nettleseren ut til Googles server — det er HTTPS. Først når Gmails servere skal levere meldingen videre til mottakerens server, kommer SMTP inn. SMTP er fortsatt limet mellom organisasjoner; alt fra brukeren til hans egen server er gjerne HTTPS når det er en webtjeneste, eller SMTP/IMAP når det er en tradisjonell klient. Blanding er normalen, ikke unntaket.

Svar: DNS har tre nivåer: rotservere (ca. 13 logiske, replikert til 1000+ fysiske via anycast, koordinert av IANA (under ICANN)) → TLD-servere (.com, .no, .org …) → autoritative servere for hvert enkelt domene (driftet av domeneeieren selv). Ingen enkelt server vet alt; hver server vet litt og vet hvem den skal spørre om resten.

Hvorfor ikke sentralt: Comcast alene håndterer ~600 milliarder DNS-oppslag i døgnet. Én sentral server ville (1) være et enkeltpunkt for feil, (2) ha umulig trafikkvolum, (3) være langt unna for de fleste, (4) være umulig å holde oppdatert når enhver kan flytte sin tjeneste til ny IP. Hierarkiet fordeler både last og administrativt ansvar, og caching gjør at det meste stopper hos den lokale navneserveren.

Svar: Mellom maskinen din og hele DNS-hierarkiet sitter en lokal navneserver — driftet av ISP-en din, NTNU, eller bedriften du jobber i. Hver gang maskinen din skal slå opp et navn, går spørsmålet alltid først hit. Den lokale serveren er teknisk sett ikke en del av selve DNS-hierarkiet, men er den absolutt viktigste serveren for ytelsen din.

Hvorfor: Den har en lokal cache med navn den nylig har slått opp. Ligger svaret der, slipper du hele turen oppover hierarkiet — du får svaret tilbake på millisekunder. Det er derfor DNS oppleves som umiddelbart selv om det egentlig kan involvere flere mellomledd: de fleste forespørsler stopper i cachen. Den lokale serveren er det som skjuler all kompleksiteten, og samtidig det som utfører selve hopperingen i iterative oppslag.

Svar: I iterativ oppslag svarer hver navneserver med «jeg vet ikke, men spør denne i stedet» — den lokale navneserveren gjør selv hopperingen: rot → TLD → autoritativ, og samler svaret. I rekursiv oppslag spør den lokale serveren rotserveren og sier «finn ut av dette for meg»; rotserveren spør TLD som spør autoritativ, og svaret bobler tilbake gjennom hele kjeden.

Hvorfor det blir en miks: Rekursivt er enkelt på klientsiden, men legger tung last på de øverste lagene. Iterativt fordeler arbeidet, men gjør den lokale serveren mer kompleks. I praksis er det vanligvis rekursivt mellom deg og din lokale navneserver, og iterativt videre opp i hierarkiet — det balanserer enkelhet ved klienten mot skalerbarhet for rot-/TLD-serverne.

Svar: Når en navneserver lærer en mapping, lagrer den den i minnet sitt for fremtidige forespørsler. Hver resource record har en TTL (time to live) som sier hvor lenge svaret er gyldig — etter TTL utløper må mappingen hentes på nytt. Lokale navneservere har stort sett alltid TLD-servernes adresser i cachen, så iterative oppslag kan hoppe rett til TLD og videre derfra.

Konsekvensen: Rot-serverne blir dermed «kontakt-av-siste-utvei» — viktig at de finnes, men sjelden faktisk forespurt. Bakdelen er at endringer ikke forplanter seg umiddelbart: hvis du flytter en tjeneste til ny IP, vil cachede svar med gammel IP fortsatt brukes til TTL utløper. Det er ikke en feil, det er TTL-en som gjør jobben sin — du må bare planlegge for det ved å sette lav TTL i forkant av en flytting.

Svar: DNS bruker stort sett UDP på port 53. Hvert spørsmål er kort nok til å passe i én UDP-pakke, og spørsmål-svar-mønsteret er idempotent — hvis svaret ikke kommer, prøver klienten bare på nytt. Både spørsmål og svar har samme meldingsformat: en header med en 16-bits identifikator og noen flagg, etterfulgt av seksjoner for spørsmål, svar, autoritative poster og tilleggsinformasjon.

Hvorfor UDP og ikke TCP: DNS skjer milliarder av ganger om dagen. TCPs trefoldige håndtrykk og forbindelsestilstand ville lagt på en RTT og betydelig overhead på hvert oppslag — uakseptabelt når lavest mulig latens er hele poenget med å cache mye, spørre lite, og gjenta ved tap. ID-feltet i headeren lar serveren matche svar mot spørsmål når mange er underveis samtidig.

Svar: Hver RR har formatet (name, value, type, ttl):

A: name = hostname, value = IPv4-adresse — den klassiske «navn til IP»-mappingen.
NS: name = domene (f.eks. amazon.com), value = hostname til en autoritativ navneserver for det domenet.
CNAME: name = alias, value = det kanoniske navnet — gjør at www.ibm.com kan peke videre til noe sånt som servereast.backup2.ibm.com.
MX: name = domene, value = hostname til en mailserver for domenet.

Hvorfor MX og CNAME er separate: Uten MX-poster ville e-post for et domene ikke fungert — sendere må vite hvilken server som tar imot, og den heter sjelden det samme som webserveren. CNAME muliggjør CDN-magi: netcinema.com kan peke til kingcdn.com uten at brukeren merker det.

Svar: Du går til en registrar — en ICANN-akkreditert organisasjon (GoDaddy, Domeneshop osv.) — sjekker at navnet er ledig, betaler en avgift, og oppgir navn og IP-adresser til dine egne autoritative navneservere (f.eks. dns1.networkutopia.com, dns2.networkutopia.com). Registraren setter da inn poster i .com-TLD-serverne: en NS-post som peker domenet til dine navneservere, og en A-post med IP-adressene deres.

Hvorfor flere ledd: Etter registrering legger du selv inn A-poster for webserveren (www.networkutopia.com → IP) og MX-poster for mailserveren på dine autoritative servere. Da er hele kjeden komplett: root → TLD → autoritativ → endelig svar. ICANN delegerer altså myndighet nedover — TLD-eieren kontrollerer .com, du kontrollerer ditt eget domene.

Svar: (1) DDoS — bombardere root- eller TLD-serverne med trafikk for å lamme dem. Hittil aldri lyktes med å lamme Internett, blant annet på grunn av caching og trafikkfiltrering. (2) DNS-poisoning — sende falske svar til en navneserver så den cacher feil informasjon og sender brukere til feil sted. (3) DNS-amplifisering — sende DNS-spørsmål med forfalsket avsender-IP slik at de mye større svarene treffer offeret; brukes som DDoS-våpen.

DNSSEC (RFC 4033) er forsvaret: digitale signaturer på DNS-svar slik at klienten kan verifisere at svaret faktisk kommer fra en autoritativ kilde. Det stopper poisoning ved at usigerte/feilaktige svar avvises. Ikke universelt utrullet ennå, men er den langsiktige løsningen. DDoS løses heller med caching, anycast-replikering av rotservere, og trafikkfiltrering.

Svar: En UDP-server klarer seg med én sokkel for alle klienter (SOCK_DGRAM): recvfrom returnerer både dataene og avsenderens adresse, og sendto tar adresse hver gang — det er ingen forbindelse å holde rede på. En TCP-server (SOCK_STREAM) har to typer sokler: en velkomstsokkel som gjør accept() og venter på nye forbindelser, og én forbindelsessokkel per aktiv klient.

Hvorfor: TCP er forbindelsesorientert. Når en klient kobler seg til, lager OS en helt ny sokkel dedikert til akkurat denne samtalen, slik at innkommende bytes kan rutes til riktig sesjon. Velkomstsokkelen lever videre og venter på neste klient. Slik kan én server snakke med mange klienter parallelt — én velkomst, mange forbindelser.

Svar:

(1) Push vs pull: SMTP er push (avsender dytter), HTTP og IMAP er pull (mottaker spør). Bruksmønsteret bestemmer protokollformen.

(2) Sentralisert vs desentralisert: SMTP er desentralisert (hver organisasjon driver sin server). DNS er hierarkisk distribuert — ingen vet alt, men strukturen sikrer at du alltid kan finne den som vet. Sentralisering er enkelt; desentralisering er nødvendig på Internetts skala.

(3) Tilstandsløs vs tilstand: HTTP er tilstandsløs for skalerbarhet; cookies legger på tilstand der det trengs. UDP er tilstandsløs, TCP er tilstandsbevart.

(4) Kompleksitet i kanten: Selve nettverket er bevisst dumt; all intelligens sitter i endepunktene. Det er derfor en student kan rulle ut en ny tjeneste globalt uten å spørre noen om lov.

Hvorfor: Hvert designvalg ble tatt fordi alternativet ikke ville fungert i den skalaen eller med de begrensningene som fantes. Når du forstår problemet, blir formen protokollen tar nesten uunngåelig.