Beeinflusst die physische Entfernung die Download-Geschwindigkeit?


22

Ich hatte gerade einen Streit mit einem Kollegen von mir und dachte, ich würde mich nur an die Experten wenden. Hier ist das Szenario. Wir haben eine Website verwendet, die die Geschwindigkeit Ihrer Verbindung misst. Wir haben mit einem Server getestet, der weit von uns entfernt ist (wir sind in Malaysia und der Server war in den USA). Es waren ungefähr 2 Mbit / s. Dann haben wir es mit einem Server in Singapur versucht und es war viel schneller (ca. 15 Mbit / s). Mein Kollege glaubte, es liege an der physischen Distanz, obwohl ich glaube, dass es nicht darauf ankommt. Meines Wissens nach ist es egal, wo sich der Server befindet, sobald Sie den ersten Handshake ausgeführt und der Datenfluss gestartet haben. Das Ergebnis sollte fast dasselbe sein. Vermisse ich hier etwas? Wie funktioniert es wirklich?


2
Sie können dies einfach selbst bestätigen. Pingen Sie den Server an, um die Latenz zu ermitteln. Dann 2Mbps * Latenz == Fenster. Sie können die tatsächliche Fenstergröße mit wireshark überprüfen. Angenommen, Sie haben keine Fensterskalierung aktiviert, dann sind es 64 kB / 2 Mbit / s = 256 ms. Ich gehe also davon aus, dass Ihr Server 256 ms entfernt ist.
Ytti

2
@ytti beschreibt indirekt das BDP (Bandbreiten-Verzögerungsprodukt), das sich grob in langen (Verzögerungs-), fetten (Bandbreiten-) Netzwerken niederschlägt. Siehe en.wikipedia.org/wiki/Bandwidth-delay_product .
Generalnetworkerror

2
Bei @ytti, Windows Vista und höher ist die Fensterskalierung standardmäßig aktiviert. Wir müssen wissen, welches Betriebssystem Navid für den Test verwendet
Mike Pennington

Diesem Support zufolge ist die Skalierung (Faktor 8) in Vista standardmäßig aktiviert, jedoch nur für Nicht-HTTP. Ich bin kein Windows-Benutzer und kann es nicht überprüfen.
Ytti

2
@ytti, ich bin mir nicht sicher, ob das relevant ist. Ich verwende Vista, und ich sehe mir meine HTTP-Verbindung zu dieser Support-Seite an, und die TCP-SYN sagt: "Window Scale: 2 (Multiplizieren mit dem Faktor 4)"
Mike Pennington

Antworten:


23

Mein Kollege glaubte, es liege an der physischen Distanz, obwohl ich glaube, dass es nicht darauf ankommt. Meines Wissens nach ist es egal, wo sich der Server befindet, sobald Sie den ersten Handshake ausgeführt und der Datenfluss gestartet haben. Das Ergebnis sollte fast dasselbe sein. Vermisse ich hier etwas? Wie funktioniert es wirklich?

Sie hatten beide irgendwann Recht, aber Ihr Verständnis ist größtenteils richtig ... heute :). Es gibt ein paar Faktoren, die sich zwischen der älteren Antwort Ihres Freundes und den Fähigkeiten, die wir heute haben, geändert haben.

  • TCP-Fensterskalierung
  • Host Buffer Tuning

Der Unterschied in den Ergebnissen, den Sie gesehen haben, könnte beeinflusst worden sein durch:

  • Paketverlust
  • Parallele TCP-Übertragungen

TCP Window Scaling: Der Bandbreitenverzögerungseffekt

Wie Ihr Freund bereits erwähnt hat, litten ältere TCP-Implementierungen unter den Beschränkungen der ursprünglichen 16-Bit-Empfangsfenstergröße im TCP-Header (siehe RFC 793: Abschnitt 3.1 ). RWIN steuert, wie viele nicht bestätigte Daten in einem einzelnen TCP-Socket warten können. 16-Bit-RWIN-Werte beschränken Internetpfade mit Produkten mit hoher Bandbreitenverzögerung (und viele der heutigen Internetverbindungen mit hoher Bandbreite würden durch einen 16-Bit-Wert begrenzt).

