Co oblicza kalkulator czasu transmisji z narzutem?
Proste obliczenie czasu transmisji polega na podzieleniu liczby bitów przez prędkość łącza. W sieci Ethernet nie wszystkie przesłane bity są jednak danymi aplikacji. Dane są dzielone na pakiety, do których dochodzą nagłówki IP i TCP lub UDP, a następnie ramki Ethernet z własnym nagłówkiem i FCS. Na medium przesyłane są również preambuła z SFD, a między kolejnymi ramkami wymagany jest odstęp IFG.
Ten kalkulator sumuje te elementy i wyznacza czas potrzebny do przesłania określonej ilości danych aplikacji. Dzięki temu wynik jest bliższy limitowi warstw Ethernet/IP/TCP lub Ethernet/IP/UDP niż zwykłe przeliczenie GB na sekundy.
Jak liczony jest narzut?
Dla każdego pakietu kalkulator najpierw wyznacza maksymalną porcję danych aplikacji mieszczącą się w MTU. Przy typowym MTU 1500 B, IPv4 bez opcji i TCP bez opcji pozostaje 1460 B danych aplikacji: 1500 - 20 B nagłówka IPv4 - 20 B nagłówka TCP.
Pełny pakiet IP jest następnie umieszczany w ramce Ethernet. Do czasu zajęcia medium kalkulator dolicza 14 B podstawowego nagłówka Ethernet, 4 B FCS, 8 B preambuły z SFD i 12 B IFG. Jeden tag 802.1Q zwiększa koszt ramki o kolejne 4 B.
Ostatni pakiet może przenosić mniej danych niż pozostałe, dlatego liczba pakietów jest zaokrąglana w górę i ostatnia ramka jest liczona osobno.
Przykład: 1 GiB przez Gigabit Ethernet
Dla 1 GiB danych, łącza 1 Gb/s, IPv4 + TCP, MTU 1500 B i braku VLAN pojedynczy pełny pakiet przenosi 1460 B danych aplikacji. Na medium pełna ramka wraz z preambułą i IFG zajmuje czas odpowiadający 1538 B. Do przesłania całego 1 GiB potrzeba więc setek tysięcy ramek, a ich narzut kumuluje się.
Idealne przesłanie 1 GiB przy dokładnie 1 Gb/s, bez żadnego narzutu, trwa około 8,59 s. Po uwzględnieniu modelowanego narzutu Ethernet, IPv4 i TCP czas jest nieco dłuższy. Różnica może być większa przy małym MTU lub małych porcjach danych, ponieważ stały narzut przypada wtedy na mniejszą ilość danych użytkownika.
Ważne: to nie jest prognoza czasu pobierania z Internetu
Wynik zakłada ciągłą transmisję z pełną podaną prędkością łącza i brak strat. Nie uwzględnia m.in. potwierdzeń TCP, retransmisji, TLS, SMB, HTTP, VPN, PPPoE, tuneli, kolejkowania ani ograniczeń serwera, dysku czy procesora. Kalkulator służy do oceny wpływu podstawowego narzutu protokołów na czas transmisji.
TCP a UDP - skąd bierze się różnica?
Bazowy nagłówek TCP ma 20 B, natomiast UDP 8 B. Przy tym samym MTU UDP pozostawia więc więcej miejsca na dane aplikacji w pojedynczym pakiecie. W modelu bez dodatkowych mechanizmów oznacza to nieco mniejszy narzut i krótszy czas transmisji tej samej ilości danych.
Nie oznacza to jednak, że dowolna aplikacja UDP będzie zawsze szybsza od TCP. TCP zapewnia m.in. kontrolę kolejności, retransmisje i sterowanie przepływem, a zachowanie konkretnej aplikacji zależy od jej protokołu i warunków sieci. Kalkulator porównuje wyłącznie podstawowy koszt nagłówków i ramek.
Jak MTU wpływa na czas transmisji?
Większe MTU pozwala umieścić więcej danych aplikacji w jednym pakiecie, dzięki czemu stały koszt nagłówków i elementów Ethernet przypada na większą porcję danych. Przy dużych transferach może to zmniejszyć liczbę ramek i poprawić efektywną przepustowość. Zmiana MTU musi jednak być obsługiwana przez całą ścieżkę, a większa wartość wpisana do kalkulatora nie oznacza automatycznie, że sieć rzeczywiście może używać takich ramek.
Przy standardowym Ethernet najczęściej spotyka się MTU 1500 B. Jumbo frames mogą być używane w kontrolowanych sieciach, np. w centrach danych lub sieciach storage, ale wymagają zgodnej konfiguracji urządzeń po drodze.
VLAN i dodatkowe nagłówki
Tag IEEE 802.1Q ma 4 B i zwiększa rozmiar ramki Ethernet. Kalkulator pozwala uwzględnić jeden lub dwa tagi, dzięki czemu można oszacować wpływ zwykłego VLAN albo podwójnego tagowania. W rzeczywistych sieciach mogą występować również inne warstwy enkapsulacji, na przykład PPPoE, MPLS, VXLAN, GRE lub IPsec. Nie są one automatycznie dodawane przez ten kalkulator.
Jak interpretować efektywną przepustowość?
Efektywna przepustowość pokazuje, ile bitów danych aplikacji przypada średnio na sekundę zajęcia medium w przyjętym modelu. Jeśli wynik jest niższy od nominalnej prędkości portu, różnica wynika z narzutu wymaganych nagłówków, ramek i odstępów międzyramkowych.
Jeżeli rzeczywisty pomiar jest wyraźnie niższy niż wynik kalkulatora, przyczyny należy szukać poza podstawowym narzutem: w ograniczeniach TCP, stratach i retransmisjach, opóźnieniach, wydajności urządzeń, konfiguracji, szyfrowaniu albo aplikacji.
Źródła merytoryczne
Najczęstsze pytania
Ostatnia aktualizacja: 09.09.2026