tor-webwml.git

@@ -1103,7 +1103,7 @@ Tor သည္ မ်ိဳးစံုေသာ ကဲြျပားျခာ

 <p>

 <b>Authentication</b>: Every Tor relay has a public decryption key called

 the "onion key".  When the Tor client establishes circuits, at each step it

-<a href="<gitblob>doc/design-paper/tor-design.html#subsec:circuits">demands

+<a href="<svnprojects>design-paper/tor-design.html#subsec:circuits">demands

 that the Tor relay prove knowledge of its onion key</a>. That way the first

 node in the path can't just spoof the rest of the path.  Each relay rotates

 its onion key once a week.

@@ -1212,7 +1212,7 @@ requiring that all Tor relays be able to connect to all Tor relays) and of

 the directory (how to stop requiring that all Tor users know about all Tor

 relays). Changes like this can have large impact on potential and actual

 anonymity. See Section 5 of the <a

-href="<gitblob>doc/design-paper/challenges.pdf">Challenges</a> paper for

+href="<svnprojects>design-paper/challenges.pdf">Challenges</a> paper for

 details. Again, UDP transport would help here.

 </p>

@@ -86,7 +86,7 @@ Rogers Vortrag <q>blocking-resistance and circumvention</q> vom 23C3 im Dezember

 href="http://freehaven.net/~arma/23C3-1444-en-tor_and_china.m4v">Video</a>, <a

 href="http://freehaven.net/~arma/slides-23c3.pdf">Folien</a>, <a

 href="http://events.ccc.de/congress/2006/Fahrplan/events/1444.en.html">Kurzdarstellung</a>,

-<a href="<gitblob>doc/design-paper/blocking.html">Designvorschlag</a>) und

+<a href="<svnprojects>design-paper/blocking.html">Designvorschlag</a>) und

 Rogers Vortrag <q>Current events in 2007</q> vom 24C3 aus dem Dezember 2007 (<a

 href="http://freehaven.net/~arma/24c3-2325-en-current_events_in_tor_development.mp4">Video</a>,

 <a href="http://freehaven.net/~arma/slides-24c3.pdf">Folien</a>, <a

@@ -153,13 +153,13 @@ ist das die Liste für dich.</li> </ul>

   <ul>

     <li>Das <b>Designdokument</b> (zur Usenix Security 2004 veröffentlicht)

       gibt dir unsere Einstellungen und Sicherheitsanalyse zum Tor-Design:

-      <a href="<gitblob>doc/design-paper/tor-design.pdf">PDF-Entwurf  (engl.)</a> und

-      <a href="<gitblob>doc/design-paper/tor-design.html">HTML-Entwurf (engl.)</a>

+      <a href="<svnprojects>design-paper/tor-design.pdf">PDF-Entwurf  (engl.)</a> und

+      <a href="<svnprojects>design-paper/tor-design.html">HTML-Entwurf (engl.)</a>

       stehen zur Verfügung.</li>

     <li>Das darauf folgende Papier mit dem Titel <q>challenges in low-latency

       anonymity</q> (noch im Entwurf) hat mehr Details über die letzten

       Erfahrungen und Richtungen: <a

-      href="<gitblob>doc/design-paper/challenges.pdf">PDF version

+      href="<svnprojects>design-paper/challenges.pdf">PDF version

       (engl.)</a>.</li>

       <li>Unsere Veröffentlichung bei der WEIS 2006 &mdash; <b>Anonymity Loves

       Company: Usability and the Network Effect</b> &mdash; erklärt, warum

@@ -169,7 +169,7 @@ ist das die Liste für dich.</li> </ul>

       <li>Unser vorläufiges Design, um Firewalls den Zugriff auf das

       Tornetzwerk zu erschweren, ist in <b>design of a blocking-resistant

       anonymity system</b> (<a

-      href="<gitblob>doc/design-paper/blocking.pdf">PDF-Entwurf</a>)

+      href="<svnprojects>design-paper/blocking.pdf">PDF-Entwurf</a>)

       beschrieben. Du kannst auch einen Blick auf die <a

       href="http://freehaven.net/~arma/slides-23c3.pdf">Vortragsunterlagen</a>

       oder das <a

@@ -140,7 +140,7 @@ Client und drei vom versteckten Dienst gewählt.

 <p>Es gibt detailliertere Beschreibungen zu dem Protokoll als diese

 Seite. Schaue dir hierzu die

 <a

-href="<gitblob>doc/design-paper/tor-design.pdf">Designbeschreibung

+href="<svnprojects>design-paper/tor-design.pdf">Designbeschreibung

 von Tor</a> und die

 <a

 href="<gitblob>doc/spec/rend-spec.txt">Rendezvous-Spezifikation</a>

@@ -226,7 +226,7 @@ Skill Level: <i>High</i>

 Likely Mentors: <i>Nick, Roger, Steven</i>

 <br />

 The Tor 0.2.0.x series makes <a

-href="<gitblob>doc/design-paper/blocking.html">significant

+href="<svnprojects>design-paper/blocking.html">significant

 improvements</a> in resisting national and organizational censorship.

 But Tor still needs better mechanisms for some parts of its

 anti-censorship design.  For example, current Tors can only listen on a

@@ -239,7 +239,7 @@ to make Tor more scanning-resistant.  Right now, an adversary can identify

 <a href="<gitblob>doc/spec/proposals/125-bridges.txt">Tor bridges</a>

 just by trying to connect to them, following the Tor protocol, and

 seeing if they respond.  To solve this, bridges could

-<a href="<gitblob>doc/design-paper/blocking.html#tth_sEc9.3">act like

+<a href="<svnprojects>design-paper/blocking.html#tth_sEc9.3">act like

 webservers</a> (HTTP or HTTPS) when contacted by port-scanning tools,

 and not act like bridges until the user provides a bridge-specific key.

 <br />

@@ -1143,7 +1143,7 @@ throughput experiment</a>. We'll need to measure and tweak, and maybe

 overhaul if the results are good.</li>

 <li>Our censorship-resistance goals include preventing

 an attacker who's looking at Tor traffic on the wire from <a

-href="<gitblob>doc/design-paper/blocking.html#sec:network-fingerprint">distinguishing

+href="<svnprojects>design-paper/blocking.html#sec:network-fingerprint">distinguishing

 it from normal SSL traffic</a>. Obviously we can't achieve perfect

 steganography and still remain usable, but for a first step we'd like to

 block any attacks that can win by observing only a few packets. One of

