Mas mabagal ang upload ng VPN kaysa download? Alamin kung aling limitasyon ang tinatamaan mo

Karamihan ng access line ay asymmetrical, kaya ang isang tunnel ay karaniwang mas mabagal mag-upload kaysa mag-download, at iyon ang inaasahang sagot, hindi depekto. Ang kawili-wiling tanong ay kung ang iyong upload ay nililimitahan ng linya, ng ibang bagay na gumagamit na nito, o ng daloy na natigil sa halip na tumakbo nang pantay. Ang tatlong ito ay gumagawa ng parehong reklamo at nangangailangan ng ibang trabaho.

Tatlong limitasyong mukhang pareho mula sa progress bar

Ang kapasidad ang una, at ito ay katangian ng access product, hindi ng tunnel. Ang uplink na ilang megabit ay normal sa consumer fiber at sa maraming mobile plan, at ang gastos ng encryption ay maliit kumpara sa agwat na iyon. Ang encapsulation ay nagdadagdag din ng bytes bawat packet, na pumapayat sa kapaki-pakinabang na throughput sa parehong direksyon at hindi lang sa isa, kaya hindi nito mag-isa na maipaliwanag ang malaking asymmetry.

Ang kompetisyon ang pangalawa. Ang cloud sync, mga photo library at update agent ay nag-upload habang mukhang idle ang makina, at ang pangalawang device sa parehong linya ay ganoon din. Ang pila ang pangatlo: ang puspos na uplink ay nagtutulak sa interactive na traffic sa likod ng bulk data, kaya napuputol ang mga tawag habang ang transfer mismo ay nag-uulat ng malusog na pag-unlad.

Subukan ang isang direksyon sa isang pagkakataon

Gamitin ang parehong device, parehong profile at parehong destinasyon, at huwag kailanman patakbuhin ang parehong direksyon nang sabay, maliban kung ang kompetisyon ang talagang nais mong obserbahan. I-pause ang sarili mong opsyonal na transfer bago ang unang pagtakbo. Dalawang pagtakbo na may isang flag sa pagitan ang magtatakda ng halos lahat.

iperf3 ay nagpapadala mula sa client bilang default, kaya ang simpleng pagtakbo ay sumusukat sa iyong upload path; -R ay binabaliktad ang direksyon at sumusukat sa download. Patakbuhin ang mga ito nang ilang minuto ang layo at itala ang parehong numero sa halip na kunin ang average:

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

Kung ang upload figure ay maliit na bahagi ng download figure at nananatiling stable sa pagitan ng mga pagtakbo, ang hugis ay tumutugma sa isang asymmetrical na access line at ang tunnel ay hindi ang kuwento. Kung ang upload ay umiindayog sa pagitan ng mga pagtakbo o bumabagsak pagkatapos ng sampung segundo, magpatuloy sa pagbabasa.

Magpasya batay sa kung saan nagbabago ang upload

Baguhin ang isang variable sa isang pagkakataon at tingnan kung aling direksyon ang gumagalaw. Ang pangalawang VPN endpoint na mas mahusay mag-upload ay tumuturo sa endpoint na iyon o sa ruta patungo doon. Ang parehong mabagal na upload mula sa pangalawang device sa parehong linya ay tumuturo sa linya. Ang ibang device sa ibang linya na mabagal din ay tumuturo sa ingress policy ng destinasyon, na hindi mo maaayos nang lokal.

Itala ang bytes per second at lumipas na oras para sa parehong workload, hindi isang speed score. Ang backup client at speed test ay gumagamit ng iba't ibang destinasyon at iba't ibang concurrency, kaya ang paghahambing ng kanilang mga numero ay walang sinasagot. Kung maayos ang maliliit na request at ang malalaking transfer lang ang gumagapang, malamang hindi bandwidth ang limitasyon.

Para sa araw-araw na gamit, ang paglilimita sa background upload o pag-iskedyul nito sa labas ng oras ng pulong ay kadalasang tumutulong nang higit kaysa sa anumang setting ng tunnel. Hatulan ang pagbabagong iyon sa pinagsamang workload: ang backup na natatapos nang mas huli ngunit hindi na sinisira ang mga tawag ay karaniwang ang mas mabuting kalakal.

Kapag natalo ng paghinto ang bagal

Ang transfer na nagyeyelo sa paulit-ulit na punto at pagkatapos ay nagpapatuloy ay kumikilos na parang problema sa MTU ng ruta, hindi bilang limitasyon sa bilis. Binabawasan ng tunnel ang kapaki-pakinabang na payload bawat packet, at ang device na nagtatapon ng resultang ICMP message ay nag-iiwan sa nagpadala na manghula. Ang pattern na iyon ay karapat-dapat sa sarili nitong pagsubok, dahil ang pag-aayos ay iba sa pag-tune ng bilis. Ang stable na mababang numero ay tumuturo sa kapasidad, habang ang pagsabog na sinusundan ng katahimikan ay tumuturo sa payload na hindi kayang dalhin ng ruta.

Subukan ang ruta gamit ang payload na hindi dapat i-fragment, pagkatapos ay ihambing ang MTU ng tunnel interface sa halagang dumadaan:

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

Kung ang malaking probe ay nawala habang ang mas maliit ay nagtagumpay, higpitan ang TCP MSS sa tunnel sa halip na babaan ang MTU ng interface para sa bawat protocol. Ang matagal na paghinto pagkatapos ng puntong iyon ay pag-aari ng storage o pacing ng tumatanggap na application, hindi ng network path.

Ano ang babaguhin at ano ang iiwan

Baguhin ang mga bagay na kontrolado mo: ang mga iskedyul ng background transfer, ang pagpili ng endpoint at ang MSS para sa rutang natigil. Panatilihing maibabalik ang bawat pagbabago at limitado sa isang workload. Iwanan ang mga bagay na sinasabi ng pagsukat na maayos, kabilang ang bilis ng download na tumutugma na sa linya.

Isulat ang mga numero bago at pagkatapos kasama ang profile, endpoint at oras ng araw, dahil ang problema sa upload na gumagalaw kasama ang endpoint ay tanong sa routing, at ang gumagalaw kasama ang device ay lokal. Ang talaan na iyon ang nagbabago ng malabong reklamo tungo sa desisyon, at nagkakahalaga ito ng dalawang pagtakbo ng parehong command.