Bittorrente

BitTorrent ( lett. inglese) Bitstream è un protocollo di rete peer-to- peer (P2P) per la condivisione di file cooperativa su Internet .

I file vengono trasferiti in parti, ogni client torrent , ricevendo (scaricando) queste parti, allo stesso tempo le fornisce (scarica) ad altri client, il che riduce il carico e la dipendenza da ciascun client di origine e fornisce la ridondanza dei dati .

Il protocollo è stato creato da Bram Cohen , che ha scritto il primo client torrent BitTorrent in Python , il 4 aprile 2001 . Il lancio della prima versione è avvenuto il 2 luglio 2001 .

Esistono molti programmi client per lo scambio di file utilizzando il protocollo BitTorrent.

File di metadati

Articolo principale: .torrent

Il file di metadati è un dizionario in formato bencode con estensione .torrent - contiene informazioni sulla distribuzione (file, tracker , ecc.)

Come funziona il protocollo

Come funziona BitTorrent: il carico sul distributore di file è ridotto in quanto i client iniziano a scambiare dati immediatamente, anche se il file non viene scaricato fino in fondo.

Prima del download, il client si connette al tracker all'indirizzo specificato nel file torrent, gli comunica il suo indirizzo e la somma hash del file torrent, a cui il client riceve in risposta gli indirizzi di altri client che scaricano o distribuiscono lo stesso file. Inoltre, il cliente informa periodicamente il tracker sullo stato di avanzamento del processo e riceve un elenco aggiornato di indirizzi. Questo processo è chiamato annuncio . 

I clienti si connettono tra loro e si scambiano segmenti di file senza la partecipazione diretta del tracker, che memorizza solo le informazioni ricevute dai clienti collegati allo scambio, un elenco dei clienti stessi e altre informazioni statistiche. Affinché la rete BitTorrent funzioni in modo efficace, è necessario che il maggior numero possibile di client sia in grado di accettare le connessioni in entrata. Impostazioni errate del NAT o del firewall possono impedirlo.

Quando si connettono, i client si scambiano immediatamente informazioni sui segmenti che hanno. Un cliente che desidera scaricare un segmento ( leecher ) invia una richiesta e, se il secondo cliente è pronto a fornire, riceve questo segmento. Il client verifica quindi il checksum del segmento. Se corrisponde a quello registrato nel file torrent, il segmento viene considerato scaricato correttamente e il client notifica a tutti i peer collegati che ha questo segmento. Se i checksum differiscono, il segmento ricomincia a essere scaricato. Alcuni client escludono quei peer che forniscono segmenti errati troppo spesso.

Pertanto, la quantità di informazioni sul servizio (la dimensione del file torrent e la dimensione dei messaggi con un elenco di segmenti) dipende direttamente dal numero e quindi dalla dimensione dei segmenti. Pertanto, nella scelta di un segmento, è necessario mantenere un equilibrio: da un lato, con un segmento di grandi dimensioni, la quantità di informazioni di servizio sarà inferiore, ma in caso di errore di verifica del checksum, sarà necessario disporre di maggiori informazioni essere scaricato di nuovo. D'altra parte, con una piccola dimensione, gli errori non sono così critici, poiché un volume più piccolo deve essere scaricato nuovamente, ma la dimensione del file torrent e dei messaggi sui segmenti esistenti aumenta.

Algoritmo di scambio dati

Ogni cliente ha la possibilità di bloccare temporaneamente il ritorno ad un altro cliente ( eng.  choke ). Questo viene fatto per un uso più efficiente del canale di ritorno. Inoltre, quando si sceglie chi sbloccare, viene data preferenza ai peer che hanno trasferito loro stessi molti segmenti a questo client. Pertanto, le feste con buoni tassi di rendimento si incoraggiano a vicenda secondo il principio "tu - a me, io - a te".

Lo scambio di segmenti viene effettuato secondo il principio "tu - a me, io - a te" simmetricamente in due direzioni. I client si scambiano informazioni sugli shard che hanno quando si connettono e poi quando ricevono nuovi shard, in modo che ogni client possa archiviare informazioni sugli shard che hanno altri peer connessi. L'ordine di scambio è scelto in modo tale che i client scambino per primi i segmenti più rari: ciò aumenta la disponibilità dei file nella distribuzione. Allo stesso tempo, la scelta di un segmento tra i più rari è casuale, e quindi è possibile evitare la situazione in cui tutti i client iniziano a scaricare lo stesso segmento raro, il che avrebbe un impatto negativo sulla performance.

