Lastar VPN opp tregare enn det lastar ned? Avgjer kva grense du treff

Dei fleste aksesslinjer er asymmetriske, så ein tunnel lastar vanlegvis opp tregare enn han lastar ned, og det er det forventa svaret, ikkje ein feil. Det interessante spørsmålet er om opplastinga blir avgrensa av linja, av noko anna som allereie brukar henne, eller av ein flyt som stoppar i staden for å gå jamt. Desse tre gir same klage og krev ulikt arbeid.

Tre grenser som ser like ut frå framdriftslinja

Kapasitet er den første, og han er ein eigenskap ved aksessproduktet, ikkje ved tunnelen. Ein oppstraumsforbindelse på nokre få megabit er normal på forbrukarfiber og på mange mobilabonnement, og kostnaden ved kryptering er liten samanlikna med det gapet. Innpakking legg også til byte per pakke, noko som reduserer den nyttige gjennomstrøyminga i begge retningar og ikkje berre éi, så han kan ikkje åleine forklare ein stor asymmetri.

Konkurranse er den andre. Skysynkronisering, fotobibliotek og oppdateringsagentar lastar opp medan maskina ser ledig ut, og eit anna apparat på same linje gjer det same. Kø er den tredje: ein metta oppstraumsforbindelse skyv interaktiv trafikk bak bulkdata, så samtalar bryt saman medan sjølve overføringa rapporterer sunn framgang.

Mål éin retning om gongen

Bruk same eining, same profil og same destinasjon, og køyr aldri begge retningar samtidig med mindre konkurranse er nettopp det du vil observere. Set dine eigne valfrie overføringar på pause før første køyring. To køyringar med eitt flagg mellom avgjer det meste.

iperf3 sender frå klienten som standard, så den vanlege køyringa målar oppstraumsvegen din; -R snur retninga og målar nedlasting. Køyr dei med nokre minutt mellom og noter begge tala i staden for å ta gjennomsnitt:

iperf3 -c speed.example.net -t 30 -P 4
iperf3 -c speed.example.net -t 30 -P 4 -R

Viss opplastingstalet er ein liten brøkdel av nedlastingstalet og held seg stabilt mellom køyringar, passar forma med ei asymmetrisk aksesslinje og tunnelen er ikkje historia. Viss opplastinga svingar mellom køyringar eller kollapsar etter ti sekund, les vidare.

Avgjer etter kvar opplastinga endrar seg

Endre éin variabel om gongen og sjå kva retning som flyttar seg. Eit anna VPN-endepunkt som lastar opp betre peikar på det endepunktet eller ruta dit. Den same trege opplastinga frå eit anna apparat på same linje peikar på linja. Eit anna apparat på ei anna linje som også er treg peikar på inngangspolitikken til destinasjonen, som du ikkje kan rette lokalt.

Noter byte per sekund og medgåen tid for same arbeidsbelastning, ikkje éin einaste hastigheitsscore. Ein sikkerheitskopiklient og ein hastigheitstest brukar ulike destinasjonar og ulik samtidighet, så samanlikning av tala deira svarar ikkje på noko. Viss små førespurnader er fine og berre store overføringar kryp, er grensa truleg ikkje bandbreidd i det heile.

Til dagleg bruk hjelper det ofte meir enn noka tunnelinnstilling å avgrense ei bakgrunnsopplasting eller planleggje henne utanfor møtetimane. Vurder den endringa etter den samla arbeidsbelastninga: ein sikkerheitskopi som blir ferdig seinare men ikkje lenger øydelegg samtalar er vanlegvis den betre handelen.

Når stopping slår tregleik

Ei overføring som frys på eit repeterbart punkt og deretter held fram, oppfører seg som eit MTU-problem på ruta og ikkje som ei hastigheitsgrense. Tunnelen reduserer den brukbare nyttelasta per pakke, og eit apparat som slepp den resulterande ICMP-meldinga, lèt sendaren gjetta. Det mønsteret fortener sin eigen test, fordi reparasjonen er ulik frå å justere ei hastigheit. Eit stabilt lågt tal peikar på kapasitet, medan eit utbrot etterfølgt av stille peikar på ei nyttelast som ruta ikkje kan bera.

Test ruta med ei nyttelast som ikkje må fragmenterast, og samanlikn deretter MTU-en til tunnegrensesnittet med verdien som passerer:

ping -M do -s 1400 -c 3 203.0.113.10
ip link show dev tun0 | grep -o "mtu [0-9]*"

Viss den store sonden forsvinn medan ein mindre lukkast, klem TCP MSS på tunnelen i staden for å senke grensesnitt-MTU-en for kvar protokoll. Vedvarande stopp etter det punktet høyrer til lagringa eller takta til det mottakande programmet, ikkje nettverksruta.

Kva du bør endre, og kva du bør la vere

Endre tinga du kontrollerer: tidsplanar for bakgrunnsoverføringar, val av endepunkt og MSS for ei rute som stoppar. Hald kvar endring reversibel og avgrensa til éi arbeidsbelastning. Lèt tinga som målinga seier er fine vere, mellom anna ein nedlastingshastigheit som allereie passar til linja.

Skriv ned tala før og etter saman med profil, endepunkt og tid på dagen, fordi eit opplastingsproblem som flyttar seg med endepunktet er eit rutingsspørsmål, og eitt som flyttar seg med eininga er lokalt. Den registreringa er det som gjer ei vag klage til ei avgjerd, og ho kostar to køyringar av same kommando.