Comment est-ce que I2P fonctionne, pourquoi est-il lent, et pourquoi n'utilise-t-il pas complètement ma bande passante ?

Probablement qu'une de choses la plus fréquemment demandée par les gens est "à quelle vitesse est I2P ?", et aucun ne semble aimer la réponse - "cela dépend". Après avoir essayé I2P, la chose suivante qu'ils demandent est "deviendra-t-il plus rapide ?", et la réponse à cela est plus emphatique oui.

I2P est un réseau complètement dynamique. Chaque client est connu par les autres noeuds et teste des noeuds connus localement pour leur accessibilité et leur capacité. Seuls des noeuds accessibles et capables sont sauvegardés dans la NetDB (base de données réseau) locale (ceci est généralement seulement une portion du réseau, autour de 500-1000). Quand I2P construit des tunnels, il sélectionne la meilleure ressource depuis ce bassin. Par exemple, un petit sous-ensemble de 20-50 noeuds est seulement disponible pour construire des tunnels avec. Parce que le test se produit chaque minute, le bassin de noeuds utilisés change chaque minute. Chaque noeud I2P connaît une partie différente du réseau, cela signifiant que chaque routeur a un ensemble différent de noeuds I2P pouvant être utilisé pour des tunnels. Même si deux routeurs ont le même sous-ensemble de noeuds connus, les tests d'accessibilité et de capacité montreront probablement des résultats différents, parce que les autres routeurs pourraient être chargés pendant qu'un autre routeur teste, mais être libres si le deuxième routeur teste.

Le texte ci-dessus décrit pourquoi chaque noeud I2P a des noeuds différents pour construire des tunnels. Parce que chaque noeud I2P a une latence différente et une largeur de bande passante, des tunnels (qui sont construits via ces noeuds) ont une latence différente et des valeurs différentes de bande passante. Et parce que chaque noeud I2P a différents tunnels construits, aucun de deux noeud I2P n'a les mêmes ensembles de tunnels.

Un serveur/client est connu comme une "destination" et chaque destination a au moins un tunnel arrivant et un en partance. Par défaut il y a 3 étapes par tunnel. Ceci s'élève à 12 étapes (c'est-à-dire 12 noeuds I2P différents) pour un aller-retour complet client-serveur-client.

Chaque paquet de données est envoyé par 6 autres noeuds I2P jusqu'à ce qu'il atteigne le serveur :

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

et au retour 6 noeuds I2P différents :

server - hopb1 - hopb2 - hopb3 - hopc1 - hopc2 - hopc3 - client

Comme la plupart du trafic sur I2P (www, torrent, ...) a besoin de paquets ack jusqu'à ce que de nouvelles données soient envoyées, il doit attendre jusqu'à ce qu'un paquet ack revienne du serveur. Au final : envoyer des données, attendre ack, envoyer plus de données, attendre ack, ... Comme le RTT (RoundTripTime) s'additionne de la latence de chaque noeud individuel I2P et chaque connexion de cet aller-retour, cela prend d'habitude 1-3 secondes jusqu'à ce qu'un paquet ack revienne au client. Avec quelques composants de TCP et du transport d'I2P, un paquet de données a une taille limitée et ne peut pas être aussi grand que nous le voudrions. Ensemble, ces conditions mettent une limite de bande passante maximum par tunnel de 20-50 Ko/sec. Mais si SEULEMENT UNE étape dans le tunnel a une bande passante de seulement 5 Ko/sec à dépenser, le tunnel entier est limité à 5 Ko/sec, indépendamment de la latence et d'autres limitations.

En raison du chiffrement utilisé et autres configurations dans I2P (comment les tunnels sont construits, latence, ...) c'est assez coûteux en temps CPU de construire un tunnel. C'est pourquoi il est seulement permis à une destination d'avoir un max de tunnels de transport de données de : 6 ENTRANTS et 6 SORTANTS. Avec un max de 50 Ko/sec par tunnel, une destination pourrait utiliser grossièrement 300 Ko/sec de trafic combiné (en réalité cela pourrait être davantage si des tunnels plus courts étaient utilisés avec un anonymat disponible bas ou nul). Les tunnels utilisés sont renoncés - mis au rebut - toutes les 10 minutes et de nouveaux sont créés. Ce changement de tunnels (et parfois des clients qui se ferment durement en raison de l'utilisation de l'"arrêt immédiat" ou des situations où il y a une perte d'alimentation électrique) fait parfois se produire des cassures de tunnels et de connexions, comme vu sur le réseau IRC2P dans perte de connexion (échéance de ping) ou durant utilisation de eepget.

Avec un ensemble limité de destinations et un ensemble limité de tunnels par destination, un noeud I2P utilise seulement un ensemble limité de tunnels à travers d'autres noeuds I2P. Par exemple, si un noeud I2P est "hop1" dans le petit exemple ci-dessus, nous voyons seulement 1 tunnel participant provenant du client. Si nous résumons le réseau I2P entier, seul un nombre plutôt limité de tunnels participants pourrait être construit avec une quantité limitée de bande passante tous ensemble. Si on distribue ces nombres limités à travers le numéro de noeuds I2P, il y a seulement une fraction de bande passante/capacité disponible disponible pour utilisation.

Pour garder l'anonymat un routeur ne devrait pas être utilisé par l'ensemble du réseau pour la construction de tunnels. Si un routeur agit comme un routeur de tunnel pour tous les nœuds de I2P, il devient un véritable point central de défaillance, ainsi qu'un point central pour récolter des adresses IP et des données des clients. Ce n'est pas bon. I2P tente de répartir la charge sur un grand nombre de nœuds I2P à cause de cette raison.

Un autre point est le réseau complètement maillé. Chaque connexion saut-à-saut utilise une connexion TCP ou UDP sur les nœuds I2P. Avec 1000 connexions, on voit 1000 connexions TCP. C'est beaucoup et certains routeurs (DSL, câble, ...) domestique ou de petit bureau permettent seulement un petit nombre de connexions (ou deviennent simplement fous si vous utilisez plus de X connexions.) I2P essaie de limiter le nombre de ces connexions pour être en dessous de 1500 par UDP et par type TCP. Ce qui limite la quantité de trafic acheminé à travers votre nœud I2P aussi.

En résumé, I2P est très complexe et il n'y a aucune façon facile de définir exactement pourquoi votre noeud n'est pas utilisé. Si votre noeud est accessible et a un réglage de bande passante partagée > à 128 Ko/secondes et est accessible 24/7, il devrait être utilisé après quelque temps pour le trafic de participation. Si il est coupé (down) entre temps, le test de votre noeud I2P fait par d'autres noeuds le leur dira : vous n'êtes pas accessible. Cela bloque votre noeud sur d'autres noeuds pour au moins 24h. Ainsi, les autres noeuds qui vous ont testé n'utiliseront pas votre noeud pour construire des tunnels durant 24h. C'est pourquoi votre trafic sera inférieur après une rédémarrage/arrêt durant un minimum de 24h.

Aussi : les autres noeuds I2P doivent connaître votre routeur I2P pour tester son accessibilité et sa capacité. Cela prend du temps pour que les autres noeuds prennent connaissance de votre noeud. Cela sera plus rapide si vous utilisez I2P et construisez davantage de tunnels, par exemple utilisez un torrent ou www pendant quelque temps.

Améliorations de performance

Pour de possible futures améliorations de performance voir Améliorations de performance futures.

Pour les améliorations de performance passées voir l'historique de performance.