Lo scambio di dati inizia quando entrambe le parti sono interessate, ovvero ciascuna delle parti ha segmenti che l'altra non ha. Viene contato il numero di segmenti trasmessi, e se una delle parti scopre che sta trasmettendo in media più di quanto riceve, blocca ( eng.  choke ) per un po' il ritorno dall'altra parte. Pertanto, la protezione contro le sanguisughe è incorporata nel protocollo .

I segmenti sono divisi in blocchi con una dimensione di 16-4096 kilobyte e ogni client richiede esattamente questi blocchi. È possibile richiedere contemporaneamente blocchi di segmenti diversi. Inoltre, alcuni client supportano il download di blocchi dello stesso segmento da peer diversi. In questo caso, gli algoritmi ei meccanismi di scambio sopra descritti sono applicabili anche al livello di blocco.

Termina la modalità di gioco

Quando il download è quasi completo, il client entra in una modalità speciale chiamata end game. In questa modalità, richiede tutti i segmenti rimanenti a tutti i peer connessi, il che evita un rallentamento o un "blocco" completo di un download quasi completato a causa di diversi client lenti.

La specifica del protocollo non definisce esattamente quando il client deve entrare nel gioco finale, ma esiste una serie di pratiche generalmente accettate. Alcuni client entrano in questa modalità quando non sono rimasti blocchi non richiesti, altri fino a quando il numero di blocchi rimanenti è inferiore al numero di quelli trasmessi e non superiore a 20. C'è un'opinione tacita secondo cui è meglio mantenere il numero di blocchi in sospeso basso (1 o 2) per ridurre al minimo la ridondanza e che quando la richiesta casuale ha meno possibilità di ottenere duplicati dello stesso blocco .

Semina

Quando viene ricevuto un file completo, il client passa a una modalità operativa speciale in cui invia solo dati (diventa un seme). Inoltre, il seed informa periodicamente il tracker sui cambiamenti nello stato dei torrent (download) e aggiorna gli elenchi di indirizzi IP.

Caratteristiche generali

• Nessuna coda di download.
• I file vengono caricati in piccoli frammenti ; meno è disponibile il frammento, più spesso sarà trasmesso. Pertanto, la presenza di un " seeder " con un file completo per il download non è necessaria sulla rete: il sistema distribuisce i segmenti tra i " peer " in modo che possano successivamente scambiare i segmenti mancanti.
• I clienti (coetanei) si scambiano segmenti direttamente tra loro, secondo il principio "tu - a me, io - a te".
• I frammenti scaricati sono immediatamente disponibili per altri client.
• L' integrità di ogni frammento è controllata .
• Non sono i singoli file a essere frammentati, ma l'intera distribuzione, quindi un " leecher ", che vuole scaricare solo alcuni file dalla distribuzione, spesso memorizzerà anche una piccola quantità di informazioni ridondanti (per lui) da mantenere l'integrità dei frammenti.
• Diversi file possono fungere da oggetto di distribuzione (ad esempio, il contenuto della directory ).

Protocolli e porte

I client si connettono al tracker utilizzando il protocollo TCP . Porta in entrata del tracker più comunemente utilizzata: 6969. Intervallo di porte in entrata del client più comunemente utilizzato: 6881-6889.

I numeri di porta non sono fissi nelle specifiche del protocollo e possono essere modificati secondo necessità. Attualmente, la maggior parte dei tracker utilizza la porta HTTP 80 e si consiglia ai client di scegliere una porta in ingresso casuale. Inoltre, alcuni tracker non consentono l'uso di porte client dall'intervallo standard 6881-6889, poiché alcuni provider vietano l'uso di questo intervallo di porte.

La rete DHT nei client BitTorrent utilizza il protocollo UDP .

Inoltre, il protocollo UDP viene utilizzato dai tracker UDP (non supportato da tutti i client e non è una parte ufficiale del protocollo) e per connettere i client tra loro tramite UDP NAT Traversal (utilizzato solo nel client BitComet ed è non è una parte ufficiale del protocollo).

