How does I2P work, why is it slow, and why does it not use my full bandwidth?

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.

Each data package is sent through 6 other I2P nodes until it reaches the server:

client - hop1 - hop2 - hop3 - hopa1 - hopa2 - hopa3 - server

and on way back 6 different I2P nodes:

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.

由于每个目的地的隧道有限，一个I2P节点只在其他I2P节点中使用有限的隧道。 例如，在上面的小例子中，如果一个I2P节点是 "hop1"，我们只看到1个源自客户端的参与隧道。 如果我们把整个I2P网络加起来，在有限的带宽下，只能建立数量相当有限的参与隧道。 如果把这些有限的数量分布在I2P节点的数量上，就只有一小部分可用的带宽/容量可供使用。

为了保持匿名性，一个路由器不应该被整个网络用来建立隧道。 如果一个路由器确实充当了所有I2P节点的隧道路由器，它就会成为一个故障中心点，也是一个从那里获取IP和数据的中心点。这不是好事。 由于这个原因，I2P试图将负载分散到许多I2P节点。

另一点是全网状网络。每一跳连接都利用了I2P节点上的一个TCP或UDP连接。一般默认为 1000个TCP连接。 这是一个相当大的数字，一些家庭和小型办公室的路由器（DSL、电缆......）只允许少量的连接（如果你使用超过X个连接，就会受限）。 I2P 试图将这些连接限制在每个 UDP 和每个 TCP 类型的 1500 以下。 这也限制了在您的I2P节点上传输的流量。

总之，I2P非常复杂，没有简单的方法来确定为什么您的节点没有被使用。 如果您的节点是可达的，并且共享带宽设置为>128 kbyte/sec，并且24/7可达，那么经过一段时间的参与流量，它应该被使用。 如果它在这期间停机，其他节点对您的I2P节点所做的测试会告诉他们：您是不可达的。这将使您的节点至少被禁用 24小时。因此，其他节点在测试您的节点故障后，在24小时内不会使用您的节点来建立隧道。这就是为什么你的流量会 在重启/关闭至少24小时后，流量会降低。

另外：要时间来了解您的节点，以测试它的可达性和容量。 如果您使用I2P并建立更多的隧道，例如使用torrent或www一段时间，就会更快。

性能提升

关于未来可能的性能改进，见 未来的性能改进。

For past performance improvements see the Performance History.