Czy odległość fizyczna wpływa na szybkość pobierania?


22

Właśnie pokłóciłem się z moim kolegą i pomyślałem, że po prostu skontaktuję się z ekspertami w tej sprawie. Oto scenariusz. Korzystaliśmy ze strony internetowej, która mierzy prędkość twojego połączenia. Testowaliśmy na serwerze, który jest daleko od nas (jesteśmy w Malezji, a serwer był w USA). To było około 2 Mbps. Potem próbowaliśmy z serwerem w Singapurze i było znacznie szybciej (około 15 Mb / s). Mój kolega uważał, że to z powodu dystansu fizycznego, podczas gdy nie sądzę, żeby to miało znaczenie. Rozumiem, że po pierwszym uzgadnianiu i rozpoczęciu przepływu danych nie ma znaczenia, gdzie znajduje się serwer, a wynik powinien być prawie taki sam. Czy coś mi umyka? Jak to naprawdę działa?


2
Możesz to sam potwierdzić w trywialny sposób. Wyślij ping do serwera, aby uzyskać opóźnienie. Następnie 2 Mb / s * Opóźnienie == Okno. Rzeczywisty rozmiar okna możesz potwierdzić za pomocą wireshark. Załóżmy jednak, że nie masz włączonego skalowania okna, a następnie wynosi 64 kB / 2 Mb / s = 256 ms, więc przewiduję, że twój serwer będzie oddalony o 256 ms.
— ytti

2
@ytti pośrednio opisuje BDP (produkt z opóźnieniem pasma), który z grubsza przekłada się na długie (opóźnienie), grube (szerokość pasma) sieci, które są trudniejsze do zapełnienia i cokolwiek mniej je z dala od potencjalnej przepustowości. Zobacz en.wikipedia.org/wiki/Bandwidth-delay_product .
— generalnetworkerror

2
@ytti, Windows Vista i nowsze mają domyślnie włączone skalowanie okien ... musimy wiedzieć, jakiego OS Navid używa do testu
— Mike Pennington

Zgodnie z tym support.microsoft.com/kb/934430 skalowanie (współczynnik 8) jest domyślne w systemie Vista, ale tylko w przypadku protokołu innego niż HTTP. Sam nie jestem użytkownikiem systemu Windows, więc nie mogę zweryfikować.
— ytti

2
@ytti, nie jestem pewien, czy to istotne. Używam Visty i patrzę na wąchanie mojego połączenia HTTP z tą stroną wsparcia, a TCP SYN mówi: „Skala okna: 2 (pomnóż 4 razy)”
— Mike Pennington

Odpowiedzi:


23

Mój kolega uważał, że to z powodu dystansu fizycznego, podczas gdy nie sądzę, żeby to miało znaczenie. Rozumiem, że po pierwszym uzgadnianiu i rozpoczęciu przepływu danych nie ma znaczenia, gdzie znajduje się serwer, a wynik powinien być prawie taki sam. Czy coś mi umyka? Jak to naprawdę działa?

Obaj mieli rację w pewnym momencie historii, ale twoje rozumienie jest w większości poprawne ... dzisiaj :). Istnieje kilka czynników, które zmieniły się między starszą odpowiedzią udzieloną przez twojego znajomego a możliwościami, które mamy dzisiaj.

  • Skalowanie okna TCP
  • Strojenie bufora hosta

Na różnicę w uzyskanych wynikach mogły mieć wpływ:

  • Utrata pakietu
  • Równoległe transfery TCP

Skalowanie okna TCP: efekt opóźnienia przepustowości

Jak wspomniał twój przyjaciel, starsze implementacje TCP cierpiały z powodu ograniczeń narzuconych przez oryginalny 16-bitowy rozmiar okna odbierania w nagłówku TCP (zob. RFC 793: sekcja 3.1 ); RWIN kontroluje, ile niepotwierdzonych danych może czekać w pojedynczym gnieździe TCP. 16-bitowe wartości RWIN ograniczają ścieżki internetowe z produktami o dużym opóźnieniu przepustowości (a wiele dzisiejszych połączeń internetowych o wysokiej przepustowości byłby ograniczony wartością 16-bitową).