Localizzatore

Articolo principale: tracker BitTorrent

Tracker ( in inglese  tracker ; /ˈtɹækə(ɹ)/ ) è un server specializzato che esegue il protocollo HTTP . Il tracker è necessario affinché i clienti possano trovarsi. In effetti, il tracker memorizza indirizzi IP , porte client in ingresso e somme hash che identificano in modo univoco gli oggetti coinvolti nei download. Secondo lo standard, i nomi dei file non vengono memorizzati sul tracker ed è impossibile riconoscerli tramite hash sum. Tuttavia, in pratica, il tracker spesso, oltre alla sua funzione principale, svolge anche la funzione di un piccolo web server . Tale server memorizza i file di metadati e le descrizioni dei file distribuiti, fornisce statistiche di download per diversi file, mostra il numero corrente di peer collegati, ecc.

Lavora senza tracker

Nuove versioni del protocollo hanno sviluppato sistemi trackerless  che risolvono alcuni dei problemi precedenti. Il guasto di un tracker in tali sistemi non porta automaticamente al guasto dell'intera rete.

A partire dalla versione 4.2.0 del client ufficiale, rilasciata a fine 2015, è stata implementata una funzione di lavoro trackerless basata su DHT Kademlia . In tale implementazione, il tracker è disponibile decentralizzato sui client sotto forma di una tabella hash distribuita .

Al momento, non tutti i client utilizzano un protocollo compatibile tra loro. BitComet , µTorrent , Deluge , KTorrent , Transmission , qBittorrent e il client BitTorrent ufficiale sono compatibili tra loro . Vuze (Azureus) ha anche una modalità trackerless, ma la sua implementazione differisce da quella ufficiale, per cui non può funzionare tramite DHT con i client di cui sopra . Tuttavia, è disponibile il supporto per DHT standard per Vuze tramite il plug-in Mainline DHT.

È possibile lavorare senza tracker anche quando si utilizzano client multiprotocollo che supportano BitTorrent. Shareaza scambia hash e indirizzi peer di altre reti supportate, incluso BitTorrent, tramite la rete Gnutella2 . Il supporto di BitTorrent è previsto in GreyLink 6.0, mentre la rete Direct Connect può essere utilizzata non solo per convertire in TTH , ma anche per trovare peer.

Lavorare senza un client torrent

Per prendere e distribuire file nelle reti torrent, non è necessario utilizzare programmi speciali. Esistono diversi servizi che consentono di scaricare file utilizzando solo un browser .

La presenza di informazioni aggiuntive nei file di metadati, come fonti aggiuntive e hash opzionali, consente l'utilizzo di un file di metadati .torrent in modo simile ai formati Metalink , MAGMA , File List (Direct Connect) . Il client Shareaza utilizza hash opzionali per cercare fonti alternative su altre reti.

Semi del Web

Un caso d'uso è il cosiddetto web seeding. A volte, per vari motivi, non è possibile avviare un client torrent completo sul server. In questo caso, un server che opera sul protocollo HTTP funge da origine di distribuzione. Di norma, i client preferiscono altri client BitTorrent e accedono al seed web solo quando necessario. Tieni presente che questo caso d'uso è implementato in almeno tre modi: BEP0017 Webseed in stile BitTornado , BEP0019 Webseed in stile GetRight e Sourcing esterno , ognuno dei quali differisce nei dettagli di implementazione.

È stato creato per la prima volta da John "TheSHAD0W" Hoffman, che ha creato BitTornado . Poiché la versione 5.0 del client BitTorrent supporta web seed e download da siti web, è stato creato un semplice strumento che crea pubblicazioni web seed torrent. μTorrent ha aggiunto il supporto per ottenere semi web nella versione 1.7. BitComet ha aggiunto il supporto per ottenere semi web nella versione 1.14.

BTIH (hash delle informazioni BitTorrent)

