¿Cómo funciona I2P, por qué es lento, y por qué no utiliza todo el ancho de banda?

Probablemente una de las preguntas más frecuentes es ¿cómo de rápido es I2P?, y parece que a nadie le gusta la respuesta - "depende". Después de probar I2P, la siguiente cosa que preguntan es ¿será más rápido?, y la respuesta a eso es un enfático sí.

I2P es un red totalmente dinámica. Cada cliente es conocido por otros nodos y prueba los nodos conocidos localmente para comprobar su accesibilidad y su capacidad. Sólo los nodos accesibles y capaces son guardados en la NetDB local (Esto normalmente es sólo una parte de la red, sobre 500-1000). Cuando I2P construye túneles selecciona los mejores recursos de esta fuente. Por ejemplo, sólo unos 20-50 nodos están disponibles para construir túneles. Ya que las pruebas se hacen cada minuto la fuente de los nodos usados cambia cada minuto. Cada nodo I2P conoce una parte de la red total, haciendo que cada ruter tenga una lista diferente de nodos I2P para ser usados como túneles. Incluso si dos ruters tienen la misma subred de nodos conocidos las pruebas de accesibilidad y capacidad mostrarán diferentes resultados, ya que cuando un ruter hace las pruebas otros ruters pueden estar bajo carga, pero estar libre cuando es un segundo ruter el que hace las pruebas.

El texto anterior explica porque cada nodo I2P usa diferentes nodos para construir sus túneles. Porque cada nodo I2P tienen una latencia y ancho de banda diferente, los túneles ( que se construyen con estos nodos) tienen valores diferentes de latencia y ancho de banda. Y ya que cada nodo I2P tiene diferentes nodos construidos, no hay dos nodos I2P con la misma configuración de túneles.

Un servidor/cliente se conoce como "destinación" y cada destinación tiene al menos un túnel de entrada y otro de salida. Por defecto son 3 saltos por túnel. Esto suman 12 saltos (osea 12 diferentes nodos I2P) para una ida y vuelta completa cliente-servidor-cliente.

Cada paquete de datos es enviado a través de otros 6 nodos I2P hasta que alcanza el servidor:

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

y de vuelta por 6 nodos I2P diferentes:

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

Como la mayoría del tráfico I2P (www, torrent, ...) necesita paquetes ack hasta que la nueva información es enviada, necesita esperar hasta que un paquete ack regrese del servidor. Al final: envía información, espera por ack, envía mas información, espera por ack... Y ya que el RTT (RoundTripTime) añade latencia por cada nodo individual I2P y por cada conexión de esta ida y vuelta, normalmente tarda de 1-3 segundos hasta que un paquete ack regresa al cliente. Además el funcionamiento interno del transporte de TCP y de I2P hacen que un paquete de información tenga un tamaño limitado y no pueda ser tan grande como desearíamos que fuese. Estas condiciones unidas crean un límite de ancho de banda por túnel de 20-50 kbyte/sec. Pero, si SÓLO un salto del túnel tiene solamente 5 kb/sec de ancho de banda para usar, el túnel completo estará limitado a 5 kb/sec, independientemente de las latencia y otras limitaciones.

Debido al cifrado usado y otras configuraciones de I2P (como se construyen los túneles, latencia, ...) se utiliza bastante tiempo de la CPU para crear un túnel. Esto es por lo que una destinación solo tiene permitido un máximo de 6 túneles de de entrada y 6 de salida para enviar información. Con un máximo de 50 kb/sec por túnel una destinación podría usar aproximadamente 300 kb/sec (en realidad podría ser más si se utilizan túneles más cortos con poco o ningún anonimato). Los túneles usados son eliminados cada 10 minutos y se crean unos nuevos. Estos cambios en los túneles (y a veces los clientes que apagan de golpe usando "apagar inmediatamente" o por caídas de corriente) a veces rompen los túneles y las conexiones, como se puede ver en las pérdidas de conexiones en el IRC2P (ping timeout) o cuando se está usando eepget.

Con un número limitado de destinaciones y un número limitado de túneles por destinación, un nodo I2P sólo utiliza un número limitado de túneles a través de otros nodos de I2P. Por ejemplo, si en el ejemplo de arriba un nodo I2P es "hop1", sólo tendríamos 1 túnel participante originado en el cliente. Si sumamos toda la red I2P, sólo un número limitado de túneles participantes pueden ser construidos con una cantidad limitada de ancho de banda. Si uno distribuye todo ese número limitado entre el número de nodos I2P, sólo hay disponible una fracción del ancho de banca/capacidad disponible para el uso.

Para permanecer anónimos un ruter no debería usarse por toda la red para construir túneles, si un solo ruter funciona como túnel para TODOS los nodos de I2P se convierte en el centro de un problema, así como el punto central para obtener IPs e información de los clientes. Esto no es bueno. I2P intenta repartir la carga a través de muchos nodos I2P justo por esta razón.

Otro punto a tener en cuenta es la red mesh completa. Cada conexión salto-a-salto utiliza una conexión TCP o UDP en los nodos de I2P. Con 1000 conexiones uno ve 1000 conexiones TCP. Eso es bastante y algunos ruters domésticos o de oficina (DSL, cable...) sólo permiten un cierto número de conexiones ( o simplemente se vuelven locos si se usa un número mayor de X conexiones). I2P intenta limitar esas conexiones por debajo de 1500 para UDP y TCP. Esto limita también la cantidad de tráfico enrutado a través de su nodo I2P.

En resumen, I2P es muy complejo y no hay una forma fácil de determinar con precisión por qué su nodo no se utiliza. Si su ruter es accesible y tiene mas de 128 kbyte/sec de ancho de banda compartido y está accesible 24/7, debería ser usado después de algún tiempo de tener tráfico participante. Si no esta activo siempre, las pruebas de otros nodos sobre su nodo I2P le dirá: no está accesible. Esto bloquea su nodo por al menos 24h para los otros nodos. Por lo cual los otros nodos que han testado su nodo cuando estaba caído no utilizarán su nodo para construir túneles durante 24h. Esto es por lo que su tráfico será menor después de un reinicio/apagado por lo menos durante 24h.

Además: otros nodos I2P necesitan conocer su ruter I2P para probar la accesibilidad y capacidad. Toma tiempo que otros nodos lleguen a conocer su nodo. Será más rápido si utiliza I2P y crea más túneles, por ejemplo usando torrents o webs i2p durante algún tiempo.

Mejoras en el rendimiento

Para futuras mejoras en el rendimiento vea mejoras futuras en el rendimiento.

Para ver las mejoras de rendimiento pasadas vea historial de rendimiento.