@@ -985,7 +985,7 @@ won't work.

 <b>Authentication</b>:

 Every Tor relay has a public decryption key called the "onion key".

 When the Tor client establishes circuits, at each step it <a

-href="<gitblob>doc/design-paper/tor-design.html#subsec:circuits">demands

+href="<svnprojects>design-paper/tor-design.html#subsec:circuits">demands

 that the Tor relay prove knowledge of its onion key</a>. That way

 the first node in the path can't just spoof the rest of the path.

 Each relay rotates its onion key once a week.

@@ -1084,7 +1084,7 @@ stop requiring that all Tor relays be able to connect to all Tor

 relays) and of the directory (how to stop requiring that all Tor

 users know about all Tor relays). Changes like this can have large

 impact on potential and actual anonymity. See Section 5 of the <a

-href="<gitblob>doc/design-paper/challenges.pdf">Challenges</a> paper

+href="<svnprojects>design-paper/challenges.pdf">Challenges</a> paper

 for details. Again, UDP transport would help here.

 </p>

@@ -146,7 +146,7 @@ service.

 <p>

 There are more detailed descriptions about the hidden service protocol than

 this one. See the

-<a href="<gitblob>doc/design-paper/tor-design.pdf">Tor design paper</a>

+<a href="<svnprojects>design-paper/tor-design.pdf">Tor design paper</a>

 for an in-depth design description and the

 <a href="<gitblob>doc/spec/rend-spec.txt">rendezvous specification</a>

 for the message formats.

@@ -202,7 +202,7 @@ Skill Level: <i>High</i>

 Likely Mentors: <i>Nick, Roger, Steven</i>

 <br />

 The Tor 0.2.1.x series makes <a

-href="<gitblob>doc/design-paper/blocking.html">significant

+href="<svnprojects>design-paper/blocking.html">significant

 improvements</a> in resisting national and organizational censorship.

 But Tor still needs better mechanisms for some parts of its

 anti-censorship design.  For example, current Tors can only listen on a

@@ -869,7 +869,7 @@ more scanning-resistant.  Right now, an adversary can identify <a

 href="<gitblob>doc/spec/proposals/125-bridges.txt">Tor bridges</a>

 just by trying to connect to them, following the Tor protocol,

 and seeing if they respond.  To solve this, bridges could <a

-href="<gitblob>doc/design-paper/blocking.html#tth_sEc9.3">act like

+href="<svnprojects>design-paper/blocking.html#tth_sEc9.3">act like

 webservers</a> (HTTP or HTTPS) when contacted by port-scanning tools,

 and not act like bridges until the user provides a bridge-specific key.

 To start, check out Shane Pope's <a

@@ -971,7 +971,7 @@ throughput experiment</a>. We'll need to measure and tweak, and maybe

 overhaul if the results are good.</li>

 <li>Our censorship-resistance goals include preventing

 an attacker who's looking at Tor traffic on the wire from <a

-href="<gitblob>doc/design-paper/blocking.html#sec:network-fingerprint">distinguishing

+href="<svnprojects>design-paper/blocking.html#sec:network-fingerprint">distinguishing

 it from normal SSL traffic</a>. Obviously we can't achieve perfect

 steganography and still remain usable, but for a first step we'd like to

 block any attacks that can win by observing only a few packets. One of

@@ -83,12 +83,12 @@ es únicamente para desarrolladores y tiene muy poco tráfico.</li>

 <li>El <b>documento de dise&ntilde;o</b> (publicado en Usenix Security 2004)

 da nuestras justificaciones y análisis de seguridad para el diseño de Tor:

 versiones disponibles

-<a href="<gitblob>doc/design-paper/tor-design.pdf">PDF</a> y

-<a href="<gitblob>doc/design-paper/tor-design.html">HTML</a>

+<a href="<svnprojects>design-paper/tor-design.pdf">PDF</a> y

+<a href="<svnprojects>design-paper/tor-design.html">HTML</a>

 .</li>

 <li>Nuestro documento de reafirmación en <b>desafíos en el anonimato de baja latencia</b>

 (todavía en forma de borrador) detalla experiencias y direcciones mas recientes:

-<a href="<gitblob>doc/design-paper/challenges.pdf">versión PDF</a>.</li>

+<a href="<svnprojects>design-paper/challenges.pdf">versión PDF</a>.</li>

 <li>Nuestro artículo en WEIS 2006 &mdash; <b>Anonymity Loves Company:

 Usability and the Network Effect (Al anonimato le encanta la compañía:

 Usabilidad y el efecto en red)</b> &mdash; explica porqué la usabilidad

@@ -97,8 +97,8 @@ href="http://freehaven.net/anonbib/cache/usability:weis2006.pdf">PDF</a>.</li>

 <li>Nuestro diseño preliminar para hacer más difícil que cortafuegos grandes

 eviten el acceso a la red Tor se describe en 

 <b>el diseño de un sistema de anonimato resistente al bloqueo</b>:

-<a href="<gitblob>doc/design-paper/blocking.pdf">borrador PDF</a> y

-<a href="<gitblob>doc/design-paper/blocking.html">borrador HTML</a>.

+<a href="<svnprojects>design-paper/blocking.pdf">borrador PDF</a> y

+<a href="<svnprojects>design-paper/blocking.html">borrador HTML</a>.

 También puede ver <a

 href="http://freehaven.net/~arma/slides-23c3.pdf">transparencias</a> y <a

 href="http://freehaven.net/~arma/23C3-1444-en-tor_and_china.m4v">vídeo</a>

@@ -231,7 +231,7 @@ para Tor y UDP</a> &mdash; por favor díganos qué problemas tiene.</li>

 de destino (en los nodos de salida). Si le importa mucho IPv6, ése es

 probablemente el primer sitio para empezar.</li>

 <li>¿No le gusta ninguna de éstas? Mire el <a

-href="<gitblob>doc/design-paper/roadmap-2007.pdf">plan de desarrollo Tor</a> 

+href="<svnprojects>design-paper/roadmap-2007.pdf">plan de desarrollo Tor</a> 

 para más ideas.</li>

 <li>¿No ve su idea aquí? ¡Probablemente la necesitemos de todas formas! 

 Contáctenos y averígüelo.</li>

@@ -119,7 +119,7 @@ how Tor is built.

 <li>

 There's a skeletal <a