Questo è l' hash SHA-1 del campo Info dal file di metadati . Questo hash viene utilizzato nei collegamenti magnetici , nonché per l'identificazione sul tracker e tra i client. Quando si carica un file di metadati su un tracker , il relativo hash delle informazioni potrebbe cambiare, poiché il tracker potrebbe modificare il campo delle informazioni impostando il flag di distribuzione privata o modificando/aggiungendo campi all'interno delle informazioni. Pertanto, è necessario scaricare nuovamente il file di metadati (file .torrent) dal tracker e aggiungerlo al client .

Collegamento BTC

Specificato come:

btc://[Адрес]: [Порт]/[Peer ID]/[ BTIH ]

Un collegamento di questo tipo si riferisce alla distribuzione e alla sua fonte. Supportato in Shareaza .

Svantaggi e limitazioni

Indisponibilità di distribuzione

Se la distribuzione è impopolare, potrebbe verificarsi una situazione in cui non c'è un solo seme e i peer presenti non hanno dati sufficienti per completare il download. In questo caso, è necessario attendere la comparsa di un seed o di un peer che ha segmenti mancanti rispetto agli altri. Puoi anche utilizzare copie di file ottenuti in un altro modo. Una mano che non ha seme per molto tempo si chiama "morta".

Per incoraggiare gli omaggi, è stato persino creato un token BitTorrent .

Mancanza di anonimato e personalizzazione

Il principio del protocollo BitTorrent implica che ogni client conosca gli indirizzi IP di almeno altri client ricevuti dal server. L'uso di varie estensioni di protocollo in alcuni casi consente anche di scoprire gli indirizzi di altri peer dello sciame. Ecco perchè:

• Gli utenti di sistemi non protetti e client con vulnerabilità note possono essere attaccati.
• È possibile conoscere gli indirizzi degli utenti che inviano o ricevono un determinato file.

Il problema dell'anonimato può essere risolto usando Tor . Il client Vuze BitTorrent ha un supporto software integrato per questa rete anonima . Ma questo metodo non è efficace al 100% .

Il protocollo, invece, non prevede l'uso di nickname. Nessuna chat tra pari. Impossibile elencare i file peer (cercando altri file che potrebbero essere di interesse). La maggior parte di queste funzionalità è implementata in altri protocolli (come Direct Connect ).

Il problema delle sanguisughe

Alcuni utenti, in particolare sui tracker che non richiedono la registrazione, non supportano la distribuzione dopo il completamento del download, il che porta a una diminuzione delle prestazioni complessive, quindi alcuni tracker torrent tengono conto anche della quantità di scaricati / dati via e danno il permesso da scaricare a seconda della dimensione dei dati forniti dal cliente.

Mancanza di una contabilità del traffico accurata

A differenza di molti protocolli di distribuzione dei contenuti multimediali commerciali, l'architettura del protocollo non fornisce un meccanismo accurato per la contabilizzazione e il controllo del traffico tra i punti di rete. Tutto quello che c'è sono i campi scaricati e caricati, in cui i client passano il numero di byte presi in considerazione durante il download / caricamento dei dati dall'annuncio precedente quando si annunciano al tracker. Tuttavia, non controllati da nessuno diverso dal client, possono essere facilmente falsificati. Per fare ciò, gli utenti assegnano staticamente i valori di questi campi all'URI del tracker , utilizzano patch per client o programmi separati (RatioMaster, GiveMeTorrent, GreedyTorrent, ecc.), o semplicemente eliminano il record del tracker dal client subito dopo aver ricevuto un elenco di punti di rete dal tracker. Tutto ciò consente di aggirare le restrizioni artificiali create dall'amministrazione di molti tracker privati ​​e pubblici.

Terminologia

