Thread
Forum zu:
Threads:
Übersicht
Menü

EDGE zu langsam?


27.08.2006 22:15 - Gestartet von techie
Vorab folgendes: Ich habe selber natürlich (noch) keinerlei Erfahrung mit EDGE (machen dürfen), verfübe aber über ausreichende UMTS-Erfahrung.

Die Aussage, daß die EDGE-Verbindung beim Surfen fast (oder exakt) genauso langsam ist, wie GPRS-Verbindungen, bezweifle ich. Das paßt auch zu der gemacht Aussage, daß Downloads wiederum merklich schneller gehen, als bei GPRS.

Wo bitte sollte der Unterschied zwischen einem (größeren) Download und dem Surfen liegen? In beiden Fällen werden TCP-Sessions zu einem (HTTP-)Server aufgemacht und von diesem Daten empfangen.

Der einzige Unterschied zwischen beiden ist folgender: Bei einer Surf-Session wird nicht nur eine TCP-Session zu einem HTTP-Server geöffnet und alles übertragen, sondern die (HTML-)Datei wird vom Server geholt und jedes zusätzliche Element (z.B. Grafiken, Skripte, Style-Sheets) in jeweils einer eigenen TCP-Session. Da viele Elemente nicht vom gleichen Server kommen (bzw. nicht mit identischem Hostnamen), müssen in den meisten Fällen mehrere DNS-Anfragen abgesetzt werden.

Diese DNS-Anfragen wiederum sind sehr zeitaufwändig und dies merkt man erstrecht bei Funk-Verbindungen (wie GPRS und UMTS) durch die hohe Latenzzeit.

Der Test sollte mit einem cachenden DNS-Resolver wiederholt werden und die Aussage im Bericht anschließend korrigiert werden, denn so, wie sie im Bericht steht, ist sie falsch.

Kommen die Inhalte alle vom gleichen Server, sodaß beim Surfen nur Inhalte von einem Host aus kommen, kann man durch optimiertere Einstellungen die hohe Latenzzeit bei GPRS/UMTS/EDGE, die gerade bei der Eröffnung von neuen TCP-Sessions merklich wird, etwas umschiffen. Dies kann durch Browser-Einstellungen "Persistant Server Connections" verbessert werden oder durch Einsatz eines Proxies.
Menü
[1] fruli antwortet auf techie
27.08.2006 22:36

einmal geändert am 27.08.2006 22:40
Hi,

der Unterschied zwischen der Geschwindigkeit bei umfangreichen Downloads und der Geschwindigkeit beim Surfen auf Websites mit vielen Bildern/Elementen liegt vor allem darin, dass bei Downloads die extrem hohe Latenz von EDGE/GPRS im Bereich von bis zu einer halben Sekunde keine Rolle spielt während sich diese hohe Latenz beim Surfen auf Seiten mit vielen Elementen potenziert auswirkt: für jedes Bild/Script/Element einer Webseite wird ein http-Request fällig - und die 0,5-Sekunden-Reaktionszeit schlägt daher bei jedem Request voll durch - selbst wenn einige http-Requests parallel ablaufen (wie viele parallel ablaufen kann man z.B. in den Netzwerk-Einstellungen von Opera konfigurieren), bedeutet das bei umfangreichen Webseiten doch eine merkliche Verzögerung bis die Seite komplett geladen ist.

So long.
fruli
Menü
[1.1] techie antwortet auf fruli
27.08.2006 23:29

einmal geändert am 27.08.2006 23:31
Benutzer fruli schrieb:
Hi,

der Unterschied zwischen der Geschwindigkeit bei umfangreichen Downloads und der Geschwindigkeit beim Surfen auf Websites mit vielen Bildern/Elementen liegt vor allem darin, dass bei Downloads die extrem hohe Latenz von EDGE/GPRS im Bereich von bis zu einer halben Sekunde keine Rolle spielt während sich diese hohe Latenz beim Surfen auf Seiten mit vielen Elementen potenziert auswirkt: für jedes Bild/Script/Element einer Webseite wird ein http-Request fällig - und die 0,5-Sekunden-Reaktionszeit schlägt daher bei jedem Request voll durch - selbst wenn einige http-Requests parallel ablaufen (wie viele parallel ablaufen kann man z.B. in den Netzwerk-Einstellungen von Opera konfigurieren), bedeutet das bei umfangreichen Webseiten doch eine merkliche Verzögerung bis die Seite komplett geladen ist.

