Maaari bang Maging Mas Mabilis ang VPN kaysa Direktang Koneksyon?

Ang isang paglilipat na gumagapang sa koneksyon ng opisina ay kung minsan mabilis na natatapos sa pamamagitan ng tunnel, at ginagawang imposible itong tila dahil sa karagdagang encapsulation. Ang halatang kabalintunaan ay nagmumula sa paghahambing ng maling bagay. Nagdaragdag ng trabaho ang tunnel, at binabago rin nito kung aling landas ng network ang tinatahak ng trapiko, kung aling address ang nakikita ng destinasyon at kung minsan kung aling server ang sumasagot. Ang desisyon sa pagitan ng dalawang ruta ay nangangailangan ng paghihiwalay ng tatlong epektong ito bago ang anumang konklusyon tungkol sa bilis.

Tatlong Bagay na Maaaring Baguhin ng Tunnel

Ang una ay ang transit. Ang routing sa internet ay sumusunod sa patakaran ng operator at mga relasyong pangkalakal, hindi sa sinukat na latency, kaya ang landas sa pamamagitan ng provider ng VPN ay maaaring tumawid sa ibang network kaysa sa direktang ruta. Maaari nitong iwasan ang isang masikip na exchange point o mapunta sa isang may mas magandang peering, at kasing-dali nitong maging mas masama.

Ang pangalawa ay ang destinasyon. Ang pagbabago ng outgoing address ay madalas na nagbabago ng sagot ng DNS, at ang isang content network ay maaaring magbigay sa iyo ng ibang cache o rehiyon. Bahagi ng pagbuti ay pag-aari ng bagong server at hindi ng tunnel. Ang parehong hostname ay maaaring mapunta sa mas malapit o hindi gaanong kargadong server nang walang nagbabago sa kliyente.

Ang pangatlo ay ang pag-uugali ng transport. Binabago ng encapsulation ang epektibong laki ng packet, at ang isang tunnel na umiiwas sa isang middle segment na may pagkalugi ay maaaring hayaang palakihin ng isang daloy ng TCP ang window nito sa halip na paulit-ulit na umurong. Wala sa mga ito ang pangkalahatang mekanismo ng pagpapabilis; bawat isa ay kondisyon na dapat obserbahan. Ang paghihiwalay sa kanila ang nagiging katotohanan ang pagkamangha.

Ano ang Hindi Nito Mababago

Wala sa tunnel ang nagdaragdag ng kapasidad sa link sa pagitan ng device at ng network. Ang saturated na Wi-Fi channel, masikip na huling milya o limitadong mobile plan ay parehong naglilimita sa dalawang landas nang pareho, at ang speed test sa tunnel ay hindi maaaring lumampas sa kisame na iyon. Ang parehong link ay nagdadala ng encapsulated packets, kaya ang encapsulation ay maaaring gumastos ng kapasidad ngunit hindi kailanman lumikha nito. Ang nagbabago ay kung saan pupunta ang mga packet pagkatapos umalis sa link na iyon. Kaya naman ang mabilis na resulta ng tunnel ay laging may paliwanag sa itaas ng unang hop.

Ang mga limitasyon sa panig ng server ay kasing walang pakialam. Kung ang malayong host ay mabagal magserbisyo, ang mas magandang landas ay naghahatid lamang ng mabagal na sagot nang mas mahusay, at naghihintay pa rin ang gumagamit. Ang isang nakabahaging pinagmulan sa ilalim ng karga ay mukhang mabagal sa dalawang landas sa parehong sandali.

Ihambing ang mga Landas nang Tama

Panatilihing pareho ang application, direksyon, tagal at sabay-sabay, at baguhin lamang ang landas. Patakbuhin ang bawat pagsubok nang higit sa isang beses, sa parehong oras ng araw, at itala ang outgoing address at ang sagot ng resolver sa tabi ng throughput. Ang isang pagtakbo ay isang sample at hindi isang pagsukat, at ang isang mabilis na download ay maaaring isang cache hit na walang sinasabi tungkol sa ruta. Isulat ang mga kondisyon bago ang mga resulta, dahil mahirap bigyang-kahulugan ang mga numero pagkatapos.

mtr -rwc 50 -T -P 443 203.0.113.20
curl -o /dev/null -s -w '%{speed_download} %{time_connect}\n' https://example.com/file
dig +short cdn.example.com
traceroute -n -T -p 443 cdn.example.com

Ang sagot ng resolver ang detalyeng iniiwan ng karamihang paghahambing, at ipinaliliwanag nito ang “mga pagbuti” na nawawala kapag pinilit ang parehong server. Kung magkaiba ang address sa bawat pagtakbo, ang pagsubok ay naghambing ng dalawang destinasyon at hindi dalawang landas. Iulat ang latency at pagkalugi sa tabi ng throughput, dahil ang isang landas na mas mabilis sa kabuuan ngunit nagdaragdag ng pagkaantala sa bawat interactive na kahilingan ay hindi mas mahusay para sa workload na nagreklamo. Ang oras ng pagpunta at pagbalik ay mas mahalaga kaysa sa maramihang bilis para sa anumang bagay na nagtatanong at naghihintay.

Kailan Sulit Panatilihin ang Pagkakaiba

Kung ang isang aprubadong tunnel ay mapagkakatiwalaang nagpapabuti ng isang partikular na workload, iyon ay isang lehitimong pagpipilian sa operasyon: idokumento ang workload, ang pagsukat at ang exit na ginamit. Ang isang kapaki-pakinabang na tala ay nagpangalan ng isang host, ang exit address na ginawa ng tunnel, ang sagot ng resolver, at ang parehong mga bilang mula sa direktang landas sa parehong araw. Sapat ito para sa susunod na inhinyero upang ulitin ang paghahambing sa halip na pagtalunan itong muli. Hindi pa rin ito patunay na may nililimitahan ang provider, at hindi ito naipapasa sa ibang application o ibang oras.

Itago ang tala ng pagsukat kasama ng configuration. Sinasagot nito ang susunod na tanong kung umiiral pa ang pagbuti, at iyon lamang ang paraan upang malaman kung nagbago ang landas o ang workload. Ang talang walang petsa ay hindi masasagot iyon nang lubusan.