Mit Proxy schneller im Internet. Wo ist da die Logik?

Michael`

Enthusiast
Thread Starter
Mitglied seit
08.09.2005
Beiträge
734
Hätte da mal eine dumme Frage:

Warum ist das surfen über einen Proxy schneller als ohne?

Hab vor 2h nen Proxy im Internet eingerichtet und nun das erste mal im Firefox eingetragen. Sofort ist mir aufgefallen, das das Surfen deutlich schneller ist als ohne (schnellerer Seitenaufbau). Das entzieht sich allerdings meiner Vorstellungskraft. Wäre doch theoretisch so:

Ohne Proxy:

Browser ->2Mbit/s-> Webserver ->2Mbit/s-> Browser

Mit Proxy:

Browser ->2Mbit/s-> Proxy ->100Mbit/s-> Webserver ->100Mbit/s-> Proxy ->2Mbit/s->Browser

Wieso also sollte es mit Proxy schneller sein? Sollte langsamer sein! (Und nein, die Webseiten waren noch nicht im Cache).


MfG,
Michael
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Weil das routing deines ISPs Müll ist, er benutzt wohl viel billig Traffic was sich unter anderem in einem 5 minütigem Ladebalken bei Youtube usw auswirken kann.

Durch den Proxy verändert sich dein Routing wohl ins positive. Sei dir aber sicher, das er ganz bestimmt nicht anonym sein wird.
 
Falls du über den Proxy viel frequentierte Seiten besuchst, liegts ganz einfach daran, dass der Proxy dir die Seiten aus seinem Cache ausliefert und nicht vom richtigen Server.
 
(Und nein, die Webseiten waren noch nicht im Cache).
Lesen hilft :)


Danke für die Antworten. Mittlerweile konnte ich das ganze an drei Anschlüssen testen, überall das gleiche! 1x 2Mbit/s (KabelBW), 1x DSL 3Mbit/s (T-Online), 1x DSL 8Mbit/s (1und1).

Schon verrückt. Hab natürlich meinen engsten vertrauten nun auch diesen Proxy eingerichtet. Finde das ja fast schon ne schweinerei von den ISP`s - oder ist das technisch bedingt?


MfG,
Michael
 
Naja er meinte ja, das der Proxy selbst cache von meist besuchten Seiten speichert.
Das macht aber fast gar keiner!

Tja wenn immer mehr Leute schnelles Internet und das billig haben wollen, kauft man halt lieber billig Traffic ein und so sieht auch dann das routing aus.

Zahlt lieber ein paar Euro mehr und geht zu NetCologne, hansenet (alice), QSC (geschäftskunden teuer)
Bei denen ist das routing im gegensatz zu anderen Providern top.

Das Routing von der telekom sollte aber eigentlich auch nicht schlecht sein, kommt aber auch wiederum stark drauf an auf welche Seiten man geht und ob man einen Resale anschluss hat.
 
auch wenn OT, aber seit wann hat alice/hansenet denn bitte ein gutes Routing :confused: Das ist doch seit jeher einer der größten Kritikpunkte an denen...

@topic
Ich habe ähnliches auch schon festgestellt. Dass der Download über einen Proxy mit einer guter Anbindung meist deutlich schneller als direkt als über den Heim-Anbieter von Statten geht, hat schon mit besserem Routing zu tun. Da die meisten Websites aber recht kompakt sind, dürfte das beim Surfen relativ egal sein.

Ich vermute (!) eher, dass das schnellere Surfen von flotteren DNS-Servern kommt. Wenn der DNS-Server statt 10 oder 30 ms nur noch 0.5 ms weit "entfernt" ist (wie im RZ), scheint das schon einen Unterschied zu machen.
 
Naja er meinte ja, das der Proxy selbst cache von meist besuchten Seiten speichert.
Ich meinte damit den Cache des Proxys. Diese Webseiten wurden weder vom Proxy-Cache noch vom Client "gecached". Es stimmt also das das Routing/DNS (in meinem fall) über einen Server im Rechenzentrum DEUTLICH besser funktioniert (bzw. schneller).


MfG,
Michael
 
