એક જ ટનલ પર બે VPN ઝડપ પરીક્ષણો કેમ અલગ પડે છે
નવું એક્ઝિટ પરીક્ષણ સર્વર બદલે છે, અને ધીમી શરૂઆત પરિણામ બદલે છે. લક્ષ્ય સ્થિર કરો, સ્ટ્રીમની સંખ્યા મેળવો અને પ્રોસેસર ખર્ચને લિંકની ક્ષમતાથી અલગ કરો.
બે રન, એક ટનલ, અને સંખ્યાઓ ત્રણ ગણી અલગ છે. તેમની વચ્ચે ટનલ બદલાઈ નથી. જે બદલાયું તે માપન છે: તમારા દેખાતા સ્થાનના આધારે સર્વર પસંદ કરતી પરીક્ષણ સાઇટ, સ્ટ્રીમની સંખ્યા જે નક્કી કરે છે કે પાઇપ એક ધીમી શરૂઆત ભરે છે કે છ, અને એટલો ટૂંકો સમય કે માર્ગનો યોગ્ય ઉપયોગ શરૂ થાય તે પહેલાં જ પૂરો થઈ જાય. ઝડપ પરીક્ષણો ખોટા નથી, પરંતુ તે લોકો તેમને પૂછે છે તે પ્રશ્ન કરતાં વધુ સાંકડા પ્રશ્નનો જવાબ આપે છે.
નવું એક્ઝિટ સરનામું પરીક્ષણનું લક્ષ્ય બદલે છે
મોટાભાગની પરીક્ષણ સાઇટ્સ આપમેળે માપન સર્વર પસંદ કરે છે, અને તે તમારું કનેક્શન ક્યાંથી આવતું લાગે છે તે જોઈને અંશતઃ પસંદ કરે છે. ટનલ ચાલુ કરો અને તમારો દેખાતો દેશ બદલાય છે, તેથી પસંદ કરેલો સર્વર બદલાય છે, અને સરખામણી હવે બે અલગ હોસ્ટ તરફના બે અલગ માર્ગોને આવરી લે છે.
પરિણામ કોઈ પણ રીતે VPN માપન નથી. તે તમે પસંદ ન કરેલા સર્વર તરફના તમારા માર્ગનું માપન છે, અને બે રન વચ્ચેનો તફાવત તે સર્વરના પિયરિંગ દ્વારા પ્રભાવિત હોઈ શકે છે, ટનલે કરેલા કોઈપણ કાર્ય દ્વારા નહીં.
બીજું કંઈપણ બદલતા પહેલાં લક્ષ્ય સ્થિર કરો. દરેક વિશ્વસનીય સાધન તમને સ્પષ્ટપણે સર્વર પસંદ કરવા દે છે, અને જ્યારે નથી દેતું, ત્યારે પરિણામ પૃષ્ઠ સામાન્ય રીતે વપરાયેલ સર્વરનું નામ આપે છે, જે નોંધવા માટે પૂરતું છે કે બે રન સરખાવી શકાય તેવા નથી. સાઇટે શું જોયું તે ચકાસો તેની પસંદગી પર ભરોસો કરતા પહેલાં:
curl -sS https://ipinfo.io/json | grep -E '"ip"|"org"|"country"'જો રન વચ્ચે દેશ બદલાયો હોય, તો પરીક્ષણે તે પછી પસંદ કરેલું બધું પણ બદલાયું. દરેક પરિણામની બાજુમાં જોયેલું એક્ઝિટ લખો અને મોટાભાગની મૂંઝવણ અદૃશ્ય થઈ જાય છે.
ધીમી શરૂઆત મોટાભાગના ટૂંકા પરીક્ષણો પૂરા થયા પછી પૂરી થાય છે
TCP કનેક્શન લિંકની ઝડપે શરૂ થતું નથી. તે નાની કન્જેશન વિન્ડોથી શરૂ થાય છે, લગભગ દરેક રાઉન્ડ ટ્રિપ પર તેને બમણી કરે છે, અને ઘણા રાઉન્ડ ટ્રિપ પછી જ માર્ગની ક્ષમતા સુધી પહોંચે છે. વધુ લેટન્સીવાળા માર્ગ પર દસ સેકન્ડનું પરીક્ષણ તેના જીવનનો નોંધપાત્ર ભાગ તે ચઢાણમાં પસાર કરી શકે છે.
તેથી જ વધુ લેટન્સીવાળી ટનલ ટૂંકા પરીક્ષણમાં લાયક કરતાં ખરાબ પરિણામ આપે છે, અને તેથી જ લાંબી રન ઘણી વાર કોઈ પણ ગોઠવણી બદલ્યા વિના વધુ સંખ્યા બતાવે છે. RFC 6349 થ્રુપુટ ઢાંચો આને સ્પષ્ટપણે સંબોધે છે, અને તેથી જ ગંભીર માપન સ્થિર સ્થિતિ સુધી પહોંચવા પૂરતું લાંબું ચાલે છે. સેટેલાઇટ માર્ગ પર પાંચ સેકન્ડની રન માર્ગને નહીં, પ્રવેગકને માપે છે.
એક જ સંખ્યા પર ભરોસો કરવાને બદલે કનેક્શનના તબક્કાઓ જુઓ. Curl દરેક તબક્કો અલગથી જણાવે છે, તેથી તમે જોઈ શકો છો કે સમય હેન્ડશેકમાં જાય છે, ચઢાણમાં કે ટ્રાન્સફરમાં:
curl -sS -o /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total} bytes/s=%{speed_download}\n' \
https://mirror.example.net/testfile.binતેને એ જ લક્ષ્ય પર સળંગ બે વાર ચલાવો. જો બીજી રન ઘણી ઝડપી હોય, તો તમે ચઢાણ માપી રહ્યા હતા, માર્ગ નહીં, અને ફક્ત પહેલી રન વાપરેલી કોઈપણ સરખામણી શંકાસ્પદ છે.
એક સ્ટ્રીમ અને છ સ્ટ્રીમ અલગ વસ્તુઓ માપે છે
એક TCP સ્ટ્રીમ તે વિન્ડો દ્વારા મર્યાદિત છે જે તે ઉડાનમાં રાખી શકે છે, જે લગભગ રાઉન્ડ ટ્રિપ સમયને દરથી ગુણ્યા જેટલી છે. લાંબા માર્ગ પર તે ગુણનફળ એક સ્ટ્રીમ વાપરશે તેનાથી વધુ હોય છે, તેથી એક ડાઉનલોડ હાલની ક્ષમતાને ઓછી દર્શાવે છે. છ સમાંતર સ્ટ્રીમ ખાલી જગ્યા ભરે છે અને મોટી સંખ્યા આપે છે.
iperf3 -c speed.example.net -t 20
iperf3 -c speed.example.net -t 20 -P 6
mtr -rwc 50 speed.example.netબંને સંખ્યાઓ સાચી છે. એક સ્ટ્રીમની સંખ્યા કહે છે કે એક ડાઉનલોડ શું કરશે, જે સામાન્ય રીતે બ્રાઉઝર ટૅબને મળે છે. સમાંતર સંખ્યા કહે છે કે માર્ગ એકંદરે શું વહન કરી શકે છે, જે ટોરેન્ટ કે બહુ-ભાગ ડાઉનલોડ વાપરી શકે છે. એકને બીજી હોય તેમ ટાંકવું એ જ રીત છે જેમાં સ્વસ્થ ટનલ વિના કારણે બદલાઈ જાય છે.
સમાંતર પરિણામને એક સ્ટ્રીમના પરિણામ સાથે સરખાવવું એ લોકો એ નિષ્કર્ષ પર આવવાની સૌથી સામાન્ય રીત છે કે VPN એ તેમની ઝડપ અડધી કરી નાખી. પદ્ધતિ મેળવો, પછી સરખાવો. ત્રીજા આદેશનો ટ્રેસ ખૂટતો સંદર્ભ ઉમેરે છે: વધુ જિટરવાળો માર્ગ બંને મોડમાં અસંગત પરિણામો આપશે, અને કોઈ સ્ટ્રીમ સંખ્યા તેને સુધારતી નથી.
એન્ક્રિપ્શન પ્રોસેસરનો સમય લે છે, એન્કેપ્સ્યુલેશન બાઇટ લે છે
લિંક કેટલી ઝડપી છે તે ધ્યાનમાં લીધા વિના દરેક પેકેટ પર બે પદ્ધતિઓ ચાલે છે. એન્ક્રિપ્શન પ્રતિ બાઇટ પ્રોસેસર વાપરે છે, અને એન્કેપ્સ્યુલેશન હેડર બાઇટ ઉમેરે છે જે લિંકને હજી વહન કરવા પડે છે. બંને ટોચમર્યાદા તરીકે દેખાય છે, અને તેમની નિશાનીઓ અલગ છે.
પ્રોસેસરની ટોચમર્યાદા ઉચ્ચપ્રદેશ તરીકે દેખાય છે: તમે કેટલી પણ સ્ટ્રીમ ઉમેરો, થ્રુપુટ વધવાનું બંધ કરે છે, અને મશીનનો પ્રોસેસર વ્યસ્ત હોય છે જ્યારે લિંક નથી હોતી. નાના રાઉટર કે ફોન પર તે ઘણી વાર સાચી મર્યાદા હોય છે, અને તેથી જ ઝડપી લાઇન પણ સાધારણ ટનલ આપી શકે છે.
બાઇટ ખર્ચ નાનો પણ સ્થિર છે. વધારાના હેડર એટલે પ્રતિ પેકેટ ઓછો પેલોડ, અને નિશ્ચિત મહત્તમ ટ્રાન્સમિશન યુનિટવાળા માર્ગ પર તે ફ્રેગ્મેન્ટેશન કે બ્લેકહોલ પણ સર્જી શકે છે જે મોટા ટ્રાન્સફરમાં ધીમી સરેરાશ તરીકે નહીં, પણ અટકી જવા તરીકે દેખાય છે.
| Observation | Likely mechanism | What to measure |
|---|---|---|
| Throughput flat as streams increase | CPU per packet on one core | Per-core utilisation during the test |
| Fast small transfers, stalled large ones | MTU and fragmentation | Payload size at which it breaks |
| Good average, unusable calls | Queueing delay behind a full buffer | Latency under load |
આ ત્રણ ઘણી વાર ભેળવી દેવાય છે કારણ કે વપરાશકર્તાઓ તેમને બધાને «VPN ધીમું છે» કહે છે. ફક્ત પહેલું મોટા મશીનને પ્રતિસાદ આપે છે, ફક્ત બીજું નાના MTU ને પ્રતિસાદ આપે છે, અને ફક્ત ત્રીજું કતાર સંચાલનને પ્રતિસાદ આપે છે.
પદ્ધતિ રેકોર્ડમાં લખો
રાખવા લાયક પરિણામ ઉપકરણ, એક્સેસ નેટવર્ક, એક્ઝિટ, માપન સર્વર, દિશા, સ્ટ્રીમ સંખ્યા અને સમયગાળાનું નામ આપે છે. તેના વિના બે સંખ્યાઓ સરખાવી શકાતી નથી, અને એક સંખ્યા ધરાવતી ટિકિટ વાસ્તવમાં એક મૂડ છે.
ખરાબ રન પણ રાખો. જે શ્રેણીમાં એક એક્ઝિટ દર વખતે અટકી જવાનું સર્જે છે તે સરેરાશ કરતાં ઘણી વધુ માહિતીપ્રદ છે, અને અટકી જવા એ જ છે જે સરેરાશ છુપાવે છે.
પછી તમને ખરેખર જેની પરવા છે તેનું પરીક્ષણ કરો. જો ધ્યેય મોટું ડાઉનલોડ હોય, તો ફાઇલ ડાઉનલોડ કરો. જો ધ્યેય કૉલ હોય, તો નિષ્ક્રિય થ્રુપુટને બદલે ભાર હેઠળ લેટન્સી માપો, કારણ કે ટનલ ઝડપ પરીક્ષણમાં સારો સ્કોર કરી શકે છે અને તેમ છતાં દરેક મીટિંગને સાંભળી ન શકાય તેવી બનાવી શકે છે.