Dlaczego prędkość do serwerów UE jest niższa niż w Speedtest

Speedtest pokazał 290 Mb/s. A realna prędkość do serwerów w UE wychodzi bliżej 38 Mb/s. Różnica jest niemal ośmiokrotna i trudno ją przeoczyć. Niemal zawsze tłumaczy ją długa trasa międzynarodowa, a nie twój sprzęt ani nasz serwis.

Krótko

Speedtest i realne połączenie z odległym serwerem mierzą różne rzeczy. Speedtest sprawdza samą przepustowość twojego łącza na bardzo krótkiej trasie. Praca z serwerami w UE zależy od opóźnienia i od stanu kanałów międzynarodowych, przez które biegnie twój ruch. Dlatego wysoki wynik Speedtestu mówi tylko o zdrowiu łącza. Niska prędkość do UE wynika z fizyki dalekich połączeń i z obciążenia sieci tranzytowych.

Jak wygląda ta różnica

Oto jedno i to samo łącze, zmierzone dwa razy w odstępie kilku minut. Najpierw Speedtest do serwera, który wybrał sobie sam.

Dwa szczegóły na tym panelu tłumaczą prawie całą tę liczbę. W wierszu "Connections" stoi "Multi", czyli ta liczba to suma kilku strumieni naraz. A wybrany serwer stoi w tym samym kraju. Teraz to samo łącze do serwerów, które naprawdę obsługują webinary, na kroku "Speed" naszego testera połączenia.

Pobieranie spadło mniej więcej ośmiokrotnie. Wysyłanie osunęło się tylko z 26 do 16, a to zjazd o wiele łagodniejszy. Żadna z tych liczb nie świadczy o zepsutym łączu. Dokąd idzie każda z nich, omawia reszta artykułu.

Drugi panel warto czytać uważnie. "TO YOU" to odbiór, a "FROM YOU" to wysyłanie. Prowadzisz webinar sam? Wtedy liczy się właśnie "FROM YOU", bo kamera, mikrofon i pokaz ekranu idą w górę. Uczestnikowi, który tylko ogląda, ważna jest "TO YOU". W pomiarze wyżej 15,98 Mb/s na wysyłanie to około dziesięciokrotny zapas dla prowadzącego.

Podpisy na zrzutach są angielskie, bo interfejs sfotografowano w wersji angielskiej. W polskiej te same pozycje noszą polskie nazwy i stoją w tych samych miejscach.

Co naprawdę mierzy Speedtest

Speedtest zbudowano tak, żeby pokazał możliwie wysoką liczbę. Dlatego jego wynik tylko po części oddaje pracę z odległymi serwerami.

• Bierze najbliższy serwer. Speedtest wybiera węzeł o najniższym opóźnieniu, zwykle w sieci twojego dostawcy albo w tym samym mieście. Ruch do niego idzie krótką drogą i kanałów międzynarodowych w ogóle nie dotyka.
• Otwiera wiele połączeń naraz. Speedtest uruchamia kilka strumieni TCP jednocześnie, zwykle od 4 do 16, i sumuje ich prędkość. Tak omija limit jednego połączenia na długiej trasie, o czym mówi następny rozdział. Realne programy pracują często w jednym strumieniu albo w dwóch, więc takiej premii nie dostają.
• Opóźnienie jest minimalne. Na krótkiej trasie czas obiegu, czyli RTT, wynosi kilka milisekund, a TCP zdąży rozpędzić się do pełnej prędkości łącza.

Speedtest pokazuje więc laboratoryjną przepustowość łącza. Nie pokazuje tego, co dostaniesz przy wymianie danych z serwerem w innym kraju.

Iloczyn pasma i opóźnienia oraz okno TCP

Większa część różnicy opiera się na jednym mechanizmie.

TCP wysyła dane oknami. Nadawca wypycha porcję danych i czeka na potwierdzenie odbioru, zanim ruszy dalej. Maksymalną prędkość jednego połączenia TCP liczy prosty wzór.

Prędkość = rozmiar okna / opóźnienie (RTT)

Żeby zapełnić łącze w całości, okno musi być nie mniejsze niż iloczyn pasma i opóźnienia, czyli BDP.

BDP = pasmo × RTT

