Lassabb a VPN-feltöltés, mint a letöltés? Döntse el, melyik korlátba ütközik

A legtöbb hozzáférési vonal aszimmetrikus, ezért az alagút általában lassabban tölt fel, mint amennyit lefelé tölt, és ez a várt válasz, nem hiba. Az érdekes kérdés az, hogy a feltöltést a vonal korlátozza-e, valami más, ami már használja, vagy egy folyam, amely megakad ahelyett, hogy egyenletesen haladna. Ez a három ugyanazt a panaszt okozza, és más munkát igényel.

Három korlát, amely a folyamatjelzőről nézve egyformának tűnik

A kapacitás az első, és ez a hozzáférési termék tulajdonsága, nem az alagúté. Néhány megabites feltöltési sáv normális a háztartási száloptikán és sok mobilcsomagban, és a titkosítás költsége kicsi ehhez a különbséghez képest. A becsomagolás is bájtokat ad minden csomaghoz, ami mindkét irányban csökkenti a hasznos átvitelt, nem csak az egyikben, ezért önmagában nem magyarázhat nagy aszimmetriát.

A versengés a második. A felhőszinkronizálás, a fotótárak és a frissítési ügynökök feltöltenek, miközben a gép tétlennek látszik, és egy második eszköz ugyanazon a vonalon ugyanezt teszi. A sorban állás a harmadik: a telített feltöltési sáv az interaktív forgalmat a tömeges adatok mögé szorítja, ezért a hívások megszakadnak, miközben maga az átvitel egészséges előrehaladást jelent.

Egyszerre egy irányt mérjen

Ugyanazt az eszközt, ugyanazt a profilt és ugyanazt a célt használja, és soha ne futtassa mindkét irányt egyszerre, kivéve, ha éppen a versengést akarja megfigyelni. Az első futás előtt szüneteltesse a saját opcionális átviteleit. Két futás egy kapcsolóval közöttük a legtöbbet eldönti.

iperf3 alapértelmezés szerint az ügyféltől küld, tehát az egyszerű futás a feltöltési útvonalat méri; -R megfordítja az irányt, és a letöltést méri. Néhány perc különbséggel futtassa őket, és mindkét számot jegyezze fel ahelyett, hogy átlagolna:

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

Ha a feltöltési szám a letöltési szám kis töredéke, és futásról futásra stabil marad, a forma aszimmetrikus hozzáférési vonalra utal, és az alagút nem játszik szerepet. Ha a feltöltés futások között ingadozik, vagy tíz másodperc után összeomlik, olvasson tovább.

A feltöltés változási helye alapján döntsön

Egyszerre egy változót módosítson, és figyelje, melyik irány mozdul. Egy második VPN-végpont, amely jobban tölt fel, arra a végpontra vagy az odavezető útvonalra mutat. Ugyanaz a lassú feltöltés egy második eszközről ugyanazon a vonalon a vonalra mutat. Egy másik eszköz másik vonalon, amely szintén lassú, a cél bemeneti szabályzatára mutat, amelyet helyben nem tud javítani.

Ugyanahhoz a terheléshez bájt/másodpercet és eltelt időt jegyezzen fel, ne egyetlen sebességpontszámot. A biztonsági mentés ügyfele és a sebességteszt különböző célokat és különböző párhuzamosságot használ, ezért a számaik összehasonlítása semmire sem válaszol. Ha a kis kérések rendben vannak, és csak a nagy átvitelek kúsznak, a korlát valószínűleg egyáltalán nem a sávszélesség.

A mindennapi használatban gyakran többet segít bármely alagútbeállításnál, ha a háttérfeltöltést korlátozza, vagy a megbeszélések idején kívülre ütemezi. Ezt a változást az együttes terhelés alapján ítélje meg: az a biztonsági mentés, amely később fejeződik be, de már nem rontja el a hívásokat, általában a jobb üzlet.

Amikor az elakadás legyőzi a lassúságot

Az az átvitel, amely egy ismételhető ponton megfagy, majd folytatódik, útvonal-MTU-problémaként viselkedik, nem sebességkorlátként. Az alagút csökkenti a csomagonkénti hasznos terhet, és az az eszköz, amely eldobja a keletkező ICMP-üzenetet, találgatni hagyja a küldőt. Ez a minta saját tesztet érdemel, mert a javítás különbözik a sebesség hangolásától. Az állandó alacsony szám kapacitásra utal, míg a csenddel követett kitörés olyan teherre, amelyet az útvonal nem tud elhordozni.

Tesztelje az útvonalat olyan teherrel, amelyet nem szabad töredezni, majd hasonlítsa össze az alagút-interfész MTU-ját az átjutó értékkel:

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

Ha a nagy próba eltűnik, miközben egy kisebb sikerül, szorítsa meg a TCP MSS-t az alagúton, ahelyett hogy minden protokollnál csökkentené az interfész MTU-ját. Az e pont utáni tartós elakadások a fogadó alkalmazás tárolásához vagy ütemezéséhez tartoznak, nem a hálózati útvonalhoz.

Mit változtasson, és mit hagyjon békén

Változtassa meg azokat a dolgokat, amelyeket irányít: a háttér-átvitelek ütemezését, a végpont kiválasztását és az elakadó útvonal MSS-ét. Minden változtatás legyen visszafordítható és egyetlen terhelésre korlátozott. Hagyja békén azokat a dolgokat, amelyekről a mérés azt mondja, hogy rendben vannak, beleértve a vonalhoz már illeszkedő letöltési sebességet.

Írja fel az előtte és utána értékeket a profillal, a végponttal és a napszakkal együtt, mert a végponttal együtt mozgó feltöltési probléma útválasztási kérdés, a készülékkel együtt mozgó pedig helyi. Ez a feljegyzés az, ami a homályos panaszt döntéssé alakítja, és két futásba kerül ugyanabból a parancsból.