BitTórrent (lit. engelska) Bitstream är ett peer-to- peer (P2P) nätverksprotokoll för kooperativ fildelning över Internet .
Filer överförs i delar, varje torrentklient , tar emot (laddar ner) dessa delar, samtidigt ger (nedladdningar) dem till andra klienter, vilket minskar belastningen och beroendet av varje källklient och ger dataredundans .
Protokollet skapades av Bram Cohen , som skrev den första BitTorrent -torrentklienten i Python , den 4 april 2001 . Lanseringen av den första versionen ägde rum den 2 juli 2001 .
Det finns många klientprogram för att utbyta filer med hjälp av BitTorrent-protokollet.
Metadatafilen är en ordbok i bencode -format med filtillägget .torrent - den innehåller information om distributionen (filer, spårare , etc.)
Före nedladdning ansluter klienten till spåraren på adressen som anges i torrentfilen, berättar dess adress och hashsumman för torrentfilen, till vilken klienten som svar får adresserna till andra klienter som laddar ner eller distribuerar samma fil. Vidare informerar klienten regelbundet spåraren om processens framsteg och får en uppdaterad lista med adresser. Denna process kallas ett meddelande .
Klienter ansluter till varandra och utbyter filsegment utan direkt deltagande av spåraren, som endast lagrar information mottagen från klienter anslutna till växeln, en lista över klienterna själva och annan statistisk information. För att BitTorrent-nätverket ska fungera effektivt är det nödvändigt att så många klienter som möjligt kan acceptera inkommande anslutningar. Felaktiga NAT- eller brandväggsinställningar kan förhindra detta.
Vid anslutning utbyter klienter omedelbart information om de segment de har. En klient som vill ladda ner ett segment ( leecher ) skickar en begäran och, om den andra klienten är redo att ge, tar emot detta segment. Klienten verifierar sedan checksumman för segmentet. Om det matchar den som registrerats i torrentfilen anses segmentet vara nedladdat, och klienten meddelar alla anslutna peers att den har detta segment. Om kontrollsummorna skiljer sig, börjar segmentet att laddas ner igen. Vissa klienter förbjuder de kamrater som ger felaktiga segment för ofta.
Mängden tjänstinformation (storleken på torrentfilen och storleken på meddelanden med en lista över segment) beror alltså direkt på antalet och därmed storleken på segmenten. Därför, när du väljer ett segment, är det nödvändigt att upprätthålla en balans: å ena sidan, med en stor segmentstorlek, kommer mängden serviceinformation att vara mindre, men i händelse av ett kontrollsummeverifieringsfel måste mer information laddas ner igen. Å andra sidan, med en liten storlek, är fel inte så kritiska, eftersom en mindre volym behöver laddas ner igen, men storleken på torrentfilen och meddelanden om befintliga segment blir större.
Varje klient har möjlighet att tillfälligt blockera returen till en annan klient ( eng. choke ). Detta görs för en effektivare användning av returkanalen. Dessutom, när man väljer vem som ska avblockeras, ges företräde åt kamrater som själva har överfört många segment till denna klient. Sålunda uppmuntrar högtider med bra avkastningsgrader varandra enligt principen "du - till mig, jag - till dig."
Utbytet av segment utförs enligt principen "du - till mig, jag - till dig" symmetriskt i två riktningar. Klienter berättar för varandra vilka shards de har när de ansluter och sedan när de får nya shards, så varje klient kan lagra information om vilka shards andra anslutna peers har. Utbytesordern är vald på ett sådant sätt att klienter byter ut de mest sällsynta segmenten först: detta ökar tillgängligheten för filer i distributionen. Samtidigt är valet av ett segment bland de sällsynta slumpmässigt, och därför är det möjligt att undvika situationen när alla klienter börjar ladda ner samma sällsynta segment, vilket skulle ha en negativ inverkan på prestandan.
Datautbyte börjar när båda parter är intresserade av det, det vill säga att var och en av parterna har segment som den andra inte har. Antalet sända segment räknas, och om en av parterna finner att den sänder i genomsnitt mer än den tar emot, blockerar den ( eng. choke ) en stund återgången till andra sidan. Således är skydd mot leechers inkorporerat i protokollet .
Segment är indelade i block med en storlek på 16-4096 kilobyte , och varje klient begär exakt dessa block. Block från olika segment kan begäras samtidigt. Dessutom stöder vissa klienter nedladdning av block av samma segment från olika peers. I detta fall är de ovan beskrivna algoritmerna och utbytesmekanismerna också tillämpliga på blocknivån.
När nedladdningen nästan är klar går klienten in i ett speciellt läge som kallas slutspelet. I det här läget begär den alla återstående segment från alla anslutna peers, vilket undviker en avmattning eller fullständig "frysning" av en nästan avslutad nedladdning på grund av flera långsamma klienter.
Protokollspecifikationen definierar inte exakt när klienten ska gå in i slutspelet, men det finns en uppsättning allmänt accepterade metoder. Vissa klienter går in i detta läge när det inte finns några oönskade block kvar, andra tills antalet återstående block är mindre än antalet överförda och inte fler än 20. Det finns en outtalad åsikt att det är bättre att behålla antalet väntande block. låg (1 eller 2) för att minimera redundans, och att när slumpmässig begäran mindre chans att få dubbletter av samma block [1] [2] .
När en fullständig fil tas emot växlar klienten till ett speciellt driftläge där den bara skickar data (blir ett frö). Vidare informerar fröet regelbundet spåraren om förändringar i status för torrents (nedladdningar) och uppdaterar listorna med IP-adresser.
Klienter ansluter till spåraren med TCP- protokollet . Mest använda tracker inkommande port : 6969. Vanligast använda klient inkommande port intervall: 6881-6889.
Portnummer är inte fasta i protokollspecifikationen och kan ändras vid behov. För närvarande använder de flesta spårare HTTP- port 80, och det rekommenderas för klienter att välja en slumpmässig inkommande port. Dessutom tillåter vissa spårare inte användning av klientportar från standardintervallet 6881-6889, eftersom vissa leverantörer förbjuder användningen av detta portintervall.
DHT -nätverket i BitTorrent-klienter använder UDP-protokollet .
Dessutom används UDP-protokollet av UDP-trackers (stöds inte av alla klienter och är inte en officiell del av protokollet) och för att koppla klienter till varandra via UDP NAT Traversal (används endast i BitComet-klienten och är inte en officiell del av protokollet).
Tracker ( engelsk tracker ; /ˈtɹækə(ɹ)/ ) är en specialiserad server som körs över HTTP-protokollet . Spåraren behövs för att kunderna ska hitta varandra. Faktum är att spåraren lagrar IP-adresser , inkommande klientportar och hash-summor som unikt identifierar objekt som är involverade i nedladdningar. Enligt standarden lagras inte filnamn på trackern, och det är omöjligt att känna igen dem med hashsummor. Men i praktiken utför trackern ofta, förutom sin huvudfunktion, även funktionen av en liten webbserver . En sådan server lagrar metadatafiler och beskrivningar av distribuerade filer, ger nedladdningsstatistik för olika filer, visar aktuellt antal anslutna peers, etc.
Nya versioner av protokollet har utvecklat spårlösa system som löser några av de tidigare problemen. Fel på en tracker i sådana system leder inte automatiskt till fel på hela nätverket.
Från och med version 4.2.0 av den officiella klienten, släppt i slutet av 2015, har en spårlös arbetsfunktion baserad på DHT Kademlia implementerats . I en sådan implementering är spåraren tillgänglig decentraliserat på klienter i form av en distribuerad hashtabell .
För närvarande använder inte alla klienter ett protokoll som är kompatibelt med varandra. BitComet , µTorrent , Deluge , KTorrent , Transmission , qBittorrent och den officiella BitTorrent-klienten är kompatibla med varandra . Vuze (Azureus) har också ett spårlöst läge, men dess implementering skiljer sig från det officiella, vilket gör att det inte kan fungera via DHT med ovanstående klienter [3] . Det finns dock stöd för standard DHT för Vuze via Mainline DHT-plugin.
Arbete utan tracker är också möjligt när du använder multiprotokollklienter som stöder BitTorrent. Shareaza utbyter hash- och peer-adresser till andra nätverk som stöds, inklusive BitTorrent, via Gnutella2 -nätverket. BitTorrent-stöd är planerat i GreyLink 6.0, medan Direct Connect -nätverket inte bara kan användas för att konvertera till TTH utan också för att hitta peers.
För att ta och distribuera filer i torrentnätverk är det inte nödvändigt att använda speciella program. Det finns flera tjänster som låter dig ladda ner filer med endast en webbläsare [4] .
Närvaron av ytterligare information i metadatafilerna, såsom ytterligare källor och valfria hash, tillåter användning av en .torrent-metadatafil på ett liknande sätt som Metalink , MAGMA , File List (Direct Connect)-format . Shareaza- klienten använder valfria hash för att söka upp alternativa källor på andra nätverk.
Ett användningsfall är så kallad webbsådd. Ibland, av olika anledningar, kan en fullfjädrad torrentklient inte startas på servern. I det här fallet fungerar en server som arbetar över HTTP-protokollet som en distributionskälla. Som regel föredrar klienter andra BitTorrent-klienter och får endast tillgång till webbfröet när det behövs. Var medveten om att detta användningsfall implementeras på minst tre sätt: BEP0017 BitTornado-stil webseed , BEP0019 GetRight-stil webseed och External Sourcing , som var och en skiljer sig i implementeringsdetaljer.
Den skapades först av John "TheSHAD0W" Hoffman, som skapade BitTornado [5] . Eftersom version 5.0 av BitTorrent-klienten stöder webbfrön och nedladdningar från webbplatser, har ett enkelt verktyg skapats som skapar torrent-webfröpublikationer. μTorrent lade till stöd för att hämta webbfrön i version 1.7. BitComet lade till stöd för att få webbfrön i version 1.14.
Detta är SHA-1- hash för infofältet från metadatafilen . Denna hash används i magnetlänkar , såväl som för identifiering på spåraren och mellan klienter. När du laddar upp en metadatafil till en spårare kan dess Info Hash ändras, eftersom spåraren kan ändra infofältet genom att ställa in flaggan för privat distribution eller genom att ändra/lägga till fält inuti info. Därför måste du ladda ner metadatafilen (.torrent-fil) från spåraren igen och lägga till den i klienten [6] .
Specificerat som:
btc://[Адрес]: [Порт]/[Peer ID]/[ BTIH ]
En länk av detta slag hänvisar till distributionen och dess källa. Stöds i Shareaza .
Om distributionen är impopulär kan en situation uppstå när det inte finns ett enda frö och de närvarande jämnåriga inte har tillräckligt med data för att slutföra nedladdningen. I det här fallet är det nödvändigt att vänta på utseendet av antingen ett frö eller en kamrat som har segment som saknas från de andra. Du kan också använda kopior av filer som erhållits på annat sätt. En hand som inte har något frö på länge kallas "död".
För att uppmuntra giveaways har en BitTorrent-token till och med skapats [7] .
Principen för BitTorrent-protokollet innebär att varje klient känner till IP-adresserna för åtminstone andra klienter som tas emot från servern. Användningen av olika protokollförlängningar i vissa fall låter dig också ta reda på adresserna till andra kamrater från svärmen. Det är därför:
Problemet med anonymitet kan lösas genom att använda Tor [8] . Vuze BitTorrent -klienten har inbyggt mjukvarustöd för detta anonyma nätverk . Men denna metod är inte 100 % effektiv [9] .
Å andra sidan innebär protokollet inte användning av smeknamn. Ingen chatt mellan kamrater. Det går inte att lista peer-filer (letar efter andra filer som kan vara av intresse). De flesta av dessa funktioner är implementerade i andra protokoll (som Direct Connect ).
Vissa användare, särskilt på trackers som inte kräver registrering, stöder inte distribution efter att nedladdningen är klar, vilket leder till en minskning av den totala prestandan, så vissa torrent trackers tar också hänsyn till mängden nedladdade/givna bort och ger tillstånd att ladda ner beroende på storleken på data som ges av klienten.
Till skillnad från många protokoll för distribution av kommersiellt mediainnehåll, tillhandahåller inte protokollarkitekturen en korrekt mekanism för att redovisa och kontrollera trafik mellan nätverkspunkter. Allt som finns där är de nedladdade och uppladdade fälten, i vilka klienter passerar antalet byte som tagits i beaktande vid nedladdning/uppladdning av data sedan det föregående meddelandet när de tillkännagav till spåraren. Men om de inte kontrolleras av någon annan än kunden, kan de lätt förfalskas. För att göra detta tilldelar användare statiskt värdena för dessa fält till tracker -URI , använder patchar för klienter eller separata program (RatioMaster, GiveMeTorrent, GreedyTorrent, etc.), eller tar helt enkelt bort tracker-posten från klienten omedelbart efter att ha mottagit en lista över nätverkspunkter från spåraren. Allt detta låter dig kringgå de konstgjorda begränsningarna som skapas av administrationen av många privata och offentliga spårare.
Arbetet med BitTorrent-protokollet för den andra versionen har pågått sedan 2008. Protokollet har gått bort från att använda SHA-1-algoritmen, som har problem med valet av kollisioner, till förmån för SHA2-256. SHA2-256 används både för att kontrollera datablockens integritet och för poster i index (info-dictionary), vilket bryter kompatibiliteten med DHT och trackers. Ett nytt prefix "urn:btmh:" har föreslagits för magnetlänkar till torrents med SHA2-256-hashar (för SHA-1 och hybridtorrenter används "urn:btih:").
Eftersom förändringen i hashfunktionen bryter protokollkompatibiliteten (ett hashfält på 32 byte istället för 20 byte), var utvecklingen av BitTorrent v2-specifikationen ursprungligen inte bakåtkompatibel, och andra betydande ändringar gjordes, såsom användningen av en Merkle-hash träd i index för att minska storleken på torrentfiler och kontrollera nedladdade data på blocknivå.
Andra höjdpunkter i ändringarna i BitTorrent v2 är att gå över till att associera separata hashträd för varje fil och tillämpa filjustering i delar (utan att lägga till ytterligare utfyllnad efter varje fil), vilket eliminerar duplicering av data när det finns identiska filer och gör det lättare att identifiera olika källor för filer. Förbättrad kodningseffektivitet för torrentkatalogstruktur och tillagda optimeringar för att hantera ett stort antal små filer.
För att jämna ut samexistensen av BitTorrent v1 och BitTorrent v2, implementeras möjligheten att skapa hybridtorrentfiler, som förutom strukturer med SHA-1-hashar inkluderar index med SHA2-256. Dessa hybridtorrenter kan användas med klienter som endast stöder BitTorrent v1-protokollet. Utveckling pågår också för att stödja WebTorrent-protokollet [10] . Övergången från SHA-1 i sig skapar inkompatibilitet i DHT-nätverk, trackers (som har en fast info-hash-längd på 20 tecken). För att inte förlora kompatibiliteten kan du först kontrollera både SHA-1 och SHA-256, vilket minskar 32-tecken, inkompatibelt med det gamla BitTorrent v1-protokollet, SHA-256 till 20 tecken [11] .
| BitTorrent filutbytesprotokoll ( klientprogram ) | |
|---|---|
| Författarna | Personer Eric Clinker Bram Cohen Navin Företag BitTorrent Inc. Vuse, Inc. |
| Teknologi |
|
| Spårare | |
| Motorer |
|
| Relaterade artiklar | |
| Grundläggande TCP / IP-protokoll efter lager av OSI-modellen | |
|---|---|
| Fysisk | |
| kanaliserad | |
| nätverk | |
| Transport | |
| session | |
| Representation | |
| Applicerad | |
| Annat ansökt | |
| Lista över TCP- och UDP-portar | |