Podstawmy to samo łącze na 290 Mb/s i opóźnienie do serwera w UE około 50 ms.

BDP = 290 000 000 bit/s × 0,05 s = 14 500 000 bitów = 1,81 MB

Znaczy to, że w każdej chwili w drodze musi być około 1,8 MB danych. Inaczej łącze się nie nasyci. Jedna ze stron utknęła na ograniczonym oknie, czyli na klasycznych 64 KB bez skalowania? Wtedy pułap jednego połączenia wychodzi taki.

Prędkość = 65 536 bajtów × 8 bitów / 0,05 s ≈ 10,5 Mb/s

Właśnie dlatego jedno połączenie z odległym serwerem zatrzymuje się na 10 do 20 Mb/s, choć samo łącze ma setki megabitów. Na krótkiej trasie z RTT 2 ms to samo okno dałoby ponad 260 Mb/s. Dlatego Speedtest nigdy tego kłopotu nie pokaże. Im wyższe opóźnienie, tym silniejszy efekt. Nic tu nie jest zepsute, po prostu tak działa protokół.

Opóźnienie i fizyka długich kanałów

Opóźnienie na długiej trasie składa się z kilku części, a niektórych nie usuniesz w ogóle.

Światło biegnie w światłowodzie z prędkością około 200 000 km/s, wyraźnie wolniej niż w próżni, przez współczynnik załamania szkła. Każdy tysiąc kilometrów trasy dokłada około 5 ms w jedną stronę, czyli około 10 ms na obieg. Prostych tras prawie nie ma, więc realna droga bywa dłuższa od odległości geograficznej.

Dalej opóźnienie na każdym węźle pośrednim. Router przetwarza pakiet, wstawia go do kolejki i wysyła dalej. W drodze do serwera w UE takich węzłów, zwanych też hopami, bywa od 10 do 20. Każdy dokłada swoją część. Im wyższy końcowy RTT, tym niższy pułap jednego połączenia według wzoru wyżej.

Straty pakietów i ich wpływ na TCP

Nawet niewielkie straty pakietów na kanale międzynarodowym ostro ścinają końcową prędkość. Zgubiony pakiet TCP czyta jako oznakę przeciążenia, więc zwalnia tempo i potem znów je nabiera. Zależność opisuje wzór Mathisa.

Prędkość ≈ MSS / (RTT × √p)

MSS to maksymalny rozmiar segmentu, zwykle około 1460 bajtów. RTT to opóźnienie, a p to udział zgubionych pakietów. Prędkość spada odwrotnie do pierwiastka z udziału strat i wprost zależy od opóźnienia.

W praktyce liczby wyglądają groźnie. Przy RTT 50 ms i zwykłym MSS nawet 0,1 procent strat trzyma jedno połączenie koło 7 Mb/s. Procent strat spycha je mniej więcej do 2,3 Mb/s, a dwa procent poniżej 1,7 Mb/s. Na długich trasach tranzytowych straty od 1 do 2 procent w godzinach szczytu są zupełnie zwyczajne. Tam, gdzie dorastają do takich wartości, szkodzą bardziej niż limit okna. Stąd trasa, która rano jest po prostu wolna, a wieczorem już do niczego się nie nadaje.

Trasowanie i peering

Droga ruchu do serwera w UE nie jest prosta. Biegnie przez łańcuch operatorów i protokół trasowania BGP. A ten wybiera drogę według przesłanek handlowych i technicznych, a nie według najkrótszej odległości.

Stąd kilka typowych kłopotów. Trasa potrafi iść przez trzeci kraj, choć istnieje krótsza droga, a wtedy rosną i opóźnienie, i ryzyko strat. Ruch przekracza też styki między sieciami, czyli punkty peeringu i kanały tranzytowe. Zapchany styk to dokładnie to miejsce, gdzie prędkość spada. Częste bywa trasowanie asymetryczne, gdy pakiety idą jedną drogą, a wracają inną, i diagnoza robi się mętna. Pojemność międzynarodową trzeba jeszcze kupić, więc dostawcy, który oszczędzał, w szczycie jej brakuje.

Przeciążenie kanałów międzynarodowych dostawcy

