La rivoluzione BitTorrent
INTRODUZIONE
Prima dell’avvento della tecnologia BitTorrent la rete internet si basava principalmente su due protocolli per i download, FTP e HTTP. Entrambi questi protocolli già pesantemente collaudati avevano un grosso problema. I server erano si facilmente raggiungibili da tutto il mondo e l’upload era unicamente centralizzato ad un unico server, ma proprio qui si vede la fragilità del sistema. Infatti se il traffico diretto al server non è ingente la connessione è fluida, ma quando le richieste di download diventano sempre più alte allora vi è una caduta di prestazioni e un sovraccarico della banda (sintomo: una velocità di download molto bassa).
BRAM COHEN
È partendo da questa questione che Bram Cohen a partire dal 2001 ha cominciato a progettare e a realizzare il protocollo BitTorrent (BT), un sistema di download dei file in maniera cooperativa.
L’idea si basa su una semplice considerazione, durante il download dei file attraverso un protocollo FTP o HTTP si lascia inutilizzata la banda dell’ upload. Questo è davvero uno spreco, perché la maggior parte degli utenti non paga il proprio traffico a consumo e dunque potrebbe utilizzare la propria banda in uscita senza costi aggiuntivi.
Qui si basa BitTorrent, esso risolve il problema in una soluzione centralizzata, distribuendo il download tra i client (utenti), che permettono la diffusione del file ad altri utenti attraverso la loro banda di uscita (upload). In ciò il server centrale avrà il solo compito di coordinare lo scambio dei file e non dare l’upload diretto (ma solo all’inizio), in questo modo si riduce in maniera drastica il suo consumo di banda.
Cohen è riuscito nel suo intento di plasmare un sistema il più compatibile con il web. Infatti il BitTorrent si basa su specifici file (*.torrent) che si possono trovare su internet o con altre fonti di comunicazione. Questo protocollo ha da prima attirato l’attenzione dei produttori del software libero (open source) per la distribuzione di programmi di grandi dimensioni (CD, DVD).
Il FUNZIONAMENTO DEL BitTorrent
Ora vediamo come funziona il protocollo BitTorrent che ruolo svolgono le varie parti.
Il tutto si basa su un file *.torrent che viene solitamente distribuito da parte del tracker nel suo server web, poi serve almeno un client che disponga del file completo che viene solitamente chiamato seeder o sorgente, serve anche, ovviamente, un mezzo per accedere al file *.torrent e, per finire, altri utenti che vogliono scaricare il file attraverso BitTorrent, i leechers.
Di norma tramite il link delle normali pagine web HTML si può scaricare un file *.torrent, una volta scaricato lo si fa partire con un client BT e così iniziare il download. In questa situazione sino a che si è connessi e il client BT in esecuzione, si rende possibile la diffusione delle proprie parti ad altri peer. Quando il download è terminato l’utente non si troverà più in uno stato di leecher ma di seeder così da poter contribuire alla diffusione del file (questo passaggio è svantaggioso perché tende ad occupare banda preziosa in caso di traffico intenso e per questo ci si trova spesso con file *.torrent incompleti, mi raccomando, se ne avete la possibilità scollegate il file solo se non avete nessuno a carico!).
Schema di funzionamento di BitTorrent. Quando si ottiene il file *.torrent i leecher contattano il Tracker per ottenere una lista degli altri Leecher e di Seeder; poi si procede al download dal Seeder o dagli altri Leecher che dispongono dei pezzi dei file richiesti.
Il FILE *.torrent
Cominciamo ad addentrarci nel tecnico; ora parliamo delle funzioni del file *.torrent.
Per cominciare bisogna mettere in chiaro che il file *.torrent è un file statico, ovvero, non cambia nel corso del download e a seconda della rete peer. Il file *.torrent fornisce al client quattro informazioni indispensabili:
- l’indirizo del tracker
- la data della creazione del torrent
- il nome del file da scaricare
- il numero di chunk in cui è suddiviso il file (in gergo pezzi del file), la loro lunghezza e la loro relativa hash SHA1
E’ ovvio notare che nella lista non sono presenti informazioni riguardanti peer, client e dei chunk dei file scaricati.
Partiamo dai chunk, a che cavolo serve dividere il file in tante parti? Ebbene la risposta non è per velocizzare il download (o ne è una conseguenza minore) ma quello di controllo dell’ errore applicativo che si aggiunge al controllo TCP/IP e al controllo HAS1 (la questione dell’HAS1 la riprenderò in seguito); in pratica in questo modo è possibile scaricare un solo chunk corrotto durante la fase di download e non il file intero (qui si parla di file molto grandi), inoltre questo metodo permette a una più agevole distribuzione del file che viene, appunto, suddiviso in tanti pezzettini uguali, a eccezione dell’ultimo che può essere inferiore, di 256 KB (a partire solo dalla versione 3.2 di BitTorrent).
I chunk a loro volta vengono crittografati dall’ algoritmo SHA1, il numero dei chunk, come già detto, è inserito nel file *.torrent, il controllo SHA1 consiste nel confrontare l’ hash dei vari chunk dei leechers, se la hash dei chunk corrisponde allora è possibile effettuare il download del pezzo, inoltre controlla anche che il file scaricato corrisponda a quello riportato dal *.torrent ( a proposito dell’ SHA1, di recente ne è stato trovato un bug, nulla di cui preoccuparsi, ma da riferir che è in progetto una hash SHA2 per il futuro, casomai ne parlerò in un altro articolo). Tutto questo meccanismo di per sé è un grande passo in avanti rispetto ai tradizionali HTTP e FTP, infatti quest’ ultimi non permettono un controllo del download a meno che non si vada a confrontare l’hash MD5 del file con quello del sito (caso che si riscontra di rado e solo in siti per programmi open source). Tuttavia è bene avere una prolifica coda di richieste, per questa esigenza si è deciso di suddividere i chunk in sotto-chink rispettivamente da 16 KB così parallelizzare il trasferimento in upload tra i peer.
Il COMPITO DEI TRACKER
Come già anticipato, nella rete BitTorrent vi è una figura chiamata Tracker. Questa utenza (ripeto come detto prima) ha il compito di far si che i vari peer della rete BT si “trovino” così da permettere un regolare download con BT; in pratica gestisce i la rete peer. La figurare del tracker è un vero passo in avanti in quanto è la vera novità di questa tecnologia che la distingue da quelle “vecchie” di http o FTP. Il ruolo del tracker è, infatti, solo quello di raccogliere e gestire le informazioni di ogni peer che lo contatta (questo avviene con il lancio del file *.torrent). Le informazioni che forniamo sono il nome del file scaricato (poiché un tracker può fornire anche più torrent), l’indirizzo IP e la porta sulla quale ogni peer è in ascolto. Oltre alle informazioni che utilizzerà per statistiche (mai viste nei siti?) il tracker non farà nient’altro.
L’unico compito al quale deve adempiere è l’invio al peer di una lista di peers che hanno il file richiesto, questa lista non offre ne la lista dei file condivisi ne ha il compito di coordinare lo scambio tra i vari client (come invece avviene nei sistemi di sharing classici). Questo punto rispecchia e affronta la richiesta di partenza, ovvero, quello di far gravare il meno possibile la banda e il carico del server, facendo un rapporto con la modalità di download HTTP la banda usata risulta essere 1/1000 (un bel vantaggio, no?). Ma è proprio il tracker ad essere il vero tallone d’ achille del sistema BT, infatti, se esso non è raggiungibile i peer non potrebbero avere la lista degli altri peers e dunque non riuscire ad allacciarsi alla rete, tuttavia se invece questa situazione si verificasse durante il download, i peer interessati non ne subirebbero il peso poiché sono già collegati ad una rete peer. Questo sistema offre tutto sommato un vantaggio poiché nel caso HTTP se venisse a mancare il tracker di origine salterebbe tutta la rete di download allegata ad esso.
IL PROTOCOLLO (visione della rete BitTorrent estesa)
Vediamo ora cosa succede quando si dà il via a un download con BitTorrent.
Chi rende disponibile il file (un seeder) dovrà:
- creare un file *.torrent
- eseguire un tracker, oppure trovare un server che gestisca i suoi torrent
- condividere il file *.torrent creato, generalmente questo avviene attraverso siti web
- avviare un programma di gestione torrent e diventare seeder
I client che scaricheranno il torrent e che cominceranno il download entreranno a far parte di una rete peer to peer (p2p). Il primo utente che entrerà nella rete p2p di questo tracker sarà, ovviamente, il solo a farlo e per cui riceverà indisturbato i vari chunk fino a quando non entreranno in gioco gli altri utenti.
Ipotizziamo ora che un altro utente entri nella rete p2p di questo file; ci sarà un solo seeder e due leecher di cui uno è in possesso di qualche chunk, l’ultimo ad essersi connesso alla rete invece non ha nulla. Questo allora potrà richiedere le parti del file a entrambi i client facendo sì che il tutto non gravi in un unico client. Continuando con questa ottica si arriverà ad avere una rete con decine di peer dei quali ci saranno dei leecher ma anche, nel frattempo, si avranno dei seeder che contribuiranno alla distribuzione dei file. Ora considerandoci un nuovo client che comincia il download di un *.torrent in una rete già molto affollata (inutile dire che più client ci sono nella stessa rete e più facile è effettuare un download veloce); prima di tutto il *.torrent contatterà il tracker che gli fornirà un’ultima lista di peer presenti nella rete. Ogni peer riserva un numero di connessioni (di solito quattro) per effettuare l’upload verso altri peer, ognuna di queste connessioni sarà chiamata slot. La disponibilità di più chunk da scaricare e di più peer da servire pone il problema di stabilire delle priorità per decidere quale porzione di file chiedere (generalmente questo avviene in una rete con pochi, sulla trentina, peer)o di assecondare una richiesta di upload: per questo i BitTorrent si stabiliscono delle regole chiare alle quali i peer devono adeguarsi. Contrariamente a quanto si può pensare, anche la scelta del file da scaricare è importante e può influenzare in maniera critica il download da parte dei client. Ipotizziamo che tutti i peer cominciano a scaricare con la stessa velocità lo stesso numero di chunk di un file da un solo seeder (è quasi un paradosso). In questo caso ci ritroviamo un solo seeder che condivide il file e di cui ne diventa l’unica fonte, proprio come in un protocollo HTTP, ma con l’aggravante che il seeder ha un numero di slot limitato e dunque non può servire tutti i client ma solo una minima parte di essa (in genere quattro). Questo fatto si traduce con l’attesa da parte degli altri client durante la prima fase del download, poiché, in BT chi scarica non può anche contemporaneamente condividere il file agli altri client, come avviene invece nel protocollo HTTP. Diventa chiaro che bisogna evitare questa situazione procedendo a una distribuzione omogenea del download.
Il compito dell’ algoritmo, che come detto prima è l’ SHA1, è molto importante, comunque questo deve essere in grado di adattarsi anche a un brusco cambiamento di gestione dei chunk (a causa di utenti che si disconnettono, etc….). Il tutto si risolve con due semplici regole. Come prima cosa è importante cercare di completare il download dei file incompleti, scaricando eventuali sotto-chunk mancanti, che verranno richiesti con la massima priorità; nella richiesta di rutine dovranno essere richiesti i chunk più rari in possesso di un solo client, o di una fascia ristretta, così in caso di disconnessione da parte del client il download del file non venga irrimediabilmente corrotto. Si fa eccezione a questa “regola” solo con il primo chunk scaricato; infatti, il primo chunk da scaricare non sarà (di solito) una chunk raro (che avrà anche una bassa velocità di upload) ma uno qualunque. Il perché a questa motivazione è semplice: chi comincia il download non ha pezzi da offrire agli altri client dunque si vede il bisogno di avere un chunk completo da “offrire” agli altri client; statisticamente parlando, chi possiede un chunk completo, (in questo caso l’unico) diventa una fonte per altri peer con una velocità di upload alta e dunque di rapida diffusione anche se questo non è un pezzo raro. Le risorse vengono gestite dai vari peer che devono far in modo di scaricare il più possibile da più fonti possibili. Ogni utente ha anche il compito di scegliere se assecondare (unchoke) o di respingere (choke) una richiesta di upload, in realtà un peer non può in effettivamente negare l’upload a un peer ma solo ritardarlo. La decisione di ciò avviene in base al criterio “occhio per occhio”. Queste decisioni avvengono in base a due criteri: il primo è quello di cercare di “ricambiare il favore”, ovvero, privilegiare le richieste di upload da parte degli utenti da cui si sta scaricando così da avere una serie di connessioni da entrambe le direzioni. Questo approccio ha un altro vantaggio: esclude gli utenti che non condividono il proprio download penalizzando la rete e altri peer ad effettuarlo. Il secondo vede l’algoritmo privilegiare i client che scaricano a una velocità maggiore: generalmente gli slot riservati all’upload sono ben inferiori al numero di peer dai quali si sta scaricando (di solito sono abilitati 20 slot in download e 4 in upload). Questo costringe ogni client a fare una selezione tra i peer che gli mettono a disposizione dei pezzi e che vorrebbe ricambiare il “favore”; il criterio di scelta si baserà, quindi, quello di premiare coloro che scaricano a una velocità maggiore.
Fermandosi a queste due regole si otterrebbe in breve tempo un punto di stallo che potrebbe essere quello non ottimale (un download incompleto, per intenderci), di preciso, i nodi non riuscirebbero a sfruttare a pieno la banda e a non scoprire altri peer in grado di offrire una velocità maggiore.
Per questo motivo è prevista una eccezione alla regola, per cui ogni peer, nell’arco di 30 secondi, abiliterà il download da un peer con cui non aveva ancora scambiato dati verificando se quel nodo ha una maggior velocità di upload indipendentemente da quella che è in grado di ricambiare.
Una volta deciso cosa scaricare e a chi chiederlo, il trasferimento avrà luogo attraverso il protocollo TCP utilizzando per default le porte 6881 alla 6889. Bisogna anche precisare che BitTorrent supporta anche i client dietro NAT che però non potranno effettuare connessioni tra essi.
April 01 2005 | Internet and Recensioni | No Comments »
