calendar
« Okt123456789101112131415161718192021222324252627282930 Dez »

Der Tor-Speed

Dieser Text ist im Cache von metaowl.de - das Original ist hier zu finden.
Immer wieder höre ich mir – im Zeitalter von "fetten" Breitbandanbindungen – verständliches Gemecker über die niedrigere Geschwindigkeit beim anonymisierten Websurfen mit Tor an. Mir persönlich ist das Nebensache, mal abgesehen von den auftretenden Fehlschlägen bei der Namensauflösung von einzelnen Adressen, weil z. B. der Exit Node bzw. dessen DNS überlastet ist.

Aber ein Blick auf die Interna des "Tor Netzwerks" sollten jedem Meckerer klar machen, dass es bei einer Browser Verbindung über Tor nun mal nicht mit einer vorherigen Abfrage bei einem DNS-Server und dem nachfolgenden "direkten" und unverschlüsselten Abrufen von Inhalten getan ist, wobei ja auch dort eine "direkte" Verbindung zwischen Clientrechner und Website eher die Ausnahme ist. Im Normalfall werden die Anfragen und Abrufe über mehrere Router, Gateways usw. transportiert, wobei die beteiligten Rechner im Gegensatz zum Tor Netz meistens aus leistungsstarken Maschinen mit guten Anbindungen bestehen und eben nicht aus Privatrechnern mit den gängigen Internetanbindungen, auf denen oft zeitgleich anderen Verbindungen abgewickelt werden.

Das Tor Netz ist höchst unterschiedlich: Man findet dort Tor Router, die auf leistungsstarken Rechnern mit Standleitungen großer Bandbreite laufen, aber auch den kleinen Kauf-PC, der gerade mal die geforderten 20 kilobytes Minimum für Tor abzwacken kann. Manche Tor Nodes können für die Namensauflösung der angefragten Adressen auf gute DNS-Anbindungen zurückgreifen, manche eben nicht. Tor Router laufen auf Linuxmaschinen, die genug gleichzeitige TCP-Verbindungen öffnen können oder auf Windowsrechnern, die von Microsoft künstlich beschränkt und erst einmal selbst gepatcht werden müssen. Einige Tor Nodeadmins aktualisieren ihre Tor Version regelmäßig, um an möglichen Verbesserungen bezüglich Verbindungen, Namensauflösung und Geschwindigkeit teilzuhaben, andere Admins lassen ihre Nodes mit veraltenen Tor Versionen vor sich hin dümpeln.

Bei allen Vorgängen spielt bei Tor die Verschlüsselung eine große Rolle – angefangen bei der ersten Verbindung vom lokalen Tor Proxy zum ersten Kontaktnode im Tor Netz, über die Aushandelung von Schlüsseln bis zur Ver- und Entschlüsselung der transportierten Daten zwischen allen drei Tor Routern, die pro Anfrage beteiligt sind. Das bedeutet "Arbeit" – sowohl auf der eigenen Maschine, als auch auf allen Tor Routern, also Zeitaufwand.
Kleine Übung: Man nehme eine dicke Zwiebel, löse die Schalen so von außen nach innen, dass jede Schale unbeschädigt bleibt und füge anschließend die Zwiebel wieder mit allen Schalen zusammen.

Und last but not least seid Ihr nicht alleine da draußen. Ein Tor Node hat vielleicht gerade einmal 10 Verbidnungen, während zeitgleich ein anderer Tor Node Hunderte von Verbindungen abzuwicklen hat. Es gibt Tor "Nutzer", die sich mit dem Abruf von Webseiten oder E-Mails zufrieden geben und es gibt Nutzer, die jedes Videofile und jedes Programm megabyteschwer über die "Leitungen" des Tor Netzes heruntersaugen.

Trotzdem ein paar Tipps am Ende, die hier zu einer teilweisen Verbesserung (die wird in einem Netz wie Tor immer realtiv bleiben) der Geschwindigkeit beigetragen haben:
  • Statt der stabilen Version wird die aktuelle Entwicklerversion von Tor heruntergeladen und eingesetzt.
  • Für Firefox wird die Erweiterung Fasterfox installiert, mit der man mit ein paar Klicks auf "Optimiert" oder "Turbo" die Einstellungen ändern bzw. verbessern kann, die sich auf die Performance und Netzwerkfunktionen von Firefox auswirken.
  • Es wird die aktuelle 3.0.5-Beta von Privoxy heruntergeladen und eingesetzt, die u. a. die Konfigurationsoption forwarded-connect-retries n für die Privoxy Konfigurationsdatei config[.txt] bietet und angibt, wie oft (mit n = 1-3 würde ich testen) Privoxy einen erneuten Verbindungsversuch unternimmt, wenn eine weitergeleitet Verbindung fehlschlägt, sich also auch auf die Weiterleitungen zum Tor Proxy bezieht:
    forwarded-connect-retries is mainly interesting for socks4a connections, where Privoxy can't detect why the connections failed. The connection might have failed because of a DNS timeout in which case a retry makes sense, but it might also have failed because the server doesn't exist or isn't reachable. In this case the retry will just delay the appearance of Privoxy's error message.
Ansonsten: Benutzt Tor wie es ist oder lasst es bleiben. Wählt selbst Eure Prioritäten: Daurnder Zeitgewinn und Speed oder Schutz vor Profiling, Data-Mining und Vorratsspeicherung. Und wer das nächste Mal meckert, bekommt den Tor-Speed Link vor den Latz geknallt.
von rabenhorst - Owl, gepostet am Montag, 13. November 2006 um 17:04
Aufgrund der Textinhalte könnten folgende Beiträge thematisch zu diesem Beitrag passen:
Stoppt die Vorratsdatenspeicherung! Jetzt klicken & handeln!Willst du auch bei der Aktion teilnehmen? Hier findest du alle relevanten Infos und Materialien: