added german translation fo...
Oliver Knapp authored 15 years ago
|
3) # Last-Translator: mail (a/t) oliverknapp .de
4)
5) #include "head.wmi" TITLE="Das NLnet Projekt: Versteckte Dienste beschleunigen" CHARSET="UTF-8"
6)
7) <div class="main-column">
8)
9) <!-- PUT CONTENT AFTER THIS TAG -->
10)
11) <h2>Das NLnet Projekt: Versteckte Dienste beschleunigen</h2>
12) <hr />
13)
14) <p> Versteckte Dienste bei Tor erlauben dem Nutzer anonyme Informationsdienste
15) wie Webseiten zu erstellen, welche nur über das Tor-Netzwerk erreichbar sind
16) und deren Aufenthaltsort geheim bleibt. Die kritischsten Einschränkungen von
17) versteckten Diensten sind momentan die Zeit, die es dauert, bis ein versteckter
18) Dienst im Netzwerk registriert ist und die Zeit die es dauert, bis eine
19) Verbindung zum versteckten Dienst hergestellt ist, wenn ein Nutzer auf den
20) Dienst zugreifen möchte.
21)
22) Auf Grund von Designproblemen im originalen Tor Protokoll kann eine Verbindung
23) zu einem versteckten Dienst mehrere Minuten dauern, was dafür sorgt, dass die
24) meisten Nutzer den Verbindungsversuch aufgeben, bevor die Verbindung
25) hergestellt wurde. Versteckte Dienste für eine direkte, interaktive
26) Kommunikation zwischen Nutzern zu verwenden (z.B. für Instant Messenger) ist
27) auf Grund der hohen Latenz für den Verbindungsaufbau daher momentan nahezu
28) unmöglich.</p>
29)
30) <p>Das Ziel dieses Projektes ist es, versteckte Dienste zu beschleunigen, in
31) dem sowohl die Methode, mit der Verbindungen zwischen den Nutzern und den
32) versteckten Diensten hergestellt werden, als auch die Methode für die
33) Registrierung von versteckten Diensten im Netzwerk, verbessert werden. In einem
34) ersten Schritt wird eine präzise Diagnose von versteckten Diensten unter
35) Labor- als auch unter Realbedingungen durchgeführt, um den Hauptgrund für die
36) schlechte Performanz zu finden. Basierend auf diesen Diagnosen werden
37) Optimierungsstrategien erarbeitet und auf mögliche unerwünschte Effekte für
38) die Sicherheit und Anonymität des Tor-Netzwerks untersucht. Die
39) vielversprechensten Lösungen werden dann implementiert, um eine Verbesserung
40) für den Nutzer zu erreichen. In der Diagnosephase, sobald bekannt ist wo Zeit
41) verloren geht und was für Verbesserungen wahrscheinlich sind, werden auch
42) genaue Erfolgsmaßstäbe entwickelt. Das Ziel ist es, die Veränderungen am
43) Protokoll von versteckten Diensten innerhalb von 12 Monaten entwickelt und in
44) Tor integriert zu haben.</p>
45)
46) <p>
47) Dieses Projekt wird großzügigerweise gesponsert von:
48) </p>
49)
50) <p>
51) <a href="http://www.nlnet.nl/news/2008/20080514-awards.html">
52) <img src="$(IMGROOT)/nlnet-160x60.png" alt="Der NLnet Stiftung" /></a>
53) </p>
54)
55) <table width="100%" border="0" cellspacing="0" cellpadding="3">
56) <thead>
57) <tr>
58) <th><big>Projekt</big></th>
59) <th><big>Fälligkeit</big></th>
60) </tr>
61) </thead>
62)
63) <tr bgcolor="#e5e5e5">
64) <td>
65) <b>Etappe A:</b> Analyse, Messungen und Problem eingrenzen<br />
66)
67) <small><em>Da das Protokoll von versteckten Diensten in den letzten Jahren
68) nicht aktiv weiterentwickelt wurde, sind bestimmte Teilaspekte des Problems
69) nicht ausreichend erforscht. Um die genaue Quelle für die Latenz und den
70) Zeitverlust zu finden, muss eine ausführliche Analyse der Hintergründe
71) durchgeführt werden. Etappe A wird ungefähr einen Monat benötigen. Die
72) Ergebnisse der Analyse werden die Designentscheidungen von Etappe B
73) beeinflussen.</em></small>
74)
75) </td>
76) <td>
77) 15. Juni 2008
78) </td>
79) </tr>
80)
81) <tr>
82) <td>
83) <b>Etappe B:</b> Design und Bewertung der nötigen Veränderungen<br />
84)
85) <small><em>Die Veränderungen an den versteckten Diensten werden Kernfunktionen
86) des Tor Protokolls berühren und müssen daher genau auf mögliche Gefahren für
87) die Sicherheit und Anonymität untersucht werden. Für die Design- und
88) Überprüfungsphase, welche mit einer ausführlichen, externen Prüfung endet,
89) sind 2 Monate vorgesehen</em></small>
90)
91) </td>
92) <td>
93) 15. August 2008
94) </td>
95) </tr>
96)
97) <tr bgcolor="#e5e5e5">
98) <td>
99) <b>Etappe C:</b> Implementation<br />
100)
101) <small><em>Nach Design, Folgeabschätzung und externer Prüfung müssen die
102) Veränderungen umgesetzt und in die aktuellen Torquellen eingepflegt werden.
103) Die eigentliche Umsetzung der Veränderungenn wird etwa 2 Monate dauern.</em>
104) </small>
105)
106) </td>
107) <td>
108) 15. Oktober 2008
109) </td>
110) </tr>
111)
112) <tr>
113) <td>
114) <b>Etappe D:</b> Implementation und Evaluation der Änderungen bis zur Veröffentlichung<br />
115)
116) <small><em>Die Veränderung ist sehr kritisch für die Sicherheit und Anonymität
117) des Tor-Netzwerks. Sie benötigt daher intensive Tests und Fehlersuche sowohl
118) im Labor als auch unter realen Bedingungen. Wir planen für diese Phase 3
119) Monate ein, wobei der verantwortliche Entwickler 1/3 seine Zeit mit den Test
120) verbringt. Ein Teil der Testphase wird eine öffentliche Betaphase
121) beinhalten.</em></small>
122)
123) </td>
124) <td>
125) 15. Januar 2009
126) </td>
127) </tr>
128)
129) <tr bgcolor="#e5e5e5">
130) <td>
131) <b>Etappe E:</b> Veröffentlichung<br />
132)
133) <small><em>Die eigentliche Veröffentlichung für das Tor-Server-Netzwerk wird
134) mit dem regulären Veröffentlichungsplan von Tor abgestimmt. Da dieser Plan von
135) mehreren externen Faktoren, wie zum Beispiel der Vervollständigung andere
136) Softwareprojekte die in die gleiche Version einfließen sollen, abhängt, kann
137) die Zeit zwischen Veröffentlichung und Installation auf den meisten Tor
138) Servern variieren. Aus Erfahrung kann ein Zeitraum von 3 bis 4 Monaten
139) angenommen werden.</em></small>
140)
141) </td>
142) <td>
143) 15. Mai 2009
144) </td>
145) </tr>
146) </table>
147)
148) <br />
149)
150) <a id="Reports"></a>
151) <h2><a class="anchor" href="#Reports">Monatliche Statusberichte</a></h2>
152)
153) <p>Es wird insgesamt acht monatliche Statusberichte geben. Der Erste wird mit
154) dem Abschluss der ersten Etappe am 15. Juni 2008 erscheinen, der Letzte mit
155) dem Abschluss der Tests und der Implementation am 15. Januar 2009. </p>
156)
157) <table width="100%" border="0" cellspacing="0" cellpadding="3">
158) <thead>
159) <tr>
160) <th><big>Monat,</big></th>
161) <th><big>Statusbericht</big></th>
162) </tr>
163) </thead>
164)
165) <tr bgcolor="#e5e5e5">
166) <td>
167) <a id="Jun08"></a>
168) <a class="anchor" href="#Jun08">Juni 08</a>
169) </td>
170) <td>
171)
172) <small><em>Das ursprüngliche Ziel, das Problem, welches die versteckten
173) Dienste verlangsamt, zu finden, wurde erreicht. Ein Teil dieser Analyse war es,
174) die Verzögerung zu messen, die ein Nutzer erlebt, wenn er auf einen
175) versteckten Dienst zugreifen möchte. Messdaten aus dem April 08 konnten dafür
176) genutzt werden, zu erforschen welche internen Schritte wie lange dauern, wenn
177) ein Nutzer sich zu einem versteckten Dienst verbinden möchte. Die Ergebnisse
178) dieser Analyse sind in einem 22-seitigen
179) <a href="http://freehaven.net/~karsten/hidserv/perfanalysis-2008-06-15.pdf">
180) Bericht (engl.)</a> enthalten, der auf der
181) <a href="http://archives.seul.org/or/dev/Jun-2008/msg00019.html">Entwickler
182) Mailingliste</a> veröffentlicht wurde.</em></small>
183)
184) <br/> <small><em>Die Analyse hat ausserdem ein paar Fehler ans Licht gebracht,
185) die für einen Teil der Verzögerung verantwortlich waren. Ein paar Fehler
186) wurden direkt nach der Analyse behoben, andere werden bald behoben sein. Die
187) Untersuchung hat ausserdem mehrere mögliche Performanzverbesserungsansätze
188) gebracht. Mehrere der Ansätze können direkt umgesetzt werden, andere benötigen
189) intensivere Untersuchungen und neue Messungen. Im Zuge der Analyse fanden wir
190) auch heraus, dass einigen der Ansätze tiefgreifende Änderungen an Tor
191) benötigen, die nicht direkt mit versteckten Diensten zusammenhängen. Diese
192) Veränderungen können innerhalb der Zeitplanungen dieses Projektes nicht
193) umgesetzt werden.</em></small>
194)
195) </td>
196) </tr>
197)
198) <tr>
199) <td>
200) <a id="Jul08"></a>
201) <a class="anchor" href="#Jul08">Juli 08</a>
202) </td>
203) <td>
204)
205) <small><em>Alle in der Analyse gefundenen Fehler wurden behoben. Dies
206) beinhaltet 2 Fehler die schon während der Analyse behoben wurden sowie 4
207) weitere Fehler, die in den letzten 30 Tagen entfernt wurden. Während die
208) Fehlerbehebungen nur ungewollte Performanzprobleme auf Grund von
209) Programmierfehlern behoben haben, werden einige der in der Analyse entdeckten
210) Designveränderungen einen Einfluss auf Anonymität oder die generelle
211) Netzwerklast im Tor-Netzwerk haben. Diese Einflüsse müssen gegen die
212) individuellen Performanzsteigerungen evaluiert werden. Ein <a
213) href="http://freehaven.net/~karsten/hidserv/discussion-2008-07-15.pdf">
214) Bericht</a> mit 7 möglichen Designveränderungen die diskutiert werden müssen,
215) wurde auf der <a href="http://archives.seul.org/or/dev/Jul-2008/msg00034.html">
216) Entwicklermailingliste</a> veröffentlicht. Bei mehreren Überprüfungen (genauer
217) die Messungen bei niedrigen Bandbreiten und der "Grand Scaling Plan") hat sich
218) herausgestellt, dass sie mehr Zeit als erwartet benötigen und sie wurden daher
219) für eine spätere Etappe eingeplant. Der aktuelle Plan ist, diese Überprüfungen
220) innerhalb eines Zeitraums bis zum 15. Januar 2009 zu erledigen und bis dahin
221) mit Abschätzungen zu arbeiten.</em></small>
222)
223) </td>
224) </tr>
225)
226) <tr bgcolor="#e5e5e5">
227) <td>
228) <a id="Aug08"></a>
229) <a class="anchor" href="#Aug08">Aug. 08</a>
230) </td>
231) <td>
232)
233) <small><em>Während der letzen 30 Tage wurden 7 der vorgeschlagenen Designs
234) weiter untersucht und diskutiert. Vier davon wurden im Hinblick auf die zu
235) erwartenden Codeänderungen und Auswirkungen auf die Anonymität als machbar
236) eingeschätzt. Eines wurde eher als Fehler als als Designveränderung gesehen.
237) Zwei wurden auf Grund von unvorhersehbaren Sicherheitsauswirkungen oder
238) unklarer Performanzgewinne ausgeschlossen.</em></small>
239)
240) <br/> <small><em>Zusammen mit den Ergebnissen vom 15. Juli wurde die
241) Designphase beendet. Die Aufgaben für die kommende Umsetzung sind jetz klar:
242) Ein Fehler muss behoben und 4 Designveränderungen müssen implementiert werden.
243) Ausserdem müssen Untersuchungen des veränderten Designs zeigen, ob diese
244) sinnvoll sind. Ein <a
245) href="http://freehaven.net/~karsten/hidserv/design-2008-08-15.pdf">Bericht</a>
246) mit den Ergebnissen der Designphase wurde auf der <a
247) href="http://archives.seul.org/or/dev/Aug-2008/msg00025.html">Entwickler
248) Mailingliste</a> veröffentlicht.</em></small> </td> </tr>
249)
250) <tr>
251) <td>
252) <a id="Sep08"></a>
253) <a class="anchor" href="#Sep08">Sep. 08</a>
254) </td>
255) <td>
256)
257) <small><em>Während der ersten Hälfte der Umsetzungsphase konnten 2 Fehler
258) behoben werden, die mit versteckten Diessnten zusammenhingen: der <a
259) href="http://bugs.noreply.org/flyspray/index.php?do=details&id=767">erste
260) Fehler</a> wurde bereits in der Designphase entdeckt und war für eine
261) außergewöhnliche Fehlerrate beim Verfügbarmachen von versteckten Diensten
262) verantwortlich; der <a
263) href="http://bugs.noreply.org/flyspray/index.php?id=814&do=details">zweite
264) Fehler</a> wurde in der Umsetzungsphase gefunden und war dafür verantwortlich,
265) dass Verbindungen zu aktiven, versteckten Diensten fehlschlagen konnten. Beide
266) Fehlerbehebungen werden in der nächsten unstable Version enthalten sein und
267) werden wahrscheinlich auch in eine der nächsten stable Veröffentlichungen
268) zurückportiert werden.</em></small> <br/>
269)
270) <small><em>Die vier Designveränderungen die in der Designphase überlegt wurden,
271) wurden in einen <a
272) href="https://tor-svn.freehaven.net/svn/tor/branches/hidserv-design-changes/">
273) experimentellen Zweig</a> des unstable Entwicklungspfads eingebaut.Erste
274) Funktionstests zeigen, dass diese Veränderungen funktionieren und bessere
275) (gefühlte) Performanz bieten. Dies muss über die nächsten 4 Wochen in internen
276) Tests überprüft werden. Das nächste Ziel ist es eine Version dieses
277) experimentellen Zweigs für Betatester zu Beginn der folgenden Testphase zu
278) veröffentlichen.</em></small> </td> </tr>
279)
280) <tr bgcolor="#e5e5e5">
281) <td>
282) <a id="Oct08"></a>
283) <a class="anchor" href="#Oct08">Okt. 08</a>
284) </td>
285) <td>
286)
287) <small><em>Die Umsetzungsphase wurde beendet. Die Fehler die in den letzten 30
288) Tagen gefunden wurden, sind in der Entwicklerversion <a
289) href="http://archives.seul.org/or/talk/Oct-2008/msg00093.html">
290) 0.2.1.6-alpha</a> veröffentlicht worden. Die vier Designänderungen die
291) identifiziert werden konnten, wurden in <a
292) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/155-four-hidden-service-improvements.txt">
293) Vorschlag 155</a> spezifiziert. Drei Desiggnveränderungen wurden bereits in
294) die Entwicklungscodebasis übernommen und werden in der nächsten
295) Entwicklerversion automatisch enthalten sein. Die ersten beiden
296) Designveränderungen verbessern die Verbindungsherstellung zu versteckten
297) Diensten, in dem sie den die maximale Wartezeit von 60 auf 30 Sekunden
298) reduzieren und parallel einen zweiten Verbindungsversuch nach 15 Sekunden
299) starten. Die dritte Designveränderung beeinflusst die Veröffentlichung eines
300) versteckten Dienstes im Netzwerk, in dem er gleichzeitig an 5 anstelle von 3
301) Stellen bekanntgemacht wird und sobald 3 Stellen etabliert sind, aufhört. Die
302) vierte Veränderung hat sich als eher ineffektiv herausgestellt, würde
303) allerdings erhebliche Codekomplexität hinzufügen und wurde daher abgelehnt.
304) Aktuell gibt es keine weiteren Fehlerbehebungen und Designveränderungen die
305) noch umgesetzt werden können. Alle Veränderungen sind in der
306) Entwicklungsquellcodebasis und können in der nächsten Etappe getestet
307) werden.</em></small> </td> </tr>
308)
309) <tr>
310) <td>
311) <a id="Nov08"></a>
312) <a class="anchor" href="#Nov08">Nov. 08</a>
313) </td>
314) <td>
315)
316) <small><em>Die Geschwindigkeitsverbesserungen wurden in der Tor-Version
317) 0.2.1.7-alpha veröffentlicht. Benutzer können diese Entwicklungsversion direkt
318) von der Tor Homepage runterladen und die Verbesserungen mit minimalem Aufwand
319) testen. Ausserdem wurden 2 Fehler (<a
320) href="http://bugs.noreply.org/flyspray/index.php?id=767&do=details">1</a>,
321) <a href="http://bugs.noreply.org/flyspray/index.php?id=814&do=details">
322) 2</a>) die während diesem Projekt gefunden wurden, in den stabilen Zweig
323) übernommen und werden in der nächsten stable Version 0.2.0.32 enthalten
324) sein.</em></small>
325)
326) <br/> <small><em>Die Hauptaufgabe der letzten 31 Tage war es, neue Messungen
327) durchzuführen, ob die Verbesserungen effektiv sind oder nicht. Die Messungen
328) wurden zwei Tage lang voom 6. bis zum 7. November durchgeführt. Dummerweise
329) hatte das Tor-Netzwerk in dieser Zeit ein massives Problem: Ein abgelaufenes
330) Zertifikat einer Verzeichnissauthorität hat hohe Last im Tor-Netz erzeugt, was
331) <a href="http://archives.seul.org/or/talk/Nov-2008/msg00053.html">viele
332) Serbverbetreiber gezwungen hat, ihre Server abzuschalten</a>. Eine zweite
333) Messung wurde zwischen dem 13. und 15. November durchgeführt. Die Rohdaten
334) sind <a
335) href="http://freehaven.net/~karsten/hidserv/perfdata-2008-11-13.tar.gz">hier
336) zu bekommen</a> (40 MB). Leider zeigen die Ergebnisse, dass die
337) Gesamtperformanz des Tor-Netzwerks immer noch schlechter ist als im Juni 2008,
338) als die erste Messung bezüglich versteckter Dienste durchgeführt wurde. Die
339) zeigt sich vor allem bei Anfragen an Verzeichnissserver, die noch nicht von
340) den Verbesserungen profitieren und die eine deutlich schlechtere Performanz
341) als damals zeigen. Die Effekte der Verbesserungen sind sichtbar, aber absolute
342) Zahlen sind noch nicht vergleichbar. Neue Messungen werden im Dezember
343) durchgeführt, mit der Hoffnung, dass die Auswirkungen dieses Problems bis
344) dahin verschwunden sind.</em></small> <br/>
345)
346) <small><em>Zusätzlich wurde noch ein möglicher <a
347) href="http://bugs.noreply.org/flyspray/index.php?id=847&do=details">
348) Fehler</a> in der Art, wie Tor Verzeichnissinformationen beim Starten bezieht,
349) gefunden. Auch wenn dieser Fehler nicht direkt mit versteckten Diensten
350) zusammenhängt, würde die Veröffentlichung von versteckten Diensten von einer
351) Fehlerbehebung profitieren. Ein Teil der Aufgaben der nächsten 30 Tagen wir es
352) sein diesen Fehler zu untersuchen. </em></small> </td> </tr>
353)
354) <tr bgcolor="#e5e5e5">
355) <td>
356) <a id="Dec08"></a>
357) <a class="anchor" href="#Dec08">Dez. 08</a>
358) </td>
359) <td>
360)
361) <small><em>Ein Teil der letzten 30 Tagen wurde dafür genutzt, Fehler zu
362) beheben, die die Messungen negativ beeinflusst haben. Die erste <a
363) href="http://archives.seul.org/or/cvs/Nov-2008/msg00100.html">
364) Fehlerbehebung</a> behebt einen möglichen Speicherzugriffsfehler, der
365) wahrscheinlich für eine Menge an fehlgeschlagenen Messreihen verantwortlich
366) war. Ein anderer <a
367) href="https://bugs.torproject.org/flyspray/index.php?id=847&do=details">
368) Fehler</a> konnte erklärt werden, der zu massiven Verzögerungen beim Verbinden
369) mit dem Tor-Netzwerk führte: Sehr langsame Verzeichnissauthoritäten haben
370) startende Nutzer für lange Zeit beschäftigt, bis der Nutzer endlich aufgegeben
371) hat und seine Daten von einer anderen Authorität bezogen hat. Ein Ergebniss
372) war, dass die langsamsten 2 Verzeichnissauthoritäten ihren Rechnern mehr
373) Bandbreite spendiert haben, so dass der Effekt abgemindert wurde. Ein dritter
374) <a href="https://bugs.torproject.org/flyspray/index.php?id=874&do=details">
375) Fehler</a> wurde mit den Performanzverbesserungen für versteckte Dienste im
376) November eingeführt. Der Effekt war, dass Torprozesse, die versteckte Dienste
377) angeboten haben, diese nicht mehr veröffentlichten, nachdem sie ihre
378) Konfiguration neuluden. Ausserdem zeigte dieser Fehler, dass Tor seine
379) Introduction Points neu aufbaute, wenn es neugeladen wurde. Dies könnte die
380) Stabilität von versteckten Diensten beeinflusst haben. Der Fehler wurde
381) behoben und wird in der folgenden Version 0.2.1.9-alpha enthalten sein.</em>
382) </small> <br/>
383)
384) <small><em>Neben der Fehlerbehebung wurden neue Messungen zwischen dem 8. und
385) 10. Dezember durchgeführt. Dies werden wahrscheinlich die letzen Messungen
386) sein, um die Performanz von versteckten Diensten jetzt mit dem Anfang des
387) Projektes zu vergleichen. Die Daten wurden noch nicht komplett ausgewertet,
388) daher ist es aktuell schwer eine Aussage über Verbesserungen zu machen. jedoch
389) zeigt eine <a
390) href="http://freehaven.net/~karsten/hidserv/prelimreport-2008-12-15.pdf">
391) vorläufige Auswertung</a>, dass die Veröffentlichungszeit eines versteckten
392) Dienstes deutlich verbessert wurde. Dieser Erfolg kommt von der deutlich
393) verbesserten Startzeit für Tornutzer und den Verbesserungen die im November
394) eingebaut wurden. Im Gegensatz dazu sind die Ergebnisse der
395) Verbindungsherstellung zu versteckten Diensten deutlich schlechter. Obwohl die
396) Verbesserungen aus dem November einen positiven Effekt zu haben scheinen,
397) zeigen einige interne Schritte eine deutlich schlechtere Performanz als
398) vorher. Ein Beispiel dafür ist das Beziehen von Beschreibungsdateien
399) versteckter Dienste um eine Verbindung mit diesen herstellen zu können. Eine
400) mögliche Erklärung dafür ist dass der plötzliche Anstieg an Verzeichnissen für
401) versteckte Dienste einen negativen Einfluss auf die Leistungsfähigkeit hatte.
402) Ein Teil der Arbeit der letzten 31 Tage wird es sein, diese Daten genauer
403) auszuwerten und finale Schlüsse über die erreichten Ziele dieses Projektes zu
404) ziehen.</em></small> </td> </tr>
405)
406) <tr>
407) <td>
408) <a id="Jan09"></a>
409) <a class="anchor" href="#Jan09">Jan. 09</a>
410) </td>
411) <td>
412)
413) <small><em>Die Testphase ist zu Ende. Die Tests wurden in einer öffentlichen
414) Betaphase mit den gesamten Änderungen im 0.2.1.x-alpha Zweig von Tor
415) durchgeführt. Ein Ergebniss der öffentlichen Betaphase sind ein paar gefundene
416) Fehler, die bereits behoben werden konnten.</em></small> <br/>
417)
418) <small><em>Ein weiterer Teil des Testens war eine zweite Messreihe, die im
419) Dezember durchgeführt wurde. Ein <a
420) href="http://freehaven.net/~karsten/hidserv/comparison-2009-01-15.pdf">
421) Vergleich</a> der durchgeführten Messungen im Juni und im Dezember hat uns
422) gezeigt, dass die Veränderungen dieses Projektes effektiv sind. Die
423) Veröffentlichungszeit für versteckte Dienste konnte von im Mittel 2:12 Minuten
424) auf 58 Sekunden mehr als halbiert werden. Diese Verbesserung ist deutlich
425) besser als erwartet. Mit dieser Verbesserung könnte es sogar interessant sein,
426) über eine Reduzierung der Stabilisierungszeit von 30 Sekunden auf einen
427) niedrigeren Wert nachzudenken. Leider ist die Zeit die es dauert, zwischen der
428) Anforderung eines versteckten Dienstes und der Verbindungsherstellung zu
429) diesem, bei etwa 56 Sekunden geblieben. Der Hauptgrund für die fehlende
430) Verbesserung ist der Wechsel von einer zentralen, hin zu einer dezentralen
431) Speicherung der Beschreibungsdateien von versteckten Diensten. Dieser negative
432) Effekt durch die Verteilung des Verzeichnisses der versteckten Dienste wurde
433) nicht vorhergesehen. In Zukunft sollte daher an der Beschleunigung des
434) Herunterladens von Beschreibungsdateien aus dem verteilten Verzeichniss
435) gearbeitet werden. Zum Beispiel durch die Parallelisierung dieser
436) Anfragen.</em></small> <br/>
437)
438) <small><em>Dieser Report beendet die monatlichen Statusupdates. Die Verteilung
439) der 0.2.1.x Versionen mit den Verbesserungen für versteckte Dienste wird in
440) den nächsten Wochen und Monaten geschehen.</em></small>
441)
442) </td>
443) </tr>
444) </table>
445)
446) <br />
447)
448) <!-- Do we want a people section? If so, would it make sense to write what
449) these people will be doing? And what exactly are these people going to
450) do? :)
451) <a id="People"></a>
452) <h2><a class="anchor" href="#People">Leute</a></h2>
453) <ul>
454) <li><a href="<page people>#Core">Karsten Loesing</a></li>
455) <li><a href="<page people>#Core">Steven Murdoch</a></li>
456) </ul>
457) -->
458)
459) <a id="Links"></a>
460) <h2><a class="anchor" href="#Links">Links</a></h2>
461) <ul>
462) <li>Forschungsbericht über <b>Performance Measurements and Statistics of Tor
463) Hidden Services</b>
464) (<a href="http://www.uni-bamberg.de/fileadmin/uni/fakultaeten/wiai_lehrstuehle/praktische_informatik/Dateien/Publikationen/loesing2008performance.pdf">PDF</a>)
465) von Karsten Loesing, Werner Sandmann, Christian Wilms und Guido Wirtz. In
466) den Proceedings des 2008 International Symposium on Applications and the
|
added german translation fo...
closed tags