I2Pはどのように動作するのか、なぜ遅いのか、そしてなぜ私の全帯域幅を使わないのか？

恐らく最も頻繁に尋ねられることの一つは、「I2Pはどのくらい速いですか？」、 と、尋ねられることが多いのですが、誰もその答え―「時と場合による」―が好きではないようです。I2Pを試した後、次に尋ねられることは「速くなるのか？」で、答えは最も強く主張して はい 。

I2Pは完全に動的なネットワークです。各クライアントは他のノードに知られており、ローカルの既知のノードに到達可能性と容量をテストします。 到達可能で容量のあるノードのみがローカルのNetDB（これは一般的にネットワークの一部に過ぎず、約500-1000です）に保存されます。 I2Pがトンネルを構築したとき、プールから最適のリソースを選択します。例えば、20-50ノードの小さなサブセットしか、トンネルの構築に利用できません。 なぜなら、テストは毎分行われるため、使用されるノードのプールは毎分変化するからです。 各I2Pノードはネットの異なる部分を知っているので、各ルーターはトンネルに使用するI2Pノードの組み合わせが異なることを意味します。 ２つのルーターが既知のノードの同じサブセットを持っている場合でも、到達可能性と容量のテストは他のルーターが１つのルーターのテストと同じように負荷を受けている可能性がありますが、2 番目のルーターのテストの場合はフリーになる可能性があるので、結果はおそらく異なります。

以上、各I2Pノードにトンネルを構築するノードが異なる理由を説明しました。 I2Pノードごとに異なる遅延時間と帯域幅を持つため、（それらのノードを介して構築される）トンネルは異なる遅延時間と帯域幅の値を持つことになります。 また、すべてのI2Pノードには異なるトンネルが構築されているため、2つのI2Pノードが同じトンネルの組み合わせを持つことはありません。

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.

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.

In summary, I2P is very complex and there is no easy way to pinpoint why your node is not used. If your node is reachable and has a bandwidth setting of >128 kbyte/sec shared and is reachable 24/7, it should be used after some time for participating traffic. If it is down in between, the testing of your I2P node done by other nodes will tell them: you are not reachable. This blocks your node for at least 24h on other nodes. So, the other nodes which tested you as down will not use your node for 24h for building tunnels. This is why your traffic will be lower after a restart/shutdown for a minimum of 24h.

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.

パフォーマンスの改善

今後のパフォーマンス向上の可能性については、以下を参照してください 今後のパフォーマンス向上。

For past performance improvements see the Performance History.