Forståelse af TCP-gennemstrømningens grænser
Når data overføres over et netværk, bestemmes den faktiske hastighed af en enkelt TCP-strøm ikke kun af den rå båndbredde. Forbindelsens reelle ydeevne styres af det svageste led i en kæde af tre uafhængige faktorer: forbindelseskapacitet, modtagevinduet og pakketab.
Værktøjet beregner den forventede TCP-gennemstrømning ved at evaluere disse tre lofter parallelt. Det laveste af disse lofter udgør den aktive flaskehals. Formlen for den overordnede beregning er defineret som:
throughput = min(rate × eff, window ÷ RTT, MSS ÷ RTT ÷ √p) · BDP = rate × RTT
Hvor rate er forbindelseshastighed, eff er protokoleffektivitet, window er modtagevindue, RTT er svartid (round-trip time), MSS er den maksimale segmentstørrelse, og p er sandsynligheden for pakketab. Ved at identificere, hvilken af disse parametre der er den begrænsende faktor, kan netværksingeniører og systemadministratorer præcist diagnosticere, hvorfor en hurtig forbindelse ikke udnyttes fuldt ud.
Båndbredde-forsinkelsesproduktet (BDP) og modtagevinduet
Båndbredde-forsinkelsesproduktet (BDP) definerer den mængde data, der skal være "i luften" (in flight) på netværksstien for at holde forbindelsen fuldt udnyttet. Formlen for BDP og det nødvendige vindue til at fylde ruten beregnes således:
BDP = rate × RTT = ‹rate› × ‹rtt› = ‹bdp› = ‹bytes›Vindue til at fylde ruten = BDP ÷ 8 = ‹bdp› → ‹window›
Hvis modtagevinduet er sat lavere end denne værdi, vil afsenderen blive tvunget til at stoppe og vente på bekræftelser (ACK-pakker) fra modtageren, hvilket efterlader forbindelsen delvist ubenyttet. Gennemstrømningen begrænses i dette scenarie af vinduesgrænsen:
Vinduesgrænse = vindue ÷ RTT = ‹window› ÷ ‹rtt› = ‹value›
TCP-vinduesskalering (RFC 7323)
I ældre netværksimplementeringer var det maksimale modtagevindue begrænset til 16 bit, hvilket svarer til 65,535 bytes. På moderne højhastighedsforbindelser med høj latenstid (Long Fat Networks eller LFN) er dette uskalerede maksimum slet ikke tilstrækkeligt til at fylde ruten.
- Hvis det nødvendige vindue til at fylde ruten overstiger 65,535 bytes, viser værktøjet meddelelsen: "At fylde denne rute kræver et vindue på
‹window›— hvilket er over det uskalerede maksimum på 65,535 bytes, så begge ender skal forhandle TCP-vinduesskalering (RFC 7323)." - Den absolutte grænse for vinduesskalering under RFC 7323 er 1,073,725,440 bytes. Hvis det nødvendige vindue overstiger denne grænse, udløses meddelelsen: "At fylde denne rute kræver
‹window›— hvilket er mere end det største vindue, TCP kan forhandle (1,073,725,440 bytes). En enkelt strøm på denne rute kan aldrig overstige‹value›."
Hvis modtagevinduet er den aktive flaskehals, men kan øges inden for de tilladte standardgrænser, viser systemet noten: "Hvis modtagevinduet hæves til ‹window›, vil denne overførsel kunne nå op til ‹value›."
Protokol-overhead og forbindelsesgrænse
En del af den rå båndbredde går tabt til protokol-overhead. Hver pakke, der sendes over netværket, skal pakkes ind i lag-2 og lag-3 headere. Værktøjet modellerer dette baseret på standard Ethernet-rammer, hvilket tilføjer 78 bytes overhead pr. pakke (40 bytes til TCP/IP-headere og 38 bytes til fysisk wire-overhead på kablet).
Effektiviteten og den reelle forbindelsesgrænse efter overhead beregnes via følgende formler:
Protokoleffektivitet = MSS ÷ (MSS + 78 B) = ‹mss› ÷ ‹frame› = ‹eff› (40 B pakkeheadere + 38 B på kablet)Forbindelsesgrænse = hastighed × effektivitet = ‹rate› × ‹eff› = ‹value›
En standard Ethernet-nyttelast (MSS) på 1,460 bytes resulterer i en protokoleffektivitet på cirka 95%, hvilket betyder, at omkring 5% af den rå båndbredde altid forbruges af overhead.
Pakketabets indflydelse og Mathis-modellen
Pakketab har en dramatisk effekt på TCP-ydeevnen, fordi TCP tolker tabte pakker som et tegn på netværksophobning og øjeblikkeligt reducerer sin sendehastighed. For at estimere denne begrænsning anvender værktøjet Mathis-formlen:
Tabsgrænse (Mathis) = MSS ÷ RTT ÷ √p = ‹mss› ÷ ‹rtt› ÷ √‹p› = ‹value›
Mathis-modellen forudsætter, at pakketab sker jævnt og uafhængigt. Modellen er kun pålidelig ved tabsrate under ca. 1%. Hvis det indtastede pakketab overstiger denne grænse, viser værktøjet advarslen: "Tab over 1% er uden for Mathis-modellens pålidelige område — betragt tabsgrænsen som optimistisk." I virkelighedens netværk vil stødvis tab (burst loss) ofte reducere ydeevnen endnu mere, end modellen forudsiger.
Beregning af overførselstid
Når den effektive gennemstrømning er fundet som den laveste af de tre grænser, beregner værktøjet den samlede tid, det tager at flytte den angivne datamængde:
Overførselstid = RTT + 8 × størrelse ÷ gennemstrømning = ‹rtt› + 8 × ‹size› ÷ ‹throughput› = ‹time›
Formlen tager højde for den indledende svartid (1 RTT) til at etablere forbindelsen (tid til første byte), hvorefter selve dataoverførslen (bulk transfer time) finder sted.
Modelbegrænsninger og forudsætninger
Beregningerne antager en stabil tilstand for en enkelt TCP-strøm. Modellen udelader bevidst dynamiske faktorer som TCP slow start, løbende justering af overbelastningskontrol, langsomme modtagere, der ikke kan tømme deres buffere hurtigt nok, samt TLS-handshakes. Reelle overførsler vil derfor starte langsommere og kan ligge under de beregnede teoretiske lofter. Der findes ingen universel sikkerhedsmargin; resultaterne skal betragtes som en teoretisk øvre grænse.
Databehandling og privatliv
Alle indtastede værdier og beregninger udføres lokalt direkte i din egen browser. Der sendes ingen data til eksterne servere, hvilket sikrer, at følsomme netværksparametre eller datastørrelser forbliver på din lokale maskine.
Ofte stillede spørgsmål (FAQ)
Hvorfor er min overførsel langsommere end den forbindelseshastighed, jeg betaler for?
En enkelt TCP-strøm møder tre uafhængige grænser, og den laveste vinder. Protokol-overhead reducerer selve forbindelsen med ca. 5% — en standard Ethernet-ramme bærer 1,460 bytes nyttelast ud af 1,538 på kablet. Modtagevinduet begrænser gennemstrømningen til vindue ÷ RTT, så det klassiske vindue på 65,535 bytes begrænser en rute med 50 ms til ca. 10.5 Mbit/s, uanset hvor hurtig forbindelsen er. Og tab begrænser den til (MSS ÷ RTT) ÷ √tab. Resultatet ovenfor angiver, hvilken grænse der er den begrænsende faktor for dine tal.
Hvad er båndbredde-forsinkelsesproduktet (BDP), og hvorfor bestemmer det vinduesstørrelsen?
BDP — forbindelseshastighed × svartid (RTT) — er mængden af data i transit på et givet tidspunkt. TCP kan højst have ét udestående vindue uden bekræftelse, så et vindue, der er mindre end BDP, efterlader forbindelsen delvist tom: Ved 100 Mbit/s med en RTT på 50 ms rummer forbindelsen 625 kB, og et vindue på 65,535 bytes fylder knap en tiendedel af den. Det er derfor, hurtige ruter med høj latenstid kræver TCP-vinduesskalering (RFC 7323), hvilket hæver det forhandlingsbare maksimum fra 65,535 bytes til omkring 1 GB.
Hvordan begrænser pakketab TCP-gennemstrømningen?
TCP behandler tab som overbelastning og halverer sin sendehastighed ved hver tabshændelse, så selv minimale tabsrate har stor betydning på hurtige ruter. Mathis-modellen estimerer grænsen som (MSS ÷ RTT) ÷ √p — ved 0.01% tab på en rute med 50 ms og en MSS på 1,460 bytes er det ca. 23 Mbit/s, uanset forbindelsens hastighed. Modellen antager jævnt fordelte, uafhængige tabshændelser; under ca. 1% stemmer den godt overens med virkeligheden, og ved stødvis tab er den optimistisk.
Er megabytes her de samme som i mit filhåndteringsprogram?
Ikke helt. Denne side bruger decimalenheder, som er standarden inden for netværk: 1 kbit = 1,000 bits og 1 MB = 1,000,000 bytes. De fleste filhåndteringsprogrammer tæller i 1024-baserede enheder, som ofte fejlagtigt kaldes MB — en fil på ”100 MB” der er normalt 100 MiB ≈ 104.86 decimale MB, så den tager ca. 5% længere tid at flytte, end det decimale tal antyder. Indtast 104.86 MB her for at matche det præcist.