Bittorrent este o tehnologie de transfer de date peer-to-peer, una din cele mai cunoscute si mai folosite tehnologii de acest tip. In functie de statisticile consultate si de zona de pe glob cifrele variaza foarte tare dar o cifra des vehiculata pentru traficul BitTorrent de pe Internet este de approx 30%-40% din traficul total, reprezentand totodata jumatate din traficul peer-to-peer de pe Internet. Bineinteles ca pe alocuri exista diferente mari fata de aceste cifre (de exemplu in Coreea de Sud reteaua eDonkey este mult mai cunoscuta si folosita) dar o statistica clara este imposibil de facut. Oricare ar fi cifrele cantitatea de trafic transferata prin protocolul BitTorrent este incredibila si demonstreaza mai bine decat orice faptul ca BT este un protocol matur, extrem de bine pus la punct si scalabil.

Bittorrent a aparut in urma nevoii de descentralizare a resurselor. Inainte de aceasta descentralizare daca cineva dorea sa ofere spre download sa zicem un DVD cu o distributie de Linux si se astepta la un trafic foarte mare, avea nevoie de un server sau de cateva servere Web foarte puternice, care sa poata sustine mii de conexiuni de la utilizatorii care doreau sa downloadeze mii de copii ale imaginii DVD. Bineinteles ca serverul la un moment dat constituia o gatuire majora in flowul de trafic, lucru ce a dus la crearea mirror-urilor pe alte servere. Utilizatorii erau incurajati sa foloseasca pentru download un server mirror (o copie a serverului de baza) aflat cat mai “aproape” (desi e relativ ce inseamna exact “aproape”); asta aducea un overhead administrativ uneori considerabil si nu rezolva in intregime problema.

Solutia implementata prin acest protocol de transfer descentralizat a venit de la Bram Cohen, un programator care a pus bazele standardului BitTorrent si care in continuare prin firma sa BitTorrent Inc. imbunatateste si updateaza constant standardul.

Cum functioneaza

Plecand de la exemplul cu imaginea noastra de DVD oferita spre download in reteaua BitTorrent, fluxul de operatii este in principal acesta:

1. cel ce doreste sa partajeze fisierul genereaza cu ajutorul unui program (majoritatea clientilor BitTorrent de exemplu stiu sa faca acest lucru) un fisier .torrent care contine metainformatii ce descriu fisierul/ele oferite. Fisierul .torrent contine printre altele:

1. o lista de trackere (servere care pastreaza mereu starea peerilor din sistem, informatii legate de cantitatea de date download/upload a fiecaruia, etc)
2. lista de fisiere oferite spre download
3. fiecare fisier este impartit virtual in mai multe fragmente de dimensiune egala (mai putin evident ultimul fragment) si se calculeaza un hash pentru fiecare pentru verificarea downloadului (acelasi hash se calculeaza si la destinatie pe datele downloadate si se compara cu cel din fisierul .torrent); dimensiunea fragmentului este lasata la latitudinea programului care creeaza fisierul .torrent, dar daca este prea mica vor rezulta prea multe fragmente si datorita numaului de hash-uri crescut, unul per fragment, este posibil ca fisierul .torrent sa fie prea mare. In general o medie este de 512Kbytes per fragment.

2. fisierul .torrent este uploadat pe un tracker (element de importanta majora in sistemul BT) in general printr-o interfata web-based. Datele in sine raman pe calculatorul celui ce a generat .torrent-ul, niciodata datele nu se afla pe serverul tracker!

3. Clientul de torrent al celui ce a creat fisierul .torrent pune acum acest torrent in starea “Seeding” asteptand conexiuni de la alti utilizatori. Seed-erii sunt acei utilizatori care au downloadat complet fisierul si il ofera spre download altora. Clientul anunta si trackerul ca ofera fisierul (ca este in starea “Seeding”) urmand ca trackerul sa trimita datele de conectare oricui este interesat de download.

4. Serverele tip tracker au in general o interfata prin care se pot vedea fisierele .torrent disponibile. Daca un utilizator doreste sa downloadeze ceva, isi alege un fisier .torrent, il downloadeaza si il deschide intr-un client BitTorrent (ex: uTorrent, Vuze, Transmission, BitTorrent, etc).

5. clientul BT deschide fisierul .torrent si gaseste aici toate informatiile de care are nevoie pentru a incepe downloadul. Se conecteaza la tracker(ele) pe care il (le) gaseste in fisierul .torrent si cere o lista de surse la care sa se poata conecta sa inceapa downloadul

