Glem ikke latenstid, når du beregner netværksydelse

0 Flares kvidre 0 Facebook 0 LinkedIn 0 E-mail-0 Flares liter

i mit job, jeg er nødt til at lære en masse om flere emner af det. Især på virtualiseringsmarkedet er mange mennesker normalt godt forberedt, når det kommer til infrastruktur, servere og opbevaring, men jeg fandt ud af, at det svageste punkt er mange gange netværk. Der er nogle emner, der er uklare for mange, som Layer2 vs Layer3, BGP, Spanning Tree, men der er et emne, der er virkelig vigtigt, selv for infrastruktur fyre, men det er næsten ukendt for dem: latens.

hvad er latens?

så hurtigt som det kan være, er selv lyshastigheden ikke uendelig. Det tager tid for en foton at gå fra punkt A til punkt B, og for eksempel tager det lys, der genereres af solen, 8 minutter at nå jorden. Vores computernetværk er ikke engang tæt på den hastighed, for først og fremmest er vores forbindelser normalt ikke lavet med optisk fiber (som i sidste ende ville være så hurtig som lys), men med elektriske kabler og så transmissioner over disse medier er langsommere, men også fordi der er mange apparater mellem kilde og destination, der har brug for at manipulere pakken. Kildeværten, afbrydere, routere, brandvægge, målværten; hvert “hop” tilføjer tid til den samlede tid, som en pakke har brug for for at nå sin destination. Vi kan designe denne situation som denne:

(kilde: https://stackoverflow.com/questions/8682702/how-to-calculate-packet-time-from-latency-and-bandwidth )

så, simpelthen sagt, latenstid er den tid, det tager at en pakke til at gå fra kilde til destination.

i et lokalt netværk er det nemt at anvende en vis tilnærmelse og erklære, at behandlingsforsinkelsen er 0, og også at de flere kontakter mellem to værter ikke tilføjer yderligere latenstid. Når alt kommer til alt, når vi kører en ping-kommando for at kontrollere, om en vært er tilsluttet, er latenstid altid “under 1 Frk” :

af denne grund er det ikke ualmindeligt at beregne den maksimale overførselshastighed ved blot at se på den tilgængelige båndbredde:

– 1 Gb ethernet link , divideret med 8, giver mig 125 MBps

– 10 Gb ethernet link betyder 1250 MBps

og så videre. Og hvis min båndbredde er 125MBps, betyder det, at jeg kan overføre 125mb hvert sekund.

hvorfor latenstid er vigtig?

fordi at ignorere det sammen med andre parametre fører til falske resultater!

se på det foregående eksempel. Selv på et lokalt netværk, hvor latenstiden er tæt på nul, er der andre parametre, der kan påvirke den endelige hastighed. En frem for alt: TCP-vinduesstørrelse. Jeg vil ikke gentage, hvad der allerede er skrevet på en perfekt måde af andre, så hvis du vil lære mere, skal du læse dette indlæg af Brad Hedlund. Hvad er fangsten? Den linkhastighed, vi normalt taler om, er den rene kabelforbindelseshastighed. Men oven på det skal vi køre flere protokoller, den ene over den anden, som TCP over IP. TCP opdeler data i pakker, og størrelsen på pakkerne dikteres af TCP-vinduets størrelse: større denne værdi, flere data kan overføres i en enkelt transmission. Derefter pakkes en nyttelast inde i en pakke, så der er yderligere bytes for hver pakke, som skibet skal transmitteres, selvom de ikke indeholder nogen data (der er også noget overhead for den underliggende ethernet-ramme, tænk på Al diskussion med hensyn til Jumbo-rammer). Endelig spiller TCP latency sin rolle, fordi jeg kun kan overføre den næste pakke, når den forrige har nået sin destination, fordi linket ellers er optaget af at overføre de andre pakker.

latens og vinduesstørrelse bliver altafgørende, når vi flytter fra lokale netværk til offentlige netværk. Her går <1ms-værdien væk, og vi har højere værdier at tage højde for. Højere er latensen, mindre er den maksimale” rigtige ” båndbredde, jeg vil se. Lad os tage et let eksempel: en kunde har 100 Mbps link til internettet og skal overføre en 1 TB-fil til sin tjenesteudbyder.

de sædvanlige teoretiske beregninger ville være enkle:

100 Mbps = 12,5 MBps

1 TB = 1000000 MB

1000000 MB / 12,5 MBps = 80000 sekunder = 1333,33 minutter = 22,22 timer eller (d:h:m:S): 22h:13m:20s

men hvis du prøver at sende denne fil til din udbyder, vil det aldrig tage denne tid at gennemføre, medmindre du og din tjenesteudbyder er forbundet til det samme ethernet-link; hvilket betyder, at du slet ikke bruger Internet!

Sådan beregnes overførselshastigheden korrekt

jeg beregnede den forrige værdi ned til de nøjagtige sekunder ved hjælp af dette dejlige værktøj:

http://wintelguy.com/transfertimecalc.pl

hvis du ser på det dog, vil du se den samme “tilnærmelsesfejl”, som jeg tidligere talte om: kun størrelse og båndbredde tages i betragtning. Ingen vindue størrelse, og ingen ventetid. Men hjemmesiden har flere fantastiske værktøjer, og den ene er præcis, hvad vi har brug for:

http://wintelguy.com/wanperf.pl

i denne kan du se, at alle vigtige parametre er angivet og brugt til beregningerne. Lad os gentage den samme beregning, som vi gjorde før, men nu med nogle nye oplysninger:

vi tilføjede 40ms latenstid og accepterede de to andre standardværdier (pakketab og MTU). Vi har ingen chance for at ændre MTU over et Internetlink, da der er mange apparater mellem os og vores tjenesteudbydere, der ikke er under vores kontrol. Dette er en af grundene til, at mange Telco tilbyder deres kunder MPLS private links i stedet for VPN-links over offentligt internet, fordi forbindelsesindstillingerne kan styres og indstilles af udbyderen (godt, der er også en smule lock-in, men dette er en anden historie…). Her ser du, at TCP-overhead og latenstid allerede påvirker den reelle maksimale gennemstrømning, der falder ned til 94.9 MBps. Jeg vil dog sige, at dette er en rigtig god situation, og det kan være værre: lad os holde alle andre parametre som før og øge latensen til 150ms:

gennemstrømningen reduceres til 77,8 Mbps, et tab på 22% af den teoretiske hastighed. Og det kan være endnu værre: en ADSL-forbindelse har for eksempel mere pakketab, så hvis vi holder 150 ms latenstid, men vi øger pakketab med 10 gange, opnår vi dette (ignorere det faktum, at ingen ADSL kan gå til 100 Mbps, det er gjort for at holde den samme hastighed på tværs af alle eksemplerne):

pakketab er øget fra 0.0001 (1 tabt Pakke for hver 10000 transmitteret) til 0.001 (1 tabt Pakke for hver 1000 transmitteret), og denne værdi alene har reduceret vores maksimale hastighed med 75%!!!

så næste gang du ser din nye skinnende internetlinje ikke fungerer som forventet, før du bebrejder din tjenesteudbyder eller det program, du bruger til at overføre disse data, skal du se bedre på dit netværk. Du kan opleve, at disse 25Mbps er den hurtigste hastighed, du kan få.

Write a Comment

Din e-mailadresse vil ikke blive publiceret.