BitTórrent ( szó szerint angol) A Bitstream egy peer-to- peer (P2P) hálózati protokoll az interneten keresztüli kooperatív fájlmegosztáshoz .
A fájlok átvitele részenként történik, minden torrent kliens fogadja (letölti) ezeket a részeket, ugyanakkor átadja (letölti) más klienseknek, ami csökkenti az egyes forráskliensek terhelését és függőségét, valamint adatredundanciát biztosít .
A protokollt Bram Cohen készítette, aki az első BitTorrent torrent klienst írta Pythonban 2001. április 4- én . Az első verzió piacra dobására 2001. július 2-án került sor .
Számos kliensprogram létezik a BitTorrent protokoll használatával történő fájlok cseréjére.
A metaadatfájl egy bencode formátumú , .torrent kiterjesztésű szótár – információkat tartalmaz a terjesztésről (fájlok, nyomkövetők stb.)
Letöltés előtt a kliens a torrent fájlban megadott címen csatlakozik a trackerhez , megmondja neki a címét és a torrent fájl hash összegét, amelyre válaszul megkapja az ugyanazt a fájlt letöltő vagy terjesztő többi kliens címét. Ezenkívül az ügyfél rendszeresen tájékoztatja a nyomkövetőt a folyamat előrehaladásáról, és megkapja a frissített címlistát. Ezt a folyamatot bejelentésnek nevezik .
Az ügyfelek kapcsolatba lépnek egymással és fájlszegmenseket cserélnek a tracker közvetlen részvétele nélkül, amely csak a központhoz csatlakozó ügyfelektől kapott információkat, maguknak az ügyfeleknek a listáját és egyéb statisztikai információkat tárol. A BitTorrent hálózat hatékony működéséhez szükséges, hogy minél több kliens tudja fogadni a bejövő kapcsolatokat. A helytelen NAT- vagy tűzfalbeállítások megakadályozhatják ezt.
Csatlakozáskor az ügyfelek azonnal információt cserélnek a rendelkezésükre álló szegmensekről. Az a kliens, aki egy szegmenst szeretne letölteni ( leecher ), kérést küld, és ha a második kliens kész megadni, megkapja ezt a szegmenst. Az ügyfél ezután ellenőrzi a szegmens ellenőrző összegét. Ha egyezik a torrent fájlban rögzítettel, akkor a szegmens sikeresen letöltöttnek minősül, és a kliens értesíti az összes csatlakoztatott partnert, hogy rendelkezik ezzel a szegmenssel. Ha az ellenőrző összegek eltérnek, akkor a szegmens letöltése újra megkezdődik. Egyes ügyfelek tiltják azokat a partnereket, amelyek túl gyakran adnak helytelen szegmenseket.
Így a szolgáltatási információ mennyisége (a torrent fájl mérete és a szegmenslistát tartalmazó üzenetek mérete) közvetlenül függ a szegmensek számától, és így a szegmensek méretétől. Ezért a szegmens kiválasztásakor meg kell tartani az egyensúlyt: egyrészt nagy szegmensméret esetén kevesebb lesz a szolgáltatási információ mennyisége, ellenőrzőösszeg-ellenőrzési hiba esetén viszont több információra van szükség. újra le kell tölteni. Másrészt kis méretnél a hibák nem olyan kritikusak, mivel kisebb kötetet kell újra letölteni, de a torrent fájl és a meglévő szegmensekről szóló üzenetek mérete megnő.
Minden kliensnek lehetősége van ideiglenesen blokkolni a visszatérést egy másik klienshez ( eng. choke ). Ez a visszatérő csatorna hatékonyabb kihasználása érdekében történik. Ezenkívül a feloldandó személyek kiválasztásakor előnyben részesítik azokat a társakat, akik maguk is sok szegmenst adtak át ehhez az ügyfélhez. Így a jó megtérülési arányú lakomák a "te - nekem, én - neked" elv szerint bátorítják egymást.
A szegmensek cseréje a "te - nekem, én - neked" elv szerint történik, szimmetrikusan két irányban. Az ügyfelek elmondják egymásnak, hogy milyen szilánkokkal rendelkeznek, amikor csatlakoznak, majd amikor új szilánkokat kapnak, így minden ügyfél információt tárolhat arról, hogy a többi csatlakoztatott társa milyen szilánkokkal rendelkezik. A csererendelést úgy választják meg, hogy az ügyfelek először a legritkább szegmenseket cseréljék ki: ez növeli a fájlok elérhetőségét a disztribúcióban. Ugyanakkor a legritkább szegmens kiválasztása véletlenszerű, így elkerülhető az a helyzet, amikor minden kliens ugyanazt a ritka szegmenst kezdi el letölteni, ami negatívan befolyásolná a teljesítményt.
Az adatcsere akkor kezdődik, amikor mindkét fél érdeklődik iránta, vagyis mindegyik félnek vannak olyan szegmensei, amelyekkel a másik nem rendelkezik. Megszámolja az átvitt szegmensek számát, és ha az egyik fél úgy találja, hogy átlagosan többet ad, mint amennyit fogad, egy időre blokkolja ( eng. choke ) a visszatérést a másik oldalra. Így a piócák elleni védelem beépül a protokollba .
A szegmensek 16-4096 kilobájt méretű blokkokra vannak osztva , és minden kliens pontosan ezeket a blokkokat kéri. Egyszerre is kérhetők blokkok különböző szegmensekből. Ezenkívül egyes kliensek támogatják az azonos szegmens blokkjainak letöltését különböző partnerektől. Ebben az esetben a fent leírt algoritmusok és cseremechanizmusok blokkszintre is alkalmazhatók.
Amikor a letöltés csaknem befejeződött, a kliens egy speciális módba lép, amelyet a játék végéhez hívnak. Ebben a módban az összes többi szegmenst lekéri az összes csatlakoztatott partnertől, ami elkerüli, hogy a több lassú kliens miatt lelassuljon vagy teljes "lefagyjon" a majdnem befejezett letöltés.
A protokoll specifikációja nem határozza meg pontosan, hogy az ügyfélnek mikor kell belépnie a végjátékba, de van egy sor általánosan elfogadott gyakorlat. Egyes kliensek akkor lépnek be ebbe a módba, amikor már nem maradt kéretlen blokkok, mások addig, amíg a fennmaradó blokkok száma nem éri el a továbbított blokkok számát, és nem haladja meg a 20-at. Van egy kimondatlan vélemény, hogy jobb megtartani a függőben lévő blokkok számát alacsony (1 vagy 2) a redundancia minimalizálása érdekében, és véletlenszerű kérés esetén kisebb az esélye annak, hogy ugyanazon blokk ismétlődéseit kapja [1] [2] .
Amikor egy teljes fájl érkezik, a kliens speciális üzemmódra vált, amelyben csak adatokat küld (magvá válik). Ezenkívül a mag rendszeresen tájékoztatja a nyomkövetőt a torrentek (letöltések) állapotának változásairól, és frissíti az IP-címek listáját.
Az ügyfelek a TCP protokoll használatával csatlakoznak a nyomkövetőhöz . Leggyakrabban használt tracker bejövő port : 6969. Leggyakrabban használt kliens bejövő port tartománya: 6881-6889.
A portszámok nincsenek rögzítve a protokoll specifikációjában, és szükség szerint módosíthatók. Jelenleg a legtöbb nyomkövető a 80-as HTTP -portot használja, és az ügyfeleknek ajánlott véletlenszerű bejövő portot választani. Ezenkívül egyes nyomkövetők nem teszik lehetővé a 6881-6889 szabvány tartományba tartozó kliensportok használatát, mivel egyes szolgáltatók tiltják ennek a porttartománynak a használatát.
A BitTorrent kliensek DHT -hálózata az UDP protokollt használja .
Ezenkívül az UDP protokollt az UDP nyomkövetők használják (nem minden kliens támogatja, és nem hivatalos része a protokollnak), valamint a kliensek összekapcsolására UDP NAT Traversal segítségével (csak a BitComet kliensben használatos, és nem hivatalos része a jegyzőkönyvnek).
A Tracker ( angolul tracker ; /ˈtɹækə(ɹ)/ ) egy speciális szerver , amely HTTP protokollon keresztül fut . A nyomkövetőre azért van szükség, hogy az ügyfelek megtalálják egymást. Valójában a tracker tárolja az IP-címeket , a bejövő kliensportokat és a hash összegeket , amelyek egyedileg azonosítják a letöltésekben érintett objektumokat. A szabvány szerint a fájlneveket nem tárolja a tracker, és nem lehet felismerni őket hash összegekből. A gyakorlatban azonban a tracker gyakran fő funkciója mellett egy kis webszerver funkcióját is ellátja . Egy ilyen szerver metaadatfájlokat és az elosztott fájlok leírásait tárolja, letöltési statisztikát biztosít a különböző fájlokhoz, megmutatja a csatlakoztatott társak aktuális számát stb.
A protokoll új verziói nyomkövető nélküli rendszereket fejlesztettek ki , amelyek megoldanak néhány korábbi problémát. Az ilyen rendszerekben a nyomkövető meghibásodása nem vezet automatikusan a teljes hálózat meghibásodásához.
A hivatalos kliens 2015 végén megjelent 4.2.0-s verziójától kezdve egy DHT Kademlia alapú nyomkövető nélküli munkafunkció került megvalósításra . Egy ilyen megvalósításban a nyomkövető decentralizáltan elérhető az ügyfeleken egy elosztott hash-tábla formájában .
Jelenleg nem minden kliens használ egymással kompatibilis protokollt. A BitComet , a µTorrent , a Deluge , a KTorrent , a Transmission , a qBittorrent és a hivatalos BitTorrent kliens kompatibilis egymással . A Vuze (Azureus) is rendelkezik nyomkövető nélküli móddal, de ennek megvalósítása eltér a hivatalostól, ami miatt a fenti kliensekkel nem tud DHT-n keresztül működni [3] . Azonban a Mainline DHT bővítményen keresztül támogatja a szabványos DHT-t a Vuze számára.
A nyomkövető nélküli munka a BitTorrentet támogató többprotokollos kliensek használatakor is lehetséges. A Shareaza a Gnutella2 hálózaton keresztül más támogatott hálózatok kivonatait és peer címeit cseréli, beleértve a BitTorrentet is . A BitTorrent támogatást a GreyLink 6.0-ban tervezik, míg a Direct Connect hálózat nem csak TTH -ra konvertálható , hanem társak keresésére is alkalmas.
A fájlok torrent hálózatokban történő fogadásához és terjesztéséhez nem szükséges speciális programok használata. Több szolgáltatás is lehetővé teszi a fájlok letöltését csak böngésző használatával [4] .
A metaadatfájlokban további információk jelenléte, például további források és opcionális hashek, lehetővé teszi a .torrent metaadatfájl használatát a Metalink , MAGMA , File List (Direct Connect) formátumokhoz hasonló módon . A Shareaza kliens opcionális kivonatokat használ, hogy alternatív forrásokat keressen más hálózatokon.
Az egyik felhasználási eset az úgynevezett webes vetés. Néha különböző okok miatt egy teljes értékű torrent kliens nem indítható el a szerveren. Ebben az esetben a HTTP protokollon keresztül működő szerver terjesztési forrásként működik. Az ügyfelek általában más BitTorrent klienseket részesítenek előnyben, és csak szükség esetén érik el a webmagot. Ne feledje, hogy ezt a használati esetet legalább három módon valósítják meg: BEP0017 BitTornado stílusú webseed , BEP0019 GetRight stílusú webseed és Külső beszerzés , amelyek mindegyike különbözik a megvalósítás részleteiben.
Először John "TheSHAD0W" Hoffman készítette, aki létrehozta a BitTornado-t [5] . Mivel a BitTorrent kliens 5.0-s verziója támogatja a webes magokat és a webhelyekről történő letöltéseket, egy egyszerű eszközt hoztak létre, amely torrent webes seed kiadványokat hoz létre. A μTorrent hozzáadott támogatást a webes magok beszerzéséhez az 1.7-es verzióban. A BitComet az 1.14-es verzióban támogatja a webes magok beszerzését.
Ez a metaadatfájl Info mezőjének SHA-1 kivonata . Ezt a hash -t használják mágneses hivatkozásokban , valamint azonosításra a nyomkövetőn és az ügyfelek között. Ha metaadatfájlt tölt fel egy nyomkövetőbe , az Info Hash módosulhat, mivel a nyomkövető megváltoztathatja az információs mezőt a privát terjesztési jelző beállításával vagy az információn belüli mezők módosításával/adásával. Ezért újra le kell töltenie a metaadat fájlt (.torrent fájl) a trackerből, és hozzá kell adnia a klienshez [6] .
Megadva:
btc://[Адрес]: [Порт]/[Peer ID]/[ BTIH ]
Egy ilyen hivatkozás a terjesztésre és annak forrására utal. A Shareaza támogatja .
Ha a disztribúció nem népszerű, akkor olyan helyzet adódhat, amikor nincs egyetlen mag sem, és a jelenlévő társaknak nincs elegendő adatuk a letöltés befejezéséhez. Ebben az esetben meg kell várni egy mag vagy egy társ megjelenését, amelynek szegmensei hiányoznak a többiből. Használhatja más módon szerzett fájlok másolatait is. Azt a kezet, amelynek hosszú ideig nincs magja, „halottnak” nevezzük.
Az ajándékozás ösztönzésére még egy BitTorrent tokent is készítettek [7] .
A BitTorrent protokoll elve azt jelenti, hogy minden kliens ismeri legalább a szervertől kapott többi kliens IP-címét. A különféle protokollbővítmények használata bizonyos esetekben azt is lehetővé teszi, hogy megtudja a raj többi társának címét. Ezért:
Az anonimitás problémája a Tor [8] használatával megoldható . A Vuze BitTorrent kliens beépített szoftvertámogatással rendelkezik ehhez a névtelen hálózathoz . De ez a módszer nem 100%-ban hatékony [9] .
Másrészt a protokoll nem foglalja magában a becenevek használatát. Nincs csevegés a társak között. Nem lehet listázni a peer fájlokat (más érdekes fájlokat keres). Ezeknek a szolgáltatásoknak a többsége más protokollokban van megvalósítva (például a Direct Connect ).
Egyes felhasználók, különösen a regisztrációt nem igénylő trackereken, a letöltés befejezése után nem támogatják a terjesztést, ami az általános teljesítmény csökkenéséhez vezet, így egyes torrentkövetők figyelembe veszik a letöltött/ajándékozott mennyiséget is, és engedélyt adnak. letölteni az ügyfél által megadott adatok méretétől függően.
Sok kereskedelmi médiatartalom-elosztási protokolltól eltérően a protokollarchitektúra nem biztosít pontos mechanizmust a hálózati pontok közötti forgalom elszámolására és vezérlésére. Csak a letöltött és feltöltött mezők vannak, amelyekben a kliensek az előző bejelentés óta az adatok letöltése/feltöltésekor figyelembe vett bájtok számát adják át a trackernek. Azonban nem az ügyfélen kívül más irányítja őket, könnyen meghamisíthatók. Ehhez a felhasználók statikusan hozzárendelik ezeknek a mezőknek az értékeit a tracker URI -hez, javításokat használnak az ügyfelekhez vagy különálló programokhoz (RatioMaster, GiveMeTorrent, GreedyTorrent stb.), vagy egyszerűen törölhetik a tracker rekordot a kliensről, miután megkapták a hálózati pontok listája a nyomkövetőből. Mindez lehetővé teszi a számos magán- és nyilvános nyomkövető adminisztrációja által létrehozott mesterséges korlátozások megkerülését.
A második verzió BitTorrent protokollján 2008 óta folyik a munka. A protokoll eltávolodott az SHA-1 algoritmus használatától, amelynek problémái vannak az ütközések kiválasztásával, az SHA2-256 javára. Az SHA2-256 mind az adatblokkok integritásának vezérlésére, mind az indexek bejegyzéseinél (info-szótár) használatos, ami megszakítja a DHT-vel és a nyomkövetőkkel való kompatibilitást. Új „urn:btmh:” előtagot javasoltak az SHA2-256 hash-ekkel rendelkező torrentekhez mutató mágneses hivatkozásokhoz (SHA-1 és hibrid torrenteknél az „urn:btih:” használatos).
Mivel a hash függvény változása megszakítja a protokoll-kompatibilitást (20 bájt helyett 32 bájtos hash mező), a BitTorrent v2 specifikáció fejlesztése eredetileg nem volt visszafelé kompatibilis, és egyéb jelentős változtatásokat is végrehajtottak, mint például a Merkle hash használata. fát az indexekben a torrent fájlok méretének csökkentése és a letöltött adatok blokkszintű ellenőrzése érdekében.
A BitTorrent v2-ben végrehajtott változtatások másik kiemelt pontja az, hogy minden fájlhoz külön hash fákat rendelnek, és részenként alkalmazzák a fájlok igazítását (anélkül, hogy minden egyes fájl után további kitöltést adnának hozzá), ami kiküszöböli az adatok megkettőzését, ha vannak azonos fájlok, és megkönnyíti az azonosítást. a fájlok különböző forrásai. Továbbfejlesztett torrent könyvtárszerkezet kódolási hatékonyság és hozzáadott optimalizálás a nagyszámú kis fájl kezeléséhez.
A BitTorrent v1 és a BitTorrent v2 együttélésének egyenletesebbé tétele érdekében lehetőség van hibrid torrentfájlok létrehozására, amelyek az SHA-1 hash-ekkel rendelkező struktúrákon kívül SHA2-256-os indexeket is tartalmaznak. Ezek a hibrid torrentek olyan kliensekkel használhatók, amelyek csak a BitTorrent v1 protokollt támogatják. A WebTorrent protokoll támogatására fejlesztés is folyamatban van [10] . Maga az SHA-1-ről való átállás inkompatibilitást okoz a DHT hálózatokban, trackerekben (melynek fix info-hash hossza 20 karakter). A kompatibilitás elvesztése érdekében először ellenőrizheti az SHA-1-et és az SHA-256-ot is, csökkentve a 32 karakteres, a régi BitTorrent v1 protokollal, az SHA-256-tal nem kompatibilis protokollt 20 karakterre [11] .
| BitTorrent fájlcsere protokoll ( kliens programok ) | |
|---|---|
| A szerzők | Személyek Eric Clinker Bram Cohen Navin Vállalatok BitTorrent Inc. Vuse, Inc. |
| Technológia |
|
| Nyomkövetők | |
| Motorok |
|
| Kapcsolódó cikkek | |
| Alapvető TCP / IP protokollok az OSI modell rétegei szerint | |
|---|---|
| Fizikai | |
| csatornázott | |
| hálózat | |
| Szállítás | |
| ülés | |
| Reprezentáció | |
| Alkalmazott | |
| Egyéb alkalmazva | |
| A TCP és UDP portok listája | |