-href="<gitblob>doc/design-paper/roadmap-future.pdf">list of items

+href="<svnprojects>design-paper/roadmap-future.pdf">list of items

 we'd like to tackle in the future</a>. Alas, many of those items need

 to be fleshed out more before they'll make sense to people who aren't

 Tor developers, but you can still get a general sense of what issues

@@ -136,7 +136,7 @@ and circumvention" talk from 23C3 in December 2006 (<a

 href="http://freehaven.net/~arma/23C3-1444-en-tor_and_china.m4v">video</a>,

 <a href="http://freehaven.net/~arma/slides-23c3.pdf">slides</a>,

 <a href="http://events.ccc.de/congress/2006/Fahrplan/events/1444.en.html">abstract</a>,

-<a href="<gitblob>doc/design-paper/blocking.html">design paper</a>),

+<a href="<svnprojects>design-paper/blocking.html">design paper</a>),

 and Roger's "Current events in 2007" talk from 24C3 in December

 2007 (<a

 href="http://freehaven.net/~arma/24c3-2325-en-current_events_in_tor_development.mp4">video</a>,

@@ -175,12 +175,12 @@ is where the less complex discussion happens.

 <ul>

 <li>The <b>design document</b> (published at Usenix Security 2004)

 gives our justifications and security analysis for the Tor design:

-<a href="<gitblob>doc/design-paper/tor-design.pdf">PDF</a> and

-<a href="<gitblob>doc/design-paper/tor-design.html">HTML</a>

+<a href="<svnprojects>design-paper/tor-design.pdf">PDF</a> and

+<a href="<svnprojects>design-paper/tor-design.html">HTML</a>

 versions available.</li>

 <li>Our follow-up paper on <b>challenges in low-latency anonymity</b>

 (still in draft form) details more recent experiences and directions:

-<a href="<gitblob>doc/design-paper/challenges.pdf">PDF

+<a href="<svnprojects>design-paper/challenges.pdf">PDF

 draft</a>.</li>

 <li>Our paper at WEIS 2006 &mdash; <b>Anonymity Loves Company:

 Usability and the Network Effect</b> &mdash; explains why usability in

@@ -189,8 +189,8 @@ href="http://freehaven.net/anonbib/cache/usability:weis2006.pdf">PDF</a>.</li>

 <li>Our preliminary design to make it harder for large firewalls to

 prevent access to the Tor network is described in

 <b>design of a blocking-resistant anonymity system</b>:

-<a href="<gitblob>doc/design-paper/blocking.pdf">PDF draft</a> and

-<a href="<gitblob>doc/design-paper/blocking.html">HTML draft</a>.

+<a href="<svnprojects>design-paper/blocking.pdf">PDF draft</a> and

+<a href="<svnprojects>design-paper/blocking.html">HTML draft</a>.

 Want to <a href="<page volunteer>#Coding">help us build it</a>?</li>

 <li>The <b>specifications</b> aim to give

 developers enough information to build a compatible version of Tor:

@@ -351,7 +351,7 @@ Skill Level: <i>High</i>

 Likely Mentors: <i>Nick</i>

 <br />

 The Tor 0.2.0.x series makes <a

-href="<gitblob>doc/design-paper/blocking.html">significant

+href="<svnprojects>design-paper/blocking.html">significant

 improvements</a> in resisting national and organizational censorship.

 But Tor still needs better mechanisms for some parts of its

 anti-censorship design.  For example, current Tors can only listen on a

@@ -364,7 +364,7 @@ to make Tor more scanning-resistant.  Right now, an adversary can identify

 <a href="<gitblob>doc/spec/proposals/125-bridges.txt">Tor bridges</a>

 just by trying to connect to them, following the Tor protocol, and

 seeing if they respond.  To solve this, bridges could

-<a href="<gitblob>doc/design-paper/blocking.html#tth_sEc9.3">act like

+<a href="<svnprojects>design-paper/blocking.html#tth_sEc9.3">act like

 webservers</a> (HTTP or HTTPS) when contacted by port-scanning tools,

 and not act like bridges until the user provides a bridge-specific key.

 <br />

@@ -959,7 +959,7 @@ the core of the Blossom effort.

 <b>Bring up new ideas!</b>

 <br />

 Don't like any of these? Look at the <a

-href="<gitblob>doc/design-paper/roadmap-future.pdf">Tor development

+href="<svnprojects>design-paper/roadmap-future.pdf">Tor development

 roadmap</a> for more ideas.

 </li>

@@ -1065,7 +1065,7 @@ pas fonctionner.

 <b>Authentification</b>: Chaque noeud Tor a une clef de déchiffrement

 publique appelée "clef oignon".  Lorsque le client met en place des

 circuits, à chaque étape il <a

-href="<gitblob>doc/design-paper/tor-design.html#subsec:circuits">demande que

+href="<svnprojects>design-paper/tor-design.html#subsec:circuits">demande que

 le noeud Tor prouve la connaissance de sa propre clef oignon</a>. Ainsi, le

 premier noeud du circuit ne peut usurper le reste du circuit.  Chaque noeud

 change de clef oignon une fois par semaine.

@@ -1169,7 +1169,7 @@ Troisièment, nous avons besoin de travailler sur l'évolutivité du réseau

 que tous les utilisateurs Tor connaissent l'intégralité des noeuds Tor). Les

 changement à ce niveau peuvent avoir des conséquences sur

 l'anonymat. Consultez la section 4 de notre article sur <a

-href="<gitblob>doc/design-paper/challenges.pdf">nos défis</a> pour plus

+href="<svnprojects>design-paper/challenges.pdf">nos défis</a> pour plus

 détails. Encore une fois, le transport par UDP devrait améliorer grandement

 la situation.

 </p>

@@ -163,7 +163,7 @@ service caché.

 <p>

 Il existe d'autres documentations plus complètes sur le protocole de service

 caché que celle-ci. Consultez le <a

-href="<gitblob>doc/design-paper/tor-design.pdf">document de spécification de

+href="<svnprojects>design-paper/tor-design.pdf">document de spécification de

 Tor</a> pour une description plus approfondie ainsi que la <a

 href="<gitblob>doc/spec/rend-spec.txt">spécification rendez-vous</a> pour le

 format de messages. 

@@ -143,7 +143,7 @@ href="http://archives.seul.org/or/talk/Jan-2008/msg00300.html">la

 <i>Medium to High</i> <br /> Effort Level: <i>Medium</i> <br /> Skill Level:

 <i>High</i> <br /> Likely Mentors: <i>Nick, Roger, Steven</i> <br /> The Tor

 0.2.1.x series makes <a

-href="<gitblob>doc/design-paper/blocking.html">significant improvements</a>

+href="<svnprojects>design-paper/blocking.html">significant improvements</a>

 in resisting national and organizational censorship.  But Tor still needs

 better mechanisms for some parts of its anti-censorship design.  For

 example, current Tors can only listen on a single address/port combination

@@ -721,7 +721,7 @@ scanning-resistant.  Right now, an adversary can identify <a

 href="<gitblob>doc/spec/proposals/125-bridges.txt">Tor bridges</a> just by

 trying to connect to them, following the Tor protocol, and seeing if they

 respond.  To solve this, bridges could <a

-href="<gitblob>doc/design-paper/blocking.html#tth_sEc9.3">act like

+href="<svnprojects>design-paper/blocking.html#tth_sEc9.3">act like

 webservers</a> (HTTP or HTTPS) when contacted by port-scanning tools, and

 not act like bridges until the user provides a bridge-specific key.  To

 start, check out Shane Pope's <a

@@ -830,7 +830,7 @@ expérimentation autour de ssh</a>. Nous avons besoin de mesurer, de corriger

 et peut-être de refondre quelquechose si les résultats s'avèrent bons.</li>

 <li>Nos objectifs de résistance à la censure incluent l'impossibilité pour un

 attaquant qui observe le trafic Tor de <a

-href="<gitblob>doc/design-paper/blocking.html#sec:network-fingerprint">le

+href="<svnprojects>design-paper/blocking.html#sec:network-fingerprint">le

 distinguer d'un trafic SSL normal</a>. Néanmoins, nous ne pouvons pas

 recréer une stéganographie parfaire tout en restant utilisable mais, dans un

 premier temps, nous aimerions pouvoir bloquer toute attaque qui pourrait

@@ -115,7 +115,7 @@ and circumvention" dal 23C3 nel Dicembre 2006 (<a

 href="http://freehaven.net/~arma/23C3-1444-en-tor_and_china.m4v">video</a>,

 <a href="http://freehaven.net/~arma/slides-23c3.pdf">slide</a>,

 <a href="http://events.ccc.de/congress/2006/Fahrplan/events/1444.en.html">abstract</a>,

-<a href="<gitblob>doc/design-paper/blocking.html">design paper</a>),

