P2P, video og CDN

Når alle hjelper til

Hvor mye raskere kan en peer-to-peer-distribusjon faktisk være enn klient–server? La oss regne ut det matematisk — og se det visuelt.

La oss konkretisere problemet. En tjener har en fil av størrelse F som skal distribueres til N klienter. Tjeneren har opplastningskapasitet u_s. Hver klient i har opplastningskapasitet u_i og nedlastningskapasitet d_i. Vi antar at nettverket i kjernen har rikelig med båndbredde — flaskehalsene er ved endesystemene. Spørsmålet er: hvor lang tid tar det for alle N klientene å motta filen?

Klient–server: lineær i N

I klient–server-modellen må tjeneren laste opp filen N ganger — én gang per klient. Tiden for én opplastning er F/u_s, så total opplastningstid er NF/u_s. Samtidig kan ingen klient motta raskere enn sin egen nedlastningshastighet, så den tregeste klienten trenger minst F/d_min. Den totale tiden er det største av disse to:

P2P: bremser opp, men flatner ut

I P2P er regnskapet annerledes. Tjeneren må fortsatt laste opp filen minst én gang for at den skal komme inn i systemet — det gir et minimum på F/u_s. Den tregeste klienten må fortsatt laste ned hele filen — F/d_min. Men det tredje leddet er det interessante: total mengde data som må leveres er NF bits, og maksimal samlet opplastningskapasitet i systemet er u_s + Σu_i. Dette gir:

Forskjellen er enklere å se i et eksempel. Anta at hver klient har opplastningshastighet u, at det tar én time å laste opp filen én gang (F/u = 1 t), og at tjenerens hastighet er ti ganger en klients (u_s = 10u). For klient–server blir det dominerende leddet NF/u_s = N/10 — en rett linje opp og bort (inntil nedlastingsgulvet F/d_min tar over). For P2P er det tredje leddet N/(10+N) — en kurve som stiger raskt mot 1, men aldri når den. Den faktiske P2P-tiden er likevel max av alle leddene i ulikheten; med normeringen F/d_min = 1 t ligger dette gulvet ofte øverst, så den effektive tiden i figuren blir en flat strek ved 1 — ikke fordi tredje leddet er irrelevant, men fordi det ligger under max.

Du kan leke med tallene selv:

Strømmet video, og hvorfor det er vanskelig

Netflix, YouTube og Amazon Prime stod for omtrent 80 % av den residentiale ISP-trafikken i 2020. Hvordan får man en milliard mennesker til å se HD-video samtidig?

Først litt om hva video er. En video er bare en sekvens av bilder vist i konstant hastighet — typisk 24 eller 30 bilder i sekundet. Hvert bilde er en matrise av piksler, hver piksel representert som noen byte. Rå video er enormt: ukomprimert HD-video er gigabyter per minutt. Derfor komprimeres video alltid før den sendes, og komprimeringen utnytter to typer redundans. Romlig redundans innen ett bilde: hvis en stor flate er samme farge, lagre fargen og antall piksler istedenfor hver enkelt piksel. Tidsmessig redundans mellom påfølgende bilder: istedenfor å sende hele bilde i+1, send bare forskjellene fra bilde i. Det er denne dobbelte komprimeringen som gjør at MPEG-4 kan klemme HD-video ned til noen få megabit i sekundet.

Resultatet av komprimeringen kan være CBR (constant bit rate) — fast bithastighet, slik som MPEG-1 (1,5 Mbps) eller MPEG-2 DVD (3–6 Mbps) — eller VBR (variable bit rate), der hastigheten varierer ut fra hvor mye bevegelse og detalj som er i scenen. MPEG-4, som dominerer på Internett, kan ligge alt fra 64 kbps til 12 Mbps avhengig av kvalitet og innhold.

Den vanskelige delen: konstant avspilling, varierende nett

Når video er kodet og lagret på en tjener, må vi sende den til klienten over et nett som er alt annet enn forutsigbart. Båndbredden mellom tjener og klient varierer med trengsel i hjemmenettet, aksessnettet, kjernenettet og selve tjeneren. Pakker mister og forsinker. Men avspillingen hos klienten er strikt: når én gang spillingen har startet, må bildene komme i riktig rekkefølge og til riktig tid. Dette kalles continuous playout constraint — kontinuitetskravet.

Hvordan løser man det? Med en buffer på klientsiden. Klienten begynner å laste ned video før hen begynner å spille av, og bygger opp et lite forsprang. Når nettet midlertidig blir tregt, tærer avspillingen på bufferet istedenfor å stoppe opp. Når nettet blir raskt igjen, fyller bufferet seg på ny. Du har sikkert sett resultatet: «buffering...» dukker opp først når bufferet er tomt og nettet samtidig ikke leverer raskt nok.

DASH: la klienten bestemme

Den moderne løsningen for strømming heter DASH — Dynamic, Adaptive Streaming over HTTP. Idéen er å gi all intelligensen til klienten, og holde tjeneren dum. Tjenerens jobb: del videoen opp i mange korte chunks (typisk noen sekunder hver), kod hver chunk i mange forskjellige bithastigheter (lav, middels, høy, ultra), og lag en manifest-fil som lister opp URL-ene for alle chunks i alle kvaliteter.

Klienten henter manifestet, måler kontinuerlig båndbredden mot tjeneren, og bestemmer selv: hvilken chunk skal jeg be om nå, og i hvilken kvalitet? Når båndbredden er god, ber den om høyoppløselige chunks. Når båndbredden faller, faller den ned til lavere oppløsning — uten å pause avspillingen. Klienten kan også bestemme hvor den skal hente chunken fra, hvis flere tjenere har den.

