Förståelse av TCP-genomströmningens tak
Ett enskilt TCP-flöde kan aldrig utnyttja en nätverksförbindelse till fullo utan att ta hänsyn till de fysiska och protokollspecifika begränsningar som styr vägen mellan sändare och mottagare. Den faktiska prestandan bestäms alltid av det lägsta av tre oberoende tak: länkkapacitet, mottagningsfönster och paketförlust.
När data skickas över ett nätverk måste sändaren vänta på bekräftelser (ACK) från mottagaren. Tiden det tar för ett paket att färdas till mottagaren och få en bekräftelse tillbaka kallas för tur-och-retur-tid (RTT). Om mottagarens buffert eller nätverkets tolerans för förlorade paket är för liten, kommer sändaren att tvingas pausa överföringen i väntan på bekräftelser. Detta skapar en flaskhals som sänker den effektiva datatakten långt under den teoretiska länkhastigheten.
Bandbreddsfördröjningsprodukten (BDP) och buffertkrav
För att hålla en nätverksförbindelse helt fylld med data krävs att sändaren kan skicka tillräckligt mycket data innan den första bekräftelsen tas emot. Denna datamängd kallas för bandbreddsfördröjningsprodukt (BDP) och beräknas enligt formeln:
BDP = hastighet × RTT
Om mottagningsfönstret är mindre än BDP kommer sändaren att tömma sitt tillåtna sändningsfönster och tvingas vänta på ACK-paket. Detta innebär att nätverkskabeln under perioder blir helt tom på data, vilket drastiskt sänker genomströmningen.
För att beräkna det exakta fönster som krävs för att fylla vägen används formeln:
Fönster för att fylla vägen = BDP ÷ 8
Om mottagningsfönstret sätts lägre än detta värde blir överföringen fönsterbegränsad, och den maximala datatakten kan då aldrig överstiga fönstertaket:
Fönstertak = window ÷ RTT
TCP-fönsterskalning och begränsningar enligt RFC 7323
I äldre nätverksstandarder var det maximala mottagningsfönstret för TCP begränsat till 16 bitar, vilket motsvarar högst 65 535 byte. På moderna, snabba förbindelser med hög latens (så kallade LFN eller "long-fat networks") är detta fönster alldeles för litet för att fylla vägen.
För att lösa detta introducerades TCP-fönsterskalning via RFC 7323, vilket gör det möjligt att skala upp fönstret till maximalt 1 073 725 440 byte.
- Om beräkningen visar att det krävs ett fönster över 65 535 byte för att fylla vägen, visar verktyget meddelandet: "Att fylla den här vägen kräver ett fönster på
‹window›— vilket är över det oskalade maximivärdet på 65,535 byte, så båda ändar måste förhandla om TCP-fönsterskalning (RFC 7323)." - Om det krävda fönstret överskrider den absoluta gränsen för vad TCP kan förhandla fram, visas meddelandet: "Att fylla den här vägen kräver
‹window›— vilket är bortom det största fönster TCP kan förhandla om (1,073,725,440 byte). Ett enskilt flöde på den här vägen kan aldrig överskrida‹value›."
Paketförlustens inverkan och Mathis-modellen
Paketförlust har en förödande effekt på TCP-prestanda eftersom TCP tolkar varje förlorat paket som ett tecken på nätverksträngsel och omedelbart stryper sändningshastigheten. För att uppskatta genomströmningen vid paketförlust används Mathis-formeln:
Förlusttak (Mathis) = MSS ÷ RTT ÷ √p
Där MSS är max segmentstorlek och p är sannolikheten för paketförlust. Mathis-modellen förutsätter att paketförlusterna är jämnt fördelade och oberoende av varandra. Modellen är tillförlitlig endast vid förlustnivåer under cirka 1%. Om den angivna paketförlusten överstiger denna gräns visar verktyget varningen: "Förlust över 1% ligger utanför Mathis-modellens tillförlitliga intervall — betrakta förlusttaket som optimistiskt."
Protokolleffektivitet och nätverksoverhead
En del av den tillgängliga länkhastigheten försvinner alltid i form av protokollhuvuden (overhead). Verktyget baserar sina beräkningar på standard Ethernet, vilket lägger till totalt 78 byte overhead per paket (40 byte för TCP/IP-huvuden och 38 byte för fysisk kabeloverhead).
Effektiviteten beräknas som:
Protokolleffektivitet = MSS ÷ (MSS + 78 B)
Detta innebär att det faktiska länktaket efter overhead blir:
Länktak = rate × effektivitet
Enheter och beräkningsmodeller
Vid nätverksberäkningar används strikt decimala enheter (där till exempel 1 kbit = 1 000 bitar och 1 MB = 1 000 000 byte). Detta skiljer sig från operativsystem och filhanterare som ofta använder binära enheter (där 1 KiB = 1 024 byte). En fil som i filhanteraren rapporteras som 100 MB är i själva verket cirka 104.86 decimala megabyte, vilket påverkar den faktiska överföringstiden.
Modellen förutsätter ett stabilt tillstånd (steady state) för ett enskilt TCP-flöde. Faktorer som TCP slow start, justering av trängselkontroll, tröga mottagare och TLS-handskakningar är utelämnade ur modellen. Verkliga överföringar startar därför långsammare och presterar ofta under de beräknade taken.
Formler och matematiska samband
Verktyget använder följande matematiska samband för att fastställa prestandan:
- Huvudformel:
genomströmning = min(hastighet × eff, fönster ÷ RTT, MSS ÷ RTT ÷ √p) · BDP = hastighet × RTT - Protokolleffektivitet:
Protokolleffektivitet = MSS ÷ (MSS + 78 B) = ‹mss› ÷ ‹frame› = ‹eff› (40 B pakethuvuden + 38 B på kabeln) - Länktak:
Länktak = rate × effektivitet = ‹rate› × ‹eff› = ‹value› - BDP:
BDP = hastighet × RTT = ‹rate› × ‹rtt› = ‹bdp› = ‹bytes› - Fönster för att fylla vägen:
Fönster för att fylla vägen = BDP ÷ 8 = ‹bdp› → ‹window› - Fönstertak:
Fönstertak = window ÷ RTT = ‹window› ÷ ‹rtt› = ‹value› - Förlusttak (Mathis):
Förlusttak (Mathis) = MSS ÷ RTT ÷ √p = ‹mss› ÷ ‹rtt› ÷ √‹p› = ‹value› - Förväntad datatakt:
Förväntad datatakt = det lägsta av dessa tak = ‹value› → begränsas av ‹constraint› - Överföringstid:
Överföringstid = RTT + 8 × size ÷ throughput = ‹rtt› + 8 × ‹size› ÷ ‹throughput› = ‹time›
Integritet och lokal databehandling
När du använder denna kalkylator sker all databehandling lokalt. Varje värde du anger beräknas lokalt i den här webbläsaren — ingenting skickas någonstans. Detta gör att du kan analysera nätverksparametrar utan att riskera att känslig information om din infrastruktur eller dina datamängder lämnar din lokala maskin.
Vanliga frågor
Varför är min överföring långsammare än den länkhastighet jag betalar för?
Ett enskilt TCP-flöde möter tre oberoende tak, och det lägsta vinner. Protokollets overhead minskar själva länken med cirka 5% — en standard Ethernet-ram bär 1,460 byte nyttolast av 1,538 byte på kabeln. Mottagningsfönstret begränsar datatakten till fönster ÷ RTT, så det klassiska fönstret på 65,535 byte begränsar en förbindelse med 50 ms till cirka 10.5 Mbit/s oavsett hur snabb länken är. Och förlust begränsar den till (MSS ÷ RTT) ÷ √förlust. Resultatet ovan visar vilket tak som begränsar dina siffror.
Vad är bandbreddsfördröjningsprodukten (BDP) och varför sätter den fönsterstorleken?
BDP — länkhastighet × tur-och-retur-tid — är mängden data som är i rörelse vid varje givet tillfälle. TCP kan ha högst ett obekräftat fönster utestående, så ett fönster som är mindre än BDP lämnar förbindelsen delvis tom: vid 100 Mbit/s med 50 ms RTT rymmer förbindelsen 625 kB, och ett fönster på 65,535 byte fyller knappt en tiondel av den. Det är därför snabba förbindelser med långa avstånd behöver TCP-fönsterskalning (RFC 7323), vilket höjer det förhandlingsbara maximivärdet från 65,535 byte till cirka 1 GB.
Hur begränsar paketförlust TCP-datatakt?
TCP behandlar förlust som trängsel och halverar sin sändningshastighet vid varje förlusthändelse, så även minimala förlustnivåer spelar roll på snabba förbindelser. Mathis-modellen uppskattar taket till (MSS ÷ RTT) ÷ √p — vid 0.01% förlust på en förbindelse med 50 ms och en MSS på 1,460 byte är det cirka 23 Mbit/s, oavsett länkhastighet. Modellen förutsätter jämnt fördelade, oberoende förlusthändelser; under ungefär 1% stämmer den väl överens med verkligheten, och vid skurartad förlust är den optimistisk.
Är megabyte här samma sak som i mi n filhanterare?
Inte helt. Den här sidan använder decimala enheter, vilket är nätverkskonventionen: 1 kbit = 1,000 bitar och 1 MB = 1,000,000 byte. De flesta filhanterare räknar i 1024-baserade enheter, ofta felaktigt märkta MB — en fil på ”100 MB” där är vanligtvis 100 MiB ≈ 104.86 decimala MB, så den tar cirka 5% längre tid att flytta än vad den decimala siffran antyder. Ange 104.86 MB här för att matcha det exakt.