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 nœuds et teste l’accessibilité et la capacité des nœuds locaux connus. Seuls les nœuds accessibles et aptes sont enregistrés dans une base de données NetDB locale (généralement une portion du réseau seulement, environ 500 à 1 000). Quand I2P construit des tunnels, la meilleure ressource est sélectionnée de cette réserve. Par exemple, un petit sous-ensemble de 20 à 50 nœuds n’est disponible que pour construire des tunnels. Avec des tests toutes les minutes, la réserve de nœuds utilisés change toutes les minutes. Chaque nœud d’I2P connaît une partie différente du réseau, ce qui signifie que chaque routeur connaît un ensemble différent de nœuds d’I2P pouvant être utilisés pour les tunnels. Même si deux routeurs possédaient le même sous-ensemble de nœuds connus, les tests d’accessibilité et de capacité donneraient probablement des résultats différents, car les autres routeurs pourraient subir une charge lors du test d’un routeur, mais être libres lors du test du deuxième routeur.

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 ou client est connu comme une « destination » et chaque destination a au moins un tunnel entrant et un tunnel sortant. Il y a par défaut 3 sauts par tunnel. Cela s’élève à 12 sauts (c.-à-d. 12 nœuds 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 d’autres configurations dans I2P (comment construire des tunnels, la latence...) la construction d’un tunnel est gourmande en temps UCT. C’est pourquoi une destination n’est autorisée à avoir qu’un maximum de 6 tunnels entrants et 6 sortants pour transporter les données. Avec un maximum de 50 kb/s par tunnel, une destination pourrait utiliser à peu près 300 kb/s de trafic combiné (en réalité peut-être plus si des tunnels plus courts sont utilisés avec un anonymat disponible faible ou nul). Les tunnels utilisés sont éliminés toutes les 10 minutes et d’autres sont construits. Ce changement de tunnels (et parfois des clients qui se ferment à froid, car ils utilisent la « fermeture immédiate » ou des situations de panne de courant) met parfois fin aux tunnels et aux connexions, comme observé sur le réseau IRC2P en perte de connexion (dépassement du temps de ping) ou lors de l’utilisation d’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 rester anonyme, un routeur ne devrait pas être utilisé par l’ensemble du réseau pour la construction de tunnels. Si un routeur agit comme routeur de tunnels pour tous les nœuds d’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 souhaitable. I2P tente de répartir la charge sur un grand nombre de nœuds d’I2P pour 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 d’identifier exactement pourquoi votre nœud n’est pas utilisé. Si votre nœud est accessible, a un paramètre de bande passante partagée > à 128 ko/s, est accessible jour et nuit, il devrait être utilisé après quelque temps pour le trafic participant. S’il est hors service entre temps, le test de votre nœud I2P par d’autres nœuds leur indiquera que vous n’êtes pas accessible. Pour les autres nœuds, votre nœud sera bloqué pour au moins 24 h. Ainsi, les autres nœuds qui vous ont testé comme étant hors service n’utiliseront pas votre nœud pour construire des tunnels durant 24 h. C’est pourquoi votre trafic sera inférieur après un redémarrage, une fermeture pendant au moins 24 h.

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.