Hansenet hat sich auch eher in Gebieten Deutschlands eingerichtet wo es eher nicht so Top mit der Versorgung aussieht, z.B. in NRW war hansenet überhaupt nicht verfügbar (ich rede vom eigener Technik)
Im gegensatz zur Telekom hat man dort nämlich ein besseres Routing, da man von z.B. Gameservern die in Frankfurt/Düsseldorf stehen eh schon weiter weg wohnt.
Wenn man sich natürlich kein fastpath schalten lässt dann ist es überall nicht unbedingt optimal von den pingzeiten.
 
Mir kam gerade die Idee das ganze mit dem schlechten routing zu beweisen.

Die erste und einzigste Idee wäre ein tracert zu google.de und zum vergleich einen tracert über den Proxy zu google.de. Letzeres lässt sich aber leider nicht so einfach machen, da sich beim "Windows-Tracert-Programm" kein Proxy eintragen lässt.

Wie also könnte ich einen tracert durch den Proxy laufen lassen?


MfG,
Michael
 
Scheint auch mit diesem Programm nicht zu funktionieren. Lasse mich aber gerne eines besseren belehren.
 
Klar in den Optionen kannst du Proxys eintragen.

//Gerade mal geschaut, im Programm steht aber selber noch das der Proxy Server anpinngen erlauben muss..
 
Zuletzt bearbeitet:
Klar in den Optionen kannst du Proxys eintragen.
Hab die IP/Port vom Proxy eingetragen.

//Gerade mal geschaut, im Programm steht aber selber noch das der Proxy Server anpinngen erlauben muss..
Der (Proxy-)Server antwortet auch auf ICMP-Echo-Requests. Ein tracert auf google.de funktioniet zwar, die IP vom Proxy ist aber nicht auffindbar!?


MfG,
Michael
 
Wenn Du Dir den Proxy selbst "eingerichtet" hast wie im ersten Post geschrieben, solltest Du doch auch entsprechenden Zugang haben um einen tracert über den zu machen, oder? ;)
 
Wenn Du Dir den Proxy selbst "eingerichtet" hast wie im ersten Post geschrieben, solltest Du doch auch entsprechenden Zugang haben um einen tracert über den zu machen, oder?
Klar hab ich, aber was bringt mir ein tracert vom Server aus?!


MfG,
Michael
 
Mir kam gerade die Idee das ganze mit dem schlechten routing zu beweisen.

Die erste und einzigste Idee wäre ein tracert zu google.de und zum vergleich einen tracert über den Proxy zu google.de. Letzeres lässt sich aber leider nicht so einfach machen, da sich beim "Windows-Tracert-Programm" kein Proxy eintragen lässt.

Genau dafür?

Die "Gesamtroute" wenn Du etwas über den Proxy schickst, hast Du ja im allerersten Post schon richtig analysiert. :wink:

Bedenke allerdings, dass Routen asynchron in Sende-/Empfangrichtung sein können. Es ist daher nur ein grober Richtwert zu erreichen.
 
Ich weiß nicht, was du meinst. Nochmal genau was ich vorhabe:

Tracert 1:

Client -> google.de

Tracert 2:

Client -> Proxy -> google.de


Danach die Werte vergleichen, um zu beweisen das das Routing meines Providers bei Tracert 1 schlechter ist als bei Tracert 2.

Tracert 1 stellt kein Problem dar und den kann jedermann über die Windows-Interne tracert.exe nachmachen.

Tracert 2 muss allerdings über den Proxy laufen. In der Windows-Internen tracert.exe lässt sich aber leider kein Proxy eintragen.


Andere Möglichkeit für Tracert 2:

tracert von Client zu (Proxy-)Server + tracert vom Server zu google.de = Gesamtlaufzeit


Funktioniert das so einfach?

Wenn ja siehts so aus:


Tracert 1 von Client zu google.de (74.125.77.104):

Target Name: ew-in-f104.google.com
IP: 74.125.77.104
Date/Time: 03.05.2009 10:52:38

1 1 ms speedport.ip [192.168.0.1]
2 45 ms [***.***.***.***]
3 43 ms [***.***.***.***]
4 48 ms [***.***.***.***]
5 48 ms [72.14.198.117]
6 49 ms [66.249.94.86]
7 55 ms [72.14.233.107]
8 96 ms [209.85.250.140]
9 61 ms [209.85.248.79]
10 61 ms [72.14.239.197]
11 63 ms [209.85.255.98]
12 63 ms ew-in-f104.google.com [74.125.77.104]

