Bittorrent

Aus Knowledgebase
Version vom 13. Dezember 2013, 22:50 Uhr von PoC (Diskussion | Beiträge) (Es gibt keinen Client, da P2P!)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen

Bittorrent ist ein von Bram Cohen erdachtes Peer-to-Peer-Netzwerk für die Verteilung von großen Datenmengen. Gleichzeitig heißt die Referenzimplementation der Software ebenfalls Bittorrent. Bittorrent-Implementationen existieren für viele Betriebssysteme.

Komponenten

Ein minimales Bittorrent-Netzwerk (genannt Schwarm) besteht aus

  • einem Verteiler (Seeder oder Seeding-Peer); er hat die komplette Wunschdatei,
  • einem Empfänger (Leecher oder Leeching-Peer),
  • einem Tracker, einem Webserver sehr ähnlich, zur Vermittlung von Seeder und Leecher,
  • einem Verteilmechanismus für die Metadatei.

Funktionsweise

Zur Verteilung einer großen Datei (z. B. debian.iso) wird aus dieser eine Metadatei (meist: debian.iso.torrent) erzeugt. Das Erzeugen dieser Metadatei, zwischen einigen zehn und einigen 100 Kilobytes groß, beherrscht üblicherweise die Bittorrent-Software. Dieses Erstellen ist von der Verteilfunktion völlig losgelöst.
In dieser Metadatei, auch Torrent genannt, werden verschiedene Informationen hinterlegt, unter anderem

  • der gewünschte Dateiname,
  • ein Hashwert über die gesamte Datei zur dateinamenslosen Identifikation,
  • die URL des zuständigen Trackers,
  • Prüfsummen und weitere Informationen über die einzelnen Chunks (Teile) der Datei,
  • sowie Flags (z. B. privat, usw.).

Der Seeding-Peer verknüpft die vorhandene Datei mit der Metadatei mittels seiner Bittorrent-Software. Diese erkennt anhand der Prüfsumme, dass die Datei komplett ist und daher nicht geladen werden muss. Sie meldet sich bei dem in der Metadatei hinterlegten Tracker, zuzüglich weiterer Informationen:

  • Den Hashwert der Datei; der Tracker soll ganz bewusst nicht den Dateinamen kennen, weil er als zentrale Komponente doch recht einfach zu kompromittieren wäre,
  • eine Liste der IP-Adressen und Ports, welche diese Metadatei beherbergen,
  • Status der Adresse (Seeder oder Leecher),

Der Leeching-Peer erhält über den oben erwähnten (und nicht näher definierten) Verteilmechanismus die Metadatei. Dieser Verteilmechanismus ist nicht Teil von Bittorrent. Die Metadatei kann über alle möglichen Wege verbreitet werden, üblicherweise über eine, für Webcrawler zugängliche Webseite. Nur derjenige, der diese Metadatei besitzt, kommt an die Originaldaten, sofern mindestens ein Seeding-Peer im Schwarm vorhanden ist.

Der Leeching-Peer verfüttert die Metadatei seiner Bittorrent-Software. Diese kontaktiert den Tracker, wobei der Hashwert mitgeliefert wird und erhält eine Antwort mit den vorhandenen Peeradressen und ihrem Status. Nun kann die Bittorrent-Software des Leechers sich mit dem oder den Seedern verbinden und dort Chunks anfordern. Da viele Peers hinter einem NAT-Router stehen, wäre eine direkte Verbindung in keinem Fall möglich. Daher ist es gerade bei kleinen Schwärmen wichtig, dass über entsprechende Maßnahmen (uPnP, manuelle Konfiguration eines Portforwards, bzw. Firewallanpassungen) die Bittorrent-Software mit ihrem in der Konfiguration hinterlegten Port(s) von extern erreichbar ist.

Ein Leeching-Peer kann von einem weiteren Leeching-Peer kontaktiert werden und Chunks anfordern, die der anfragende Peer noch nicht hat, der Kontaktierte aber wohl. So können sich in einem großen Schwarm auch Proxyverbindungen über Dritte ergeben, weil Peer 1 keinen direkten Kontakt zu Peer 2 aufbauen kann, wohl aber zu Peer 3, der wiederum mit Peer 2 Kontakt aufbauen kann. So fließen die Daten von Peer 2 zu 3, der sie wiederum an 1 weiterleitet.

Diese Parallelität ermöglicht es dem Leecher, trotz ADSL und schmalbandigen Sendebandbreiten der Seeder, annehmbare Ladegeschwindigkeiten zu erreichen, vorausgesetzt genügend Seeder sind zum gleichen Zeitpunkt online. Außerdem wird hierdurch das NAT-Problem gemildert.

In der Regel beherrscht die Bittorrent-Software ein Einschränken der zugeteilten Bandbreite für die Übertragungen, um die eigene Upload-Bandbreite nicht völlig durch Bittorrent-Übertragungen zu belegen.

Privates Netzwerk

Um Daten in einer privaten Umgebung sauber verteilen zu können, sind ein paar Punkte zu beachten. Privat bedeutet, dass der Benutzerkreis für die Daten geschlossen ist.

Die private Umgebung ist recht einfach herstellbar:

  • Die Torrents müssen mit dem Privat-Flag erstellt werden. Das kann nicht jede Implementation.
  • Für zusätzliche Sicherheit gegen Datenlecks darf die Bittorrent-Software weder PEX noch DHT sprechen. Das wird durch das Privat-Flag normalerweise für den jeweiligen Torrent ausgeknipst.

Zusätzliche Schwierigkeiten können durch eine Umgebung mit mehreren Netzwerkschnittstellen entstehen; d. h., die Maschine hat mehrere Netzwerkkarten mit z. B. RFC1918-Adressen und externen, offiziellen Adressen. Dabei ist eine Kommunikation extern wie auch intern (VPN) möglich.

Mögliche Fehlerquellen

Für eine störungsarme Dateiübertragung sind ein paar Punkte zu beachten:

  • Falls ein interessierter Peer von extern nicht erreichbar ist (weil hinter einem NAT-Router), muss ein entsprechender Portforward auf diesem Router konfiguriert werden, damit der Peer auch von extern erreichbar ist. Gerade in kleinen Schwärmen laufen Verbindungsversuche ins Leere und die Dateiverteilung schlägt fehl. Sinnvollerweise wird dazu in der Konfiguration der Bereich der benutzten Ports manuell festgesetzt. Pro aktivem Torrent sollte ein Port verfügbar sein.
  • Bei ADSL-Verbindungen sorgt ein ausgereizter Upstream für deutliche Geschwindigkeitseinbrüche im Downstream. Empfohlen wird, die Bittorrent-Software so zu konfigurieren, dass der vorhandene Upstream maximal zur Hälfte ausgelastet wird. Viele Implementationen erlauben auch eine zeitgesteuerte Bemessung der Geschwindigkeitsrestriktionen.
  • Binden des Ports auf die externe IP-Adresse, sofern er auf Maschine mit mehreren Netzwerkschnittstellen läuft.

Transmission 2.2 und Rtorrent 0.8.6 (Debian Squeeze) sowie Rtorrent 0.7.9 (Debian Lenny) haben sich in einer Praxiskonstellation und einer Nachstellung als inkompatibel erwiesen. Beide melden sich am Tracker ordnungsgemäß an, man sieht auch den jeweilig anderen Peer, eine Übertragung kommt aber nicht zustande. Das Problem ist noch nicht eingehend erforscht.

Weblinks