Bakit natalo ng download sa VPN ang direktang koneksyon mo

Ikonekta ang tunnel, simulan ang malaking download, at tatakbo ito nang halos doble ang bilis kaysa sa nakamit ng parehong file nang wala ito. Parang patalastas ito, ngunit maaaring tunay na pagsukat sa linya ng bahay. Ang karaniwang dahilan ay limitasyon ng bilis na nakakabit sa isang port: dinadala ng tunnel ang iyong transfer sa lugar na hindi tinitingnan ng shaper, at ang tunay na kapasidad ng linya ay lumilitaw sa unang pagkakataon.

Ibig sabihin, ang kawili-wiling numero ay hindi kung gaano kabilis ang VPN. Ito ay kung gaano karami sa linya mo ang hindi mo kailanman nakuha, at bakit.

Limitasyong sumusunod sa port, hindi sa ruta

Maaaring limitahan ng provider ng access ang throughput ng bawat subscriber ayon sa protocol o port ng destinasyon, at ang port 80 ay paboritong target dahil napakaraming ordinaryong pagba-browse ang gumagamit nito. Kadalasan ay hindi ito inilalapat mula sa unang packet: nagsisimula ang transfer malapit sa bilis ng linya, gumagamit ng burst allowance, at pagkatapos ay lumulubog sa limitadong bilang. Mukhang malusog ang unang segundo at hindi ang natitirang transfer.

Ipadala ang parehong bytes sa ibang port at hindi kailanman ito makikita ng shaper sa 80. Parang natalo ng tunnel ang direktang koneksyon kahit nagdagdag ito ng hop, encryption at sariling overhead. Ang bumuti ay hindi ang ruta kundi ang kawalan ng isang tuntunin.

Kaya nga ang epekto ay napakapareho sa mga file at destinasyon. Kung ang limitasyon ay nasa port, lahat ng dinadala sa port na iyon ay pareho ang pag-uugali, gaano man kalaki ang file at sino man ang host. Ang destinasyong nag-aakit ng ibang tuntunin ay nagpapakita ng ibang kurba, at ang pagkakaibang iyon mismo ay diagnostic.

Sukatin ang patag, hindi ang tugatog

Ang tugatog ang pinakakaunting impormasyong bahagi ng isang transfer, dahil mukhang maayos ang bawat koneksyon habang napupuno ang mga buffer nito. Itala kung saan tumitigil ang bilis at gaano katagal ito roon.

curl -o /dev/null -w '%{speed_download} %{time_total}\n' https://<host>/test.bin
scp user@<transfer-host>:/data/test.bin /tmp/

Patakbuhin ang pares nang sunod-sunod sa parehong makina, sa parehong oras, laban sa mga host sa maihahambing na network. Hindi nagpapatunay ng anuman ang isang sample; ang hugis ng kurba sa dalawang pagtakbo ng bawat isa ang naghihiwalay ng burst allowance sa matatag na limitasyon. Isulat kung saan napapantay ang bilis, hindi kung ano ang ipinakita ng unang segundo, dahil ang burst mismo ang ibinibigay ng shaper bago ito magsimulang maglimita. Ang tahimik na patag na tumatagal hanggang dulo ng transfer ang bilang na ihahambing.

Panatilihing naka-compress na ang file para hindi maialok ang transport compression bilang paliwanag. Tinatanggal ng PDF o archive ang variable na iyon, at pinipigilan din nitong may mag-argue na kinompress ng tunnel ang payload. Kung parehong file ang ginagamit ng dalawang transfer, ang natitirang pagkakaiba ay ang ruta at port. Itala ang tool at port sa tabi ng bawat bilang, kung hindi ay hindi maihahambing ang ikalawang pagtakbo sa una.

Tatlong paghahambing na nag-iisa sa dahilan

Gawin ang mga ito nang sunod-sunod at huminto agad kapag malinaw na ang pattern, dahil ang bawat isa ay nagtatanggal ng ibang kuwento.

1. Ulitin ang parehong download sa karaniwang web path at sa tool na pang-transfer sa ibang port, mula sa host na may maihahambing na kapasidad.
2. Ulitin ang dalawa gamit ang file na hindi maaaring i-compress, para tumigil ang compression sa pagiging kandidato.
3. Kung ikaw mismo ang nagpapatakbo ng tunnel server, ikabit itong muli sa port 80, ayusin ang client profile para magkasundo ang dalawang dulo, at maglipat muli. Kung ngayon ay nasa limitadong web speed ang tunnel, ang paghihigpit ay sumusunod sa port at hindi sa VPN.

Ang ikatlong hakbang ang mapagpasyahan, at ito rin ang nilalaktawan ng mga tao dahil nangangailangan ito ng pagbabago sa configuration. Kung wala ito, ipinakita mo na magkaiba ang dalawang bagay, hindi na ang port ang dahilan.

Ano ang hindi kayang suportahan ng pagsukat na ito

Hindi nito ipinapakita na mas mabilis ang tunnel sa pangkalahatan, na nagko-compress ito ng anuman, o na walang limitasyon ang ibang port sa linya. Inilalarawan nito ang transfer na ito, sa linyang ito, sa oras na ito. Maaaring ilapat ang mga limitasyon kada session, kada subscriber o ayon sa oras ng araw, at maaari silang magbago nang walang abiso.

Hindi rin nito pinatutunayan na sira ang direktang ruta. Gumagana pa rin ang limitadong ruta; sadyang nilimitahan ito, at ang sinadyang patakaran ay hindi sira na naghihintay ng pagkukumpuni.

At tiyak na hindi nito binibigyang-katwiran ang pagruruta ng lahat sa tunnel. Bawat application sa port 80 ay nananatiling limitado, habang lahat ng inililihis mo ay umaasa na ngayon sa karagdagang hop at karagdagang paraan ng pagkasira.

Gawing kapaki-pakinabang ang natuklasan

Isulat ang obserbasyon bilang pagsukat at hindi hatol: ang malalaking transfer sa port 80 ay lumulubog malapit sa kalahati ng bilis na nakakamit ng parehong file sa ibang port, sa mga oras na ito, sa linyang ito, kalakip ang mga sample na ito. Iyon ay isang kahilingan sa suporta na maaaring imbestigahan ng iba.

«Mas mabilis ang VPN» ay hindi iyon. Inaanyayahan nito ang sagot tungkol sa overhead ng encryption, at ang sagot na iyon ay teknikal na tama habang walang nakukuhang kapaki-pakinabang ang sinuman. Ilakip ang bilang ng sample, oras at port, para maipakita muli ng mambabasa ang pattern.

Kung magpasya kang ipagpatuloy ang paggamit ng ibang port para sa malalaking transfer, itala ang babala sa sarili mong rekord: ang paglipat ng listener sa port 80 ay bumabangga sa anumang web server na nakatali na doon, at ang resultang pagkasira ay mukhang sirang tunnel at hindi salungatan ng port.