+<a href="<svnprojects>design-paper/blocking.html">design paper</a>),

 e la presentazione "Current events in 2007" sempre di Roger al 24C3 nel Dicembre

 2007 (<a

 href="http://freehaven.net/~arma/24c3-2325-en-current_events_in_tor_development.mp4">video</a>,

@@ -185,12 +185,12 @@ href="http://archives.seul.org/or/cvs/">commit svn e git</a>.</li>

 <li>I <b>documenti di design</b> (pubblicati alla Usenix Security 2004)

 forniscono i fondamenti e le analisi di sicurezza di Tor:

 in versione

-<a href="<gitblob>doc/design-paper/tor-design.pdf">PDF</a> e

-<a href="<gitblob>doc/design-paper/tor-design.html">HTML</a>.

+<a href="<svnprojects>design-paper/tor-design.pdf">PDF</a> e

+<a href="<svnprojects>design-paper/tor-design.html">HTML</a>.

 </li>

 <li>Il nostro studio successivo sulle <b>sfide nell'anonimato a bassa latenza</b>

 (ancora in versione di bozza) descrive nel dettaglio esperienze e direzioni di sviluppo recenti:

-<a href="<gitblob>doc/design-paper/challenges.pdf">bozza

+<a href="<svnprojects>design-paper/challenges.pdf">bozza

 PDF</a>.</li>

 <li>Il nostro paper al WEIS 2006 &mdash; <b>Anonymity Loves Company:

 Usability and the Network Effect</b> &mdash; spiega perch&eacute; l'usabilit&agrave; nei

@@ -199,8 +199,8 @@ href="http://freehaven.net/anonbib/cache/usability:weis2006.pdf">PDF</a>.</li>

 <li>Il nostro progetto preliminare per impedire ai firewall di

 bloccare l'accesso alla rete Tor è descritto in

 <b>design of a blocking-resistant anonymity system</b>:

-<a href="<gitblob>doc/design-paper/blocking.pdf">bozza PDF</a> e

-<a href="<gitblob>doc/design-paper/blocking.html">bozza HTML</a>.

+<a href="<svnprojects>design-paper/blocking.pdf">bozza PDF</a> e

+<a href="<svnprojects>design-paper/blocking.html">bozza HTML</a>.

 Vedi anche le <a

 href="http://freehaven.net/~arma/slides-23c3.pdf">diapositive</a> e il<a

 href="http://freehaven.net/~arma/23C3-1444-en-tor_and_china.m4v">video</a>

@@ -931,7 +931,7 @@ non serve a nulla.

 <b>Autenticazione</b>:

 Ogni relay Tor ha una chiave pubblica di decifratura detta "onion key".

 Quanto il client Tor stabilisce dei circuiti, ad ogni passaggio <a

-href="<gitblob>doc/design-paper/tor-design.html#subsec:circuits">richiede

+href="<svnprojects>design-paper/tor-design.html#subsec:circuits">richiede

 che il relay Tor dimostri di conoscere la sua onion key</a>. In questo modo

 il primo nodo del percorso non può semplicemente falsificare il resto del percorso.

 Ogni relay ruota la sua onion key ogni settimana.

@@ -1030,7 +1030,7 @@ vitare che tutti i relay debbano potersi connettere a tutti i relay

 Tor) sia della directory (smettere di obbligare tutti gli utenti Tor

 a sapere quali sono tutti i relay Tor). Simili cabiamenti potrebbero avere

 un impatto enorme sull'anonimato potenziale e reale. Vedi la sezione 5 del paper <a

-href="<gitblob>doc/design-paper/challenges.pdf">Challenges</a>

+href="<svnprojects>design-paper/challenges.pdf">Challenges</a>

 per maggiori informazioni. Ancora, il trasporto UDP potrebbe essere molto utile qui.

 </p>

@@ -145,7 +145,7 @@ service.

 <p>

 Ci sono descrizioni del protocollo hidden service più approfondite 

 di questa. Vedi il