• Annuncio ( eng.  annuncio ) — la richiesta del client al tracker tramite una richiesta HTTP-GET . Con ogni annuncio, il client invia al tracker informazioni sui volumi scaricati e dati e il tracker invia al client un elenco di indirizzi di altri client. Il client accede al tracker a determinati intervalli di tempo, che sono determinati dalle impostazioni del client e del tracker.
• Seme Web  : server HTTP o FTP utilizzato come origine dati, insieme a semi regolari
• Disponibilità ( ing.  disponibilità , eng.  copie distribuite  - copie comuni) - il numero di copie complete del file a disposizione del cliente. Ogni seme aggiunge 1,0 a questo numero; le sanguisughe aumentano la disponibilità in base alla quantità di download che le altre sanguisughe non hanno. Ad esempio, se nella distribuzione sono presenti un seed e due leecher che hanno scaricato il 50% del file ciascuno (le parti scaricate sono uguali), la disponibilità è 1,50.
• Soffocato ( ing.  soffocato  - in stallo, strangolato) - un client il cui scambio di dati si è bloccato. O il suo canale di uscita è completamente pieno e non può trasmettere nulla (raggiunto max_uploads), oppure è un seme e non ha bisogno di ricevere nulla.
• Interessato ( Interessato in inglese  ) - un partecipante che desidera ricevere parti di un file che ha un altro partecipante. Ad esempio, se il cliente A non ha alcune parti che il cliente B ha, allora il cliente A è considerato interessato a fare trading con il cliente B.
• Surplus  : dati inviati da un peer o seed, ma il destinatario non ne ha bisogno. Le eccedenze includono anche errori di hash.
• Un  indice è un elenco di file .torrent (in genere include descrizioni e altre informazioni) che è gestito da un sito Web (un indicizzatore ) ed è ricercabile. Un sito di indicizzazione viene spesso erroneamente chiamato tracker.

Leecher e il suo sciame.

• Lich , a volte leecher ( eng.  leech  - leech) - una festa che non ha ancora tutti i segmenti, cioè continua a scaricare. Il termine è spesso usato nel senso negativo che ha in altre reti di file sharing: un utente che regala molto meno di quanto scarica.
• L' avvelenamento da file torrent  è una situazione in cui alcuni peer distribuiscono segmenti danneggiati o appositamente falsificati.
• Peer ( eng.  peer  - complice) - un client che partecipa alla distribuzione in qualsiasi rete di condivisione di file.
• Trascurare ( ing.  snobbato ) - un cliente si è connesso al destinatario, ma non gli ha inviato dati per più di 60 secondi.
• Distribuzione ( seeding inglese  ) - il processo di distribuzione di un file utilizzando il protocollo BitTorrent.
• Valutazione ( rapporto di condivisione inglese  ) - il rapporto tra dato e scaricato.
• Swarm ( eng.  swarm ) - un insieme di tutti i pari che partecipano alla distribuzione.
• Segmento ( parte inglese   - parte) - tutti i file da trasferire sono divisi in piccoli pezzi - segmenti, che vengono poi trasmessi in rete in ordine casuale per ottimizzare lo scambio.
• Sid , a volte seeder ( inglese  seeder  - sower) - un peer che ha tutti i segmenti del file distribuito, ovvero il distributore iniziale del file o ha già scaricato l'intero file ed è rimasto nella distribuzione.
• Scrape -request ( eng. scrape  - scrape, scratch) - un protocollo aggiuntivo per richiedere un client a un tracker , in cui il tracker comunica al cliente il numero totale di semi e peer sulla distribuzione. A differenza dell'annuncio, la richiesta di scraping non è direttamente correlata al download della distribuzione, è facoltativa e richiede meno risorse dal client e dal tracker. Può anche essere richiesto per attività interrotte nel client e consente anche di ottenere informazioni su più torrent contemporaneamente (multi-scrape) con un'unica richiesta. Il cliente, utilizzando una richiesta di scraping, può ottenere il numero esatto di seed e peer su ciascun lavoro, compresi quelli interrotti. Alcuni client, come Azureus , possono anche utilizzare una richiesta di scraping per scoprire in anticipo che altri partecipanti sono apparsi nella distribuzione, fare un annuncio fuori servizio per ricevere i loro indirizzi e interrompere e avviare automaticamente il seeding dei lavori a seconda del numero di semi e coetanei, di conseguenza, seduti dove è necessario.
• Super-seeding  è una modalità di seeding speciale in alcuni client BitTorrent che cerca di ridurre al minimo la quantità di dati che il seeding fornirà prima che appaia il primo downloader. Superseed offre a ciascun peer di scaricare solo un segmento del file, che gli altri peer non hanno ancora. Il seme quindi non fornisce ulteriori segmenti a quel peer finché non riceve conferma da altri peer che anche loro hanno ricevuto quel segmento. Pertanto, il superseed cerca di evitare di regalare gli stessi frammenti più e più volte e cerca di dare frammenti solo ai coetanei che li stanno attivamente dando ad altri.
• Hash ( hash inglese  ) - SHA1 dei singoli segmenti dei file originali, elencati nel dizionario "info" del file .torrent. Ogni parte, al ricevimento, viene prima controllata per una corrispondenza hash. Se il controllo fallisce, i dati vengono scartati e richiesti nuovamente. Il protocollo utilizza anche l'hash del dizionario "info" ("infohash") stesso, che funge da identificatore per una distribuzione specifica quando si accede al tracker, ad altri punti della rete e durante la compilazione di collegamenti magnetici (contiene una rappresentazione Base32 di l'infohash).
• Passkey  - autenticatore utente su tracker non anonimi. Contenuto nel file torrent scaricabile. Pertanto, se qualcuno ottiene l'accesso a un file torrent (ad esempio, un utente lo ha condiviso accidentalmente ), sarà in grado di lavorare con il tracker per conto di questo utente. Il tracker può modificare la passkey su richiesta dell'utente, ma in questo caso sarà necessario riscaricare tutti i file torrent passati (o modificarli manualmente) per poter continuare a distribuire i file scaricati.
• Annuncio URL ( eng.  annuncio URL ) — l'indirizzo del tracker a cui il client fa un annuncio. Chiamato "URL tracker" in molti client. Può includere "passkey" - un codice univoco assegnato dal tracker all'account dell'utente, che aiuta a identificarlo sul tracker (viene aggiunto all'URL dell'annuncio nel file *.torrent stesso durante il download).

