શું VPN સીધા કનેક્શન કરતાં ઝડપી હોઈ શકે?

ઓફિસ કનેક્શન પર ધીમે ધીમે ચાલતું ટ્રાન્સફર ક્યારેક ટનલમાંથી ઝડપથી પૂરું થાય છે, અને વધારાનું એન્કેપ્સ્યુલેશન એને અશક્ય લાગવા દે છે. આ દેખીતો વિરોધાભાસ ખોટી વસ્તુઓની સરખામણીથી આવે છે. ટનલ કામ ઉમેરે છે, અને એ પણ બદલે છે ટ્રાફિક કયા નેટવર્ક માર્ગે જાય છે, ગંતવ્ય કયું સરનામું જુએ છે અને ક્યારેક કયો સર્વર જવાબ આપે છે. બે માર્ગો વચ્ચે નિર્ણય લેવા માટે ઝડપ વિશે કોઈ પણ તારણ પહેલાં આ ત્રણ અસરોને અલગ કરવી પડશે.

ટનલ જે ત્રણ વસ્તુઓ બદલી શકે છે

પહેલી છે ટ્રાન્ઝિટ. ઇન્ટરનેટ રૂટિંગ માપેલા વિલંબને નહીં, ઓપરેટરની નીતિ અને વ્યાવસાયિક સંબંધોને અનુસરે છે, તેથી VPN પ્રદાતા દ્વારા માર્ગ સીધા માર્ગ કરતાં જુદા નેટવર્કમાંથી પસાર થઈ શકે છે. એ ભીડવાળું એક્સચેન્જ ટાળી શકે છે અથવા વધુ સારા peeringવાળા પર ઉતરી શકે છે, અને એટલી જ સહેલાઈથી ખરાબ પણ હોઈ શકે છે.

બીજી છે ગંતવ્ય. આઉટગોઇંગ સરનામું બદલાવાથી ઘણી વાર DNS જવાબ બદલાય છે, અને કન્ટેન્ટ નેટવર્ક તમને બીજું કેશ અથવા પ્રદેશ આપી શકે છે. પછી સુધારાનો એક ભાગ ટનલનો નહીં, નવા સર્વરનો હોય છે. એ જ હોસ્ટનામ ક્લાઇન્ટ પર કંઈ બદલ્યા વિના નજીકના કે ઓછા ભારણવાળા સર્વર પર ઉતરી શકે છે.

ત્રીજી છે પરિવહનની વર્તણૂક. એન્કેપ્સ્યુલેશન અસરકારક પેકેટ કદ બદલે છે, અને નુકસાનવાળા મધ્ય ભાગને ટાળતી ટનલ TCP પ્રવાહને વારંવાર પાછળ હટવાને બદલે તેની વિન્ડો વધારવા દે છે. આમાંથી કોઈ પણ સાર્વત્રિક ઝડપવર્ધક પદ્ધતિ નથી; દરેક એવી શરત છે જેનું નિરીક્ષણ કરવું પડે. એમને અલગ કરવું એ જ જિજ્ઞાસાને હકીકતમાં બદલે છે.

જે એ બદલી શકતું નથી

ટનલમાં કંઈ પણ ઉપકરણ અને નેટવર્ક વચ્ચેની કડીમાં ક્ષમતા ઉમેરતું નથી. ભરેલી Wi-Fi ચેનલ, ભીડવાળો છેલ્લો માઇલ કે મર્યાદિત મોબાઇલ પ્લાન બંને માર્ગોને એકસરખી રીતે મર્યાદિત કરે છે, અને ટનલમાંથી લેવાયેલી ઝડપ પરીક્ષા એ મર્યાદા ઓળંગી શકતી નથી. એ જ કડી એન્કેપ્સ્યુલેટ પેકેટ લઈ જાય છે, તેથી એન્કેપ્સ્યુલેશન ક્ષમતા વાપરી શકે છે પણ ક્યારેય બનાવી શકતું નથી. જે બદલાય છે તે એ છે કે પેકેટ એ કડી છોડ્યા પછી ક્યાં જાય છે. તેથી ઝડપી ટનલ પરિણામની સમજૂતી હંમેશા પહેલા હોપની ઉપર હોય છે.