Für hohe RTT-Werte ist es hilfreich, eine sehr große RWIN zu haben. Wenn Ihre Pfad-RTT von Malaysia in die USA etwa 200 ms beträgt, würde Sie die ursprüngliche TCP-RWIN auf 2,6 Mbit / s beschränken.

Durchsatz max = Rcv_Win / RTT

* Durchsatz max = 65535 * 8 / 0,200 *

Durchsatz max = 2,6 Mbit / s

RFC 1323 definierte einige "TCP-Optionen", um diese Einschränkungen zu überwinden. Eine dieser TCP-Optionen ist "Fensterskalierung". Es wird ein Skalierungsfaktor eingeführt, der den ursprünglichen RWIN-Wert multipliziert, um den vollen Wert des Empfangsfensters zu erhalten. Die Verwendung von Fensterskalierungsoptionen ermöglicht eine maximale RWIN von 1073725440 Byte. Dieselben Berechnungen anwenden:

Durchsatz max = Rcv_Win / RTT

* Durchsatz max = 1073725440 * 8 / 0,200 *

Durchsatz max = 42,96 Gbit / s

Denken Sie daran, dass TCP die RWIN über die Dauer einer Übertragung allmählich erhöht, solange der Paketverlust kein Problem darstellt. Um wirklich hohe Übertragungsraten über eine Verbindung mit hoher Verzögerung zu sehen, müssen Sie eine große Datei übertragen (damit TCP Zeit hat, das Fenster zu vergrößern), und der Paketverlust kann kein Problem für die Verbindung sein.

Paketverlust

Internet-Verbindungen über den Pazifischen Ozean sind manchmal ziemlich überlastet. Ein Teil meiner Familie lebt in Taiwan. Bei der Verwendung von Google Talk treten regelmäßig Probleme auf. Ich sehe oft einen Paketverlust von über 0,5%, wenn ich ihre DSL-Leitung aus den USA anpinge. Wenn Sie einen Verlust von etwa 0,5% für den "langsameren" Server feststellen, wird der Durchsatz für einen einzelnen TCP-Socket sehr leicht begrenzt.

Parallele TCP-Streams

Zu Ihrer Information, einige Geschwindigkeitstest-Websites verwenden parallele TCP-Streams, um den Durchsatz zu erhöhen . Dies kann sich auf die angezeigten Ergebnisse auswirken, da parallele TCP-Streams den Durchsatz drastisch erhöhen, falls der Pfad Paketverluste aufweist. Ich habe gesehen, dass vier parallele TCP-Streams ein 5-Mbit / s-Kabelmodem vollständig auslasten, bei dem ein konstanter Paketverlust von 1% auftrat. Normalerweise würde ein Verlust von 1% den Durchsatz eines einzelnen TCP-Streams verringern.

Bonusmaterial: Host Buffer Tuning

Viele ältere Betriebssystemimplementierungen hatten Sockets mit begrenzten Puffern. Bei älteren Betriebssystemen (wie Windows 2000) spielte es keine Rolle, ob über TCP große Datenmengen übertragen werden konnten. Die Socket-Puffer wurden nicht so eingestellt, dass sie die Vorteile der großen RWIN nutzen konnten. Es wurden viele Untersuchungen durchgeführt, um eine hohe Leistung bei TCP-Übertragungen zu ermöglichen . Moderne Betriebssysteme (für diese Antwort können wir Windows Vista und später "modern" nennen) enthalten bessere Pufferzuweisungsmechanismen in ihren Socket-Puffer-Implementierungen.


4
Als Randnotiz: Es gibt eine Vielzahl von Routern im alten Stil, die die Skalierung von Fenstern beeinträchtigen (es gibt täglich weniger, aber immer noch viele) und diese auf Null zurücksetzen, wodurch die Bandbreite drastisch verringert wird. Die Wahrscheinlichkeit, einen dieser defekten Router zu treffen, steigt mit der Anzahl der Sprünge zum Ziel, obwohl die meisten Netzwerkinfrastrukturanbieter dieses Problem heutzutage nicht mehr haben sollten.
Chris Down

