Netwerkvertraging en bandbreedte calculator

Werking van de TCP-prestatielimieten

De Network Latency Bandwidth Calculator berekent de theoretische en praktische prestatielimieten van een enkele TCP-stroom op basis van de specifieke netwerkcondities. Door het invoeren van de verbindingssnelheid, de round-trip-tijd en de gegevensgrootte identificeert de tool direct welke bottleneck de verbinding beperkt. Hierbij worden de verwachte TCP-doorvoer en de totale overdrachtstijd nauwkeurig in kaart gebracht.

De berekening is gebaseerd op het principe dat een TCP-verbinding wordt gereguleerd door drie onafhankelijke limieten:

1. De fysieke of gecontracteerde capaciteit van de verbinding, gecorrigeerd voor protocoloverhead.
2. De bufferlimiet van de ontvanger, oftewel het ontvangstvenster.
3. De invloed van pakketverlies op de congestiecontrole van het TCP-protocol.

De laagste van deze drie limieten bepaalt uiteindelijk de werkelijke prestaties van de datastroom.

Invoerparameters van het netwerkpad

Om een nauwkeurige berekening uit te voeren, vereist de calculator een aantal specifieke invoergegevens over het netwerkpad, de payload en de TCP-instellingen:

• Verbindingssnelheid: Dit is de langzaamste hop op het pad, wat in de praktijk vaak overeenkomt met de nominale snelheid van je abonnement. De waarde moet groter zijn dan nul. De bijbehorende eenheid kies je in de keuzelijst ernaast.
• Round-trip-tijd (RTT): De ping-tijd naar de andere kant. Gebruik hierbij de hoogste waarde die je verwacht onder belasting. Deze waarde moet groter zijn dan nul; de bijbehorende eenheid kies je in de keuzelijst ernaast.
• Gegevensgrootte: De over te dragen payload, zoals een bestand, een back-up of een dataset. Deze waarde moet groter zijn dan nul; de bijbehorende eenheid kies je in de keuzelijst ernaast.
• Ontvangstvenster: De hoeveelheid bytes die de ontvanger kan bufferen. Deze waarde moet groter zijn dan nul en mag niet hoger zijn dan 1.073.725.440 bytes. Als dit veld leeg wordt gelaten, impliceert dit dat er geen vensterlimiet van toepassing is. De eenheid kies je in de keuzelijst ernaast.
• MSS (in bytes): De payload-bytes per pakket. Dit moet een geheel aantal bytes tussen 1 en 65.495 zijn. Een lege waarde zorgt ervoor dat overhead en verlies worden genegeerd in de berekening.
• Pakketverlies (%): De gemiddelde kans op pakketverlies. Dit percentage moet tussen 0 en 100 liggen. Een leeg veld of een invoer van 0 betekent dat er geen verlieslimiet wordt toegepast.
• Weergegeven decimalen: Hiermee wordt de precisie van de getoonde resultaten achter de komma ingesteld.

De interface biedt daarnaast de knop Voorbeeld laden om de velden direct te vullen met demonstratiedata, en de knop Wissen om alle invoervelden te resetten.

Analyse van de rekenresultaten

Zodra de gegevens zijn ingevoerd, toont de calculator de resultaten verdeeld over verschillende secties:

Doorvoer en overdrachtstijd

Het centrale resultaat is de Verwachte TCP-doorvoer, die direct wordt vergezeld door de actieve bottleneck via de melding "beperkt door ‹constraint›". De variabele ‹constraint› wordt dynamisch ingevuld als verbindingscapaciteit, het ontvangstvenster of pakketverlies.

Daarnaast worden de volgende specifieke statistieken berekend:

• Overdrachtstijd
• Tijd tot eerste byte (1 RTT)
• Bulk-overdrachtstijd
• Bandbreedte-vertraging product
• Venster om het pad te vullen
• Venstergelimiteerde doorvoer
• Verliesgelimiteerde doorvoer (Mathis)
• Verbindingslimiet na overhead
• Protocolefficiëntie

Met de knop Resultaat kopiëren kunnen alle berekende waarden direct naar het klembord worden gekopieerd.

Dynamische systeemnotities

Afhankelijk van de ingevoerde waarden genereert de calculator specifieke waarschuwingen en adviezen:

