Wie wird DL-Geschwindigkeit gesteuert?
- Ersteller M
- Erstellt am
M
Grand Admiral Special
Mir ist aufgefallen, dass ein Download nicht automatisch mit meiner voll zur Verfügung stehenden Geschwindigkeit erfolgt. Vielmehr tastet sich die Geschwindigkeit an das ran was der gegenüberliegende Server hergeben mag. Ist das Maximum einmal erreicht bleiben wir da oder werden durch meine genutzte Leitung limitiert.
Starte ich nun einen Zweiten Download, so teilen sich beide die zur Verfügung stehende Bandbreite bis einer der beiden zuerst fertig ist. Der andere DL geht aber nicht sofort zur vollen Bandbreite über. Er klettert eher langsam wieder hoch.
Ich kann mir das nur so erklären, dass dieses im Rahmen von Serverökonomie erfolgt. Youtube macht es ja nicht anders. Dort wird der Traffic für jede Verbindung auf das beschränkt, was man zum anschauen des Videos benötigt. Dies macht auf jeden Fall mehr Sinn als an jeden Nutzer unnötig 100mbit rauszufeuern. Dann würde bei den Nutzerzahlen ja bald garnix mehr gehen.
Da ich mir das alles nur zusammengereimt habe wär es jetzt nochmal toll wenn mir jemand erklären kann, wie es wirklich aussieht
Starte ich nun einen Zweiten Download, so teilen sich beide die zur Verfügung stehende Bandbreite bis einer der beiden zuerst fertig ist. Der andere DL geht aber nicht sofort zur vollen Bandbreite über. Er klettert eher langsam wieder hoch.
Ich kann mir das nur so erklären, dass dieses im Rahmen von Serverökonomie erfolgt. Youtube macht es ja nicht anders. Dort wird der Traffic für jede Verbindung auf das beschränkt, was man zum anschauen des Videos benötigt. Dies macht auf jeden Fall mehr Sinn als an jeden Nutzer unnötig 100mbit rauszufeuern. Dann würde bei den Nutzerzahlen ja bald garnix mehr gehen.
Da ich mir das alles nur zusammengereimt habe wär es jetzt nochmal toll wenn mir jemand erklären kann, wie es wirklich aussieht
Naja, die Download-Geschwindigkeit wird ja bei dir von deinem Client (z.B. dem Browser) errechnet. Der macht nichts anderes, als die Datenmenge die in einer bestimmten Zeit angekommen ist zu messen. Darum dauert es immer eine Weile, bis ein annährend richtiger Wert angezeigt wird. 
Gruß,
Max
Gruß,
Max
M
Grand Admiral Special
Ich wollte eigentlich nicht wissen wie die Geschwindigkeit errechnet wird. Das kann ich ja auch über den Ressourcenmonitor einsehen.
Ich wollte schon wissen wie der gegenüberliegende Server weiss wann und wieso er Bandbreite freigibt.
Ich wollte schon wissen wie der gegenüberliegende Server weiss wann und wieso er Bandbreite freigibt.
Naja, der Server sendet eben so schnell es geht und wenn mehrere Prozesse laufen, wird die verfügbare Bandbreite gerecht aufgeteilt. 
Wird dann wieder mehr Bandbreite frei, wird die Übertragung der verbleibenden Prozesse sofort wieder schneller. Oder versteh ich dich grad nicht?
Gruß,
Max
Wird dann wieder mehr Bandbreite frei, wird die Übertragung der verbleibenden Prozesse sofort wieder schneller. Oder versteh ich dich grad nicht?Gruß,
Max
JKuehl
Grand Admiral Special
Da der Emfpang von TCP Paketen bestätigt wird, kann der Server anhand der versendeten und empfangenen Anzahl eine Abschätzung treffen wie viele Daten übertragen wurden.
Die Downloads werden normalerweise über das TCP abgewickelt. TCP ist ein verbindungsorientiertes Protokoll und bestätigt den Empfang von Paketen. Der Transfer geht so schnell, wie auf der gesamten Übertragungsstrecke möglich.
Das langsame Ansteigen/Abfallen der Übertragungsrate liegt wie oben beschrieben in der Durchschnittsbildung. Wenn Dein Rechner über ein 100 Mbit Lan mit einem Router verbunden ist, kommt schliesslich jedes Paket mit 100 Mbit bei dir an. Zwischen den Paketen ist dann halt etwas länger Pause.
Gruss m0sh
/edit .. war ich wohl was langsam
Das langsame Ansteigen/Abfallen der Übertragungsrate liegt wie oben beschrieben in der Durchschnittsbildung. Wenn Dein Rechner über ein 100 Mbit Lan mit einem Router verbunden ist, kommt schliesslich jedes Paket mit 100 Mbit bei dir an. Zwischen den Paketen ist dann halt etwas länger Pause.
Gruss m0sh
/edit .. war ich wohl was langsam
aalerich
Vice Admiral Special
- Mitglied seit
- 15.01.2007
- Beiträge
- 642
- Renomée
- 18
Beim Muli zumindest läuft das so, daß zunächst so viel wie senderseitig möglich versandt wird. Bestätigt der Empfänger nicht den korrekten Empfang aller Pakete, wird die Geschwindigkeit gedrosselt. Ist eine Geschwindigkeit erreicht, bei der die Übertragung konstant fehlerfrei läuft, wird nach einer Weile wieder ausgetestet, ob es auch schneller geht. Kommt es dabei wieder zu ausbleibenden Empfangsbestätigungen, muß halt wieder reduziert werden, ansonsten wird weiter erhöht.
M
Grand Admiral Special
Eben nicht. Siehe EingangspostNaja, der Server sendet eben so schnell es geht und wenn mehrere Prozesse laufen, wird die verfügbare Bandbreite gerecht aufgeteilt.
Danke Jacko
ich nehme an das war die Antwort die ich gesucht hab. 
.
EDIT :
.
Danke auch den beiden anderen. Von der Bestätigung der Protokolle höre ich jetzt das erste mal.
Warum macht man das - etwa um den Server nicht unbedingt mehr zu belasten als nötig?
JKuehl
Grand Admiral Special
Wenn man keine Bestätigung braucht nimmt man UDP - das wurde u.a. bei frühen Streaminglösungen wie RealMedia genutzt.
TCP selbst ist nur das Übertragungsprotokoll, welches unabhängig von den zwei darüberliegenden Schichten Internet und Netzwerkhardware operiert - somit kannst du TCP auf jeglicher Netzwerkhardware und OS verwenden, egal wie diese intern aufgebaut sind.
DIe Bestätigung erfolgt u.a. deswegen, weil große Datenmengen in kleine Pakete aufgeteilt werden und dann durch unterschiedliche Routen zum Empfänger gelangen. So ist es z.b. denkbar dass ein Paket deines Youtube-Videos durch die Niederlande geroutet wird, ein anderes aber über die Schweiz. Ein zweiter Grund ist die Fehleranfälligkeit von übertragenen Datenpaketen: wird ein Paket fehlerhaft übertragen, wird kein ACK zurückgesendet und der Client erhält das betreffende Paket erneut zugestellt.
TCP selbst ist nur das Übertragungsprotokoll, welches unabhängig von den zwei darüberliegenden Schichten Internet und Netzwerkhardware operiert - somit kannst du TCP auf jeglicher Netzwerkhardware und OS verwenden, egal wie diese intern aufgebaut sind.
DIe Bestätigung erfolgt u.a. deswegen, weil große Datenmengen in kleine Pakete aufgeteilt werden und dann durch unterschiedliche Routen zum Empfänger gelangen. So ist es z.b. denkbar dass ein Paket deines Youtube-Videos durch die Niederlande geroutet wird, ein anderes aber über die Schweiz. Ein zweiter Grund ist die Fehleranfälligkeit von übertragenen Datenpaketen: wird ein Paket fehlerhaft übertragen, wird kein ACK zurückgesendet und der Client erhält das betreffende Paket erneut zugestellt.
Zuletzt bearbeitet:
MagicEye04
Grand Admiral Special
Ich lade öfter gleichzeitig mehrere große Dateien herunter.
Mein Netzwerkmonitor hat mir dabei nie die von Dir beobachteten Effekte beobachtet. Die Leitung wird immer voll ausgelastet (außer der Server ist langsamer).
Die Anzeige im Download-Programm ist allerdings sehr träge, wahrscheinlich berechnet die einen gleitenden Mittelwert für die Anzeige. Wenn ich mich darauf verlassen würde, dann käme ich auch zu dem Schluß, dass die Bandbreite eine Weile braucht, um sich neu zu sortieren. Ist aber nicht so.
Mein Netzwerkmonitor hat mir dabei nie die von Dir beobachteten Effekte beobachtet. Die Leitung wird immer voll ausgelastet (außer der Server ist langsamer).
Die Anzeige im Download-Programm ist allerdings sehr träge, wahrscheinlich berechnet die einen gleitenden Mittelwert für die Anzeige. Wenn ich mich darauf verlassen würde, dann käme ich auch zu dem Schluß, dass die Bandbreite eine Weile braucht, um sich neu zu sortieren. Ist aber nicht so.
TCP versucht immer deine Leitung auszulasten, es versucht so viel wie möglich zu senden, erst sobald Pakete verloren gehen, wird die Geschwindigkeit gedrosselt.
Dabei versucht TCP sich immer wieder an deine Leitungsgrenzen heran zu tasten. Wenn du zwei Verbindungen offen hattest und eine davon fertig wird, also nichts mehr empfängt, gehen beim nächsten Versuch des Servers mehr Pakete zu senden keine verloren, also erhöht er die Sendegeschwindigkeit wieder langsam.
Für genauere Erläuterungen siehe Wikipedia "Slow Start und Congestion Avoidance".
Dabei versucht TCP sich immer wieder an deine Leitungsgrenzen heran zu tasten. Wenn du zwei Verbindungen offen hattest und eine davon fertig wird, also nichts mehr empfängt, gehen beim nächsten Versuch des Servers mehr Pakete zu senden keine verloren, also erhöht er die Sendegeschwindigkeit wieder langsam.
Für genauere Erläuterungen siehe Wikipedia "Slow Start und Congestion Avoidance".
Man kann es doch beliebig managen. Ich kann dem einen 40 kb/s geben und dem anderen 1000 Mbit/s.
Das kann man selbst zu hause mit seinem DSL Anschluss machen. Jeder Rechner im Netz bekommt eine andere Bandbreite wenn man es will.
Wenn man da gar nichts macht dann teilt sich das ganze mehr oder weniger gleichmäßig auf bis die maximale Bandbreite vom Server an irgend einer Stelle erschöpft ist. Man kann das an mehreren Stellen begrenzen. Sind die Daten nur 1x auf einer HDD und 1000 Leute greifen darauf zu kann man sich ja ausrechnen was jeder für eine Bandbreite bekommt. Denn da ist der limitierende Faktor die HDD.
Und natürlich kann man das über das Netzwerk auch noch Nutzergruppen abhängig machen. 08/15 Leute bekommen nur Modem Speed. Und die wichtigen Firmen Kunden haben die Dicke Leitung zur Verfügung.
Das kann man selbst zu hause mit seinem DSL Anschluss machen. Jeder Rechner im Netz bekommt eine andere Bandbreite wenn man es will.
Wenn man da gar nichts macht dann teilt sich das ganze mehr oder weniger gleichmäßig auf bis die maximale Bandbreite vom Server an irgend einer Stelle erschöpft ist. Man kann das an mehreren Stellen begrenzen. Sind die Daten nur 1x auf einer HDD und 1000 Leute greifen darauf zu kann man sich ja ausrechnen was jeder für eine Bandbreite bekommt. Denn da ist der limitierende Faktor die HDD.
Und natürlich kann man das über das Netzwerk auch noch Nutzergruppen abhängig machen. 08/15 Leute bekommen nur Modem Speed. Und die wichtigen Firmen Kunden haben die Dicke Leitung zur Verfügung.
Ähnliche Themen