So long.
fruli

Hi fruli,

in Deiner Aussage sehe ich keinen (großen) Widerspruch zu meiner Aussage. Du hast nur andere Worte benutzt.

An Deiner Darstellung stören mich nur folgende Dinge:

1) Die HTTP-Requests sind vollkommen unerheblich und wirken sich nicht aus. Was sich aber (durch die Latenz) auswirkt, sind TCP-Sessions. Normalerweise führt (ohne "Persistent Connections") jeder HTTP-Request auch zu einer neuen TCP-Session und wenn Du das als gegeben vorausgesetzt hast, dann stimmt die Aussage.

Genau hier kommen auch die Persistent Connections ins Spiel: TCP-Sessions werden einfach "recycled" und innerhalb einer TCP-Session werden mehrere HTTP-Requests abgesetzt und vom Server beantwortet. Dies setzt allerding voraus, daß 1) HTTP1.1 eingesetzt wird und 2) sowohl Server, wie auch Client Persistent Connections unterstützen.

2) Ob parallele HTTP-Requests genutzt werden, hängt vom Browser ab und das geht nur, wenn er Multi-Threading unterstützt (entzieht sich meiner Kenntnis, welcher Browser MT unterstützt().

3) Die hohe Latenz wirkt sich natürlich auch beim (größeren) Download aus. Er wird vom Benutzer nur nicht merklich wahrgenommen. Der HTTP-Server schickt die TCP-Pakete nämlich auf die Leitung und wartet nicht nach jedem Paket auf ein ACK durch den Client (was stark latenzbehaftet geschickt wird).

4) Die DNS-Anfragen sollten natürlich auch nicht in Vergessenheit geraten, auf die sich die Latenz auch auswirkt. Die sorgen nämlich gravierend dafür, daß bevor auch nur die ersten Daten vom Server kommen und der Client irgendwas zum rendern bekommt, auf die DNS-Anfrage gewartet werden muß. Dieser Vorgang kann schonmal einige Sekunden dauern (ebenfalls dank der hohen Latenz).
Menü
[1.1.1] fruli antwortet auf techie
27.08.2006 23:38
Hi,

Benutzer techie schrieb:

in Deiner Aussage sehe ich keinen (großen) Widerspruch zu meiner Aussage. Du hast nur andere Worte benutzt.

Stimmt - ich hatte deinen Beitrag tatsächlich nicht ausführlich genug gelesen sondern nur überflogen und ich hatte dabei den (falschen) Eindruck, du zielst v.a. auf DNS als alleinige Ursache des langsameren Surf-Eindrucks ab.


An Deiner Darstellung stören mich nur folgende Dinge:

1) Die HTTP-Requests sind vollkommen unerheblich und wirken sich nicht aus. Was sich aber (durch die Latenz) auswirkt, sind TCP-Sessions. Normalerweise führt (ohne "Persistent Connections") jeder HTTP-Request auch zu einer neuen TCP-Session und wenn Du das als gegeben vorausgesetzt hast, dann stimmt die Aussage.

Ja, das setzte ich -vereinfachend dargestellt- voraus - was aber nicht immer so ist, wie du ja ausführlich darstellst.

3) Die hohe Latenz wirkt sich natürlich auch beim (größeren) Download aus.

Schon, aber:

Er wird vom Benutzer nur nicht merklich wahrgenommen.

genau darauf zielte meine Bemerkung ab.