• "Het vullen van dit pad vereist een venster van ‹window› — groter dan het niet-geschaalde maximum van 65,535 bytes, dus beide zijden moeten TCP window scaling (RFC 7323) onderhandelen."
• "Het vullen van dit pad vereist ‹window› — meer dan het grootste venster dat TCP kan onderhandelen (1,073,725,440 bytes). Een enkele stroom op dit pad kan nooit sneller zijn dan ‹value›."
• "Het verhogen van het ontvangstvenster naar ‹window› zou deze overdracht een snelheid tot ‹value› laten bereiken."
• "Verlies boven 1% valt buiten het betrouwbare bereik van het Mathis-model — beschouw de verlieslimiet als optimistisch."

Formules en wiskundige substitutie

De calculator maakt de onderliggende wiskunde transparant door de gebruikte formules te tonen:

• Hoofdformule: doorvoersnelheid = min(snelheid × eff, venster ÷ RTT, MSS ÷ RTT ÷ √p) · BDP = snelheid × RTT
• Protocolefficiëntie: Protocolefficiëntie = MSS ÷ (MSS + 78 B) = ‹mss› ÷ ‹frame› = ‹eff› (40 B pakketheaders + 38 B op de kabel)
• Verbindingslimiet: Verbindingslimiet = snelheid × efficiëntie = ‹rate› × ‹eff› = ‹value›
• BDP: BDP = snelheid × RTT = ‹rate› × ‹rtt› = ‹bdp› = ‹bytes›
• Venster om het pad te vullen: Venster om het pad te vullen = BDP ÷ 8 = ‹bdp› → ‹window›
• Vensterlimiet: Vensterlimiet = venster ÷ RTT = ‹window› ÷ ‹rtt› = ‹value›
• Verlieslimiet (Mathis): Verlieslimiet (Mathis) = MSS ÷ RTT ÷ √p = ‹mss› ÷ ‹rtt› ÷ √‹p› = ‹value›
• Verwachte doorvoer: Verwachte doorvoer = de laagste van deze limieten = ‹value› → beperkt door ‹constraint›
• Overdrachtstijd: Overdrachtstijd = RTT + 8 × grootte ÷ doorvoer = ‹rtt› + 8 × ‹size› ÷ ‹throughput› = ‹time›

Randvoorwaarden en modelbeperkingen

Bij het interpreteren van de resultaten moet rekening worden gehouden met de volgende technische regels en aannames:

• Decimale eenheden: Alle netwerkberekeningen maken gebruik van decimale standaarden (bijvoorbeeld 1 kbit = 1.000 bits en 1 MB = 1.000.000 bytes). Bestandsbeheerders rapporteren bestandsgroottes daarentegen vaak in binaire eenheden (1024-gebaseerd), waardoor een bestand van "100 MB" in werkelijkheid 100 MiB (ongeveer 104,86 decimale MB) groot is.
• Protocoloverhead: De calculator modelleert de overhead op basis van standaard Ethernet. Dit voegt 78 bytes per pakket toe aan de fysieke laag (40 bytes voor de TCP/IP-headers en 38 bytes voor de fysieke kabeloverhead).
• Grenzen van het Mathis-model: Dit model is ontworpen voor stabiel, gelijkmatig verdeeld en onafhankelijk pakketverlies. Zodra het verliespercentage de grens van 1% overschrijdt, verliest het model zijn betrouwbaarheid en moet de berekende verlieslimiet als te optimistisch worden beschouwd.
• Window Scaling Limieten: Zonder window scaling (RFC 7323) is het TCP-ontvangstvenster beperkt tot maximaal 65.535 bytes. Met actieve window scaling ligt de absolute limiet op 1.073.725.440 bytes. Invoerwaarden die deze grens overschrijden, resulteren in een foutmelding.
• Systeemuitsluitingen: De berekeningen gaan uit van een stabiele, reeds opgezette single-stream TCP-verbinding. Factoren zoals de TCP slow start-fase, specifieke congestiecontrole-algoritmen, trage verwerking aan de ontvangstzijde en TLS-handshakes zijn niet in dit model opgenomen. Echte overdrachten zullen hierdoor in de praktijk langzamer opstarten.

Foutmeldingen bij invoer

Wanneer ingevoerde gegevens niet voldoen aan de validatieregels, toont de calculator een van de volgende foutmeldingen:

