BitTórrent (lit. engelsk) Bitstream er en peer-to- peer (P2P) netværksprotokol til samarbejdsfildeling over internettet .
Filer overføres i dele, hver torrent- klient , der modtager (downloader) disse dele, giver (downloader) dem på samme tid til andre klienter, hvilket reducerer belastningen og afhængigheden af hver kildeklient og giver dataredundans .
Protokollen blev skabt af Bram Cohen , som skrev den første BitTorrent torrent-klient i Python , den 4. april 2001 . Lanceringen af den første version fandt sted den 2. juli 2001 .
Der er mange klientprogrammer til udveksling af filer ved hjælp af BitTorrent-protokollen.
Metadatafilen er en ordbog i bencode -format med filtypenavnet .torrent - den indeholder information om distributionen (filer, trackere osv.)
Før download opretter klienten forbindelse til trackeren på den adresse, der er angivet i torrent-filen, fortæller den dens adresse og hash-summen af torrent-filen, som klienten som svar modtager adresserne på andre klienter, der downloader eller distribuerer den samme fil. Endvidere informerer klienten periodisk trackeren om processens fremskridt og modtager en opdateret liste over adresser. Denne proces kaldes en meddelelse .
Klienter forbinder med hinanden og udveksler filsegmenter uden direkte deltagelse af trackeren, som kun gemmer information modtaget fra kunder, der er tilsluttet centralen, en liste over klienter selv og andre statistiske oplysninger. For at BitTorrent-netværket kan fungere effektivt, er det nødvendigt, at så mange klienter som muligt kan acceptere indgående forbindelser. Forkerte NAT- eller firewall-indstillinger kan forhindre dette.
Ved tilslutning udveksler klienter straks information om de segmenter, de har. En klient, der ønsker at downloade et segment ( leecher ), sender en anmodning og modtager dette segment, hvis den anden klient er klar til at give. Klienten verificerer derefter checksummen for segmentet. Hvis det matcher den, der er registreret i torrent-filen, anses segmentet for at være downloadet, og klienten meddeler alle tilsluttede peers, at den har dette segment. Hvis kontrolsummerne er forskellige, begynder segmentet at blive downloadet igen. Nogle klienter forbyder de peers, der giver ukorrekte segmenter for ofte.
Mængden af serviceinformation (størrelsen af torrentfilen og størrelsen af beskeder med en liste over segmenter) afhænger således direkte af antallet og dermed størrelsen af segmenterne. Derfor, når du vælger et segment, er det nødvendigt at opretholde en balance: på den ene side, med en stor segmentstørrelse, vil mængden af serviceoplysninger være mindre, men i tilfælde af en kontrolsumverifikationsfejl skal flere oplysninger downloades igen. På den anden side, med en lille størrelse, er fejl ikke så kritiske, da en mindre volumen skal downloades igen, men størrelsen på torrentfilen og beskeder om eksisterende segmenter bliver større.
Hver klient har mulighed for midlertidigt at blokere tilbagevenden til en anden klient ( eng. choke ). Dette gøres for mere effektiv udnyttelse af returkanalen. Derudover, når man vælger, hvem der skal fjerne blokeringen, gives fortrinsret til peers, der selv har overført mange segmenter til denne klient. Fester med gode afkastrater opmuntrer således hinanden efter princippet "du - til mig, jeg - til dig."
Udvekslingen af segmenter udføres efter princippet "du - til mig, jeg - til dig" symmetrisk i to retninger. Klienter fortæller hinanden, hvilke shards de har, når de forbinder, og derefter når de modtager nye shards, så hver klient kan gemme information om, hvilke shards andre tilsluttede peers har. Udvekslingsordren er valgt på en sådan måde, at klienter udveksler de sjældneste segmenter først: dette øger tilgængeligheden af filer i distributionen. Samtidig er valget af et segment blandt de sjældneste tilfældigt, og derfor er det muligt at undgå situationen, hvor alle klienter begynder at downloade det samme sjældne segment, hvilket ville have en negativ indvirkning på ydeevnen.
Dataudveksling begynder, når begge parter er interesserede i det, det vil sige, at hver af parterne har segmenter, som den anden ikke har. Antallet af transmitterede segmenter tælles, og hvis en af parterne finder ud af, at den i gennemsnit sender mere, end den modtager, blokerer den ( eng. choke ) et stykke tid for returen til den anden side. Beskyttelse mod leechers er således indarbejdet i protokollen .
Segmenter er opdelt i blokke med en størrelse på 16-4096 kilobyte , og hver klient anmoder om præcis disse blokke. Blokke fra forskellige segmenter kan rekvireres på samme tid. Desuden understøtter nogle klienter at downloade blokke af det samme segment fra forskellige peers. I dette tilfælde er algoritmerne og udvekslingsmekanismerne beskrevet ovenfor også anvendelige på blokniveauet.
Når overførslen er næsten færdig, går klienten ind i en speciel tilstand kaldet slutspillet. I denne tilstand anmoder den om alle resterende segmenter fra alle tilsluttede peers, hvilket undgår en opbremsning eller fuldstændig "frysning" af en næsten afsluttet download på grund af flere langsomme klienter.
Protokolspecifikationen definerer ikke præcis, hvornår klienten skal gå ind i slutspillet, men der er et sæt almindeligt accepterede praksisser. Nogle klienter går ind i denne tilstand, når der ikke er nogen uopfordrede blokke tilbage, andre indtil antallet af resterende blokke er mindre end antallet af transmitterede og ikke mere end 20. Der er en uudtalt mening om, at det er bedre at beholde antallet af ventende blokke lav (1 eller 2) for at minimere redundans, og at når tilfældig anmodning mindre chance for at få dubletter af den samme blok [1] [2] .
Når en fuld fil modtages, skifter klienten til en speciel driftstilstand, hvor den kun sender data (bliver et frø). Yderligere informerer frøet periodisk trackeren om ændringer i status for torrents (downloads) og opdaterer listerne over IP-adresser.
Klienter opretter forbindelse til trackeren ved hjælp af TCP -protokollen . Mest almindeligt anvendte tracker indgående port : 6969. Mest almindeligt anvendte klient indgående portinterval: 6881-6889.
Portnumre er ikke fastsat i protokolspecifikationen og kan ændres efter behov. I øjeblikket bruger de fleste trackere HTTP -port 80, og det anbefales for klienter at vælge en tilfældig indgående port. Desuden tillader nogle trackere ikke brugen af klientporte fra standardområdet 6881-6889, da nogle udbydere forbyder brugen af dette portområde.
DHT -netværket i BitTorrent-klienter bruger UDP-protokollen .
Derudover bruges UDP-protokollen af UDP-trackers (understøttes ikke af alle klienter og er ikke en officiel del af protokollen) og til at forbinde klienter med hinanden via UDP NAT Traversal (bruges kun i BitComet-klienten og er ikke en officiel del af protokollen).
Tracker ( engelsk tracker ; /ˈtɹækə(ɹ)/ ) er en specialiseret server, der kører over HTTP-protokollen . Trackeren er nødvendig, så kunderne kan finde hinanden. Faktisk gemmer trackeren IP-adresser , indgående klientporte og hash-summer , der unikt identificerer objekter involveret i downloads. Ifølge standarden gemmes filnavne ikke på trackeren, og det er umuligt at genkende dem ved hash-summer. Men i praksis udfører trackeren ofte, udover sin hovedfunktion, også funktionen som en lille webserver . En sådan server gemmer metadatafiler og beskrivelser af distribuerede filer, leverer downloadstatistik for forskellige filer, viser det aktuelle antal tilsluttede peers osv.
Nye versioner af protokollen har udviklet sporløse systemer , der løser nogle af de tidligere problemer. Fejlen af en tracker i sådanne systemer fører ikke automatisk til fejl på hele netværket.
Fra version 4.2.0 af den officielle klient, udgivet i slutningen af 2015, er en sporløs arbejdsfunktion baseret på DHT Kademlia blevet implementeret . I en sådan implementering er trackeren tilgængelig decentraliseret på klienter i form af en distribueret hash-tabel .
I øjeblikket er det ikke alle klienter, der bruger en protokol, der er kompatibel med hinanden. BitComet , µTorrent , Deluge , KTorrent , Transmission , qBittorrent og den officielle BitTorrent-klient er kompatible med hinanden . Vuze (Azureus) har også en trackerløs tilstand, men dens implementering adskiller sig fra den officielle, som et resultat af hvilken den ikke kan fungere via DHT med ovenstående klienter [3] . Der er dog understøttelse af standard DHT til Vuze via Mainline DHT plugin.
Arbejde uden en tracker er også muligt, når du bruger multiprotokolklienter, der understøtter BitTorrent. Shareaza udveksler hashes og peer-adresser på andre understøttede netværk, inklusive BitTorrent, via Gnutella2 -netværket. BitTorrent-understøttelse er planlagt i GreyLink 6.0, mens Direct Connect -netværket ikke kun kan bruges til at konvertere til TTH , men også til at finde peers.
For at tage og distribuere filer i torrent-netværk er det ikke nødvendigt at bruge specielle programmer. Der er flere tjenester, der giver dig mulighed for at downloade filer ved hjælp af kun en browser [4] .
Tilstedeværelsen af yderligere oplysninger i metadatafilerne, såsom yderligere kilder og valgfri hashes, tillader brugen af en .torrent-metadatafil på samme måde som Metalink , MAGMA , File List (Direct Connect)-formaterne . Shareaza- klienten bruger valgfri hash til at finde alternative kilder på andre netværk.
En use case er såkaldt web seeding. Nogle gange kan en fuldgyldig torrentklient af forskellige årsager ikke startes på serveren. I dette tilfælde fungerer en server, der opererer over HTTP-protokollen, som en distributionskilde. Som regel foretrækker klienter andre BitTorrent-klienter og får kun adgang til web-seedet, når det er nødvendigt. Vær opmærksom på, at denne use case er implementeret på mindst tre måder: BEP0017 BitTornado style webseed , BEP0019 GetRight style webseed og External Sourcing , som hver især adskiller sig i implementeringsdetaljer.
Det blev først skabt af John "TheSHAD0W" Hoffman, som skabte BitTornado [5] . Da version 5.0 af BitTorrent-klienten understøtter web-seed og downloads fra websteder, er der blevet oprettet et simpelt værktøj, der skaber torrent web-seed-publikationer. μTorrent tilføjede support til at få webfrø i version 1.7. BitComet tilføjede support til at få webfrø i version 1.14.
Dette er SHA-1- hashen for Info-feltet fra metadatafilen . Denne hash bruges i magnetlinks såvel som til identifikation på trackeren og mellem klienter. Når du uploader en metadatafil til en tracker , kan dens Info Hash ændre sig, da trackeren kan ændre infofeltet ved at indstille flaget for den private distribution eller ved at ændre/tilføje felter inde i info. Derfor skal du downloade metadatafilen (.torrent-fil) fra trackeren igen og tilføje den til klienten [6] .
Specificeret som:
btc://[Адрес]: [Порт]/[Peer ID]/[ BTIH ]
Et link af denne art henviser til distributionen og dens kilde. Understøttet i Shareaza .
Hvis distributionen er upopulær, kan der opstå en situation, hvor der ikke er et enkelt frø, og de tilstedeværende peers ikke har nok data til at fuldføre downloadingen. I dette tilfælde er det nødvendigt at vente på udseendet af enten et frø eller en peer, der har segmenter, der mangler fra de andre. Du kan også bruge kopier af filer opnået på anden måde. En hånd, der ikke har nogen frø i lang tid, kaldes "død".
For at opmuntre til giveaways er der endda blevet oprettet et BitTorrent-token [7] .
Princippet i BitTorrent-protokollen indebærer, at hver klient kender IP-adresserne på mindst andre klienter modtaget fra serveren. Brugen af forskellige protokoludvidelser giver dig i nogle tilfælde også mulighed for at finde ud af adresserne på andre jævnaldrende fra sværmen. Derfor:
Problemet med anonymitet kan løses ved at bruge Tor [8] . Vuze BitTorrent-klienten har indbygget softwareunderstøttelse til dette anonyme netværk . Men denne metode er ikke 100 % effektiv [9] .
På den anden side involverer protokollen ikke brugen af øgenavne. Ingen chat mellem jævnaldrende. Ude af stand til at liste peer-filer (søger efter andre filer, der kunne være af interesse). De fleste af disse funktioner er implementeret i andre protokoller (såsom Direct Connect ).
Nogle brugere, især på trackere, der ikke kræver registrering, understøtter ikke distribution efter overførslen er afsluttet, hvilket fører til et fald i den samlede ydeevne, så nogle torrent-trackere tager også højde for mængden af downloadet/givet væk og giver tilladelse at downloade afhængigt af størrelsen af de data, som klienten har givet.
I modsætning til mange kommercielle medieindholdsdistributionsprotokoller giver protokolarkitekturen ikke en nøjagtig mekanisme til at opgøre og kontrollere trafik mellem netværkspunkter. Det eneste, der er der, er de downloadede og uploadede felter, hvor klienter passerer antallet af bytes, der er taget i betragtning ved download/upload af data siden den forrige meddelelse, når de annoncerede til trackeren. Men ikke kontrolleret af andre end klienten, kan de let forfalskes. For at gøre dette tildeler brugere statisk værdierne af disse felter til tracker- URI'en , bruger patches til klienter eller separate programmer (RatioMaster, GiveMeTorrent, GreedyTorrent osv.), eller sletter simpelthen tracker-posten fra klienten umiddelbart efter at have modtaget en liste over netværkspunkter fra trackeren. Alt dette giver dig mulighed for at omgå de kunstige restriktioner skabt af administrationen af mange private og offentlige trackere.
Arbejdet med BitTorrent-protokollen til den anden version har været i gang siden 2008. Protokollen er gået væk fra at bruge SHA-1-algoritmen, som har problemer med udvælgelsen af kollisioner, til fordel for SHA2-256. SHA2-256 bruges både til at kontrollere integriteten af datablokke og til indtastninger i indekser (info-ordbog), som bryder kompatibiliteten med DHT og trackere. Et nyt præfiks "urn:btmh:" er blevet foreslået for magnetlinks til torrents med SHA2-256 hashes (for SHA-1 og hybrid torrents bruges "urn:btih:").
Fordi ændringen i hashfunktionen bryder protokolkompatibiliteten (et hashfelt på 32 bytes i stedet for 20 bytes), var udviklingen af BitTorrent v2-specifikationen oprindeligt ikke bagudkompatibel, og der blev foretaget andre væsentlige ændringer, såsom brugen af en Merkle-hash træ i indekser for at reducere størrelsen af torrent-filer og kontrollere downloadede data på blokniveau.
Andre højdepunkter i ændringerne i BitTorrent v2 går over til at tilknytte separate hash-træer for hver fil og anvende filjustering i dele (uden at tilføje yderligere polstring efter hver fil), hvilket eliminerer duplikering af data, når der er identiske filer og gør det lettere at identificere forskellige kilder til filer. Forbedret torrent-biblioteksstruktur kodningseffektivitet og tilføjede optimeringer til at håndtere et stort antal små filer.
For at udjævne sameksistensen af BitTorrent v1 og BitTorrent v2 implementeres evnen til at skabe hybride torrent-filer, som ud over strukturer med SHA-1-hashes inkluderer indekser med SHA2-256. Disse hybrid torrents kan bruges med klienter, der kun understøtter BitTorrent v1-protokollen. Udvikling er også i gang for at understøtte WebTorrent-protokollen [10] . Selve overgangen fra SHA-1 skaber inkompatibilitet i DHT-netværk, trackere (som har en fast info-hash-længde på 20 tegn). For ikke at miste kompatibiliteten, kan du først tjekke både SHA-1 og SHA-256, hvilket reducerer de 32 tegn, inkompatibel med den gamle BitTorrent v1-protokol, SHA-256 til 20 tegn [11] .
| BitTorrent filudvekslingsprotokol ( klientprogrammer ) | |
|---|---|
| Forfatterne | Personer Eric Clinker Bram Cohen Navin Virksomheder BitTorrent Inc. Vuse, Inc. |
| Teknologi |
|
| Sporer | |
| Motorer |
|
| Relaterede artikler | |
| Grundlæggende TCP / IP-protokoller efter lag af OSI-modellen | |
|---|---|
| Fysisk | |
| kanaliseret | |
| netværk | |
| Transportere | |
| session | |
| Repræsentation | |
| Anvendt | |
| Andet anvendt | |
| Liste over TCP- og UDP-porte | |