ਕੀ 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

ਰਿਜ਼ਾਲਵਰ ਦਾ ਜਵਾਬ ਉਹ ਵੇਰਵਾ ਹੈ ਜੋ ਬਹੁਤੀਆਂ ਤੁਲਨਾਵਾਂ ਛੱਡ ਦਿੰਦੀਆਂ ਹਨ, ਅਤੇ ਇਹ ਉਹ “ਸੁਧਾਰ” ਸਮਝਾਉਂਦਾ ਹੈ ਜੋ ਉਹੀ ਸਰਵਰ ਲਾਗੂ ਕਰਨ 'ਤੇ ਗ਼ਾਇਬ ਹੋ ਜਾਂਦੇ ਹਨ। ਜੇ ਪਤਾ ਹਰ ਵਾਰ ਵੱਖਰਾ ਹੋਵੇ, ਤਾਂ ਟੈਸਟ ਨੇ ਦੋ ਮਾਰਗ ਨਹੀਂ, ਦੋ ਮੰਜ਼ਿਲਾਂ ਦੀ ਤੁਲਨਾ ਕੀਤੀ ਹੈ। ਥ੍ਰੂਪੁਟ ਦੇ ਨਾਲ ਦੇਰੀ ਅਤੇ ਨੁਕਸਾਨ ਦੱਸੋ, ਕਿਉਂਕਿ ਕੁੱਲ ਮਿਲਾ ਕੇ ਤੇਜ਼ ਪਰ ਹਰ ਇੰਟਰੈਕਟਿਵ ਬੇਨਤੀ ਵਿੱਚ ਦੇਰੀ ਜੋੜਨ ਵਾਲਾ ਮਾਰਗ ਸ਼ਿਕਾਇਤ ਕਰਨ ਵਾਲੇ ਵਰਕਲੋਡ ਲਈ ਵਧੀਆ ਨਹੀਂ ਹੈ। ਪੁੱਛ ਕੇ ਉਡੀਕ ਕਰਨ ਵਾਲੀ ਹਰ ਚੀਜ਼ ਲਈ ਰਾਊਂਡ-ਟ੍ਰਿਪ ਸਮਾਂ ਵੱਡੇ ਪੱਧਰ ਦੀ ਰਫ਼ਤਾਰ ਤੋਂ ਵੱਧ ਮਾਅਨੇ ਰੱਖਦਾ ਹੈ।

ਕਦੋਂ ਫ਼ਰਕ ਰੱਖਣਾ ਯੋਗ ਹੈ

ਜੇ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਟਨਲ ਕਿਸੇ ਖ਼ਾਸ ਵਰਕਲੋਡ ਨੂੰ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਸੁਧਾਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਜਾਇਜ਼ ਕਾਰਜ-ਚੋਣ ਹੈ: ਵਰਕਲੋਡ, ਮਾਪ ਅਤੇ ਵਰਤਿਆ ਗਿਆ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਮਾਰਗ ਦਰਜ ਕਰੋ। ਲਾਭਦਾਇਕ ਰਿਕਾਰਡ ਇੱਕ ਹੋਸਟ, ਟਨਲ ਵੱਲੋਂ ਬਣਾਇਆ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਪਤਾ, ਰਿਜ਼ਾਲਵਰ ਦਾ ਜਵਾਬ ਅਤੇ ਉਸੇ ਦਿਨ ਸਿੱਧੇ ਮਾਰਗ ਦੇ ਉਹੀ ਅੰਕੜੇ ਦੱਸਦਾ ਹੈ। ਇਹ ਅਗਲੇ ਇੰਜੀਨੀਅਰ ਲਈ ਤੁਲਨਾ ਦੁਹਰਾਉਣ ਲਈ ਕਾਫ਼ੀ ਹੈ, ਦੁਬਾਰਾ ਬਹਿਸ ਕਰਨ ਲਈ ਨਹੀਂ। ਇਹ ਅਜੇ ਸਬੂਤ ਨਹੀਂ ਕਿ ਪ੍ਰਦਾਤਾ ਕੁਝ ਥ੍ਰੋਟਲ ਕਰ ਰਿਹਾ ਹੈ, ਅਤੇ ਇਹ ਹੋਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਜਾਂ ਹੋਰ ਘੰਟਿਆਂ 'ਤੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦਾ।

ਮਾਪ ਦਾ ਰਿਕਾਰਡ ਕਨਫਿਗਰੇਸ਼ਨ ਨਾਲ ਰੱਖੋ। ਇਹ ਅਗਲੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਕਿ ਸੁਧਾਰ ਹਾਲੇ ਵੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਮਾਰਗ ਬਦਲਿਆ ਜਾਂ ਵਰਕਲੋਡ, ਇਹ ਜਾਣਨ ਦਾ ਇਹੀ ਇੱਕੋ ਤਰੀਕਾ ਹੈ। ਤਾਰੀਖ਼ ਤੋਂ ਬਿਨਾਂ ਰਿਕਾਰਡ ਉਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਬਿਲਕੁਲ ਨਹੀਂ ਦੇ ਸਕਦਾ।