Streaming video...
Prima di entrare nel merito dello streaming video, vediamo le caratteristiche dei video. I video sono delle sequenze di immagini visualizzate, in genere, a tasso costante come 24 o 30 immagini al secondo. Un'immagine non compressa e digitalmente codificata consiste in un array di pixel ognuno dei quali è codificato con un certo numero che identifica il colore che vuole rappresentare. I video possono essere compressi in modo tale da raggiungere un compromesso tra qualità e bit rate. Più è altro il bit rate, migliore è la qualità del video. Il bit rate è il tasso con la quale i bit vengono trasmessi in rete.
Esempio: un video con un bit rate di 2Mbps con una durata di 67 minuti consuma un gigabyte di spazio di archiviazione e di traffico. La misura più importante per lo streaming video è il throughput medio, il cui valore deve essere almeno pari al bit rate. La compressione può essere usata per creare diverse versione dello stesso video, con bit rate più o meno alto. Possono esistere video a 300kbps, a 1Mbps e a 3 Mbps. L'utente può scegliere quello più adatto per la sua larghezza di banda.
Streaming HTTPS e DASH...
Nello streaming HTTP il file video è memorizzato su un server HTTP e viene scaricato come un qualsiasi altro file quando viene richiesto con una GET da un client. I frame del video vengono scaricati dal browser in un buffer (dell'applicazione con cui è effettuata la richiesta, il browser in questo caso). Quando la memorizzazione nel buffer ha raggiunto una certa soglia, l'applicazione decodifica i frame nel buffer e li mostra all'utente. Il limite di HTTP è che il file video ricevuto dagli utente ha un bit rate fisso. Non tutti i client hanno la stessa larghezza di banda. Quindi client con larghezza di banda bassa visualizzeranno numerosi blocchi se il video è compresso con un alto bit rate. Per superare questi limiti nasce DASH (dynamic adaptive streaming over http). Il punto è che ci sono diverse versioni dello stesso file video a bit rate diverso. Il browser salva nel buffer un blocco di frame prelevandoli dal video col bit rate adatto alla larghezza di banda dell'utente in quel preciso momento. La qualità del video si adatta alla larghezza di banda disponibile. I video sono salvati nel server con URL diverso, nel server è disponibile un file (manifest) in cui sono disponibili i link a tutte le versioni di un file video. Il client all'inizio richiede questo file per venire a conoscenza delle locazioni dei video, poi li richiede (con delle GET) come spiegato sopra.
Reti per la distribuzioni di contenuti...
Come fa una società come YouTube che fruisce costantemente milioni di video ad utenti di tutto il mondo? Una soluzione potrebbe essere di salvare tutti i file video in un unico data center, ma questa soluzione presenta tre problemi:
- Se un client che richiede il video è molto distante dal data center centrale il video per giungere a destinazione deve percorrere un lungo cammino.
- Se il data center per qualche motivo non funziona, YouTube non può fruire nessun video (unico punto di rottura).
- Possono esserci dei video più popolari di altri, che magari saranno inviati più spesso sullo stesso collegamento, in questo caso YouTube deve pagare il proprio ISP per tutte le volte che il video transita sul collegamento.
Per superare questi problemi le maggiori società di fruizione di video online usano le CDN (content distribution networks). Le CDN adottano generalmente due politiche:
- Enter deep (di Akamai): consiste nell'installare un gruppo di server (cluster) negli ISP di accesso, sparsi in tutto il mondo.
- Bring home: è quello di costruire grandi cluster in poche decine di punti chiave e interconnetterli con una rete privata ad alta velocità. Queste CDN pongono ogni cluster vicino a PoP (point of presence) di molti ISP di livello 1.
Una volta posizionati i cluster la CDN replica i contenuti su di essi. I video raramente richiesti o quelli richiesti solo in alcuni paesi non vengono replicati su tutti i cluster. Quando ad un cluster viene richiesto un video che non ha, esso le recupera da un cluster centrale o da un altro cluster, mentre lo invia, ne salva una copia (proprio come i server proxy).
Esempio di funzionamento di una CDN:
- L'utente visita NetCinema
- Quando l'utente seleziona il link http://video.netcinema.com/6Y7B23V corrispondente a Transformers 7, il suo host invia una interrogazione DNS a video.netcinema.com
- Il server locale DNS dell'utente invia l'interrogazione DNS a un DNS server autoritativo per NetCinema, che osserva la stringa "video" nel nome dell'host video.netcinema.com. Il DNS server autoritativo per NetCinema per passare l'interrogazione DNS a KingCDN (CDN di NetCinema) restituisce al DNS locale il nome di un host di dominio di KingCDN. invece di un indirizzo IP, diciamo a11728.kingcdn.com.
- Da questo momento l'interrogazione DNS entra nell'infrastruttura DNS privata di KingCDN. Il DNS locale dell'utente effettua un'interrogazione per a11728.kingcdn.com, e infine il sistema DNS di KingCDN restituisce gli indirizzi IP di un server di KingCDN al DNS locale, è qui che viene specificato il server CDN da cui l'utente riceverà il contenuto.
- Il DNS locale inoltra l'IP del nodo CDN che fornirà il contenuto all'host dell'utente.
- Il client ricevuto l'IP stabilisce una connessione TCP diretta a quell'indirizzo IP e gli invia una richiesta GET per il video. Nel caso in cui viene impiegato DASH, il server invierà prima di tutto un file manifest con la lista degli URL con le varie versioni del video.
