Kalkulator for nettverksforsinkelse og båndbredde

Forventet TCP-gjennomstrømning og flaskehalser

Når data overføres over et nettverk, er den faktiske hastigheten til en enkelt TCP-strøm begrenset av mer enn bare den nominelle kapasiteten på linjen. Forbindelsens ytelse påvirkes kontinuerlig av fysisk avstand, signalforsinkelse, bufferstørrelser og pakketap.

Dette verktøyet beregner det reelle ytelsestaket for en enkelt TCP-forbindelse basert på gjeldende nettverksforhold. Ved å analysere samspillet mellom linjehastighet, tur-retur-tid (RTT), mottaksvindu, maksimal segmentstørrelse (MSS) og pakketap, identifiserer kalkulatoren nøyaktig hvilken faktor som utgjør den aktive flaskehalsen.

Slik beregnes nettverkets ytelsestak

For å finne den forventede gjennomstrømningen, evaluerer kalkulatoren tre uavhengige ytelsestak parallelt. Det laveste av disse tre takene bestemmer den faktiske hastigheten:

1. Linjetak etter overhead: Den fysiske kapasiteten redusert med protokollens faste overhead.
2. Vindusbegrenset gjennomstrømning: Grensen som settes av mottakerens evne til å bufre data i forhold til forsinkelsen på ruten.
3. Tapsbegrenset gjennomstrømning (Mathis): Grensen som oppstår fordi TCP tolker pakketap som nettverksforstoppelse og reduserer sendehastigheten.

Protokolleffektivitet og overhead

Hver pakke som sendes over nettverket bærer med seg nødvendig kontrollinformasjon. Protokolloverhead beregnes med utgangspunkt i standard Ethernet, som legger til totalt 78 byte per pakke (40 byte for TCP/IP-hoder og 38 byte for fysisk overhead på linjen). Effektiviteten uttrykkes som:

Protokolleffektivitet = MSS ÷ (MSS + 78 B) = ‹mss› ÷ ‹frame› = ‹eff› (40 B pakkehoder + 38 B på linjen)

Dette betyr at det reelle linjetaket for nyttelast alltid vil ligge under den rå linjehastigheten:

Linjetak = hastighet × effektivitet = ‹rate› × ‹eff› = ‹value›

Båndbredde-forsinkelsesprodukt (BDP)

Båndbredde-forsinkelsesproduktet definerer hvor mye data som må være "i luften" for å holde nettverkslinjen fullt utnyttet. Formelen for BDP is:

BDP = hastighet × RTT = ‹rate› × ‹rtt› = ‹bdp› = ‹bytes›

For å fylle denne ruten helt, kreves det en spesifikk bufferstørrelse hos mottakeren:

Vindu for å fylle ruten = BDP ÷ 8 = ‹bdp› → ‹window›

Hvis mottaksvinduet er mindre enn denne verdien, vil senderen bli tvunget til å vente på bekreftelser (ACK) før den kan sende mer data, noe som begrenser hastigheten:

Vindustak = vindu ÷ RTT = ‹window› ÷ ‹rtt› = ‹value›

Mathis-modellen for pakketap

Når det oppstår pakketap, benytter kalkulatoren Mathis-formelen for å beregne den maksimale teoretiske gjennomstrømningen:

Taptak (Mathis) = MSS ÷ RTT ÷ √p = ‹mss› ÷ ‹rtt› ÷ √‹p› = ‹value›

Her representerer p den gjennomsnittlige sannsynligheten for pakketap. Mathis-modellen forutsetter jevnt fordelt, uavhengig pakketap og er pålitelig for tapsrater opp til omtrent 1%.

Endelig gjennomstrømning og overføringstid

Når alle tre takene er beregnet, bestemmes den forventede gjennomstrømningen av den mest restriktive faktoren:

Forventet gjennomstrømning = det laveste av disse takene = ‹value› → begrenset av ‹constraint›

Den totale tiden det tar å overføre den angitte datamengden inkluderer tiden det tar å etablere forbindelsen (1 RTT) pluss selve overføringen av nyttelasten:

Overføringstid = RTT + 8 × størrelse ÷ gjennomstrømning = ‹rtt› + 8 × ‹size› ÷ ‹throughput› = ‹time›

Grenser og tekniske forutsetninger

For at beregningene skal bli korrekte, må inndataene ligge innenfor definerte tekniske rammer og standarder:

