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.