Wie funktioniert I2P, warum ist es langsam und warum nutzt es nicht meine gesamte Bandbreite?
Probably one of the most frequent things people ask is "how fast is I2P?", and no one seems to like the answer - "it depends". After trying out I2P, the next thing they ask is "will it get faster?", and the answer to that is a most emphatic yes.
I2P is a full dynamic network. Each client is known to other nodes and tests local known nodes for reachability and capacity. Only reachable and capable nodes are saved to a local NetDB (This is generally only a portion of the network, around 500-1000). When I2P builds tunnels, it selects the best resource from this pool. For example, a small subset of 20-50 nodes are only available to build tunnels with. Because testing happens every minute, the pool of used nodes changes every minute. Each I2P node knows a different part of the net, meaning that each router has a different set of I2P nodes to be used for tunnels. Even if two routers have the same subset of known nodes, the tests for reachability and capacity will likely show different results, as the other routers could be under load just as one router tests, but be free if the second router tests.
The above describes why each I2P node has different nodes to build tunnels. Because every I2P node has a different latency and bandwith, tunnels (which are built via those nodes) have different latency and bandwidth values. And because every I2P node has different tunnels built, no two I2P nodes have the same tunnel sets.
A server/client is known as a "destination" and each destination has at least one inbound and one outbound tunnel. The default is 3 hops per tunnel. This adds up to 12 hops (aka 12 different I2P nodes) for a full roundtrip client-server-client.
Jedes Datenpaket wird durch 6 andere I2P Knoten gesendet bevor es den Server erreicht:
client - hop1 - hop2 - hop3 - hopa1 - hopa2 - hopa3 - server
und auf dem Weg zurück durch 6 andere I2P Knoten:
server - hopb1 - hopb2 - hopb3 - hopc1 - hopc2 - hopc3 - client
As most traffic on I2P (www, torrent,...) needs ack packages until new data is sent, it needs to wait until a ack package returns from the server. In the end: send data, wait for ack, send more data, wait for ack,.. As the RTT (RoundTripTime) adds up from the latency of each individual I2P node and each connection on this roundtrip, it takes usually 1-3 seconds until a ack package comes back to the client. With some internals of TCP and I2P transport, a data package has a limited size and cannot be as large as we want it to be. Together these conditions set a limit of max bandwidth per tunnel of 20-50 kbyte/sec. But if ONLY ONE hop in the tunnel has only 5 kb/sec bandwidth to spend, the whole tunnel is limited to 5 kb/sec, independent of the latency and other limitations.
Due to encryption used and other setups in I2P (howto built up tunnels, latency, ...) it is quite expensive in CPU time to build a tunnel. This is why a destination is only allowed to have a max of 6 IN and 6 OUT tunnels to transport data. With a max of 50 kb/sec per tunnel, a destination could use roughly 300 kb/sec traffic combined ( in reality it could be more if shorter tunnels are used with low or no anonymity available). Used tunnels are discarded every 10 minutes and new ones are built up. This change of tunnels (and sometimes clients that shutdown hard due to usage of "shut down at once" or situations where there is power loss) does sometimes break tunnels and connections, as seen on the IRC2P Network in loss of connection (ping timeout) or on when using eepget.
With a limited set of destinations and a limited set of tunnels per destination, one I2P node only uses a limited set of tunnels across other I2P nodes. For example, if an I2P node is "hop1" in the small example above, we only see 1 participating tunnel originating from the client. If we sum up the whole I2P network, only a rather limited number of participating tunnels could be built with a limited amount of bandwidth all together. If one distributes these limited numbers across the number of I2P nodes, there is only a fraction of available bandwidth/capacity available for use.
To remain anonymous one router should not be used by the whole network for building tunnels. If one router does act as a tunnel router for ALL I2P nodes, it becomes a very real central point of failure as well as a central point to grab IPs and data from the clients. This is not good. I2P attempts to spread the load across a lot of I2P nodes because of this reason.
Another point is the full mesh network. Each connection hop-hop utilizes one TCP or UDP connection on the I2P nodes. With 1000 connections, one sees 1000 TCP connections. That is quite a lot and some home and small office routers (DSL, cable,..) only allow a small number of connections (or just go mad if you use more than X connections). I2P tries to limit these connections to be under 1500 per UDP and per TCP type. This limits the amount of traffic routed across your I2P node as well.
Zusammenfassend gesagt, ist I2P sehr komplex und es gibt keinen einfachen Weg festzustellen, warum ihr Knotenpunkt nicht verwendet wird. Wenn Ihr Knotenpunkt erreichbar ist und eine Bandbreite von >128 kbyte/sec verfügbar ist und 24/7 errichbar ist, sollte er nach einer Zeit am Traffic beteiligt werden. Falls er zwischendurch offline geht, wird ein Test ihres I2P Knotens durch andere Knoten denen sagen: sie sind nicht erreichbar. Dies blockiert Ihren Knoten für mindestens 24 Std für andere Knoten. Daher werden die anderen Knoten, die Ihren als down gestestet haben, ihren Knoten für 24 Std nicht mehr zum bauen von Tunneln verwenden. Deshalb wird Ihr Traffic nach dem Neustart/Herunterfahren für mindestens 24 Std niedriger sein als normal.
Also: other I2P nodes needs to know your I2P router to test it for reachability and capacity. It takes time for other nodes to get known to your node. It will be faster if you use I2P and build more tunnels, e.g. use a torrent or www for some time.
Für mögliche zukünftige Verbesserungen in der Performance, schauen sie unter Zukünftige Performance Verbesserungen nach.
Für bisherige Leistungsverbesserungen, schauen Sie in der Performance Historie nach.