Ping statistics for ew-in-f104.google.com
Packets: Sent = 1, Received = 1, Lost = 0 (0,0%)
Round Trip Times: Minimum = 63ms, Maximum = 63ms, Average = 63ms


Tracert 2 von Client zu (Proxy)-Server:

Target Name: *********************
IP: ****************
Date/Time: 03.05.2009 10:53:54

1 1 ms speedport.ip [192.168.0.1]
2 44 ms [217.0.116.230]
3 43 ms [217.0.78.90]
4 52 ms [217.5.71.30]
5 52 ms **************************** [***.***.***.***]
6 53 ms **************************** [***.***.***.***]
7 52 ms **************************** [***.***.***.***]
8 * [-]
9 53 ms **************************** [***.***.***.***]

Ping statistics for ************************
Packets: Sent = 1, Received = 1, Lost = 0 (0,0%)
Round Trip Times: Minimum = 53ms, Maximum = 53ms, Average = 53ms

Tracert 2 von Server zu google.de (74.125.77.104):

***@**********:/$ traceroute 74.125.77.104
traceroute to 74.125.77.104 (74.125.77.104), 30 hops max, 40 byte packets
1 * * *
2 **************************** (***.***.***.***) 0.217 ms 68.502 ms 0.186 ms
3 **************************** (***.***.***.***) 0.663 ms 0.627 ms 0.590 ms
4 **************************** (***.***.***.***) 5.200 ms 39.169 ms 5.076 ms
5 de-cix10.net.google.com (80.81.192.108) 5.190 ms 5.011 ms 5.007 ms
6 209.85.255.172 (209.85.255.172) 5.841 ms 209.85.255.170 (209.85.255.170) 6.543 ms 209.85.255.172 (209.85.255.172) 5.581 ms
7 72.14.232.208 (72.14.232.208) 11.740 ms 209.85.248.182 (209.85.248.182) 12.159 ms 209.85.250.140 (209.85.250.140) 12.330 ms
8 72.14.233.114 (72.14.233.114) 16.545 ms 64.233.175.246 (64.233.175.246) 16.477 ms 14.170 ms
9 72.14.239.199 (72.14.239.199) 15.970 ms 209.85.255.166 (209.85.255.166) 15.897 ms 72.14.239.197 (72.14.239.197) 15.474 ms
10 209.85.255.102 (209.85.255.102) 28.515 ms 17.033 ms 18.103 ms
11 ew-in-f104.google.com (74.125.77.104) 16.267 ms 16.108 ms 16.401 ms


Wären dann bei...

Tracert 1: 63ms Laufzeit
Tracert 2: 53ms + 16ms = 69ms Laufzeit

... was genau das Gegenteil beweisen müsste, nämlich das das routing ohne Proxy schneller sein müsste. War die Überlegung mit dem addieren falsch?



MfG,
Michael
 
ja u. nein

die frage ist auch wie der Proxy arbeitet den der Proxy kann zb wenn du eine Seite aufrufst alle Inhalte schon abrufen während er deinen Browser noch beliefert den eine Seite besteht ja aus weit mehr als nur einer HTML(Bilder Scripte etc)

beim Firefox kann man ja zb. einstellen wie viele gleichzeitige verbindungen er nutzen darf um wirklcih herauszufinden woran es genau liegt müstet du den quellcode kennen/anaysieren

aber es wirkt sich schon merkbar aus das der Proxy so einen geringen Ping hat so kann er die Verbindungen viel schneller aufbauen/beenden den so gut wie alle Webserver sind ja auch entsprechend schnell angebunden

ein nicht zu unterschätzendes detail ist auch noch die Größe der Objekte die transportiert werden müssen dem wird ein Tracert o. Ping nicht ganz gerecht wenn eine HTML like HWL 89kiB u. dazugehörige Objekte 349kiB durchs Internet geschleust werden denn die meisten switche skalieren nicht mal einfach Linear mit der Größe der TCP Rakete sondern brechen enorm ein dazu kommt dann noch Trafik Shaping beim Peering etc also das ist ein ganz schön komplexes Problem

sinnvoll ist es allerdings auch lokal einen Proxy zu verwenden um möglichst viele Verbindungen zu sparen den auch die Webserver haben mit langsamen Verbindungen ein Problem da sie diese ja aufhalten müssen