-<a href="<gitblob>doc/design-paper/tor-design.pdf">Tor design paper</a>

+<a href="<svnprojects>design-paper/tor-design.pdf">Tor design paper</a>

 per una descrizione dettagliata e la

 <a href="<gitblob>doc/spec/rend-spec.txt">rendezvous specification</a>

 per il formato dei messaggi.

@@ -211,7 +211,7 @@ Skill Level: <i>High</i>

 Likely Mentors: <i>Nick, Roger, Steven</i>

 <br />

 The Tor 0.2.0.x series makes <a

-href="<gitblob>doc/design-paper/blocking.html">significant

+href="<svnprojects>design-paper/blocking.html">significant

 improvements</a> in resisting national and organizational censorship.

 But Tor still needs better mechanisms for some parts of its

 anti-censorship design.  For example, current Tors can only listen on a

@@ -224,7 +224,7 @@ to make Tor more scanning-resistant.  Right now, an adversary can identify

 <a href="<gitblob>doc/spec/proposals/125-bridges.txt">Tor bridges</a>

 just by trying to connect to them, following the Tor protocol, and

 seeing if they respond.  To solve this, bridges could

-<a href="<gitblob>doc/design-paper/blocking.html#tth_sEc9.3">act like

+<a href="<svnprojects>design-paper/blocking.html#tth_sEc9.3">act like

 webservers</a> (HTTP or HTTPS) when contacted by port-scanning tools,

 and not act like bridges until the user provides a bridge-specific key.

 <br />

@@ -1133,7 +1133,7 @@ di throughput ssh</a>. Dovremmo misurare e provare, e forse applicare il metodo

 se i risultati fossero soddisfacenti.</li>

 <li>Uno degli obiettivi per resistere alla censura &egrave; impedire

 ad un attaccante che osservi il traffico Tor su una connessione di <a

-href="<gitblob>doc/design-paper/blocking.html#sec:network-fingerprint">distinguerlo

+href="<svnprojects>design-paper/blocking.html#sec:network-fingerprint">distinguerlo

 dal normale traffico SSL</a>. Non possiamo ovviamente ottenere perfetta

 steganografia e al contempo essere ancora utilizzabili, ma come primo passo ci

 bloccare tutti quegli attacchi che funzionano solo osservando pochi pacchetti. Uno degli

@@ -117,7 +117,7 @@ href="http://freehaven.net/~nickm/slides/Defcon07/TorChanges.pdf">スライド</

 href="http://freehaven.net/~arma/23C3-1444-en-tor_and_china.m4v">ビデオ</a>、

 <a href="http://freehaven.net/~arma/slides-23c3.pdf">スライド</a>、

 <a href="http://events.ccc.de/congress/2006/Fahrplan/events/1444.en.html">要約</a>、

-<a href="<gitblob>doc/design-paper/blocking.html">設計文書</a>)、