4) Die DNS-Anfragen sollten natürlich auch nicht in Vergessenheit geraten, auf die sich die Latenz auch auswirkt. Die sorgen nämlich gravierend dafür, daß bevor auch nur die ersten Daten vom Server kommen und der Client irgendwas zum rendern bekommt, auf die DNS-Anfrage gewartet werden muß. Dieser Vorgang kann schonmal einige Sekunden dauern (ebenfalls dank der hohen Latenz).

Gut, das hat bei meinem mobilen Surfen jedoch keine Auswirkungen, da ich immer per zwischengeschaltetem Proxy des Netzbetreibers surfe, was dieses Problem ausschaltet (wie du ja bereits in deinem ersten Posting geschrieben hast)

So long.
fruli
Menü
[1.1.1.1] techie antwortet auf fruli
28.08.2006 00:08
Benutzer fruli schrieb:
Gut, das hat bei meinem mobilen Surfen jedoch keine Auswirkungen, da ich immer per zwischengeschaltetem Proxy des Netzbetreibers surfe, was dieses Problem ausschaltet (wie du ja bereits in deinem ersten Posting geschrieben hast)

ReHi fruli,

genau, denn bei einem (eingestellten) Proxy im Browser macht der Client keine DNS-Anfrage mehr - er schickt einfach den HTTP-Request zum Proxy und überläßt die DNS-Auflösung dem Proxy. Das sollte das Browserverhalten merklich beschleunigen.

Schlaf gut! ;)
Menü
[1.1.1.1.1] Telly antwortet auf techie
28.08.2006 00:42
Benutzer techie schrieb:
Benutzer fruli schrieb:
Gut, das hat bei meinem mobilen Surfen jedoch keine Auswirkungen, da ich immer per zwischengeschaltetem Proxy des Netzbetreibers surfe, was dieses Problem ausschaltet (wie du ja
bereits in deinem ersten Posting geschrieben hast)

ReHi fruli,

genau, denn bei einem (eingestellten) Proxy im Browser macht der Client keine DNS-Anfrage mehr - er schickt einfach den HTTP-Request zum Proxy und überläßt die DNS-Auflösung dem Proxy. Das sollte das Browserverhalten merklich beschleunigen.

Schlaf gut! ;)

Nachdem ich Euch so schön zugelauscht habe, hier eine Frage von einem Laien.

Kann ich meine Surfgeschwindigkeit auch bei einem Schmalbandzugang durch Hinzunahme eines Proxies steigern?

Wenn ja.... wie muss ich das genau machen. Ich habe davon nämlich keine Ahnung.

Danke schon jetzt

Telly
Menü
[1.1.1.1.1.1] techie antwortet auf Telly
28.08.2006 01:25
Hi Telly,

Benutzer Telly schrieb:
Nachdem ich Euch so schön zugelauscht habe,

...der Lauscher an der Wand... :)

Kann ich meine Surfgeschwindigkeit auch bei einem Schmalbandzugang durch Hinzunahme eines Proxies steigern?

Wenn ja.... wie muss ich das genau machen. Ich habe davon nämlich keine Ahnung.

Jaein... nicht wirklich. Der Proxy (sofern man einen irgendwo im Netz zur Verfügung hat) hilft (teilweise) bei den Latenzproblemen, die das Funknetz mit sich bringen.

Ich nehme mal an, daß Du einen einzelnen Rechner (Windows?) hinter einer schmalbandingen Leitung betreibst und nun einen Proxy (irgendwo im öffentlichen Internet) nutzen willst. Was die DNS-Anfragen (vorhergehende Diskussion mit Fruli) angeht, gilt hier natürlich das Gleiche: Der Client (also Dein Rechner) muß die nicht mehr machen, sondern der Proxy. Daraus ergibt sich (auf der leitungsgebundenen, schmalbandigen Verbindung nur ein kleiner) Performancegewinn (den sollte man aber bei kabelgebundenen Verbindungen nicht zu hoch einschätzen - könnte sogar eher zu vernachlässigen sein).

