Laddar VPN upp långsammare än det laddar ner? Avgör vilken gräns du träffar

De flesta accesslinjer är asymmetriska, så en tunnel laddar oftast upp långsammare än den laddar ner, och det är det förväntade svaret, inte ett fel. Den intressanta frågan är om din uppladdning begränsas av linjen, av något annat som redan använder den, eller av ett flöde som stannar i stället för att gå jämnt. Dessa tre ger samma klagomål och kräver olika arbete.

Tre gränser som ser likadana ut från förloppsindikatorn

Kapacitet är den första, och den är en egenskap hos accessprodukten, inte hos tunneln. En upplänk på några megabit är normal på konsumentfiber och på många mobilabonnemang, och kostnaden för kryptering är liten jämfört med den klyftan. Inkapsling lägger också till byte per paket, vilket minskar den nyttiga genomströmningen i båda riktningarna och inte bara i en, så den kan inte ensam förklara en stor asymmetri.

Konkurrens är den andra. Molnsynkronisering, fotobibliotek och uppdateringsagenter laddar upp medan maskinen ser ledig ut, och en andra enhet på samma linje gör samma sak. Kö är den tredje: en mättad upplänk trycker interaktiv trafik bakom bulkdata, så samtal bryts medan själva överföringen rapporterar sund framgång.

Mät en riktning i taget

Använd samma enhet, samma profil och samma destination, och kör aldrig båda riktningarna samtidigt om inte konkurrens är precis det du vill observera. Pausa dina egna valfria överföringar före den första körningen. Två körningar med en flagga mellan sig avgör det mesta.

iperf3 skickar från klienten som standard, så den vanliga körningen mäter din upplänksväg; -R vänder riktningen och mäter nedladdning. Kör dem med några minuters mellanrum och notera båda talen i stället för att medelvärdesbilda:

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

Om uppladdningstalet är en liten bråkdel av nedladdningstalet och håller sig stabilt mellan körningar passar formen med en asymmetrisk accesslinje och tunneln är inte historien. Om uppladdningen svänger mellan körningar eller kollapsar efter tio sekunder, läs vidare.

Avgör efter var uppladdningen ändras

Ändra en variabel i taget och se vilken riktning som rör sig. En andra VPN-slutpunkt som laddar upp bättre pekar på den slutpunkten eller vägen dit. Samma långsamma uppladdning från en andra enhet på samma linje pekar på linjen. En annan enhet på en annan linje som också är långsam pekar på destinationens ingångspolicy, som du inte kan åtgärda lokalt.

Notera byte per sekund och förfluten tid för samma arbetsbelastning, inte en enda hastighetspoäng. En säkerhetskopieringsklient och ett hastighetstest använder olika destinationer och olika samtidighet, så en jämförelse av deras tal svarar inte på något. Om små förfrågningar är bra och bara stora överföringar kryper är gränsen förmodligen inte bandbredd alls.

För daglig användning hjälper det ofta mer än någon tunnelinställning att begränsa en bakgrundsuppladdning eller schemalägga den utanför mötestimmarna. Bedöm den ändringen efter den sammanlagda arbetsbelastningen: en säkerhetskopiering som blir klar senare men inte längre förstör samtal är vanligtvis den bättre affären.

När stockning slår långsamhet

En överföring som fryser på en repeterbar punkt och sedan fortsätter beter sig som ett MTU-problem på vägen och inte som en hastighetsgräns. Tunneln minskar den användbara nyttolasten per paket, och en enhet som släpper det resulterande ICMP-meddelandet låter avsändaren gissa. Det mönstret förtjänar sitt eget test, eftersom repareringen skiljer sig från att justera en hastighet. Ett stabilt lågt tal pekar på kapacitet, medan ett utbrott följt av tystnad pekar på en nyttolast som vägen inte kan bära.

Testa vägen med en nyttolast som inte får fragmenteras och jämför sedan tunnelns gränssnitts-MTU med värdet som passerar:

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

Om den stora sonden försvinner medan en mindre lyckas, kläm TCP MSS på tunneln i stället för att sänka gränssnittets MTU för varje protokoll. Ihållande stockningar efter den punkten hör till det mottagande programmets lagring eller takt, inte till nätverksvägen.

Vad du bör ändra och vad du bör lämna

Ändra det du kontrollerar: scheman för bakgrundsöverföringar, val av slutpunkt och MSS för en väg som stockar sig. Håll varje ändring återställbar och begränsad till en arbetsbelastning. Låt det vara som mätningen säger är bra, inklusive en nedladdningshastighet som redan matchar linjen.

Skriv ner talen före och efter tillsammans med profil, slutpunkt och tid på dagen, eftersom ett uppladdningsproblem som flyttar sig med slutpunkten är en routingfråga, och ett som flyttar sig med enheten är lokalt. Den anteckningen är det som gör ett vagt klagomål till ett beslut, och den kostar två körningar av samma kommando.