VPN-oplaai stadiger as aflaai? Bepaal watter perk jou tref

Die meeste toegangslyne is asimmetries, so ’n tonnel sal gewoonlik stadiger oplaai as aflaai, en dit is die verwagte antwoord eerder as ’n fout. Die interessante vraag is of jou oplaai beperk word deur die lyn, deur iets anders wat dit reeds gebruik, of deur ’n vloei wat vassteek in plaas van bestendig te loop. Dié drie lewer dieselfde klag en verg verskillende werk.

Drie beperkings wat van die vorderingsbalk af identies lyk

Kapasiteit is die eerste, en dit is ’n eienskap van die toegangsproduk eerder as van die tonnel. ’n Opstroom van ’n paar megabis is normaal op verbruikersvesel en op baie mobiele planne, en enkripsie-oorhoofs is klein teenoor daardie gaping. Enkapsulering voeg ook grepe per pakket by, wat goeie deurset in beide rigtings verminder eerder as net een, so dit kan nie op sy eie ’n groot asimmetrie verduidelik nie.

Mededinging is die tweede. Wolk-sinkronisering, fotobiblioteke en opdateringsagente laai op terwyl die masjien ledig lyk, en ’n tweede toestel op dieselfde lyn doen dieselfde. Toustaan is die derde: ’n versadigde opstroom skuif interaktiewe verkeer agter grootmaatdata, so oproepe breek op terwyl die oordrag self gesonde vordering rapporteer.

Meet een rigting op ’n slag

Gebruik dieselfde toestel, dieselfde profiel en dieselfde bestemming, en laat nooit beide rigtings gelyk loop nie, tensy mededinging juis is wat jy wil waarneem. Pouseer jou eie opsionele oordragte voor die eerste lopie. Twee lopies met een vlag tussenin besleg die meeste daarvan.

iperf3 stuur by verstek vanaf die kliënt, so die gewone lopie meet jou opstroompad; -R keer die rigting om en meet aflaai. Laat hulle minute uitmekaar loop en teken beide syfers aan in plaas daarvan om te gemiddeld:

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

As die opstroomsyfer ’n klein breukdeel van die aflaaisyfer is en oor lopies stabiel bly, pas die vorm by ’n asimmetriese toegangslyn en is die tonnel nie die storie nie. As die opstroom tussen lopies swaai of ná tien sekondes ineenstort, hou aan lees.

Besluit op grond van waar die opstroom verander

Verander een veranderlike op ’n slag en kyk watter rigting beweeg. ’n Tweede VPN-eindpunt wat beter oplaai, wys na daardie eindpunt of die roete daarheen. Dieselfde stadige opstroom vanaf ’n tweede toestel op dieselfde lyn wys na die lyn. ’n Ander toestel op ’n ander lyn wat ook stadig is, wys na die bestemming se inkombeleid, wat jy nie plaaslik kan regmaak nie.

Teken grepe per sekonde en verstreke tyd vir dieselfde werk aan, nie ’n enkele spoedtelling nie. ’n Rugsteunkliënt en ’n spoedtoets gebruik verskillende bestemmings en verskillende gelyktydigheid, so om hul syfers te vergelyk antwoord niks. As klein versoeke reg is en net groot oordragte kruip, is die perk waarskynlik glad nie bandbreedte nie.

Vir alledaagse gebruik help dit dikwels meer as enige tonnelinstelling om ’n agtergrondoplaai te beperk of dit buite vergadertye te skeduleer. Beoordeel daardie verandering aan die gekombineerde werklading: ’n rugsteun wat later klaarmaak maar nie meer oproepe verwoes nie, is gewoonlik die beter ruil.

Wanneer vassteek sloerdheid klop

’n Oordrag wat op ’n herhaalbare punt vries en dan hervat, gedra hom soos ’n pad-MTU-probleem eerder as ’n tempostrek. Die tonnel verminder die bruikbare loonvrag per pakket, en ’n toestel wat die gevolglike ICMP-boodskap laat val, laat die sender raai. Daardie patroon verdien sy eie toets, want die herstel verskil van die instel van ’n tempo. ’n Bestendige lae syfer wys op kapasiteit, terwyl ’n uitbarsting gevolg deur stilte wys op ’n loonvrag wat die pad nie kan dra nie.

Toets die pad met ’n loonvrag wat nie mag fragmenteer nie, en vergelyk dan die tonnelkoppelvlak se MTU met die waarde wat deurkom:

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

As die groot peiling verdwyn terwyl ’n kleiner een slaag, knyp die TCP-MSS op die tonnel in eerder as om die koppelvlak-MTU vir elke protokol te verlaag. Aanhoudende vassteek ná daardie punt hoort by die ontvangende toepassing se berging of tempo, nie by die netwerkpad nie.

Wat om te verander, en wat om alleen te laat

Verander die dinge wat jy beheer: agtergrond-oordragskedules, eindpuntkeuse en MSS vir ’n vassteekpad. Hou elke verandering omkeerbaar en beperk tot een werklading. Laat die dinge alleen wat die meting sê reg is, insluitend ’n aflaaitempo wat reeds by die lyn pas.

Skryf die voor- en nasyfers neer saam met die profiel, eindpunt en tyd van die dag, want ’n oplaai-probleem wat met die eindpunt saambeweeg is ’n roetevraag, en een wat met die toestel saambeweeg is ’n plaaslike een. Daardie rekord is wat ’n vae klag in ’n besluit omskep, en dit kos twee lopies van dieselfde opdrag.