Forestil dig, at en uafhængig skaber netop har uploadet en video. Da første seer åbner siden, deler ingen andre filen. En time senere ser mange med samtidig. Få dage senere er besøgene sporadiske. Det samme indhold har mødt tre leveringsforhold. En enkelt hastighedsmåling siger lidt om systemets egnethed til langvarig drift.
P2P og CDN skal udformes til hele denne livscyklus. P2P lader deltagere levere data til hinanden, mens CDN giver et mere styrbart tjenestepunkt. Arbejdsdelingen bør afhænge af forbindelser, efterspørgsel og afspilningsmål.
Undersøg først, om seerne kan oprette forbindelse
Browsere og desktopprogrammer har forskellige netværksmuligheder. WebTorrents officielle FAQ forklarer, at browserklienter kræver modparter med WebRTC. En ressource på det traditionelle BitTorrent-netværk kan ikke nødvendigvis hentes direkte fra alle noder i browseren. WebTorrent FAQ
Test derfor webklienter, desktopklienter og netværksmiljøer hver for sig. Kontornet, hjemmeroutere og mobilnet giver forskellige forbindelsesvilkår. Succes på én udviklermaskine er ikke et fælles udgangspunkt for alle brugere.
Forbindelser kan også kræve støtteinfrastruktur. libp2ps WebRTC-guide beskriver STUN, signalering og relæer og påpeger driftsomkostninger ved videresendelse af trafik. Komponenterne afhænger af implementeringen. libp2ps forbindelsesguide
Vi anbefaler at registrere forbindelsesfejl separat. Ellers ligner en tom afspiller blot en ”langsom download”, uden at teamet ved, om fejlen opstod ved søgning efter modparter, oprettelse af forbindelsen eller dataoverførsel.
Fordel roller gennem indholdets livscyklus
Tabellen er et udgangspunkt for arkitekturdiskussion, ikke et løfte om et produkts ydeevne:
| Situation | Prioriteret funktion | P2P’s bidrag |
|---|---|---|
| Nyudgivet med få modparter | Pålidelig seed eller HTTP-kilde | Lade de første modtagere gradvist begynde at dele |
| Mange samtidige seere | Hurtigt første billede og ubrudt afspilning | Dele gentagne overførsler, når forbindelserne tillader det |
| Sjældent efterspurgt indhold | Mindst én vedvarende tilgængelig kilde | Supplere med kopier, der lejlighedsvis er online |
| Begrænsede brugernetværk | Tydelige fejl og reserveveje | Deltage, når forbindelsen virker, uden uendelig ventetid |
HTTP og P2P kan kombineres. BitTorrents BEP 19 beskriver download fra HTTP/FTP-kilder via WebSeed, og WebTorrent har et API til at tilføje WebSeeds. BEP 19 · WebTorrent API
Et API er kun begyndelsen. Kontrollér, at kildefiler matcher, at serveren understøtter de nødvendige forespørgsler, og at browserens indstillinger for adgang på tværs af domæner er korrekte. Afprøv reservevejen før udgivelse i stedet for at improvisere, når der mangler noder.
Lad afspilningsprioriteter styre hentningen
En fuld download skal til sidst hente hele filen; videovisning kræver, at vigtige data ankommer i tide. Et hurtigt første billede og fortsat afspilning efter spoling betyder normalt mere end antallet af noder i baggrunden.
En mulig hybridstrategi bruger en pålidelig kilde ved start, inddrager dernæst modparter efter forbindelseskvalitet og henter hurtigt manglende data, når bufferen svinder. Fastlæg grænser for reservevejen gennem test på virkelige enheder og netværk, ikke ét fast sekundtal til alle programmer.
Håndtér også dobbelte forespørgsler. Henter to kilder samme del, bør unødvendige forespørgsler om muligt annulleres, og forbrugte, ubrugte byte tælles med. Ellers kan tilsyneladende acceleration blot bytte ekstra trafik for en lejlighedsvis hastighedsgevinst.
Beregn omkostninger for hele systemet
Opdel udgifterne i indholdslagring, seednoder, relæer, udgående CDN-trafik samt brugernes upload og enhedsforbrug. En lavere serverudgift fjerner ikke andre deltageres omkostninger.
Opret først en reference med ren HTTP-levering, og vurder hybriden med sammenligneligt indhold, regioner, enheder og afspilningsopgaver. Sammenlign afsluttede visninger, ikke kun serverens udgående byte i en periode. Mange seere, der forlader tidligt, kan også sænke trafikken.
Deling fra brugerens enhed skal forklares tydeligt. Uploadgrænser, mobilnetvalg og regler for lukning af forbindelser ved afslutning viser, hvornår brugeren deltager. Fælles deling bygger på forståelige valg, ikke en uklar ”acceleration”-kontakt.
Test med målinger, der forklarer resultatet
Et mindre forsøg bør mindst besvare disse spørgsmål:
- Første billede: hvor længe venter seere på nyt og populært indhold?
- Kontinuitet: hvor ofte og længe stopper afspilningen, og hvordan genoptages den efter spoling?
- Kildebidrag: hvor meget nyttig data kommer fra direkte modparter, HTTP og relæer?
- Reservekvalitet: fortsætter visningen uden modparter, ved forbindelsesfejl og offline seeds?
- Samlet forbrug: medregnes dobbelte downloads, mislykkede gentagelser og brugerupload?
Behold opdeling efter region, klientversion og netværkstype frem for blot et gennemsnit. En løsning kan passe til lange videoer med samtidige seere, men fungere dårligt til små filer med spredte besøg. Et tydeligt anvendelsesområde hjælper ressourcerne med at gøre nytte.
AlphaBizs offentlige arkitekturbeskrivelse nævner WebTorrent. For sådanne medieprogrammer handler hybridlevering især om at hjælpe folk med at se færdigt under forskellige netværksforhold, ikke blot om at maksimere P2P-andelen. AlphaBizs projektbeskrivelse
Start med en virkelig afspilningsopgave, og registrér fejl og reserveadfærd før optimering af protokoller og udgifter. Del dit scenarie og dine målemetoder i AlphaBiz Discussions for at diskutere reproducerbare resultater.