ich nutze zb. zwei Proxy nur zu hause einen direkt im router und einen auf meinem Server um Werbung etc zu blocken da kommen am tag mal einige 100.000 Verbindungen zusammen die erst gar nicht aufgebaut werden müssen besonders Werbung braucht teilweise lange
 
aber es wirkt sich schon merkbar aus das der Proxy so einen geringen Ping hat so kann er die Verbindungen viel schneller aufbauen/beenden den so gut wie alle Webserver sind ja auch entsprechend schnell angebunden

ein nicht zu unterschätzendes detail ist auch noch die Größe der Objekte die transportiert werden müssen dem wird ein Tracert o. Ping nicht ganz gerecht wenn eine HTML like HWL 89kiB u. dazugehörige Objekte 349kiB durchs Internet geschleust werden denn die meisten switche skalieren nicht mal einfach Linear mit der Größe der TCP Rakete sondern brechen enorm ein dazu kommt dann noch Trafik Shaping beim Peering etc also das ist ein ganz schön komplexes Problem
Dachte ich mir schon das da einiges zusammenkommt. Der Geschwindigkeitsvorteil ist also schlichtweg nur sehr schwer messbar. Subjektiv kann man aber sagen das das surfen mit Proxy deutlich schneller funktioniert.

sinnvoll ist es allerdings auch lokal einen Proxy zu verwenden um möglichst viele Verbindungen zu sparen den auch die Webserver haben mit langsamen Verbindungen ein Problem da sie diese ja aufhalten müssen

ich nutze zb. zwei Proxy nur zu hause einen direkt im router und einen auf meinem Server um Werbung etc zu blocken da kommen am tag mal einige 100.000 Verbindungen zusammen die erst gar nicht aufgebaut werden müssen besonders Werbung braucht teilweise lange
Darf ich fragen, welche Proxy-Software du benutzt? Ich hab hier Squid und bin von der einfachen konfiguration sehr überrascht. Werbung kann man ja anscheinend mit SquidGuard blocken, was natürlich ein sehr geniales feature ist. Ich hab mich mit SquidGuard jetzt noch nicht beschäftigt, werde mich aber in nächster zeit ein bisschen einlesen.

Kann man mit SquidGuard wirklich Werbung blocken? Wenn ja, wie wird das ganze konfiguriert? So ne art Browser-Implementierung wie beispielsweise NoScript/Adblock für Firefox, die mit dem SquidGuard kommuniziert wäre sehr geil. So müsste der Server den "Webseitenrotz" erst garnicht laden bzw. nicht an den Client weiterleiten.



MfG,
Michael
 
Das kann man mit SquidGuard machen, aber es geht auch ganz einfach mit ACLs und nem Cron Job, der regelmäßig eine aktuelle Filterliste holt.
Code:
acl ads dstdom_regex -i "/etc/squid/ad_block.txt"
http_access deny ads
Update Skript, das vom Cron Job ausgeführt wird:
Code:
## get new ad server list
wget -O /tmp/temp_ad_file http://pgl.yoyo.org/adservers/serverlist.php?hostformat=squid-dstdom-regex;showintro=0

## clean html headers out of list
cat /tmp/temp_ad_file | grep "(\^|" > /etc/squid/ad_block.txt

## refresh squid
/usr/sbin/squid -k reconfigure

## rm temp file
rm -rf /tmp/temp_ad_file
Man kann natürlich auch andere Filterlisten nehmen als die von yoyo.org, muss dann aber ggf. die Einträge als RegEx umschreiben lassen.
 
Gerade mal (etwas abgeändert) ausprobiert. Funktioniert einwandfrei. Leider sind die Listen, die ich im Internet gefunden hab meist für Werbebanner aus den USA oder Russland. Einfach mal kurz für eine Website nen Banner wegbekommen ist halt nicht so einfach.

Mittlerweile wächst die squid.conf. Auch Transparenz hab ich nun aktiviert, scheint zu funktionieren und ist nicht langsamer geworden.

Hier meine squid.conf:

http_port ***

cache_mem 200 MB
cache_dir ufs /var/squid/cache 3000 16 256

acl all src 0.0.0.0/0.0.0.0
http_access allow all

acl VERBOTEN url_regex "/home/squid/adlist/ad_block.txt"
http_access deny VERBOTEN