• Mottaksvindu: Må være større enn null, og kan maksimalt settes til 1 073 725 440 byte. Hvis feltet etterlates tomt, antar modellen at det ikke finnes noen vindusbegrensning.
• Maksimal segmentstørrelse (MSS): Må være et heltall mellom 1 og 65 495 byte. Hvis feltet står tomt, ignoreres protokolloverhead og pakketap i beregningen.
• Pakketap: Må oppgis som en verdi mellom 0 og 100 prosent. Tomt felt eller 0 tolkes som en rute helt uten pakketap.
• TCP-vindusskalering (RFC 7323): Det klassiske, uskalerte TCP-mottaksvinduet har en øvre grense på 65 535 byte. Dersom ruten krever et større vindu for å fylles, må begge endepunkter forhandle om vindusskalering i henhold til RFC 7323. Den absolutte grensen for skalerte vinduer er 1 073 725 440 byte.
• Modellbegrensninger: Beregningene forutsetter en etablert, stabil enkeltstrøm (steady-state). Reelle nettverksfaktorer som TCP slow start, dynamisk justering av flytkontroll, trege mottakere og TLS-håndtrykk faller utenfor denne modellen. Faktiske overføringer vil derfor starte tregere og kan ende opp under de beregnede takene.

Feilmeldinger ved ugyldige inndata

Kalkulatoren validerer alle inndata fortløpende og vil gi spesifikke feilmeldinger dersom verdiene ikke kan behandles:

• Dersom et felt inneholder ulovlige tegn: "‹field›: «‹token›» er ikke et tall."
• Dersom linjehastigheten er null eller negativ: "Linjehastigheten må være større enn null."
• Dersom tur-retur-tiden er null eller negativ: "Tur-retur-tiden må være større enn null."
• Dersom datastørrelsen er null eller negativ: "Datastørrelsen må være større enn null."
• Dersom mottaksvinduet er null eller negativ: "Mottaksvinduet må være større enn null."
• Dersom mottaksvinduet overskrider protokollgrensen: "TCP kan ikke forhandle om et vindu over 1,073,725,440 byte (RFC 7323-vindusskalering)."
• Dersom MSS er utenfor gyldig område: "MSS må være et heltall i byte mellom 1 og 65,495."
• Dersom pakketap er utenfor gyldig område: "Pakketapet må være mellom 0 og 100 prosent."
• Dersom beregningene blir for store for systemet: "En verdi eller et mellomresultat overskrider det støttede tallområdet."

Personvern og lokal databehandling

Sikkerhet og personvern ivaretas ved at alle beregninger utføres lokalt. Hver verdi du skriver inn beregnes i denne nettleseren — ingenting sendes noen steder.

Ofte stilte spørsmål (FAQ)

Hvorfor er overføringen min tregere enn linjehastigheten jeg betaler for?
En enkelt TCP-strøm møter tre uavhengige tak, og det laveste vinner. Protokolloverhead reduserer selve linjen med rundt 5% — en standard Ethernet-ramme bærer 1,460 byte nyttelast av totalt 1,538 på linjen. Mottaksvinduet begrenser gjennomstrømningen til vindu ÷ RTT, så det klassiske vinduet på 65,535 byte begrenser en rute på 50 ms til rundt 10.5 Mbit/s uansett hvor rask linjen er. Og tap begrenser den til (MSS ÷ RTT) ÷ √tap. Resultatet ovenfor navngir hvilket tak som er begrensende for dine tall.

Hva er båndbredde-forsinkelsesproduktet, og hvorfor bestemmer det vindusstørrelsen?
BDP — linjehastighet × tur-retur-tid — er mengden data som er underveis i et gitt øyeblikk. TCP kan maksimalt ha ett ubekreftet vindu utestående, så et vindu som er mindre enn BDP, lar linjen være delvis tom: Ved 100 Mbit/s med en RTT på 50 ms rommer linjen 625 kB, og et vindu på 65,535 byte fyller knapt en tiendedel av den. Det er derfor raske ruter med lang avstand trenger TCP-vindusskalering (RFC 7323), som hever det forhandlingsbare maksimumet fra 65,535 byte til rundt 1 GB.

Hvordan begrenser pakketap TCP-gjennomstrømningen?
TCP behandler tap som overbelastning og halverer sendehastigheten ved hver tapshendelse, så selv svært lave tapsrater har stor betydning på raske ruter. Mathis-modellen estimerer taket til (MSS ÷ RTT) ÷ √p — ved 0.01% tap på en 50 ms rute med en MSS på 1,460 byte tilsvarer det rundt 23 Mbit/s, uavhengig av linjehastigheten. Modellen forutsetter jevnt fordelte, uavhengige tapshendelser; under omtrent 1% stemmer den godt med virkeligheten, og ved ujevnt tap (bursty loss) er den optimistisk.

Er megabytene her de samme som i filbehandleren min?
Ikke helt. Denne siden bruker desimale enheter, som er nettverkskonvensjonen: 1 kbit = 1,000 bit og 1 MB = 1,000,000 byte. De fleste filbehandlere teller i 1024-baserte enheter, ofte feilaktig merket som MB — en fil på «100 MB» der er vanligvis 100 MiB ≈ 104.86 desimale MB, så den tar omtrent 5% lengre tid å overføre enn det det desimale tallet antyder. Skriv inn 104.86 MB her for at det skal samsvare nøyaktig.