• Bij ongeldige tekens of lege verplichte velden: "‹field›: “‹token›” is geen getal."
• Bij een verbindingssnelheid van nul of lager: "De verbindingssnelheid moet groter zijn dan nul."
• Bij een RTT van nul of lager: "De round-trip time moet groter zijn dan nul."
• Bij een gegevensgrootte van nul of lager: "De gegevensgrootte moet groter zijn dan nul."
• Bij een ontvangstvenster van nul of lager: "Het ontvangstvenster moet groter zijn dan nul."
• Bij een ontvangstvenster dat de RFC 7323-limiet overschrijdt: "TCP kan geen venster onderhandelen dat groter is dan 1,073,725,440 bytes (RFC 7323 window scaling)."
• Bij een MSS buiten de toegestane grenzen: "De MSS moet een geheel aantal bytes tussen 1 en 65,495 zijn."
• Bij een verliespercentage buiten de grenzen: "Het verliespercentage moet tussen 0 en 100 procent liggen."
• Bij het overschrijden van de rekenlimieten van het systeem: "Een waarde of tussenresultaat overschrijdt het ondersteunde getallenbereik."

Privacy en gegevensverwerking

De privacy van de ingevoerde gegevens is lokaal gewaarborgd. Elke waarde die je invoert, wordt direct binnen jouw eigen webbrowser berekend. Er vindt geen enkele gegevensoverdracht plaats naar externe servers of databases.

Veelgestelde vragen (FAQ)

Wat is het bandwidth-delay product en waarom bepaalt dit de venstergrootte?

De BDP — verbindingssnelheid × round-trip time — is de hoeveelheid gegevens die op elk moment onderweg is. TCP kan maximaal één niet-bevestigd venster openstaan hebben, dus een venster kleiner dan de BDP laat de pijplijn deels leeg: bij 100 Mbit/s met een RTT van 50 ms bevat de pijplijn 625 kB, en een venster van 65,535 bytes vult nog geen tiende daarvan. Daarom hebben snelle, lange paden TCP window scaling (RFC 7323) nodig, wat het onderhandelbare maximum verhoogt van 65,535 bytes naar ongeveer 1 GB.

Waarom is mijn overdracht trager dan de verbindingssnelheid waarvoor ik betaal?

Een enkele TCP-stroom heeft te maken met drie onafhankelijke limieten, waarbij de laagste wint. Protocoloverhead vermindert de verbinding zelf met ongeveer 5% — een standaard Ethernet-frame bevat 1,460 bytes aan payload van de 1,538 bytes op de kabel. Het ontvangstvenster begrenst de doorvoer op venster ÷ RTT, waardoor het klassieke venster van 65,535 bytes een pad van 50 ms beperkt tot ongeveer 10.5 Mbit/s, hoe snel de verbinding ook is. En verlies begrenst de doorvoer op (MSS ÷ RTT) ÷ √verlies. Het resultaat hierboven geeft aan welke limiet bindend is voor jouw cijfers.

Hoe beperkt pakketverlies de TCP-doorvoer?

TCP behandelt verlies als congestie en halveert de verzendsnelheid bij elke verliesgebeurtenis, waardoor zelfs minimale verliespercentages zwaar wegen op snelle paden. Het Mathis-model schat de limiet op (MSS ÷ RTT) ÷ √p — bij 0.01% verlies op een pad van 50 ms met een MSS van 1,460 bytes is dat ongeveer 23 Mbit/s, ongeacht de verbindingssnelheid. Het model gaat uit van gelijkmatig verdeelde, onafhankelijke verliesgebeurtenissen; onder de circa 1% komt dit goed overeen met de realiteit, en bij geconcentreerd (bursty) verlies is het optimistisch.

Zijn de megabytes hier hetzelfde als in mijn bestandsbeheerder?

Niet helemaal. Deze pagina gebruikt decimale eenheden, de netwerkconventie: 1 kbit = 1,000 bits en 1 MB = 1,000,000 bytes. De meeste bestandsbeheerders rekenen in eenheden gebaseerd op 1024, vaak verkeerd gelabeld als MB — een bestand van "100 MB" daar is meestal 100 MiB ≈ 104.86 decimale MB, waardoor het overzetten ongeveer 5% langer duurt dan het decimale getal suggereert. Voer hier 104.86 MB in om het exact te laten overeenstemmen.