Was aber durchaus etwas bringen könnte, wäre, wenn der Proxy, den Du ansteuerst, gzip unterstützt. Dabei würde nämlich der Proxy allen Datenverkehr zu Dir komprimiert schicken. Das würde mehr "Transportkapazität" auf Deiner schmalbandigen Verbindung "herauskitzeln", allerdings Deinen Client auch wiederum etwas mehr Rechenleistung (durch die Dekompression) abfordern. Die Kompression bringt aber nur bei nicht komprimierten Inhalten etwas (HTML, GIF usw.) - hätte bei JPEG oder ZIP-Dateien aber keinen Vorteil (da dieser Inhalt schon komprimiert ist).

Solltest Du mehrere Clients in einem LAN hinter einer Schmalbandleitung betreiben, würde ein lokaler Proxy auch Vorteile bringen (wenn auch anders gelagert). Dieses Thema würde jetzt aber deutlich überlange Postings nach sich ziehen, dies hier im Forum auch noch zu schildern.

HTH!
Menü
[1.1.1.1.1.1.1] fruli antwortet auf techie
28.08.2006 13:41
Hi,

Benutzer techie schrieb:

Was aber durchaus etwas bringen könnte, wäre, wenn der Proxy, den Du ansteuerst, gzip unterstützt. Dabei würde nämlich der Proxy allen Datenverkehr zu Dir komprimiert schicken. Das würde mehr "Transportkapazität" auf Deiner schmalbandigen Verbindung "herauskitzeln", allerdings Deinen Client auch wiederum etwas mehr Rechenleistung (durch die Dekompression) abfordern. Die Kompression bringt aber nur bei nicht komprimierten Inhalten etwas (HTML, GIF usw.) - hätte bei JPEG oder ZIP-Dateien aber keinen Vorteil (da dieser Inhalt schon komprimiert ist).

Solche speziellen Komprimierungs-Proxys werden ja z.T. vermarktet z.B. vom umstrittenen Anbieter safersurf/nutzwerk

Die Mobilfunkanbieter und z.B. auch Freenet beim Dialin-Schmalband-Zugang freenetSpeed haben transparente Proxys im Einsatz, die Bilddaten verlustbehaftet komprimieren (konfigurierbar)

https://www.teltarif.de/a/freenet/speed.html


Man sollte auch wissen, dass bei Analogmodem-Verbindungen grundsätzlich die V.42bis/V.44-Hardwarekomprimierung aktiv ist und bereits einen Gutteil der durch Proxy-gzip-Kompression möglichen Geschwindigkeitssteigerung dadurch erreicht wird.

Bei ISDN-Einwahl bieten Dialin-Provider je nach Dialin-Backbone und verwendetem Betriebssystem/PPP-Stack passende PPP-Software-Komprimierung ("ISDN-Softwarekomprimierung"; auch nutzbar bei Analogmodemverbindungen) an: BT-Dialin-Backbone, Colt-Dialin-Backbone und Telefonica-Dialin-Backbone mstac und mppc; Verizon (Ex-UUnet/MCI Worldcom)- und T-Com-Dialin-Backbones nur mstac für Win98/FritzWeb

Die damit erzielbaren Komprimierungs/Geschwindigkeitsgewinne bewegen sich im Mittel zwischen einem Komprimierungs-Proxy und der Analogmodem-Hardware-Komprimierung.

So long.
fruli
Menü
[1.1.1.1.1.1.2] Telly antwortet auf techie
28.08.2006 13:43
Ich danke Dir für Deine Ausführungen.

Aber es ist dann doch nicht die Revolution;-)

Telly
Menü
[1.1.2] hafenbkl antwortet auf techie
29.08.2006 13:31
Benutzer techie schrieb:
Genau hier kommen auch die Persistent Connections ins Spiel: TCP-Sessions werden einfach "recycled" und innerhalb einer TCP-Session werden mehrere HTTP-Requests abgesetzt und vom Server beantwortet. Dies setzt allerding voraus, daß 1) HTTP1.1 eingesetzt wird und 2) sowohl Server, wie auch Client Persistent Connections unterstützen.

Bei SeaMonkey/Mozilla:
network.http.max-persistent-connections-per-server