BitTorrent v2

Dal 2008 sono in corso i lavori sul protocollo BitTorrent della seconda versione. Il protocollo si è allontanato dall'utilizzo dell'algoritmo SHA-1, che ha problemi con la selezione delle collisioni, a favore di SHA2-256. SHA2-256 viene utilizzato sia per controllare l'integrità dei blocchi di dati che per le voci negli indici (dizionario informativo), il che interrompe la compatibilità con DHT e tracker. È stato proposto un nuovo prefisso "urn:btmh:" per i collegamenti magnetici ai torrent con hash SHA2-256 (per i torrent SHA-1 e ibridi, viene utilizzato "urn:btih:").

Poiché la modifica della funzione hash interrompe la compatibilità del protocollo (un campo hash di 32 byte invece di 20 byte), lo sviluppo della specifica BitTorrent v2 non era originariamente compatibile con le versioni precedenti e sono state apportate altre modifiche significative, come l'uso di un hash Merkle albero negli indici per ridurre le dimensioni dei file torrent e controllare i dati scaricati a livello di blocco.

Altri punti salienti delle modifiche in BitTorrent v2 stanno passando all'associazione di alberi hash separati per ciascun file e all'applicazione dell'allineamento dei file in parti (senza aggiungere ulteriore riempimento dopo ogni file), che elimina la duplicazione dei dati quando sono presenti file identici e semplifica l'identificazione diverse fonti per i file. Migliorata l'efficienza della codifica della struttura delle directory torrent e aggiunte ottimizzazioni per gestire un numero elevato di file di piccole dimensioni.

Per facilitare la coesistenza di BitTorrent v1 e BitTorrent v2, è implementata la possibilità di creare file torrent ibridi, che includono, oltre alle strutture con hash SHA-1, indici con SHA2-256. Questi torrent ibridi possono essere utilizzati con client che supportano solo il protocollo BitTorrent v1. È inoltre in corso lo sviluppo per supportare il protocollo WebTorrent . La transizione da SHA-1 stessa crea incompatibilità nelle reti DHT, tracker (che ha una lunghezza fissa dell'hash delle informazioni di 20 caratteri). Per non perdere la compatibilità, in un primo momento puoi controllare sia SHA-1 che SHA-256, riducendo i 32 caratteri, incompatibile con il vecchio protocollo BitTorrent v1, SHA-256 a 20 caratteri .

Collegamenti

• La specifica del protocollo BitTorrent
• Sito ufficiale di BitTorrent
• La specifica attuale per il protocollo BitTorrent
• BitTorrent su Curlie Link Directory (dmoz)