Die I2P Performance

Infos und Dskussionen in deutscher Sprache zu I2P
Post Reply
User avatar
lgillis
Posts: 26
Joined: 20 Oct 2018 12:52
Contact:

Die I2P Performance

Post by lgillis »

Gillis’ Übersetzung aus dem Englischen vom 15. Mai 2018.

Wie funktioniert I2P, warum ist es langsam und warum nutzt es nicht meine volle Bandbreite?

Eine der häufigsten Fragen ist wohl „wie schnell ist I2P“, und niemand scheint die Antwort zu mögen: „Es kommt darauf an“. Nachdem Sie I2P ausprobiert haben, fragen Sie als nächstes: „Wird es schneller“, und die Antwort darauf ist ein klares Ja.

I2P ist ein vollständig dynamisches Netzwerk. Jeder Client ist anderen Knoten bekannt und testet lokal bekannte Knoten auf Erreichbarkeit und Kapazität. Nur erreichbare und fähige Knoten werden in einer lokalen NetDB gespeichert (diese enthält ist in der Regel nur ein Teil des Netzwerks, ca. 500-1000 I2P-Knoten). Wenn I2P Tunnel erstellt, wählt es die beste Ressource aus diesem Pool aus. Zum Beispiel ist eine kleine Teilmenge von 20-50 Knoten nur für den Aufbau von Tunneln verfügbar. Da das Testen jede Minute stattfindet, ändert sich der Pool der verwendeten Knoten jede Minute. Jeder I2P-Knoten kennt einen anderen Teil des Netzes, was bedeutet, dass jeder Router einen anderen Satz von I2P-Knoten hat, die für Tunnel verwendet werden sollen.

Selbst wenn zwei Router die gleiche Untermenge an bekannten Knoten haben, werden die Tests auf Erreichbarkeit und Kapazität wahrscheinlich unterschiedliche Ergebnisse zeigen, da die anderen Router unter Last stehen könnten, wenn der erste Router testet, aber frei sein, wenn der zweite Router testet.

Das oben Gesagte beschreibt, warum jeder I2P-Knoten verschiedene Endpunkte kennt, um Tunnel zu bilden. Da jeder I2P-Knoten eine andere Latenz und Bandbreite hat, haben Tunnel (die über diese Endpunkte aufgebaut werden) unterschiedliche Latenz- und Bandbreitenwerte. Und weil jeder I2P-Knoten unterschiedliche Tunnel hat, haben keine zwei I2P-Knoten die gleichen Tunnelsätze.

Das Rendezvous aus Server und Klient bildet die s. g. Destination und jede Destination hat zumindest einen ankommenden (inbound) und einen abgehenden (outbound) Tunnel. Als Grundeinstellung wurden von der Projektleitung für jede Anwendung drei Hops pro Tunnel festgelegt, mit Ausnahme der Erkundungstunnel, die zwei Hops verwenden. Diese drei Hops-Einstellung summiert sich auf zwölf Hops (also zwölf verschiedene I2P-Knoten) für einen vollen Rundgang von Klient zu Server und zurück. Jedes Datenpaket wird also auf dem Hinweg durch sechs andere I2P-Klienten geleitet, bevor es den Server erreicht:
        Client - hop1 - hop2 - hop3 -|- hopa1 - hopa2 - hopa3 - Server
und auf dem Rückweg wieder durch sechs andere I2P-Klienten:
        Server - hopb1 - hopb2 - hopb3 -|- hopc1 - hopc2 - hopc3 - Client
(Das Symbol -|- kennzeichnet das Zusammentreffen der Tunnel und verdeutlicht den nicht vorhandenen Einfluss auf die eingesetzten Hops der jeweiligen Gegenstelle.)

Da der meiste Verkehr über I2P (WWW, BitTorrent usw.) ACK-Pakete benötigt, bis neue Daten gesendet werden, muss er warten, bis ein ACK-Paket vom Server zurückkehrt. Also: Daten senden, auf ACK warten, weitere Daten senden, auf ACK warten und so weiter. Da sich die Paketumlaufzeit (Round-Trip-Time, RTT) aus der Latenz jedes einzelnen I2P-Knotens und jeder Verbindung auf diesem Rundgang addiert, dauert es in der Regel 1-3 Sekunden, bis ein ACK-Paket zum Client zurückkommt. Bei einigen internen TCP- und I2P-Transporten hat ein Datenpaket eine begrenzte Größe und kann nicht so groß sein, wie das Projekt es gerne hätte. Zusammen genommen legen diese Bedingungen eine maximale Bandbreite pro Tunnel von 20-50 kB/s fest. Aber wenn bereits ein einziger Hop im Tunnel nur 5 kB/s Bandbreite zur Verfügung stellt, ist der gesamte Tunnel auf 5 kB/s begrenzt, unabhängig von der Latenzzeit und anderen Einschränkungen. Zur Veranschaulichung ein konstruiertes drei-Hop-Szenario, in dem der Server 50 kB/s an den Client senden könnte (in kB/s):
        Server 50 - 25 - 30 - 5 -|- 30 - 45 - 20 - Client empfängt max. 5