Router sind L3-Geräte. Die TCP-Fensterskalierung ist ein L4-Prozess. Der Router leitet das Paket entweder weiter oder nicht, und abgesehen von der Verwendung von QoS-Mechanismen gibt es keine Unterscheidung zwischen TCP, UDP oder einem anderen Protokoll. Router wirken sich zwar auf die anfängliche MSS-Aushandlung aus (oder wenn sie ICMP nicht erreichen lassen), aber der Schiebefenster-Algorithmus ist nur eine Funktion der Stapel auf Endsystemen.
rnxrx

2
@rnxrx Ich würde zustimmen, es wäre meistens Edge-FW, die sich über TCP-Optionen ärgern würde. Ich habe noch nie von der Option zur TCP-Fensterskalierung mit Router-Mangeln gehört, aber ich wäre nicht sonderlich überrascht, wenn jemand einen Anbieter / ein Modell finden würde, der / das dies getan hat, wenn man bedenkt, dass Edge-Router die TCP-MSS-Option während der Übertragung nicht selten mangeln Es ist kein großer Sprung, sich vorzustellen, wie jemand das aufspürt.
Ytti

3

Kurze Antwort: Ja, die Entfernung wirkt sich auf die Single-Stream-Bandbreite aus.

Das Internet hat Mittel entwickelt, um diesen Effekt zu begrenzen ... verzögertes ACK, Fensterskalierung, andere Protokolle :-) Aber die Physik gewinnt am Ende immer noch. In diesem Fall ist es viel wahrscheinlicher, dass das Netzwerk über so viele Hops hinweg überlastet ist. Es wird nur ein einziges Paket benötigt, um einen TCP-Stream zu beenden.


1

Obwohl es bereits hervorragende Antworten darauf gibt, möchte ich hinzufügen: Nein, die Geschwindigkeit wird nicht unbedingt von der Entfernung beeinflusst, und ja, sehr oft ist die Geschwindigkeit von der Entfernung abhängig, beides ist wahr.

Warum das?

Stark vereinfacht, je länger die Distanz, desto mehr "Hops" sind auf dem Weg durch das Internet involviert. Die maximale Bandbreite wird durch den langsamsten Hop und den konkurrierenden Verkehr bestimmt. Mit zunehmender Entfernung und einer etwas zufälligen Verteilung der Sprunggeschwindigkeiten steigt die Wahrscheinlichkeit , insgesamt langsamer zu werden. Zusätzlich wird die Physik behindert und eine zunehmende Latenz kann auch die Verbindung verlangsamen.

Dies ist jedoch nicht selbstverständlich. Die Technologie ermöglicht es uns, eine weltumspannende Verbindung mit nahezu jeder gewünschten Bandbreite aufzubauen. Bandbreite und Entfernung sind jedoch ein Feind und erhöhen die Kosten für die Verbindung dramatisch, was wiederum die Wahrscheinlichkeit verringert, dass sie nur für die Verbindung besteht, die Sie gerade benötigen.

Natürlich ist dies zu einfach, aber in Wirklichkeit ist dies die Situation, die Sie sehr oft vorfinden. Und dann auch nicht, wenn es eine überraschend schnelle Verbindung oder einen Distributions-Proxy gleich um die Ecke gibt - aber wenn alles sofort ist, denken wir selten über die Geschwindigkeit des Internets nach ...


-1

Laut Andrew Martin lautet die Antwort ja

Diagramme


Antworten nur auf Links werden nicht empfohlen. Bitte machen Sie Angaben, die diese Antwort nützlich machen, ohne von der verlinkten Webseite abzuhängen.
Teun Vink

Alter, es ist nicht nur eine Link-Antwort, es ist ein Bild mit Statistiken
Jonathan

Ich bin nicht dein Typ. Auch dieses Bild hat keine Bedeutung ohne eine Erklärung, was auf der Y-Achse ist und wie es gemessen wurde. Und selbst dann sollten Sie erklären, wie dieses Bild eine Antwort auf die Frage ist.
Teun Vink

Ich weiß nicht, warum es für Sie schwierig ist, aber die X- und Y-Achse sind beschriftet. "Durchschnittliche Download-Geschwindigkeit in Mbit / s"
Jonathan
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.