Fordi alt foregår over vanlig HTTP, drar DASH nytte av alt det eksisterende web-stacket: cacher, brannmurer, lastbalansere, CDN-er. Dette er en del av hvorfor DASH har vunnet over eldre, dedikerte strømmeprotokoller.

Hvordan Netflix slipper å sende fra ett sted

Selv med DASH har vi et problem: hundretusenvis av samtidige seere som krever millioner av forskjellige videoer. Én tjener — selv en mega-tjener — kan ikke gjøre det. Vi må fysisk distribuere innholdet.

Tenk deg at Netflix prøvde å betjene hele verden fra ett enkelt datasenter i California. Det ville ikke fungere. For det første ville det vært et enkelt kritisk feilpunkt — én feil og hele verden mister Netflix. For det andre ville det skapt enorm trengsel på nettverkslinkene inn til datasenteret. For det tredje ville hver bruker fått en altfor lang reise frem til innholdet, med tilhørende latens. For det fjerde ville samme video blitt sendt over de samme stamlinjene millioner av ganger. Kort sagt: én mega-tjener skalerer ikke.

Løsningen er et Content Distribution Network — CDN. Idéen er enkel: lagre kopier av innholdet på mange tjenere fordelt geografisk over hele kloden, og styr hver bruker til en tjener i nærheten. Det finnes to varianter av strategien.

Den ene heter «enter deep»: dytt CDN-tjenere helt inn i mange aksessnettverk, så nær brukerne som overhodet mulig. Akamai, en pioner i bransjen, hadde rundt 240 000 tjenere i mer enn 120 land i 2015. Fordelen er at innholdet ligger nesten på samme ISP som brukeren — minimal latens, minimal trafikk over Internett-kjernen. Ulempen er kompleksitet: du må administrere et enormt antall fysiske lokasjoner.

Den andre heter «bring home»: et mindre antall (titalls) større klynger plassert i POP-er nær — men ikke inni — aksessnettverkene. Limelight er et eksempel. Det er enklere å drifte, men gir litt høyere latens enn enter-deep.

Hvordan en bruker faktisk havner på riktig CDN-tjener

Når du klikker på en Netflix-video, foregår det en koreografert dans bak kulissene. La oss følge Bob, som vil se en film som ligger lagret som http://netcinema.com/6Y7B23V men faktisk er kopiert ut til en CDN under domenet KingCDN.com.

Bob klikker på lenken fra netcinema.com sin webside (steg ①). Nettleseren spør sin lokale DNS hvilken IP-adresse netcinema.com har (②). Den lokale DNS-en spør netcinemas autoritative DNS (③), men istedenfor å få en IP-adresse direkte, får den en CNAME tilbake — en alias-omdirigering — som peker mot et navn under KingCDN.com (④). Den lokale DNS-en må da spørre KingCDN sin autoritative DNS, og denne tjeneren har magien: den vet hvor i verden Bob er (basert på hvilken DNS-forespørsel som kom inn) og svarer med IP-adressen til den nærmeste KingCDN-noden som har videoen (⑤). Bob åpner en HTTP-forbindelse til den noden og strømmer videoen (⑥).

Hele DNS-akrobatikken er usynlig for Bob. Han skrev netcinema.com i nettleseren; han fikk video fra en tjener noen kilometer unna. Det er CDN-magien.

OTT — over the top

En CDN som Netflix er et OTT-system: «over the top». Det betyr at innholdsleverandøren bygger sin egen distribusjons-overbygning oppå Internett, uten å eie de underliggende linjene. Internett gir bare host-til-host-kommunikasjon som tjeneste — alt det smarte, all videolagring, all server-utvelgelse, all DASH-koreografering, foregår på applikasjonslaget på endesystemene som Netflix kontrollerer. Utfordringene er reelle: hvilken CDN-node skal en gitt seer hentes fra? Hvordan oppfører seere seg når nettet er treigt? Hvilket innhold skal lagres på hvilke noder, gitt at man ikke har plass til alt overalt?

Netflix og YouTube — to forskjellige strategier

Netflix bruker en todelt arkitektur. Selve applikasjonslogikken — brukerkontoer, betalinger, søk, anbefalinger — kjører i Amazon Web Services (AWS), altså i skyen. Men videoen leveres fra Netflix sitt eget CDN, kalt Open Connect. Open Connect følger en «enter deep»-strategi: Netflix plasserer dedikerte servere (kalt OCA-er) direkte inne i ISP-enes nettverk over hele verden. Når du trykker «play» i Netflix-appen, bestemmer Netflix sin programvare (via AWS) hvilken OCA som er best for deg — basert på nettverksnærhet og kapasitet — og du strømmer videoen derfra med DASH over HTTP.

YouTube bruker Googles eget private CDN, med en kombinasjon av store datasenterklynger og mange mindre lokasjoner nærmere brukerne. En viktig forskjell fra Netflix er at YouTube i større grad bruker pull-basert caching: ikke alt innhold er forhåndsplassert overalt. Populært innhold havner naturlig på mange noder fordi det etterspørres ofte, mens sjeldent sett innhold kanskje bare finnes i et sentralt datasenter. YouTube bruker også DNS-omdirigering for å sende brukere til riktig klynge, men hele prosessen skjer innenfor Googles egen infrastruktur.