Hvorfor VPN-tapet ser verre ut på mobilnett enn på Ethernet

Den samme bærbare maskinen, den samme serveren og den samme tunnelen kan miste en femtedel av gjennomstrømningen på Ethernet og tre fjerdedeler på mobilnettet, og ingen av de to tallene betyr at VPN-en er ødelagt. Hvert aksessnettverk gir en annen vei, og tunnelen legger en andre vei på toppen. Å sammenligne ett tunnelet tall med ett ikke-tunnelet tall svarer på ingenting, fordi de to tallene beskriver ulike nevnere. Fire celler og én bevaringsbrøk per rad forteller deg hvilket spørsmål du bør stille neste gang.

Fire celler, ikke én straff

Mål den direkte basislinjen og det tunnelete resultatet på hvert aksessnettverk, og hold dem som en matrise i stedet for som én enkelt dom. Basislinjen er den samme oppgaven utført på det nettet uten tunnelen; det tunnelete resultatet er den samme oppgaven med den.

Bruk en autorisert arbeidsbelastning for de direkte testene og behold personvernkontrollene miljøet krever. En test som bryter retningslinjene gir et tall du ikke kan publisere og ikke bør gjenta.

Hold variablene faste

Hold enheten, applikasjonen, målet, overføringsretningen og VPN-endepunktet fast i alle fire cellene. Hvis en tjeneste i det stille bytter testserver mellom kjøringer, registrer endringen og behandle paret som ukontrollert i stedet for å jevne ut forskjellen med et gjennomsnitt.

Gjenta matrisen i begge retninger og på sammenlignbare tider av døgnet. Forholdene for en mobilradio og belastningen på cellen endrer seg i løpet av minutter, så én enkelt uvanlig god basislinje kan overdrive det tilsynelatende tapet. Registrer spredningen av resultater ved siden av en representativ verdi, og noter om de tunnelete kjøringene ble flettet med basislinjene eller kjørt i en blokk.

Fletting betyr mer enn de fleste forventer. En basislinje målt før lunsj og en tunnelet kjøring målt etter er to forskjellige nettverk med samme navn.

Hold nevneren synlig

Rapporter bevaringsbrøken så vel som den absolutte hastigheten: E1 delt på E0, og C1 delt på C0. En rask linje som beholder en liten del av gjennomstrømningen, og en treg linje som beholder det meste, er forskjellige funn, og bare brøken viser forskjellen.

Absolutt gjennomstrømning avgjør fortsatt hva en bruker kan gjøre. Brøken avgjør hvor man skal se. Når Ethernet beholder det meste av basislinjen og mobilnettet mye mindre, er den interessante variabelen på mobilveien og ikke inne i krypteringen.

Begge tallene hører hjemme i rapporten, fordi hvert av dem alene støtter en konklusjon dataene ikke støtter.

Les mønsteret før du endrer noe

Lignende tunnelete tak på begge nettverkene peker på noe felles: endepunktet, prosessoren, en hastighetsgrense eller ett enkelt overbelastet hopp. En nedgang som bare vises på mobilnettet, peker på nettets rute, tap, latenstid og effektiv pakkestørrelse.

Dette er spor, ikke diagnoser, og forskjellen betyr noe når du skriver saken. Et felles tak blir ikke bedre når du bytter mobilmodemet, og en nedgang som bare gjelder mobil blir ikke bedre når du endrer størrelsen på endepunktet. Oppgi hvilket av de to mønstrene du så før du foreslår en endring. Da bærer endringen en prediksjon, og neste måling kan bekrefte eller drepe den.

OpenVPNs egne ytelsesretningslinjer skiller båndbredde-, prosessor-, transport- og pakkestørrelsesbegrensninger langs de samme linjene, noe som er en nyttig påminnelse om at tunnelen sjelden er én variabel.

Når pakkestørrelsen er den mistenkte

Innkapsling bruker pakkeplass, så den effektive størrelsen på en mobilvei kan være mindre enn den grensesnittet annonserer. Behold dokumentasjon om pakkestørrelse for veien du sammenligner i stedet for å anta en verdi ut fra aksessteknologiens navn.

Datagram packetization-layer path MTU discovery beskriver å finne den effektive størrelsen i stedet for å hardkode den. Bruk observasjonene implementasjonen støtter, og ikke dytt en vilkårlig lav MTU på hver klient som en forholdsregel, fordi det bytter ett problem mot et verre på veier som var i orden.

En størrelseshypotese trenger sine egne bevis: den samme overføringen i to størrelser, med tapsmønsteret registrert.

Legg til én variabel om gangen

Sammenlign en alternativ transport først etter at basislinjematrisen er lagret. Det holder én bevisst variabel i spill, og det lar deg tilskrive endringen i stedet for å gjette på den.

Hold TCP-nyttelastdimensjonering atskilt fra UDP-datagramadferd, siden de to reagerer ulikt på tap og på veistørrelse. En forbedring fra en transportendring er bevis om den transporten, ikke bevis for at kryptering eller dekning var den opprinnelige årsaken.

Rekkefølge: fyll de fire cellene, beregn begge brøkene, flett kjøringene, velg deretter én hypotese og test den med én endring. Alt annet er en sammenligning av to ukjente.