+<a href="<svnprojects>design-paper/blocking.html">設計文書</a>)、

 そして2007年12月の24C3からRogerの"Current events in 2007"トーク

 (<a

 href="http://freehaven.net/~arma/24c3-2325-en-current_events_in_tor_development.mp4">ビデオ</a>,

@@ -192,12 +192,12 @@ orアナウンスリストの

 <ul>

 <li><b>設計ドキュメント</b> (Usenix Security 2004で公開)

 Torの設計の存在意義とセキュリティ分析について示唆を与えてくれます:

-<a href="<gitblob>doc/design-paper/tor-design.pdf">PDF</a>または

-<a href="<gitblob>doc/design-paper/tor-design.html">HTML</a>

+<a href="<svnprojects>design-paper/tor-design.pdf">PDF</a>または

+<a href="<svnprojects>design-paper/tor-design.html">HTML</a>

 で閲覧可能です。</li>

 <li>追加文書の<b>低レイテンシ匿名化の課題</b>

 (まだドラフト形式)は最新の経験と傾向について掘り下げています:

-<a href="<gitblob>doc/design-paper/challenges.pdf">PDF

+<a href="<svnprojects>design-paper/challenges.pdf">PDF

 ドラフト</a>.</li>

 <li>

@@ -208,8 +208,8 @@ href="http://freehaven.net/anonbib/cache/usability:weis2006.pdf">PDF</a>。</li>

 <li>大きなファイアーウォールがTorネットワークへのアクセスを

 邪魔しにくくするため、私達が採用した暫定的なデザインについては

 <b>抗ブロッキング匿名化システムのデザイン</b>で述べられています:

-<a href="<gitblob>doc/design-paper/blocking.pdf">PDF ドラフト</a> および

-<a href="<gitblob>doc/design-paper/blocking.html">HTML ドラフト</a>。

+<a href="<svnprojects>design-paper/blocking.pdf">PDF ドラフト</a> および

+<a href="<svnprojects>design-paper/blocking.html">HTML ドラフト</a>。

 <a href="<page volunteer>#Coding">ビルドを手伝

 </a>ってくれませんか？</li>

 <li><b>仕様</b>は、開発者が互換性のあるTorのバージョンを制作するのに十分な

@@ -225,7 +225,7 @@ Skill Level: <i>High</i>

 Likely Mentors: <i>Nick, Roger, Steven</i>

 <br />

 Tor 0.2.0.xシリーズは国家や組織による検閲に対して抵抗力に関して

-<a href="<gitblob>doc/design-paper/blocking.html">著しい進歩</a>

+<a href="<svnprojects>design-paper/blocking.html">著しい進歩</a>

 を遂げています。しかし、Torは依然としてその反検閲の設計のいくつかの

 部分についてよりよいメカニズムを必要としています。例えば、

 現在のTorは同時に単一のアドレス/ポートをリッスンすることしか

@@ -239,7 +239,7 @@ Tor 0.2.0.xシリーズは国家や組織による検閲に対して抵抗力に

 <a href="<gitblob>doc/spec/proposals/125-bridges.txt">Torブリッジ</a>

 を識別することができます。この問題を解決するには、ブリッジはポートスキャニング

 ツールでコンタクトされたときには

-<a href="<gitblob>doc/design-paper/blocking.html#tth_sEc9.3">ウェブサーバの

+<a href="<svnprojects>design-paper/blocking.html#tth_sEc9.3">ウェブサーバの

 ように振る舞い</a>(HTTPまたはHTTPSで)、ユーザがブリッジ固有の鍵を与えない限り

 ブリッジとして振る舞うことがないようにすることが考えられます。

 <br />

@@ -1157,7 +1157,7 @@ href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">SSH

 より徹底した調査をすることになるでしょう。</li>

 <li>私たちの抗検閲の目標の一つとして、回線上のTorの通信を観察している

 攻撃者が<a

-href="<gitblob>doc/design-paper/blocking.html#sec:network-fingerprint">

+href="<svnprojects>design-paper/blocking.html#sec:network-fingerprint">

 Torの通信を通常のSSLの通信と区別する</a>

 ことを妨げることが挙げられます。明らかに私たちは完全で依然利用可能な

 ステガノグラフィをを得ることは出来ませんが、始めの一歩として数個の

@@ -84,12 +84,12 @@ zou interessant kunnen zijn voor ontwikkelaars.</li>

 <ul>

 <li>Het <b>ontwerpdocument</b> gepubliceerd op het Usenix Security 2004

 symposium geeft de onderbouwing en veiligheidsanalyse voor het Tor concept: 

-<a href="<gitblob>doc/design-paper/tor-design.pdf">PDF</a> en

-<a href="<gitblob>doc/design-paper/tor-design.html">HTML</a>

+<a href="<svnprojects>design-paper/tor-design.pdf">PDF</a> en

+<a href="<svnprojects>design-paper/tor-design.html">HTML</a>

 versies beschikbaar.</li>

 <li>Ons opvolgende werkdocument over <b>uitdagingen in laag-latente anonimiteit</b>

 zet onze recente ervaringen en richtingen uiteen:

-<a href="<gitblob>doc/design-paper/challenges.pdf">PDF

+<a href="<svnprojects>design-paper/challenges.pdf">PDF

 werkdocument</a>.</li>

 <li>Ons artikel op de WEIS 2006 getiteld <b>Anonymity Loves Company:

 Usability and the Network Effect</b> legt uit hoe de bruikbaarheid van

@@ -98,8 +98,8 @@ href="http://freehaven.net/anonbib/cache/usability:weis2006.pdf">PDF</a>.</li>

 <li>Ons voorlopig ontwerp, om het grote firewalls moeilijker te maken 

 de toegang tot het Tor network te blokkeren, wordt beschreven in

 <b>Design of a Blocking-Resistant Anonymity System</b>:

-<a href="<gitblob>doc/design-paper/blocking.pdf">PDF werkdocument</a> en

-<a href="<gitblob>doc/design-paper/blocking.html">HTML werkdocument</a>.

+<a href="<svnprojects>design-paper/blocking.pdf">PDF werkdocument</a> en

+<a href="<svnprojects>design-paper/blocking.html">HTML werkdocument</a>.

 U kunt ook de <a

 href="http://freehaven.net/~arma/slides-23c3.pdf">dia's</a> en <a

 href="http://freehaven.net/~arma/23C3-1444-en-tor_and_china.m4v">videoclip</a>

@@ -271,7 +271,7 @@ verkeerd aan is.</li>

 eerste plaats om te beginnen.</li>

 <li>Geen van alle naar uw zin? Kijk naar de <a

-href="<gitblob>doc/design-paper/roadmap-2007.pdf">plan voor verdere

+href="<svnprojects>design-paper/roadmap-2007.pdf">plan voor verdere

 ontwikkeling van Tor</a> voor meer idee�n.</li>

 <li>Uw idee hier niet gevonden? Tien tegen ��n dat we het toch nodig hebben! Neem

 contact met ons op.</li>

@@ -116,7 +116,7 @@ Rogera z 23C3 w grudniu 2006 (<a

 href="http://freehaven.net/~arma/23C3-1444-en-tor_and_china.m4v">wideo</a>,

 <a href="http://freehaven.net/~arma/slides-23c3.pdf">slajdy</a>,

 <a href="http://events.ccc.de/congress/2006/Fahrplan/events/1444.en.html">abstrakt</a>,

-<a href="<gitblob>doc/design-paper/blocking.html">dokument projektowy</a>),

+<a href="<svnprojects>design-paper/blocking.html">dokument projektowy</a>),

 lub przemówienie "Bieżące wydarzenia w roku 2007" Rogera z 24C3 w grudniu

 2007 (<a

 href="http://freehaven.net/~arma/24c3-2325-en-current_events_in_tor_development.mp4">wideo</a>,

@@ -189,11 +189,11 @@ a kanał IRC #tor to miejsce na mniej złożone dyskusje.

 <ul>

 <li><b>Dokumenty Projektu</b> (opublikowane na Usenix Security 2004)

  podaje nasze uzasadnienia i analizy bezpieczeństwa projektu Tora: są wersje

- <a href="<gitblob>doc/design-paper/tor-design.pdf">PDF</a> i

- <a href="<gitblob>doc/design-paper/tor-design.html">HTML</a>.</li>

+ <a href="<svnprojects>design-paper/tor-design.pdf">PDF</a> i

+ <a href="<svnprojects>design-paper/tor-design.html">HTML</a>.</li>

 <li>Nasz dodatkowy dokument na temat <b>wyzwań w krótkoczasowej anonimowości</b>

  (ciągle w postaci szkicu) podaje szczegóły nowszych doświadczeń i kierunki:

- <a href="<gitblob>doc/design-paper/challenges.pdf">szkic

+ <a href="<svnprojects>design-paper/challenges.pdf">szkic

  PDF</a>.</li>

 <li>Nasz dokument z WEIS 2006 &mdash; <b>Anonimowość uwielbia towarzystwo:

   użyteczność i efekt sieci</b> &mdash; tłumaczy, dlaczego użyteczność w

@@ -202,8 +202,8 @@ a kanał IRC #tor to miejsce na mniej złożone dyskusje.

 <li>Nasz wstępny projekt jak utrudnić wielkim zaporom ogniowym (firewallom)

  zapobieganie dostępowi do sieci Tor jest opisany w

   <b>projekcie systemu anonimowości odpornego na blokowanie</b>:

-  <a href="<gitblob>doc/design-paper/blocking.pdf">szkic PDF</a> i

-  <a href="<gitblob>doc/design-paper/blocking.html">szkic HTML</a>.

+  <a href="<svnprojects>design-paper/blocking.pdf">szkic PDF</a> i

+  <a href="<svnprojects>design-paper/blocking.html">szkic HTML</a>.

   Chcesz <a href="<page volunteer>#Coding">pomóc nam to stworzyć</a>?</li>

 <li><b>Specyfikacje</b> mają za zadanie dać

  deweloperom dość informacji, by stworzyć kompatybilną wersję Tora:

@@ -1013,7 +1013,7 @@ w celu odkrycia klucza nie podziała.

 <b>Uwierzytelnianie</b>: Każdy przekaźnik sieci Tora ma publiczny klucz

 deszyfrujący zwany "kluczem cebulowym". Gdy klient Tora uruchamia obwody, na

 każdym kroku <a

-href="<gitblob>doc/design-paper/tor-design.html#subsec:circuits">żąda, by

+href="<svnprojects>design-paper/tor-design.html#subsec:circuits">żąda, by

 przekaźnik sieci udowodnił znajomość swojego klucza cebulowego</a>. Tym

 sposobem, pierwszy węzeł w ścieżce nie może podszyć się pod resztę

 ścieżki. Każdy przekaźnik zmienia swój klucz raz w tygodniu.

@@ -1114,7 +1114,7 @@ wymagać, by każdy przekaźnik mógł się połączyć z każdym) i katalogów

 przestać wymagać, by wszyscy użytkownicy Tora wiedzieli o wszystkich

 przekaźnikach). Takie zmiany mogą mieć wielki wpływ na potencjalną i

 rzeczywistą anonimowość. Przeczytaj sekcję 5 dokumentu <a