quick_abort_min 0 KB
quick_abort_max 0 KB
quick_abort_pct 100

forwarded_for off

header_access Via deny all
header_access X-Forwarded-For deny all

cache_effective_user squid

Fehlt nur noch die User-Authentifizierung. Das scheint leider nicht so einfach zu gehen (dachte da an ne simple Textdatei mit Benutzernamen und Passwörtern).



MfG,
Michael
 
Authentifizierung per HTTP Basic Auth:
Code:
auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/proxy_users
# Pfade anpassen, User zum Passwort-File hinzufügen mit htpasswd /etc/squid/proxy_users username
auth_param basic children 5
auth_param basic realm Private Cache
auth_param basic casesensitive on

Die Zeile http_access allow all ersetzen durch:
Code:
acl localhost src 127.0.0.1/255.255.255.255    # ACL für localhost
acl allowed_ips src 84.0.0.0/8 217.0.0.0/8     # hier kann man IPs und IP-Ranges eintragen, die Zugriff haben sollen
acl auth_users proxy_auth REQUIRED             # Per HTTP Basic Auth authentifizierte User

http_access allow allowed_ips auth_users       # Verbindungen akzeptieren, wenn sie von einer IP in allowed_ips ausgeht UND der Benutzer authentifiziert ist
http_access allow localhost                    # Verbindungen von localhost akzeptieren
http_access deny all                           # alle anderen Verbindungen blockieren
 
Hab nun ein paar User mit htpasswd erstellt, funktioniert erste Sahne. Wollte dann auch noch Client-Software ala Proxifier einsetzen, musst aber dann feststellen, das das mit Squid aufgrund fehlendem SOCKS4/5 nicht geht - schade eigendlich.

Allerdings möchte ich noch Quotas für die User vergeben (50GB/Monat). In einem anderen Internetforum bin ich auf den Begriff delay-pools gestoßen. Leider wird in der offiziellen Dokumentation kein Wort darüber verloren. Hat noch jemand Ahnung, woher ich weitere Infos über delay-pools bekommen kann?



MfG,
Michael


EDIT: Mann, macht das Spaß!

Hab nun, um den Datenverkehr von mir bis zum Proxy zu verschlüsseln OpenVPN verwendet (2048-bit RSA-PSK). Nun läuft der Gesamte Datenverkehr meines Rechners über die VPN/Proxy-Kombination. Freu :)

Die Geschwindigkeit ist aber immer noch ok, durch den VPN ist es jetzt minimal langsamer geworden.

Die Config ist nun leicht Paraniod, aber man weiß ja nie. Es stört mich ja auch nicht alles so zu lassen und Nachteile kann ich keine erkennen.

Hat jemand eine ähnliche Konfiguration? Möchte mal erfahren wie Ihr euch schützt!


MfG,
Michael
 
Zuletzt bearbeitet:
Jop hab genau dieselbe Konfiguration. Proxy-Zugriff via VPN mit beidseitiger Zertifikatsauthentisierung oder HTTP Basic Auth kombiniert mit IP-Filtern. Meine Waffe gegen das von der Leyen Gesetz, sollte sich die Petition nicht durchsetzen, das Gesetz verabschiedet werden und die Provider auf die dumme Idee kommen Zwangsproxys einzuführen (was zumindest bei der Telekom recht wahrscheinlich ist).
 
Zuletzt bearbeitet:
dann auch noch Client-Software ala Proxifier einsetzen, musst aber dann feststellen, das das mit Squid aufgrund fehlendem SOCKS4/5 nicht geht - schade eigendlich.

Proxifier lief bei mir mit dem Squid. Ging glaube ich über HTTPS. Da gibts aber ein default Timeout von 30 Minuten oder so. Wenn du also über deinen Proxy noch zocken willst, solltest du unbedingt das HTTPS Timeout hochsetzen.
 
Proxifier lief bei mir mit dem Squid. Ging glaube ich über HTTPS. Da gibts aber ein default Timeout von 30 Minuten oder so. Wenn du also über deinen Proxy noch zocken willst, solltest du unbedingt das HTTPS Timeout hochsetzen.
Hat sich ja nun mit dem OpenVPN erledigt, das hat den gleichen, sogar besseren Effekt. Trotzdem gut zu wissen, danke.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh