VPN દ્વારા ડાઉનલોડ સીધા કરતાં ઝડપી કેમ છે

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

વક્રનો આકાર જ તેને જાહેર કરે છે

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

એ જ ફાઇલની બે રન, એક સીધી અને એક ટનલ દ્વારા, પ્લેટો છે કે નહીં તે જોવા માટે પૂરતી છે.

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

ત્રણ સરખામણી, દરેકમાં એક ચલ

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

curl -o /dev/null -w '%{speed_download}' https://files.example/big.iso
scp [email protected]:/exports/big.iso /dev/null

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

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

આ માપણી શું ટેકો આપી શકતી નથી

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

તે એ પણ દર્શાવતું નથી કે સીધો માર્ગ ખામીયુક્ત છે. મર્યાદિત માર્ગ બરાબર એ રીતે કામ કરે છે જે રીતે ધાર્યું છે, તે ફક્ત નીતિથી મર્યાદિત છે.

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

શોધને સહાય વિનંતીમાં ફેરવો

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

ફક્ત તે સંખ્યાની પાછળ દોડવા માટે દરેક એપ્લિકેશનને ટનલમાં ધકેલશો નહીં.

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