-href="<gitblob>doc/design-paper/challenges.pdf">Wyzwania</a>, by poznać

+href="<svnprojects>design-paper/challenges.pdf">Wyzwania</a>, by poznać

 szczegóły. Ponownie, transport UDP by tu pomógł.

 </p>

@@ -135,7 +135,7 @@ punktem spotkania, a pozostałe 3 zostały wybrane przez usługę ukrytą.

 <p>

 Istnieją bardziej szczegółowe opisy protokołu usług ukrytych niż ta strona.

-Przeczytaj <a href="<gitblob>doc/design-paper/tor-design.pdf">dokument projektowy Tora</a>

+Przeczytaj <a href="<svnprojects>design-paper/tor-design.pdf">dokument projektowy Tora</a>

 zawierający dogłębny opis projektu, oraz

 <a href="<gitblob>doc/spec/rend-spec.txt">specyfikację spotkań (rendezvous)</a>,

 zawierającą formaty wiadomości.

@@ -187,7 +187,7 @@ Poziom umiejętności: <i>Wysoki</i>

 Prawdopodobni opiekunowie: <i>Nick, Roger, Steven</i>

 <br />

 Wersje 0.2.1.x Tora robią <a

-href="<gitblob>doc/design-paper/blocking.html">znaczne postępy</a> w opieraniu

+href="<svnprojects>design-paper/blocking.html">znaczne postępy</a> w opieraniu

 się narodowej i firmowej cenzurze. Ale Tor ciągle potrzebuje lepszych mechanizmów w

 niektórych częściach projektu anty-cenzurowania. Na przykład, bieżące wersje mogą

 nasłuchiwać połączeń tylko na jednym zestawie adres/port na raz. Istnieje

@@ -199,7 +199,7 @@ W chwili obecnej ktokolwiek może zidentyfikować

 <a href="<gitblob>doc/spec/proposals/125-bridges.txt">mostki Tora</a>

 po prostu łącząc się z nimi, zgodnie z protokołem Tora, i sprawdzając,

 czy odpowiadają. By rozwiązać ten problem, mostki mogłyby

-<a href="<gitblob>doc/design-paper/blocking.html#tth_sEc9.3">udawać serwery

+<a href="<svnprojects>design-paper/blocking.html#tth_sEc9.3">udawać serwery

 internetowe</a> (HTTP lub HTTPS), gdy łączą się z nimi programy do skanowania portów,

 a nie zachowywać się jak mostki do chwili, gdy użytkownik poda klucz specyficzny

 dla mostka.

@@ -837,7 +837,7 @@ dwa rzędy wielkości niż wtedy, gdy napisano ten dokument.) Przeczytaj też

 <li>Nasze cele w opieraniu się cenzurze to m.in. zapobieganie temu, by napastnik

 podglądający ruch Tora mógł <a

-href="<gitblob>doc/design-paper/blocking.html#sec:network-fingerprint"

+href="<svnprojects>design-paper/blocking.html#sec:network-fingerprint"

 >odróżnić go od normalnego ruchu SSL</a>. Oczywiście, nie możemy osiągnąć idealnej

 steganografii i dalej mieć użyteczną i działającą sieć, ale w pierwszym kroku

 chcielibyśmy blokować jakiekolwiek ataki, które mogą się udać po obserwacji tylko

@@ -113,7 +113,7 @@ and circumvention" de Roger, no 23C3 em dezembro de 2006 (<a

 href="http://freehaven.net/~arma/23C3-1444-en-tor_and_china.m4v">vídeo</a>,

 <a href="http://freehaven.net/~arma/slides-23c3.pdf">slides</a>,

 <a href="http://events.ccc.de/congress/2006/Fahrplan/events/1444.en.html">abstract</a>,

-<a href="<gitblob>doc/design-paper/blocking.html">design paper</a>),

