Kuvittele, että itsenäinen tekijä on juuri ladannut videon. Ensimmäisen katsojan avatessa sivun kukaan muu ei vielä jaa tiedostoa. Tunnin kuluttua katsojia on paljon samanaikaisesti. Muutaman päivän päästä käyntejä on enää satunnaisesti. Sama sisältö kohtaa kolme jakelutilannetta. Yksi latausnopeuden mittaus kertoo vähän järjestelmän sopivuudesta pitkäaikaiseen käyttöön.
P2P:n ja CDN:n suunnittelun on katettava koko elinkaari. P2P mahdollistaa tiedon jakamisen osallistujien kesken, CDN tarjoaa hallittavamman palvelupisteen. Työnjaon tulisi riippua yhteyksistä, kysynnästä ja toiston tavoitteista.
Selvitä ensin, voivatko katsojat muodostaa yhteyden
Selainten ja työpöytäsovellusten verkko-ominaisuudet eroavat. WebTorrentin virallinen FAQ kertoo, että selainasiakkaat tarvitsevat WebRTC:tä tukevia vertaisia. Resurssin olemassaolo perinteisessä BitTorrent-verkossa ei tarkoita, että selain voi hakea sen suoraan kaikista solmuista. WebTorrent FAQ
Siksi selain- ja työpöytäasiakkaat sekä verkkoympäristöt on testattava erikseen. Toimistoverkot, kotireitittimet ja mobiiliverkot tarjoavat erilaiset yhteysolosuhteet. Onnistuminen yhdellä kehityskoneella ei ole kaikkien käyttäjien lähtökohta.
Yhteyden muodostaminen voi vaatia tuki-infrastruktuuria. libp2p:n WebRTC-opas käsittelee STUNia, signalointia ja välityspalvelimia sekä huomauttaa välitetyn liikenteen käyttökustannuksista. Tarvittavat osat riippuvat toteutuksesta. libp2p:n yhteysopas
Suosittelemme kirjaamaan yhteysvirheet erikseen. Muuten tyhjä videosoitin voi näyttää vain ”hitaalta lataukselta”, eikä tiimi tiedä, syntyikö ongelma vertaisten löytämisessä, yhteyden muodostuksessa vai tiedonsiirrossa.
Jaa tehtävät sisällön elinkaaren mukaan
Taulukko on arkkitehtuurikeskustelun pohja, ei minkään tuotteen suorituskykylupaus:
| Tilanne | Ensisijainen kyvykkyys | P2P:n mahdollinen tehtävä |
|---|---|---|
| Uusi julkaisu, vähän vertaisia | Luotettava jakaja tai HTTP-lähde | Ensimmäiset vastaanottajat alkavat vähitellen jakaa |
| Paljon samanaikaisia katsojia | Nopea ensimmäinen kuva ja jatkuva toisto | Toistuvien siirtojen jakaminen yhteyksien salliessa |
| Harvoin katsottu sisältö | Ainakin yksi jatkuvasti saatavilla oleva lähde | Jakelun täydentäminen ajoittain verkossa olevilla kopioilla |
| Rajoitettu käyttäjän verkko | Selkeät virheet ja varareitti | Osallistuminen toimivalla yhteydellä ilman loputonta odotusta |
HTTP ja P2P eivät sulje toisiaan pois. BitTorrentin BEP 19 kuvaa lataamista HTTP/FTP-lähteistä WebSeedien avulla, ja WebTorrent tarjoaa rajapinnan niiden lisäämiseen. BEP 19 · WebTorrent API
Rajapinta on vasta alku. Tarkista lähdetiedostojen vastaavuus, palvelimen tuki tarvittaville pyynnöille ja selaimen toimialueiden välisen käytön asetukset. Testaa varareitti ennen julkaisua sen sijaan, että rakentaisit sen kiireessä solmujen loppuessa.
Huomioi toiston tarpeet latausten ajoituksessa
Täysi lataus tavoittelee lopulta koko tiedostoa; videon katselu tarvitsee tärkeät tiedot ajoissa. Nopea ensimmäinen kuva ja toiston jatkuminen siirtymisen jälkeen merkitsevät katsojalle yleensä enemmän kuin taustalla näkyvä solmumäärä.
Yksi arvioitava hybridistrategia käyttää luotettavaa lähdettä alussa, ottaa vertaisia mukaan yhteyden laadun perusteella ja täydentää puuttuvat tiedot nopeasti puskurin vähentyessä. Määritä varareitin rajat todellisilla laitteilla ja verkoilla, älä yhdellä kaikille sovelluksille tarkoitetulla sekuntimäärällä.
Käsittele myös päällekkäiset pyynnöt. Jos kaksi lähdettä lataa samaa osaa, peru tarpeettomat pyynnöt mahdollisuuksien mukaan ja laske kulutetut mutta käyttämättömät tavut mukaan. Muuten näennäinen monilähdekiihdytys voi vaihtaa suuremman liikennemäärän satunnaiseen nopeushyötyyn.
Laske koko järjestelmän kustannukset
Erittele sisällön säilytys, jakajasolmut, välityspalvelimet, CDN:n ulosmenevä liikenne sekä käyttäjien lähetysliikenne ja laitteiden kulutus. Yhden palvelinkulun lasku ei poista muiden osallistujien kustannuksia.
Luo ensin pelkän HTTP-jakelun vertailutaso ja arvioi hybridiä vastaavalla sisällöllä, alueilla, laitteilla ja toistotehtävillä. Vertaa loppuun katsottuja katselukertoja, älä vain palvelimen ulosmeneviä tavuja ajanjaksolla. Myös katsojien varhainen poistuminen voi vähentää liikennettä.
Käyttäjän laitteelta jakaminen on selitettävä. Lähetysrajat, mobiiliverkkoasetukset ja yhteyksien sulkeminen sovelluksesta poistuttaessa auttavat ymmärtämään osallistumista. Yhteisöllinen jakaminen perustuu ymmärrettäviin valintoihin, ei epämääräiseen ”kiihdytys”-kytkimeen.
Testaa tuloksia selittävillä mittareilla
Pienen kokeilun pitäisi vastata ainakin seuraaviin kysymyksiin:
- Ensimmäinen kuva: kuinka kauan uuden ja suositun sisällön katsojat odottavat?
- Toiston jatkuvuus: kuinka usein ja pitkäksi aikaa toisto pysähtyy, ja miten se palautuu siirtymisen jälkeen?
- Lähteiden osuus: paljonko hyödyllistä tietoa tulee suorilta vertaisilta, HTTP:stä ja välityspalvelimilta?
- Varareitin laatu: jatkuuko katselu ilman vertaisia, yhteysvirheissä ja jakajien poistuessa verkosta?
- Kokonaiskulutus: huomioidaanko päällekkäiset lataukset, epäonnistuneet yritykset ja käyttäjien lähetykset?
Säilytä erittely alueen, asiakasversion ja verkkotyypin mukaan, älä julkaise vain keskiarvoa. Ratkaisu voi sopia pitkille, samanaikaisesti katsotuille videoille mutta huonosti harvoin haettaville pienille tiedostoille. Käyttöalueen tunteminen ohjaa resurssit hyödyllisesti.
AlphaBizin julkinen arkkitehtuurikuvaus mainitsee WebTorrentin. Tällaisissa mediasovelluksissa hybridijakelun keskeinen kysymys on, miten käyttäjä saa katsottua loppuun erilaisissa verkoissa, ei vain P2P-osuuden maksimointi. AlphaBizin projektikuvaus
Aloita oikeasta toistotehtävästä ja kirjaa virheet sekä varareitin toiminta ennen protokollien ja kulujen optimointia. Jaa tilanteesi ja mittaustapasi AlphaBiz Discussionsissa, jotta tuloksista voidaan keskustella toistettavasti.