upd todo_fr
This commit is contained in:
magma
@@ -2,7 +2,7 @@
|
||||
{% block title %}À faire / Sur le feu{% endblock %}
|
||||
{% block content %}
|
||||
<h1>Cibles du project I2P</h1>
|
||||
Traduction en cours (24 fév 2011)
|
||||
Traduction en cours (25 fév 2011)
|
||||
<p>Vous trouverez ci-dessous une exposition plus détaillée (bien que toujours incomplète)
|
||||
des principales zones du développement du cœur du réseau I2P, embrassant les
|
||||
nouvelles versions éventuellement planifiées. Ceci n'inclu ni le transport stéganographique,
|
||||
@@ -17,113 +17,102 @@ Traduction en cours (24 fév 2011)
|
||||
<li><a href="#transport">Couche transport de haut-niveau par UDP, NBIO, ou NIO.</a></li>
|
||||
<li><a href="#netdb">Base de donnée réseau, ajustement de profil et stratégie d'éjection pour les grands réseaux.</a></li>
|
||||
</ul>
|
||||
<h2>Sécurité / anonymat <font size="-1"><a href="#security">[link]</a></font></h2>
|
||||
<h2>Sécurité / anonymat <font size="-1"><a href="#security">[zyva]</a></font></h2>
|
||||
<ul class="targetlist">
|
||||
<li><a href="#tunnelId">ID de tunnel "par saut" & nouvelle encryption permutée de la structure de vérification des tunnels.</a></li>
|
||||
<li><a href="#ordering">Tri strict des participants des tunnels.</a></li>
|
||||
<li><a href="#tunnelLength">Longueur des tunnels aléatoirement permutée.</a></li>
|
||||
<li><a href="#fullRestrictedRoutes">Routes réservées à n-sauts finalisées avec liens de confiance optionnels.</a></li>
|
||||
<li><a href="#hashcash">Hashcash for routerIdentity, destination, and tunnel request.</a></li>
|
||||
<li><a href="#batching">Advanced tunnel operation (batching/mixing/throttling/padding)</a></li>
|
||||
<li><a href="#stop">Stop & go mix w/ garlics & tunnels</a></li>
|
||||
<li><a href="#hashcash">Hashcash pour routerIdentity, destination, et demande de tunnel.</a></li>
|
||||
<li><a href="#batching">Fonctionnement étendu des tunnels (batching/mixing/throttling/padding)</a></li>
|
||||
<li><a href="#stop">Mélange de Stop & go pour les <a href="http://www.i2p2.de/how_garlicrouting.html">"garlics"</a> et les tunnels</a></li>
|
||||
</ul>
|
||||
<h2>Performance <font size="-1"><a href="performance.html">[link]</a></font></h2>
|
||||
<h2 id="core">Core functionality</h2>
|
||||
<h2>Performances <font size="-1"><a href="performance.html">[doigt]</a></font></h2>
|
||||
<h2 id="core">Fonctionalités centrales</h2>
|
||||
<ul class="targetlist">
|
||||
<li>
|
||||
<h3 id="nat">NAT/Firewall bridging via 1-hop restricted routes</h3>
|
||||
<h3 id="nat">Pontage du Pare-feu/NAT via une route réservée à 1 saut.</h3>
|
||||
</li>
|
||||
<b><i>Implemented in I2P 0.6.0.6</i></b>
|
||||
<p>The functionality of allowing routers to fully participate within the network
|
||||
while behind firewalls and NATs that they do not control requires some basic
|
||||
restricted route operation (since those peers will not be able to receive
|
||||
inbound connections). To do this successfully, you consider peers one of
|
||||
two ways:</p>
|
||||
<b><i>Implémenté dans I2P 0.6.0.6</i></b>
|
||||
<p>La fonctionalité permettant aux routeurs de participer pleinement aux réseau
|
||||
même lorsqu'ils se trouvent derrière un pare-feu ou un traducteur d'adresses réseau (NAT) hors de contrôle nécessite quelques
|
||||
opérations avec une route réservée (car ces pairs ne peuvent pas recevoir
|
||||
de connexions entrantes). Pour y parvenir, il y a deux façons de considérer les pairs:</p>
|
||||
</ul>
|
||||
<ul>
|
||||
<li><b>Peers who have reachable interfaces</b> - these peers do not need to
|
||||
do anything special</li>
|
||||
<li><b>Peers who do not have reachable interfaces</b> - these peers must build
|
||||
a tunnel pointing at them where the gateway is one of the peers they have
|
||||
established a connection with who has both a publicly reachable interface
|
||||
and who has agreed to serve as their 'introducer'.</li>
|
||||
<li><b>Pairs disposant d'interfaces joignables</b> - ils n'ont rien de particulier à faire.</li>
|
||||
<li><b>Pairs ne disposant pas d'interfaces joignables</b> - ces pairs doivent créer
|
||||
un tunnel pointant sur eux dans lequel la passerelle est un des pairs avec lesquels ils ont établi une connexion
|
||||
et qui, lui, dispose d'une interface publiquement joignable et a accepté de jouer le rôle "d'entremetteur".</li>
|
||||
</ul>
|
||||
<ul class="targetlist">
|
||||
<p>To do this, peers who have no IP address simply connect to a few peers,
|
||||
build a tunnel through them, and publish a reference to those tunnels within
|
||||
their RouterInfo structure in the network database.</p>
|
||||
<p>When someone wants to contact any particular router, they first must get
|
||||
its RouterInfo from the network database, which will tell them whether they
|
||||
can connect directly (e.g. the peer has a publicly reachable interface)
|
||||
or whether they need to contact them indirectly. Direct connections occur
|
||||
as normal, while indirect connections are done through one of the the published
|
||||
tunnels.</p>
|
||||
<p>When a router just wants to get a message or two to a specific hidden peer,
|
||||
they can just use the indirect tunnel for sending the payload. However,
|
||||
if the router wants to talk to the hidden peer often (for instance, as part
|
||||
of a tunnel), they will send a garlic routed message through the indirect
|
||||
tunnel to that hidden peer which unwraps to contain a message which should
|
||||
be sent to the originating router. That hidden peer then establishes an
|
||||
outbound connection to the originating router and from then on, those two
|
||||
routers can talk to each other directly over that newly established direct
|
||||
connection.</p>
|
||||
<p>Of course, that only works if the originating peer can receive connections
|
||||
(they aren't also hidden). However, if the originating peer is hidden, they
|
||||
can simply direct the garlic routed message to come back to the originating
|
||||
peer's inbound tunnel.</p>
|
||||
<p>This is not meant to provide a way for a peer's IP address to be concealed,
|
||||
merely as a way to let people behind firewalls and NATs fully operate within
|
||||
the network. Concealing the peer's IP address adds a little more work, as
|
||||
described <a href="#fullRestrictedRoutes">below.</a></p>
|
||||
<p>With this technique, any router can participate as any part of a tunnel.
|
||||
For efficiency purposes, a hidden peer would be a bad choice for an inbound
|
||||
gateway, and within any given tunnel, two neighboring peers wouldn't want
|
||||
to be hidden. But that is not technically necessary.</p>
|
||||
<p>Pour ce faire, les pairs privés se connectent simplement à quelques autres,
|
||||
créent un tunnel à travers chacun d'eux, et en publient une référence dans leur
|
||||
structure RouterInfo de la base de donnée du réseau.</p>
|
||||
<p>Lorsque quelqu'un souhaite joindre un routeur particulier, il doit d'abord obtenir
|
||||
sa "RouterInfo" à partir de la base de donnée, et il saura s'il peut se connecter
|
||||
directement (cas du pair cible public) ou indirectement. Les connexions directes se passent
|
||||
normalement, alors que les indirectes se font via les tunnels publiés.</p>
|
||||
<p>Quand un routeur veut seulement envoyer un ou deux messages à un pair caché,
|
||||
il peut simplement utiliser le tunnel indirect publié pour envoyer les données utiles. Cependant,
|
||||
si le routeur doit converser souvent avec le pair privé (par exemple en tant que participant
|
||||
à un tunnel), il doit envoyer un message "routé-à-la-garlic" à travers le tunnel
|
||||
indirect au pair caché, qui le déballe pour y trouver... un message destiné au routeur originaire.
|
||||
Le pair caché établit alors une connexion sortante
|
||||
au routeur originaire et à partir de là ces deux
|
||||
routeurs peuvent converser directement sur cette nouvelle connexion.</p>
|
||||
<p>Ce scénario ne peut bien sûr fonctionner que si le pair originaire peut recevoir des connexions
|
||||
(c'est-à-dire qu'il ne soit pas lui-même caché). Cependant, s'il est caché lui aussi, il peut indiquer dans
|
||||
le message initial de revenir par son propre tunnel d'entrée.</p>
|
||||
<p>Ceci n'est pas destiné à fournir aux pairs un moyen de dissimuler leur adresse IP,
|
||||
mais plutôt pour permettre à ceux opérant derrière un pare-feu ou un NAT de participer normalement
|
||||
au réseau. La dissimulation d'adresse IP demande plus de travail, comme
|
||||
décrit <a href="#fullRestrictedRoutes">plus bas</a>.</p>
|
||||
<p>Avec cette méthode, n'importe quel routeur peut participer à tout rôle dans un tunnel.
|
||||
Dans un but d'efficacité, opérer en pair caché est un mauvais choix pour officier en tant que passerelle d'entrée,
|
||||
et dans un tunnel donné, deux pairs voisins ne devraient pas être cachés. Mais ça n'est pas indispensable.</p>
|
||||
</ul>
|
||||
<ul class="targetlist">
|
||||
<li>
|
||||
<h3 id="transport">High degree transport layer with UDP, NBIO, or NIO</h3>
|
||||
<b><i>Both UDP and NIO have been Implemented in I2P</i></b>
|
||||
<p>Standard TCP communication in Java generally requires blocking socket
|
||||
calls, and to keep a blocked socket from hanging the entire system, those
|
||||
blocking calls are done on their own threads. Our current TCP transport
|
||||
is implemented in a naive fashion - for each peer we are talking to, we
|
||||
have one thread reading and one thread writing. The reader thread simply
|
||||
loops a bunch of read() calls, building I2NP messages and adding them
|
||||
to our internal inbound message queue, and the writer thread pulls messages
|
||||
off a per-connection outbound message queue and shoves the data through
|
||||
write() calls.</p>
|
||||
<p>We do this fairly efficiently, from a CPU perspective - at any time,
|
||||
almost all of these threads are sitting idle, blocked waiting for something
|
||||
to do. However, each thread consumes real resources (on older Linux kernels,
|
||||
for instance, each thread would often be implemented as a fork()'ed process).
|
||||
As the network grows, the number of peers each router will want to talk
|
||||
with will increase (remember, I2P is fully connected, meaning that any
|
||||
given peer should know how to get a message to any other peer, and restricted
|
||||
route support will probably not significantly reduce the number of connections
|
||||
necessary). This means that with a 100,000 router network, each router
|
||||
will have up to 199,998 threads just to deal with the TCP connections!</p>
|
||||
<p>Obviously, that just won't work. We need to use a transport layer that
|
||||
can scale. In Java, we have two main camps:</p>
|
||||
<h3 id="transport">Couche transport de haut-niveau par UDP, NBIO, ou NIO.</h3>
|
||||
<b><i>UDP et NIO sont implémentés dans I2P</i></b>
|
||||
<p>La communication TCP standard dans Java nécessite habituellement des appels de socket
|
||||
bloquants, et pour pour empêcher un socket de bloquer le bloquer tout le système, ces
|
||||
appels sont faits dans leur propres tâches. Notre transport TCP actuel
|
||||
est implémenté de façon naïve - pour chaque pair en relation, nous avons
|
||||
une tâche de lecture et une tâche d'écriture. Celle de lecture boucle simplement sur
|
||||
un paquet d'appels read(), construit les messages I2NP et les ajoute à notre file d'attente
|
||||
interne entrante. Il y a une file d'attente de messages sortants par connexion. La tâche d'écriture en extrait les messages
|
||||
et passe les données à travers les appels write().</p>
|
||||
<p>Nous effectuons ceci assez efficacement d'un point de vue charge UC - à tout moment,
|
||||
presque toutes ces tâches sont au repos, bloquées dans l'attente de grain à moudre.
|
||||
Cependant, chacune d'entre elles consomme des ressources réelles (par exemple sur de très vieux
|
||||
noyaux Linux, chacune sera souvent mise en œuvre en tant que processus fork()'ed).
|
||||
À mesure de la croissance du réseau, le nombre de pairs auxquels chaque routeur voudra s'adresser
|
||||
augmentera (souvenez-vous, I2P est entièrement connecté, c'est-à-dire que chaque pair doit savoir
|
||||
comment passer des messages à tous les autres. Le support des routes réservées
|
||||
ne réduira probablement pas sensiblement le nombre de connexions
|
||||
nécessaires). Ce qui veut dire que dans un réseau de 100000 routeurs, chaque routeur
|
||||
aura jusqu'à 199998 tâches rien que pour s'occuper des connexions TCP!</p>
|
||||
<p>Évidement, ça ne marchera pas. Nous avons besoin d'une couche transport adaptative.
|
||||
Dans Java, nous disposons de deux approches principales:</p>
|
||||
<h4>UDP</h4>
|
||||
<b><i>Implemented in I2P 0.6 ("SSU") as documented <a href="udp.html">elsewhere</a></i></b>
|
||||
<p>Sending and receiving UDP datagrams is a connectionless operation - if
|
||||
we are communicating with 100,000 peers, we simply stick the UDP packets
|
||||
in a queue and have a single thread pulling them off the queue and shoving
|
||||
them out the pipe (and to receive, have a single thread pulling in any
|
||||
UDP packets received and adding them to an inbound queue).</p>
|
||||
<p>However, moving to UDP means losing the benefits of TCP's ordering, congestion
|
||||
control, MTU discovery, etc. Implementing that code will take significant
|
||||
work, however I2P doesn't need it to be as strong as TCP. Specifically,
|
||||
a while ago I was taking some measurements in the simulator and on the
|
||||
live net, and the vast majority of messages transferred would fit easily
|
||||
within a single unfragmented UDP packet, and the largest of the messages
|
||||
would fit within 20-30 packets. As mule pointed out, TCP adds a significant
|
||||
overhead when dealing with so many small packets, as the ACKs are within
|
||||
an order of magnitude in size. With UDP, we can optimize the transport
|
||||
for both efficiency and resilience by taking into account I2P's particular
|
||||
needs.</p>
|
||||
<p>It will be a lot of work though.</p>
|
||||
<b><i>Implémenté dans I2P 0.6 ("SSU") tel que documenté <a href="udp.html">ailleurs</a>.</i></b>
|
||||
<p>L'envoi et la réception de datagrammes UDP sont des opérations sans connexion - si
|
||||
on communique avec 100000 pairs, on colle simplement les paquets UDP dans une file
|
||||
d'attente et on fait avec une seule tâche pour les extraire et les pousser dans le tuyau
|
||||
(et pour recevoir, une seule tâche en tire les paquets UDP reçus et les ajoute dans une file d'entrée).</p>
|
||||
<p>L'ennui, c'est que l'utilisation de UDP fait perdre les avantages de TCP (réordonnancement, gestion de la congestion,
|
||||
découverte du MTU, etc). Mettre ce code en œuvre demandera un travail important,
|
||||
mais I2P n'a pas besoin d'être aussi solide que TCP. Précisément,
|
||||
lorsque j'ai fait des mesures au simulateur et en réel sur Internet,
|
||||
la plupart des messages transférés tenaient facilement dans un seul paquet UDP
|
||||
non fragmenté, et les plus gros messages prenaient 20 à 30 paquets.
|
||||
Comme <i>mule</i> le mit en évidence, TCP ajoute une surcharge certaine quand il s'agit de gérer
|
||||
autant de petits paquets, vu que les ACKs sont du même ordre de grandeur.
|
||||
Avec UDP, nous pouvons optimiser le transport tant pour l'efficacité que pour la souplesse
|
||||
en prenant en compte les besoins spécifiques d'I2P.</p>
|
||||
<p>Ça ne va malgré tout pas être un énorme travail.</p>
|
||||
<h4>NIO or NBIO</h4>
|
||||
<b><i>NIO Implemented in I2P 0.6.1.22 ("NTCP")</i></b>
|
||||
<p>In Java 1.4, a set of "New I/O" packages was introduced, allowing Java
|
||||
|
||||
Reference in New Issue
Block a user