Se for deg at en uavhengig skaper nettopp har lastet opp en video. Når første seer åpner siden, deler ingen andre filen. En time senere ser mange samtidig. Noen dager etter er besøkene sporadiske. Det samme innholdet har opplevd tre leveringssituasjoner. Én hastighetsmåling sier lite om systemet egner seg for langsiktig drift.
P2P og CDN må utformes for hele denne livssyklusen. P2P lar deltakerne levere data til hverandre, mens CDN gir et mer styrbart tjenestepunkt. Arbeidsdelingen bør avhenge av tilkoblingsforhold, etterspørsel og avspillingsmål.
Sjekk først om seerne kan koble seg til hverandre
Nettlesere og skrivebordsprogrammer har ulike nettverksmuligheter. WebTorrents offisielle FAQ sier at nettleserklienter trenger motparter som støtter WebRTC. En ressurs på det tradisjonelle BitTorrent-nettverket kan ikke nødvendigvis hentes direkte fra alle noder i nettleseren. WebTorrent FAQ
Test derfor nettklienter, skrivebordsklienter og nettverksmiljøer hver for seg. Kontornett, hjemmerutere og mobilnett kan gi ulike tilkoblingsvilkår. At det virker på én utviklermaskin, er ikke et felles utgangspunkt for alle brukere.
Tilkoblinger kan også kreve støtteinfrastruktur. libp2ps WebRTC-veiledning beskriver STUN, signalering og reléer og påpeker at videresending av trafikk koster å drifte. Komponentene avhenger av implementasjonen. libp2ps tilkoblingsveiledning
Vi anbefaler å registrere tilkoblingsfeil separat. Ellers kan en tom spiller bare fremstå som «treg nedlasting», uten at teamet vet om feilen oppstår under søk etter motparter, tilkobling eller dataoverføring.
Fordel rollene gjennom innholdets livssyklus
Tabellen er et utgangspunkt for arkitekturdiskusjon, ikke et ytelsesløfte for et produkt:
| Situasjon | Prioritert egenskap | Hva P2P kan bidra med |
|---|---|---|
| Nylig publisert, få motparter | Pålitelig seed eller HTTP-kilde | La de første mottakerne gradvis begynne å dele |
| Mange samtidige seere | Rask første bilderamme og sammenhengende avspilling | Dele gjentatte overføringer når forbindelsene tillater det |
| Sjeldent etterspurt innhold | Minst én varig tilgjengelig kilde | Supplere med kopier som er på nett av og til |
| Begrensede brukernettverk | Tydelige feilmeldinger og reserveløsninger | Delta når forbindelsen virker, uten uendelig venting |
HTTP og P2P kan kombineres. BitTorrents BEP 19 beskriver nedlasting fra HTTP/FTP-kilder med WebSeed, og WebTorrent tilbyr et API for å legge til WebSeeds. BEP 19 · WebTorrent API
Et API er bare starten. Sjekk at kildefilene stemmer overens, at serveren støtter nødvendige forespørsler, og at nettleserens innstillinger for tilgang på tvers av domener er riktige. Test reserveløsningen før lansering, ikke først når det blir få noder.
La avspillingsprioriteter styre nedlastingen
En full nedlasting skal til slutt hente hele filen; videovisning krever at viktige data kommer i tide. En rask første bilderamme og videre avspilling etter spoling betyr vanligvis mer enn antall noder i bakgrunnen.
En mulig hybridstrategi er å bruke en pålitelig kilde ved oppstart, deretter innlemme motparter etter tilkoblingskvalitet og raskt fylle manglende data når bufferen tømmes. Sett terskler for reserveløsningen med tester på faktiske enheter og nettverk, ikke ett fast sekundtall for alle programmer.
Håndter også doble forespørsler. Hvis to kilder henter samme del, bør unødvendige forespørsler avbrytes der det er mulig, og forbrukte, ubrukte byte telles. Ellers kan tilsynelatende akselerasjon bare bytte økt trafikk mot en tilfeldig fartsgevinst.
Regn kostnader for hele systemet
Del kostnadene i innholdslagring, seednoder, reléer, utgående CDN-trafikk samt brukernes opplasting og enhetsforbruk. En lavere serverregning fjerner ikke andre deltakeres kostnader.
Lag først en referanse med bare HTTP, og vurder så hybriden med sammenlignbart innhold, regioner, enheter og avspillingsoppgaver. Sammenlign fullførte visninger, ikke bare serverens utgående byte i en periode. Mange seere som slutter tidlig, kan også redusere trafikken.
Deling fra brukerens enhet må forklares tydelig. Opplastingsgrenser, mobilnettvalg og regler for å lukke forbindelser ved avslutning viser når brukeren deltar. Felles deling bygger på forståelige valg, ikke en uklar «akselerasjon»-bryter.
Test med målinger som forklarer resultatet
Et lite forsøk bør minst besvare disse spørsmålene:
- Første bilderamme: hvor lenge venter seere på nytt og populært innhold?
- Sammenhengende avspilling: hvor ofte og lenge stopper den, og hvordan gjenopptas den etter spoling?
- Kildebidrag: hvor mye nyttige data kommer fra direkte motparter, HTTP og reléer?
- Reserveløsning: fortsetter avspillingen uten motparter, ved tilkoblingsfeil og frakoblede seeds?
- Samlet forbruk: er doble nedlastinger, mislykkede gjentakelser og brukeropplasting inkludert?
Behold oppdeling etter region, klientversjon og nettverkstype i stedet for bare et gjennomsnitt. En løsning kan passe lange videoer med samtidige seere, men fungere dårlig for små filer som hentes sjelden. Et tydelig bruksområde hjelper ressursene å gjøre nytte.
AlphaBizs offentlige arkitekturbeskrivelse nevner WebTorrent. For slike medieprogrammer handler hybridlevering først og fremst om å la folk se ferdig under ulike nettverksforhold, ikke bare maksimere P2P-andelen. AlphaBizs prosjektbeskrivelse
Start med en reell avspillingsoppgave og registrer feil og reserveatferd før du optimaliserer protokoller og kostnader. Del scenariet og målemetodene i AlphaBiz Discussions for å diskutere reproduserbare resultater.