Ruchu lokalnego, po mieście i po kraju, większość dostawców ma z zapasem. Dlatego Speedtest do bliskiego serwera zawsze pokazuje wysoką liczbę. Kanały międzynarodowe są droższe i kupuje się je w ograniczonej ilości. Wieczorem w szczycie to właśnie one stają się wąskim gardłem. Stąd wyraźne skoki prędkości do UE w ciągu dnia przy stale wysokim lokalnym Speedteście.

Pozostałe czynniki techniczne

Poza głównymi przyczynami na prędkość do odległego serwera wpływa jeszcze kilka rzeczy.

MTU i fragmentacja. Jeśli MTU na trasie jest mniejsze od spodziewanego, pakiety idą we fragmentach, a wydajność spada. Źle ustawiony PMTUD, czyli wykrywanie MTU na ścieżce, prowadzi do czarnych dziur i zawieszonych transmisji.

Bufferbloat. Rozdęte bufory na węzłach pośrednich podnoszą opóźnienie pod obciążeniem i mylą algorytmy sterowania przepływem w TCP. Realna prędkość spada wtedy jeszcze niżej.

Kształtowanie ruchu i priorytety, czyli QoS. Część dostawców celowo tnie ruch międzynarodowy albo odsuwa go na dalszy plan, czasem tylko jeden jego rodzaj. Widać to od razu po prędkości.

Narzuty protokołów. Nagłówki TCP, IP i szyfrowania zjadają część pasma. Na krótkiej trasie tego nie widać. Razem ze stratami i opóźnieniem na długiej trasie robi się z tego zauważalna wielkość.

Twoje własne otoczenie. Wi-Fi zamiast kabla, przeciążony router domowy, antywirus albo VPN na urządzeniu też obniżają realną prędkość. Wyklucz to najpierw, zanim ruszysz szukać przyczyny dalej.

Dlaczego rzecz nie leży w sprzęcie ani w serwisie

Wysoki wynik Speedtestu dowodzi, że sprzęt i lokalne łącze są zdrowe i dają należną prędkość. Spadek na serwerach w UE bierze się skądinąd. Winne są opóźnienie na długiej trasie, limit okna jednego połączenia TCP, straty pakietów i stan kanałów międzynarodowych dostawcy. Wszystko to leży poza naszym serwisem i poza twoim sprzętem, na odcinku sieci między dostawcą a operatorami magistralnymi.

I jeszcze jedno, zanim ruszysz w pogoń za liczbami. Webinar potrzebuje o wiele mniej niż przesyłanie plików, więc 20 Mb/s do UE całkiem nam wystarcza. Prowadzący potrzebuje około 1,6 Mb/s na wysyłanie, a z pokazem ekranu około 3,2. Uczestnikowi potrzebne jest pasmo na każdego prelegenta na antenie, a wszystko to rozkłada artykuł wymagania techniczne. Stabilność liczy się tu bardziej niż goła prędkość. Jeśli wydarzenia idą gładko, różnica wobec Speedtestu jest ciekawostką, a nie usterką.

Jak sprawdzić to samodzielnie

Kilka sprawdzeń wskaże przyczynę.

• Uruchom Speedtest ręcznie i wybierz serwer w Niemczech albo w Finlandii. Wszystkie nasze serwery stoją w UE, w Niemczech, Francji, Holandii i Finlandii, ale sam ruch webinarowy niosą maszyny niemieckie i fińskie. Holenderskie i francuskie rozsyłają zaproszenia na najbliższe wydarzenia, więc pomiar do nich opowie o trasie, którą twoje webinary nigdy nie biegną. Niemcy i Finlandia pokażą prawdziwą prędkość na trasie roboczej, a nie do najbliższego lokalnego serwera.
• Prześledź trasę. Polecenie tracert w Windows, a traceroute w macOS i Linuksie, pokaże łańcuch węzłów do naszego serwera z opóźnieniem na każdym. Straty i opóźnienie czytelniej pokazuje narzędzie mtr, w Windows to WinMTR, i warto zostawić je na kilka minut w godzinach szczytu.
• Porównaj jedno połączenie z kilkoma. Pobieranie w kilku strumieniach jest szybkie, a w jednym wolne? To właśnie potwierdza limit okna TCP na długiej trasie.
• Masz możliwości techniczne? Zmierz przepustowość do dalekiego węzła wprost narzędziem iperf3, najpierw w jednym strumieniu, potem w kilku.