+<a href="<svnprojects>design-paper/blocking.html">design paper</a>),

 e a palestra "Current events in 2007" de Roger, no 24C3 em dezembro

 de 2007 (<a

 href="http://freehaven.net/~arma/24c3-2325-en-current_events_in_tor_development.mp4">vídeo</a>,

@@ -182,12 +182,12 @@ pode ser interessante para desenvolvedores.</li>

 <li>O <b>documento de design</b> (publicado na Usenix Security 2004)

 tem as nossas justificativas e análise de segurança para o design do Tor:

 estão disponíveis versões em 

-<a href="<gitblob>doc/design-paper/tor-design.pdf">PDF</a> e

-<a href="<gitblob>doc/design-paper/tor-design.html">HTML</a>.</li>

+<a href="<svnprojects>design-paper/tor-design.pdf">PDF</a> e

+<a href="<svnprojects>design-paper/tor-design.html">HTML</a>.</li>

 <li>Nosso paper seguinte sobre <b>challenges in low-latency anonymity</b>

 ("desafios em anonimato de baixa latência" - ainda em rascunho) detalha as

 experiências e diretrizes mais recentes:

-<a href="<gitblob>doc/design-paper/challenges.pdf">rascunho em PDF</a>.</li>

+<a href="<svnprojects>design-paper/challenges.pdf">rascunho em PDF</a>.</li>

 <li>Nosso paper da WEIS 2006 &mdash; <b>Anonymity Loves Company:

 Usability and the Network Effect</b> (Anonimato Adora Companhia: Usabilidade e o

 Efeito Rede) — explica porque a usabilidade em sistemas de anonimato 

@@ -196,8 +196,8 @@ href="http://freehaven.net/anonbib/cache/usability:weis2006.pdf">PDF</a>.</li>

 <li>Nosso design preliminar para dificultar o bloqueio de acesso à rede Tor por 

 grandes firewalls está descrito em 

 <b>design of a blocking-resistant anonymity system</b>:

-<a href="<gitblob>doc/design-paper/blocking.pdf">rascunho em PDF</a> e

-<a href="<gitblob>doc/design-paper/blocking.html">rascunho em HTML</a>.

+<a href="<svnprojects>design-paper/blocking.pdf">rascunho em PDF</a> e

+<a href="<svnprojects>design-paper/blocking.html">rascunho em HTML</a>.

 Quer nos <a href="<page volunteer>#Coding">ajudar a construí-lo</a>?</li>

 <li>As <b>especificações</b> têm como objetivo dar aos desenvolvedores informação

 suficiente para construir uma versão compatível do Tor:

@@ -155,7 +155,7 @@ href="http://freehaven.net/anonbib/#hs-attack06">Расположение Скр

 <p>

 Существуют более подробные описания протокола скрытых сервисов. Обратите

-внимание на <a href="<gitblob>doc/design-paper/tor-design.pdf">Документ об

+внимание на <a href="<svnprojects>design-paper/tor-design.pdf">Документ об

 архитектуре сети Tor</a> для получения более углубленной информации об

 архитектуре и <a href="<gitblob>doc/spec/rend-spec.txt">спецификациях точек

 синхронизации</a> для форматов сообщений.

@@ -79,18 +79,18 @@ href="http://archives.seul.org/or/cvs/">cvs commits</a> som skulle kunna intress

 <ul>

 <li><b>Design dokument</b> (publiserat p&aring; Usenix Security 2004)

 anger våra skäl och säkerhetsanalys av Tors design:

-<a href="<gitblob>doc/design-paper/tor-design.pdf">PDF</a> och

-<a href="<gitblob>doc/design-paper/tor-design.html">HTML</a>

+<a href="<svnprojects>design-paper/tor-design.pdf">PDF</a> och

+<a href="<svnprojects>design-paper/tor-design.html">HTML</a>

 version finns.</li>

 <li>V&aring;r uppf&ouml;ljande artikel ang&aring;ende <b>utmaningar i l&aring;gf&ouml;rdr&ouml;jningsanonymitet</b>

 (fortfarande i utkast-format) anger i detalj de senaste erfarenheterna och inriktingar:

-<a href="<gitblob>doc/design-paper/challenges.pdf">PDF

+<a href="<svnprojects>design-paper/challenges.pdf">PDF

 version</a>.</li>

 <li>En prelimin�r desing f�r att g�re det sv�rare f�r stora brandv�ggar att

 hindra tillg�ng till Tor-n�tverket finns beskrivet i

 <b>design of a blocking-resistant anonymity system</b>:

-<a href="<gitblob>doc/design-paper/blocking.pdf">PDF draft</a>.

+<a href="<svnprojects>design-paper/blocking.pdf">PDF draft</a>.

 Se ocks� <a href="http://freehaven.net/~arma/slides-23c3.pdf">bilder</a> och

 <a href="http://freehaven.net/~arma/23C3-1444-en-tor_and_china.m4v">video</a>

 fr�n Rogers <a href="http://events.ccc.de/congress/2006/Home">23C3 f�redrag</a>.

@@ -222,7 +222,7 @@ Effort Level: <i>Medium</i>

 Skill Level: <i>High</i>

 <br />

 Likely Mentors: <i>Nick, Roger, Steven</i>

-Tor 0.2.0.x系列的<a href="<gitblob>doc/design-paper/blocking.html">一个重要改进</a

+Tor 0.2.0.x系列的<a href="<svnprojects>design-paper/blocking.html">一个重要改进</a

 >是提高了抵抗政府机关或者组织探测的能力。但是 Tor 的反审查设计在某些方面仍然需要

 更好的机制来改进。比如，现在 Tor 只能在一个 地址/端口  对上进行监听，

 有<a href="<gitblob>doc/spec/proposals/118-multiple-orports.txt">建议放开这个限制</a>，

@@ -231,7 +231,7 @@ Tor 0.2.0.x系列的<a href="<gitblob>doc/design-paper/blocking.html">一个重

 的扫描者可以通过尝试连接一个假定的 Tor 主机，向其发送 Tor 协议包，并检查它的响应来确定

 它是否在运行<a href="<gitblob>doc/spec/proposals/125-bridges.txt"> Tor 网桥</a>。

 要解决这个问题，当受到端口扫描工具扫描的时候，网桥应该

-<a href="<gitblob>doc/design-paper/blocking.html#tth_sEc9.3">伪装成一个 web 服务器</a>

+<a href="<svnprojects>design-paper/blocking.html#tth_sEc9.3">伪装成一个 web 服务器</a>

 （HTTP或者HTTPS），如果对方没有提供正确的网桥 key，那么它不会作出正确的网桥连接响应。

 <br />

 这部分的工作需要大量的研究和设计。一个巨大的挑战是，即使一个攻击者知道我们的算法和机制，

@@ -1065,7 +1065,7 @@ href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">ssh 吞吐量

 </li>

 <!-- NEED HELP -->

-<li>我们反审查机制的目标包括防止攻击者<a href="<gitblob>doc/design-paper/blocking.html#sec:network-fingerprint">

+<li>我们反审查机制的目标包括防止攻击者<a href="<svnprojects>design-paper/blocking.html#sec:network-fingerprint">

 从普通 SSL 传输中区分 Tor 数据包</a>。很明显，我们不可能既做到完美的隐藏又保持可用性，但是，

 首先，我们希望能够阻止攻击者仅仅观察几个数据包就可以取得成功。在这些攻击中，有一个我们没有进行太多测试的

 问题是，Tor 的数据包是以512字节为单位的，因此，传输的数据包可以是512字节的倍数。在物理线路上，