W przypadku wysokich wartości RTT pomocne jest posiadanie bardzo dużego RWIN. Na przykład, jeśli Twoja droga RTT z Malezji do USA wynosi około 200 ms, oryginalny RWIN TCP ograniczy Cię do 2,6 Mb / s.

Przepustowość max = Rcv_Win / RTT

* Maksymalna przepustowość = 65535 * 8 / 0,200 *

Przepustowość max = 2,6 Mb / s

RFC 1323 zdefiniował niektóre „Opcje TCP” w celu przezwyciężenia tych ograniczeń; jedną z tych opcji TCP jest „skalowanie okna”. Wprowadza współczynnik skalowania, który zwielokrotnia pierwotną wartość RWIN, w celu uzyskania pełnej wartości okna odbioru; użycie opcji skalowania okna pozwala na maksymalną RWIN wynoszącą 1073725440 bajtów. Stosując te same obliczenia:

Przepustowość max = Rcv_Win / RTT

* Przepustowość max = 1073725440 * 8 / 0,200 *

Przepustowość max = 42,96 Gb / s

Należy pamiętać, że TCP zwiększa RWIN stopniowo podczas trwania transferu, o ile utrata pakietów nie stanowi problemu. Aby zobaczyć naprawdę duże prędkości przesyłu w przypadku połączenia o dużym opóźnieniu, musisz przesłać duży plik (aby TCP miał czas na zwiększenie okna), a utrata pakietu nie może stanowić problemu dla połączenia.

Utrata pakietów

Obwody internetowe w całym Oceanie Spokojnym są czasami dość zatłoczone. Część mojej rodziny mieszka na Tajwanie, a my często spotykamy się z problemami, gdy korzystamy z Google Talk. Często widzę utratę pakietów powyżej 0,5%, gdy pinguję ich linię DSL z USA; jeśli widzisz coś takiego jak 0,5% straty na „wolniejszym” serwerze, bardzo łatwo ograniczyłoby to przepustowość pojedynczego gniazda TCP.

Równoległe strumienie TCP

Do Twojej wiadomości, niektóre strony testowe prędkości używają równoległych strumieni TCP w celu zwiększenia przepustowości ; może to wpływać na wyniki, które widzisz, ponieważ równoległe strumienie TCP znacznie zwiększają przepustowość w przypadku utraty ścieżki na ścieżce. Widziałem cztery równoległe strumienie TCP całkowicie nasycające modem kablowy 5 Mb / s, który cierpiał z powodu 1% stałej utraty pakietów. Zwykle utrata 1% obniżyłaby przepustowość pojedynczego strumienia TCP.

Materiał bonusowy: Strojenie bufora hosta

Wiele starszych implementacji systemu operacyjnego miało gniazda z ograniczonymi buforami; ze starszym systemem operacyjnym (jak Windows 2000) nie miało znaczenia, czy TCP zezwalał na duże ilości danych w locie ... ich bufory gniazd nie zostały dostrojone, aby wykorzystać dużą RWIN. Przeprowadzono wiele badań, aby umożliwić wysoką wydajność przesyłania TCP . Nowoczesne systemy operacyjne (dla tej odpowiedzi możemy nazwać Windows Vista, a później „nowoczesny”) zawierają lepsze mechanizmy alokacji buforów w swoich implementacjach buforów gniazd.


4
Na marginesie: istnieje wiele routerów w starym stylu, które blokują skalowanie okna (jest ich mniej każdego dnia, ale wciąż jest ich mnóstwo) i resetują je do zera, co znacznie zmniejsza przepustowość. Prawdopodobieństwo trafienia jednego z tych zepsutych routerów wzrasta wraz z liczbą przeskoków do miejsca docelowego, chociaż większość dostawców infrastruktury sieciowej nie powinna obecnie mieć tego problemu.
— Chris Down,