W naszym testerze sprzętu jest też odnośnik do osobnego badania jakości internetu, gdzie widać prędkość, ping i jitter. Szybki sposób, żeby uchwycić stan łącza w konkretnej chwili.

Co robić

Sprawdzenia pokazały wysokie opóźnienie albo straty pakietów na odcinku międzynarodowym? Idź do dostawcy z konkretami, czyli z wynikiem trasowania i odczytem mtr, z zaznaczoną porą dnia. Poprawianie trasy albo poszerzanie łączności międzynarodowej to praca dostawcy. My ze swojej strony podamy adresy serwerów do punktowej diagnostyki i pomożemy odczytać wyniki. Napisz na czacie online, a my je prześlemy.

Podsumowanie

Wynik Speedtestu koło 290 Mb/s potwierdza, że łącze jest zdrowe. Spadek poniżej 40 Mb/s na serwerach w UE jest spodziewany. Bierze się z opóźnienia długiej trasy, z limitu okna jednego połączenia TCP, ze strat pakietów i z obciążenia kanałów międzynarodowych dostawcy. Te przyczyny siedzą w sieci między tobą a nami, a nie w twoim sprzęcie ani w naszym serwisie. Prosta diagnoza trasy pokaże, która z czterech szkodzi.

Często zadawane pytania

Czy warto kupić szybsze łącze, żeby to naprawić?

Nie. Webinar potrzebuje o wiele mniej niż przesyłanie plików, a 20 Mb/s do UE całkiem nam wystarcza. Prowadzący potrzebuje około 1,6 Mb/s na wysyłanie, a z pokazem ekranu około 3,2. Wszystkie liczby rozkłada artykuł wymagania techniczne. Stabilność liczy się tu bardziej niż goła prędkość. Jeśli wydarzenia idą gładko, różnica wobec Speedtestu jest ciekawostką, a nie usterką.

Pobieranie spadło ośmiokrotnie, a wysyłanie ledwo drgnęło. Co się liczy?

Wysyłanie, jeśli to ty prowadzisz. Kamera, mikrofon i pokaz ekranu idą w górę, a to liczba "FROM YOU". Uczestnikowi, który tylko ogląda, ważna jest "TO YOU", więc ten sam pomiar czyta się różnie zależnie od roli na wydarzeniu. W pomiarze wyżej wysyłanie zsunęło się tylko z 26 do 16 Mb/s, a to około dziesięciokrotny zapas dla prowadzącego.

Który serwer Speedtestu wybrać do uczciwego porównania?

W Niemczech albo w Finlandii. Wszystkie nasze serwery stoją w UE, w Niemczech, Francji, Holandii i Finlandii, ale sam ruch webinarowy niosą maszyny niemieckie i fińskie. Holenderskie i francuskie rozsyłają zaproszenia na najbliższe wydarzenia, dlatego pomiar do nich opowie o trasie, którą twoje webinary nigdy nie biegną.

Co z tego naprawisz własnymi siłami?

Zacznij od swojej strony. Wi-Fi zamiast kabla, przeciążony router domowy, antywirus albo VPN na urządzeniu obniżają realną prędkość. Tu czysto, a sprawdzenia i tak pokazują wysokie opóźnienie albo straty na odcinku międzynarodowym? Dalej sprawa dostawcy, a iść do niego trzeba z konkretami, czyli z wynikiem trasowania i odczytem mtr z zaznaczoną porą dnia. Adresy naszych serwerów do punktowej diagnostyki damy my, tylko napisz na czacie online.

Dlaczego rano trasa jest normalna, a wieczorem nie nadaje się do niczego?

Kanały międzynarodowe kupuje się w ograniczonej ilości i wieczorem w szczycie stają się wąskim gardłem. Ruchu lokalnego starcza z zapasem, dlatego Speedtest do bliskiego serwera trzyma się wysoko cały dzień. Straty pakietów idą po tej samej krzywej, a od 1 do 2 procent na długich trasach tranzytowych w szczycie jest zupełnie zwyczajne. Przy RTT 50 ms procent strat trzyma jedno połączenie koło 2,3 Mb/s, i to właśnie zamienia trasę po prostu wolną w nieprzydatną.