Hur fungerar I2P, varför är det långsamt, och varför använder det inte hela min bandbredd?

Den vanligaste frågan är förmodligen "hur snabbt är I2P?", och ingen verkar gilla svaret - "det beror på". Efter att ha provate I2P är nästa sak dom frågar "kommer det att bli snabbare?", och svaret på det är ett uttryckligt ja.

I2P är ett helt dynamiskt nätverk. Varje klient är känd för andra noder och testar lokalt kända noder för nåbarhet och kapacitet. Endast nåbara och användbara noder sparas till en lokal NetDB (Vanligtvis bara en del av nätverket, runt 500-1000). När I2P bygger tunnlar, väljer den de bästa resurserna från denna pool. Till exempel, för att bygga tunnlar är endast ett litet urval av 20-50 noder tillgängliga. Eftersom den testas varje minut, skiftar poolens använda noder varje minut. Varje I2P-nod känner till olika delar av nätet, det betyder att varje router har olika set av I2P-noder att använda för tunnlar. Även om två routers har samma delmängd av kända noder, kommer testerna för nåbarhet och kapacitet troligen att ge olika resultat, eftersom andra routers kan vara under belastning just när en router testar, men fria om en annan router testar.

Ovan beskriver varför varje I2P-nod använder olika noder för att bygga tunnlar. Eftersom varje I2P-nod har olika fördröjning och bandbredd, har tunnlarna (som byggs via dess noder) olika fördröjning och bandbredd. Och eftersom varje I2P-nod bygger olika tunnlar, så har inte något par av I2P-noder samma tunnelset.

En server/klient är känd som en "destination" och varje destination har åtminstone en ingående och en utgående tunnel. Förvalet är 3 hopp per tunnel. Det blir tillsammans 12 hopp (aka 12 olika I2P-noder) för en komplett tur och retur klient-server-klient.

Varje datapaket sänds genom 6 andra I2Pnoder innan det når servern.

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

och på vägen tillbaka 6 andra I2Pnoder:

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.

För att förbli anonym bör en router inte användas av hela nätverket för att bygga tunnlar. Om en router verkligen är router för ALLA I2P-noder, så kommer den även att bli en mycket påtaglig centralpunkt för krascher, liksom en centralpunkt för att samla IP och data från klienter. Detta är inte bra. I2P försöker sprida lasten över många olika I2P-noder av just det här skälet.

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.

Prestandaförbättringar

For possible future performance improvements see Future Performance Improvements.

För tidigare prestandaförbättringar se Prestanda Historiken.