6. dupa cum spuneam  un tracker nu are in sine continutul de downloadat, datele initial sunt doar la cel ce a creat torrentul si s-a inregistrat apoi la tracker ca Seeder. In momentul in care un server tracker primeste o cerere de peeri de la un client BT care doreste sa downloadeze fisierul, acesta pe baza informatiilor referitoare la cei care sunt conectati genereaza un raspuns in care insereaza IP-urile tuturor celor ce ofera fisierul spre download, fie ca acestia sunt in starea Seeder (au fisierul complet, doar uploadeaza) sau in starea Leecher (au inceput downloadul si pot oferi altora fragmentele deja downloadate dar si ei la randul lor mai au de downloadat informatii).

7. odata ce un client a primit lista de posibili peeri cu toate datele de conectare la ei de la trakcer, el va incepe sa se conecteze la acestia si sa le ceara informatiile spre download, fragment cu fragment. In acest moment clientul este in starea Leecher si cand va termina downloadul va fi in starea Seeder si va continua sa ofere informatiile altor Leecheri care le cer

8. in mod constant clientii BT comunica cu trackerul anuntandu-l evenimentele importante, cerand noi liste de peeri, informandu-l de progresul downloadului, etc. Astfel, constant trackerul are informatii proaspete referitoare la participantii la comunicatie fie ei Seederi sau Leecheri.

Cateva consideratii

1. niciodata continutul nu se afla pe un singur server care sa fie sub tirul celor ce vor sa downloadeze fisierul; serverul tracker nu are decat scopul de a pastra la zi informatiile legate de peeri, progres, starea transferurilor de date, datele NU trec prin el ci sunt transmise pe conexiuni directe TCP sau UDP intre peeri

2. continutul se afla intotdeauna descentralizat pe toate calculatoarele implicate in transferuri legate de acest .torrent; e adevarat ca initial doar cel ce a creat fisierul este singurul detinator al datelor (Seederul initial se mai numeste Uploader) dar dupa ce primul Leecher (A) ia complet un fragment, urmatorul Leecher (B) e posibil sa ceara acel fragment de la A si nu de la Uploader, urmatorul de la A sau de la B si asa mai departe. Se creeaza astfel o plasa de conexiuni intre toti peerii implicati si astfel resursele necesare partajarii fisierului sunt repartizate pe mai multe (uneori mii sau zeci de mii) calculatoare.

3. sistemul ofera o redundanta de invidiat; daca ar exista un singur server cu datele de partajat si acesta ar cadea, nimeni nu ar mai putea downloada nimic; in contrast caderea unui seeder in majoritatea cazurilor nu are nici un efect vizibil, oricand noii doritori au o gramada de alte surse pentru datele respective; bineinteles ca daca vorbim de un torrent pentru care nu exista decat un seeder si acesta cade, ajungem la problema initiala, dar aceasta stare nedorita este valabila doar pana la aparitia a inca unui Seeder in retea.

4. creste consumul de resurse pe calculatoarele implicate in comparatie cu sistemul cu server unic (unde ar fi nevoie de doar o conexiune TCP spre exemplu pentru download); aceste calculatoare pot primi liste cu sute de peeri la care trebuie sa se conecteze pentru a initia downloaduri, conexiuni ce consuma destul de multe resurse

5. sistemul nu permite in acest moment (desi se lucreaza la asta) download progresiv, util pentru streaming; in acest moment un client poate cere fragmentele de la partenerii de transfer in ordine aleatorie sau folosind orice algoritm doreste

6. datorita faptului ca trackerul are informatii legate de cine, cand si ce a downloadat/uploadat, se pot implementa diverse reguli prin care spre exemplu unui utilizator sa i se impuna ramanerea in starea de Seed un anumit timp (sau o anumita cantiate de informatii uploadate) de la terminarea downloadului, sub pedeapsa pierderii accesului la tracker, pentru a descuraja hit-and-run (download urmat de oprirea seedingului).

Dezvoltari ulterioare si optimizari

Desi sistemul BT este unul destul de eficient si scalabil i se pot gasi diverse probleme si se pot identifica comportamente suboptime. Optimizari au venit si de la creatorul original dar si de la diversi creatori de clienti BitTorrent (ex: uTorrent cu protocolul uTP/Micro Transfer Protocol sau Vuze cu implementarea sa DHT-distributed database/trackerless system).

1. DHT – Distributed Hash Tables – sistem prin care un client poate gasi peeri si in absenta tracker-ului specificat in .torrent. Exista implementarea Mainline (propusa de clientul BitTorrent) dar si o implementare necompatibila propusa de Azureus/Vuze inainte de cea Mainline. Ambele se bazeaza pe sistemul Kademlia (folosit si de unii clienti ai retelei peer-to-peer eDonkey sub forma retelei KaD) care permite peerilor sa creeze o retea virtuala in care fiecare este un nod si in care informatia este transmisa intre noduri  fara nevoia unui server central de tracking. Fiecare nod pastreaza o lista cu resursele disponibile pe alte noduri sub forma de hash-uri de fisiere, cautarile fiind facute nod-cu-nod pana la gasirea informatiilor cautate. Sistemul construieste practic un mare graf in care fiecare peer ce implementeaza DHT este un nod si pune la dispozitie algoritmi de cautare a informatiilor necesare in “norul” de noduri.