સર્વર બાજુની મર્યાદાઓ પણ એટલી જ ઉદાસીન છે. જો દૂરનો હોસ્ટ ધીમે સેવા આપે, તો સારો માર્ગ ધીમા જવાબને વધુ કાર્યક્ષમ રીતે પહોંચાડે છે, અને વપરાશકર્તા હજી પણ રાહ જુએ છે. ભાર હેઠળનો વહેંચાયેલો સ્રોત એ જ ક્ષણે બંને માર્ગો પર ધીમો દેખાય છે.

માર્ગોની યોગ્ય સરખામણી કરો

એપ્લિકેશન, દિશા, અવધિ અને સમાંતરતા સરખી રાખો, અને ફક્ત માર્ગ બદલો. દરેક પરીક્ષણ દિવસના એ જ સમયે એક કરતાં વધુ વાર ચલાવો, અને થ્રુપુટની બાજુમાં આઉટગોઇંગ સરનામું અને રિઝોલ્વરનો જવાબ નોંધો. એક વાર ચલાવવું માપ નહીં, નમૂનો છે, અને એક ઝડપી ડાઉનલોડ કેશ હિટ હોઈ શકે છે જે માર્ગ વિશે કંઈ કહેતું નથી. પરિણામો પહેલાં શરતો લખો, કારણ કે સંખ્યાઓ પછી સમજવી મુશ્કેલ છે.

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

રિઝોલ્વરનો જવાબ એ વિગત છે જે મોટાભાગની સરખામણીઓ છોડી દે છે, અને એ “સુધારા” સમજાવે છે જે એ જ સર્વર ફરજિયાત કરવાથી અદૃશ્ય થાય છે. જો સરનામું દરેક વખતે અલગ હોય, તો પરીક્ષણે બે માર્ગ નહીં, બે ગંતવ્યની સરખામણી કરી છે. થ્રુપુટની બાજુમાં વિલંબ અને નુકસાન જણાવો, કારણ કે એકંદરે ઝડપી પણ દરેક ઇન્ટરેક્ટિવ વિનંતીમાં વિલંબ ઉમેરતો માર્ગ ફરિયાદ કરનારા વર્કલોડ માટે સારો નથી. પૂછીને રાહ જોતી દરેક વસ્તુ માટે રાઉન્ડ-ટ્રિપ સમય મોટા પાયાની ઝડપ કરતાં વધુ મહત્ત્વનો છે.

ક્યારે તફાવત રાખવા લાયક છે

જો મંજૂર કરેલી ટનલ ચોક્કસ વર્કલોડ વિશ્વસનીય રીતે સુધારે છે, તો એ કાયદેસર કામગીરીની પસંદગી છે: વર્કલોડ, માપ અને વપરાયેલું આઉટગોઇંગ દસ્તાવેજ કરો. ઉપયોગી રેકોર્ડ એક હોસ્ટ, ટનલે આપેલું આઉટગોઇંગ સરનામું, રિઝોલ્વરનો જવાબ અને એ જ દિવસે સીધા માર્ગની એ જ સંખ્યાઓનો ઉલ્લેખ કરે છે. આથી આગળના એન્જિનિયરને સરખામણી પુનરાવર્તિત કરવા પૂરતું છે, ફરી દલીલ કરવાની જરૂર નથી. એ હજી પુરાવો નથી કે પ્રદાતા કંઈક થ્રોટલ કરે છે, અને એ બીજી એપ્લિકેશનો કે બીજા કલાકો સુધી લાગુ પડતું નથી.

માપનો રેકોર્ડ રૂપરેખાંકન સાથે રાખો. એ આગળના પ્રશ્નનો જવાબ આપે છે કે સુધારો હજી છે કે નહીં, અને માર્ગ બદલાયો કે વર્કલોડ એ જાણવાનો એ એકમાત્ર રસ્તો છે. તારીખ વિનાનો રેકોર્ડ એ પ્રશ્નનો બિલકુલ જવાબ આપી શકતો નથી.