Routery są urządzeniami L3. Skalowanie okna TCP jest procesem L4. Router albo przesyła dalej pakiet, albo go nie przesyła i, z wyjątkiem mechanizmów QoS, nie ma rozróżnienia między TCP, UDP lub innym protokołem. Routery z pewnością mają wpływ na początkowe negocjacje MSS (lub robią, jeśli upuszczą ICMP nieosiągalne), ale algorytm przesuwanego okna jest wyłącznie funkcją stosów w systemach końcowych.
— rnxrx

2
@rnxrx Zgadzam się, to byłby głównie FW, który byłby zły na opcje TCP. Nie słyszałem o opcji skalowania okna TCP manglującego routera, ale nie byłbym strasznie zaskoczony, gdyby ktoś wymyślił dostawcę / model, który to zrobił, biorąc pod uwagę, że routery brzegowe nie mają wpływu na opcję tranzytową MSS TCP , to nie jest tak duży skok, aby wyobrazić sobie kogoś, kto to robi.
— ytti

3

Krótka odpowiedź: Tak, odległość ma wpływ na przepustowość pojedynczego strumienia.

Internet ewoluował sposoby ograniczania tego efektu ... opóźnione ACK, skalowanie okien, inne protokoły :-) Ale fizyka wciąż wygrywa. W takim przypadku bardziej prawdopodobne jest ogólne przeciążenie sieci na tak wielu przeskokach - zabicie strumienia TCP wymaga tylko jednego upuszczonego pakietu.


1

Chociaż istnieją już doskonałe odpowiedzi na to, chciałbym dodać: nie, prędkość niekoniecznie zależy od odległości i tak, bardzo często prędkość zależy od odległości .

Dlaczego?

Zdecydowanie uproszczone, im większa odległość, tym więcej „przeskoków” jest zaangażowanych w drodze przez Internet. Maksymalna przepustowość zależy od najwolniejszego przeskoku i jednoczesnego ruchu. Wraz ze wzrostem odległości i nieco losowym rozkładem prędkości przeskoków rośnie prawdopodobieństwo uzyskania niższych całkowitych prędkości. Dodatkowo przeszkadza fizyka, a zwiększenie opóźnień może również spowolnić połączenie.

Ale nie należy tego przyjmować za pewnik. Technologia pozwala nam zbudować połączenie obejmujące całą planetę o niemal dowolnej żądanej przepustowości. Jednak przepustowość i odległość są wrogami i oba dramatycznie zwiększają koszt połączenia, ponownie zmniejszając prawdopodobieństwo istnienia tylko dla połączenia, którego możesz teraz potrzebować.

Oczywiście jest to bardzo uproszczone, ale w rzeczywistości taka sytuacja jest bardzo często spotykana. Z drugiej strony nie dzieje się tak, gdy tuż za rogiem znajduje się zaskakująco szybkie połączenie lub proxy dystrybucyjne - ale gdy wszystko jest natychmiastowe, rzadko myślimy o szybkości Internetu ...


-1

Według Andrew Martina odpowiedź brzmi „tak”

Wykresy


Odsyłacze tylko odpowiedzi są odradzane. Podaj szczegóły, dzięki którym ta odpowiedź będzie przydatna bez uzależnienia od połączonej strony internetowej.
— Teun Vink

Koleś, to nie jest tylko odpowiedź na link, to obraz ze statystykami
— Jonathan

Nie jestem twoim facetem. Ponadto ten obraz nie ma znaczenia bez wyjaśnienia, co znajduje się na osi Y i jak został zmierzony. I nawet wtedy powinieneś wyjaśnić, w jaki sposób ten obraz jest odpowiedzią na pytanie.
— Teun Vink

Nie wiem, dlaczego to dla ciebie trudne, ale oś X i Y są oznaczone. „Średnia prędkość pobierania w Mbps”
— Jonathan
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.