2. PEX – Peer Exchange – sistem prin care fiecare client BT poate afla de alti peeri de la un peer de-al sau, fara ajutorul serverului de tracking. DHT si PEX sunt dezactivate in torrentele puse la dispozitie de site-uri cu continut inchis, pentru a nu permite utilizatorilor neinregistrati sa downloadeze datele si pentru a obliga tot traficul de control sa se faca prin tracker.

3. Multiple servere tip tracker – in majoritatea fisierelor .torrent actuale se gasesc mai multe trackere pentru situatia in care un anumit server este offline. Se obtine o redundanta mai buna crescand si protectia la cazurile in care un tracker devine nefunctional

4. Criptarea – sistemul de securitate din protocolul BitTorrent a trecut prin multe in ultimii ani, dezvoltandu-se treptat componenta cu componenta. Securitatea implementata isi propune in principal sa ofere protectie la identificarea usoara a datelor transferate prin acest protocol, lucru cu atat mai important cu cat unii ISP din US cum ar fi Comcast au recurs la bandwidth throttling (limitarea bandwidth-ului) in cazul traficului BT mai ales prin trimiterea de pachete TCP RST partenerilor de conexiune fortand astfel inchiderea masiva a conexiunilor create si ducand bineinteles la o scadere majora a vitezei de download. Acestia au folosit o serie de echipamente Sandvine special create pentru analiza nivel 7 a pachetelor si identificarea traficului BT. In acest moment criptarea intre peeri este implementata de aproape toti clientii BT desi nu este o setare default tip “require” ci una tip “accept” (un client va accepta sau va cere o sesiune criptata, dar daca partea opusa nu o doreste se va recurge la o conexiune necriptata). Criptarea aduce bineinteles un consum sporit de resurse pe clientii care o folosesc dar face mai dificila detectarea/limitarea traficului BT. Chiar si folosind criptarea insa protocolul BT poate fi supus analizei de pattern de trafic si pot fi detectate modele care sa duca la identificarea traficului BT chiar si criptat, dar este bineinteles nevoie de echipamente foarte scumpe pentru aceasta operatie. Este de retinut si ca securitatea BitTorrent NU asigura intimitatea datelor 100%, chiar si implementata la toate nivelele (peer-to-tracker, peer-to-peer).

5. Localizarea – in ultimul timp datorita cresterii traficului BT in Internet din ce in ce mai multi ISP incearca sa optimizeze flow-urile de trafic. O metoda interesanta se bazeaza pe localizarea traficului. Astfel, daca un ISP isi doreste ca traficul sa ramana in principal in interiorul retelei sale, poate recurge la o serie de echipamente speciale care monitorizeaza traficul client-tracker (peer-tracker) si pot interveni in raspunsurile trackerului catre client. Cum? Simplu: un client va primi de la tracker la conectare o lista de peers de la care poate incepe sa ceara si sa downloadeze fragmente de date. In mod normal acesti peers sunt alesi de tracker sau trimisi in intregime clientului si pot fi localizati oriunde in lume, ducand la o patternuri de trafic ce pot dezavantaja un ISP. Metoda presupune crearea de catre ISP-ul in cauza a unor liste de clase “interne” si folosirea acestor echipamente care se vor interpune ca un proxy transparent in comunicarea client-tracker dar la primirea listei de peeri de la tracker catre client, echipamentele vor filtra din lista peeri aflati in afara retelei si vor trimite doar peeri din reteaua providerului nostru; obtinem astfel o buna localizare a traficului, costuri mai mici pentru upstream provideri si/sau peeringuri si viteza imbunatatita de download/upload pentru clientii ISP-ului. Bineinteles, folosirea criptarii de catre clienti face inutil intregul sistem care in acest caz nu mai poate optimiza nimic.

6. uTP – Micro Transfer Protocol – protocol de transport bazat pe UTP propus de uTorrent. Protocolul isi propune sa rezolve cateva din problemele actuale ale conexiunilor TCP imbunatatind algoritmul acestuia de control al congestiei si emuland facilitatile de fiabilitate ale TCP-ului in contextul patternului de trafic BT. Un important plus este faptul ca folosind UTP traficul este mult mai greu de limitat: o conexiune TCP va fi inchisa daca se va primi un pachet RST cum descriam sistemul la punctul 4, pe cand o conversatie UDP nu implica aceste pachete de sfarsit de conexiune si prin urmare nu exista o metoda simpla pentru un ISP sau o alta terta parte sa inchida conexiuni sau sa limiteze traficul. As putea adauga si ca o metoda de a folosi UDP in loc de TCP pentru traficul BT este aceea de a folosi tunelele over UDP Microsoft Teredo initial create pentru a tunela IPv6 printr-un nor de IPv4 folosind UDP.