Aufgrund der verwendeten Verschlüsselung und anderer Einstellungen in I2P (wie Tunnel aufgebaut werden sollen, die Latenz usw.) ist es nach CPU-Zeit berechnet ziemlich teuer, einen Tunnel zu bilden. Deshalb darf eine Destination nur maximal sechs eingehende und sechs ausgehende Tunnel haben, um Daten zu transportieren. Mit einem Maximum von 50 kB/s pro Tunnel könnte eine Destination auf insgesamt etwa 300 kB/s Datenverkehr zurückgreifen (in der Praxis könnte es mehr sein, wenn kürzere Tunnel mit geringer oder keiner Anonymität verwendet werden). Gebrauchte Tunnel werden alle zehn Minuten verworfen und neue werden zusammengestellt. Dieser Wechsel von Tunneln (und manchmal auch von Clients, die aufgrund der Verwendung von „Router sofort abschalten“ oder von Situationen, in denen es zu Stromausfällen kommt), führt manchmal zum Abbruch von Tunneln und Verbindungen, zu beobachten in IRC2P-Netzwerk bei Verbindungsabbruch (Ping-Timeout) oder bei der Verwendung von Eepget.

Bei einer begrenzten Anzahl von Destinations und einer begrenzten Anzahl von Tunneln pro Destination verwendet ein I2P-Knoten auch nur eine begrenzte Anzahl von Tunneln über andere I2P-Knoten hinweg. Wenn beispielsweise ein I2P-Knoten aus dem kleinen Beispiel oben „Hop1“ ist, sehen wir nur einen teilnehmenden Tunnel, der vom Client stammt. Fasst man das gesamte I2P-Netzwerk zusammen, kann man nur eine recht begrenzte Anzahl von teilnehmenden Tunneln mit einer begrenzten Bandbreite aufbauen. Verteilt man diese begrenzten Zahlen auf die Anzahl der I2P-Knoten, steht nur ein Bruchteil der verfügbaren Bandbreite und Kapazität zur Verfügung.

Um anonym zu bleiben, sollte ein einzelner Router nicht vom gesamten Netzwerk zum Bau von Tunneln verwendet werden. Wenn ein Router als Tunnelrouter für sämtliche I2P-Knoten fungiert, wird er zu einem sehr reellen zentralen Fehlerpunkt sowie zu einer zentralen Anlaufstelle, um IP-Adressen und Daten von den Clients zu holen. Das ist nicht gut. I2P versucht aus diesem Grund, die Last auf viele I2P-Knoten zu verteilen.

Ein weiterer Punkt ist die ineinander verwobene Netzstruktur. Jede von Hop zu Hop-Verbindung nutzt eine TCP- oder UDP-Verbindung auf den I2P-Knoten. Bei 1000 Verbindungen entstehen 1000 TCP-Verbindungen. Das ist ziemlich viel und einige Heim- und kleine Büro-Router (DSL, Kabel usw.) erlauben nur eine kleine Anzahl von Verbindungen (oder werden einfach überfordert, wenn Sie mehr als X Verbindungen verwenden). I2P versucht, diese Verbindungen auf unter 1500 pro UDP und pro TCP-Typ zu begrenzen (3000 Verbindungen insgesamt). Dadurch wird auch die Menge des über Ihren I2P-Knoten gerouteten Datenverkehrs begrenzt.

Zusammengefasst ist I2P sehr komplex und es gibt keinen einfachen Weg, um herauszufinden, warum Ihr Knoten nicht verwendet wird. Wenn Ihr Knoten erreichbar ist und eine Bandbreiteneinstellung von über 128 kB/s hat und 24/7 erreichbar ist, sollte er nach einiger Zeit für den teilnehmenden Verkehr verwendet werden. Wenn es irgendwo dazwischen liegt, wird der Test Ihres I2P-Knotens durch andere Knoten zeigen: dieser ist nicht nutzbar. Dieses Testergebnis blockiert Ihren Knoten für mindestens 24 Stunden für andere Knoten. Die anderen Knoten, die Ihren als „ausgefallen“ getestet haben, werden Ihren Knoten also 24 Stunden lang nicht für den Bau von Tunneln verwenden. Aus diesem Grund wird Ihr Traffic nach einem Neustart oder Stillstand für mindestens 24 Stunden geringer sein.

Dazu kommt, andere I2P-Knoten müssen Ihren I2P-Router kennen, um ihn auf Erreichbarkeit und Kapazität testen zu können. Es braucht eine gewisse Zeit, bis andere Knoten den Ihren kennenlernen. Von daher wird es schneller gehen, wenn Sie I2P aktiv verwenden und mehr Tunnel aufbauen, z. B. einige Zeit lang einen Torrent laufen lassen oder Eepsites aufrufen.

Leistungssteigerungen

Für mögliche zukünftige Performance-Verbesserungen siehe Future Performance Improvements. Bereits implementierte Performance-Verbesserungen finden Sie in der Performance-Historie.
Post Reply