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å routrar 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

Eftersom den mesta trafiken i I2P (www, torrent,...) behöver ack-paket tills ny data har blivit sänd, behöver den vänta tills ett ackpaket kommer tillbaka från serven. Till slut: skicka data, vänta på ack, skicka mer data, vänta på ack..... Allt eftersom RTT (RoundTripTime) ackumuleras från fördröjningen av varje individuell I2P-nod och varje anslutning på den här turen, tar det vanligtvis 1-3 sekunder tills ett ackpaket kommer tillbaka till klienten. På grund av en del interna restriktioner i TCP och I2P-transport, kan ett datapaket på grund av begränsad storlek inte vara så stor som vi skulle vilja. Tillsammans sätter dessa restriktioner en gräns för bandbredden per tunnel till 20-50 kbyte/sek. Men om BARA ETT hopp i tunneln endast har 5 kb/sek bandbredd att spendera, begränsas hela tunneln till 5 kb/sek, oberoende av fördröjning och andra begränsningar.

Beroende på den kryptering som används och andra inställningar i I2P (hur tunnlar byggs, fördröjning....) så är det kostsamt i CPU-tid att bygga en tunnel. Det är därför en destination endast tillåts ha max 6 tunnlar IN och 6 UT som transporterar data. Med ett maximum av 50 kb/sek per tunnel, kan en destination använda ca 300kb/sek av kombinerad trafik (i verkligheten kan det vara mer om kortare tunnlar med låg eller ingen anonymitet används) Använda tunnlar kastas bort var 10 minut och nya byggs upp i deras ställe. Detta byte av tunnlar (och ibland klienter som stänger ner abrupt eller situationer med strömförlust) bryter ibland tunnlar och anslutningar, som man kan se på IRC2P i form av förlorad kontakt (ping timeout) eller när man använder eepget.

Med ett begränsat set av destinationer och ett begränsat set av tunnlar per destination, använder en I2P-nod endast ett begränsat set tunnlar över andra I2P-noder. Om, t ex, en I2P-nod är "hopp1" i det lilla exemplet ovan, så ser vi endast 1 deltagande tunnel som utgår från klienten. Om vi summerar hela I2P-nätverket, så byggs bara ett ganska begränsat antal tunnlar med en begränsad bandbredd allt som allt. Om man distribuerar dessa begränsade mängder över antalet I2P-noder, så finns det bara en liten del av den befintliga bandbredden tillgänglig.

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.

En annan punkt är det kompletta meshnätverket. Varje anslutning hip-hopanvänder en TCP eller UDP-anslutning på I2P-noden. Med 1000 anslutningar ser man 1000 TCP-anslutningar. Det är en hel del och vissa hem- och 'small-office'-routrar (DSL, kabel,...) tillåter bara ett litet antal (eller blir tokiga om du använder mer än X anslutningar). I2P försöker begränsa dessa anslutningar till under 1500 per UDP och per TCP-typ. Detta begränsar även trafikmängden som routas över din I2P.

Sammanfattningsvis är I2P väldigt komplext och det finns inget enkelt sätt att precisera varför din nod inte används. Om din nod är nåbar och har en bandbreddsinställning av mer än 128 kbyte/s delat och är nåbar 24/7, skulle den efter någon tid användas för deltagande trafik. Om den är nere emellanåt så kommer testandet av din I2P-nod av andra noder att tala om för dem att du inte är nåbar. Detta blockerar din nod under minst 24 timmar för andra noder. Så de andra noderna som testade dig när du var nere kommer inte att använda din nod på 24 timmar för att bygga tunnlar. Detta är skälet till att din trafik kommer att vara lägre i minst 24 timmar efter en omstart/nedstängning.

Dessutom: andra I2P-noder behöver känna till din I2P-router för att testa för nåbarhet och kapacitet. Det tar tid för andra noder att get sig till känna för din nod. Det kommer att gå snabbare om du använder I2P och bygger mer tunnlar, t ex använda torrent eller www under en tid.

Prestandaförbättringar

För möjliga framtida prestandaförbättringar see Framtida Prestandaförbättringar

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