VPN ਰਾਹੀਂ ਫਾਈਲ ਸਾਂਝੀਆਂ ਕਰਨਾ ਹੌਲੀ ਕਿਉਂ ਲੱਗਦਾ ਹੈ: ਰਾਊਂਡ ਟ੍ਰਿਪ, Mbps ਨਹੀਂ

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

ਦੂਰ ਦੀ ਕਾਰਜਸ਼ੀਲ ਕਾਪੀ ਦਾ ਆਕਾਰ ਗ਼ਲਤ ਹੈ

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

ਐਨਕ੍ਰਿਪਸ਼ਨ ਦਾ ਓਵਰਹੈੱਡ ਇਸਦਾ ਛੋਟਾ ਹਿੱਸਾ ਹੈ; ਨੁਕਸਾਨ ਵੱਧ ਬੁਰਾ ਹੈ, ਕਿਉਂਕਿ ਇੱਕ ਦੁਬਾਰਾ ਭੇਜਣਾ ਅਤੇ ਇੱਕ ਢਹਿ ਚੁੱਕੀ ਕੰਜੈਸ਼ਨ ਵਿੰਡੋ ਸੰਬੰਧਿਤ ਬਾਈਟਾਂ ਨਾਲੋਂ ਬਹੁਤ ਵੱਧ ਖਰਚ ਕਰਦੇ ਹਨ।

ਮੈਗਾਬਾਈਟਾਂ ਤੋਂ ਪਹਿਲਾਂ ਰਾਊਂਡ ਟ੍ਰਿਪ ਗਿਣੋ

ਸਮਰੱਥਾ ਖਰੀਦਣ ਤੋਂ ਪਹਿਲਾਂ ਦੇਰੀ ਮਾਪੋ। ਇੱਕ ping ਦੱਸਦਾ ਹੈ ਕਿ ਹਰ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕੀ ਦਿੰਦਾ ਹੈ।

ping -c 10 fileserver.example.net

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

ਕੰਮ ਸ਼ਿਫਟ ਕਰੋ, ਬਾਈਟ ਨਹੀਂ

ਵੱਧ ਪਾਈਪ ਲਈ ਭੁਗਤਾਨ ਕਰਨ ਦੀ ਬਜਾਏ ਬਦਲੋ ਕਿ ਕੰਮ ਕਿੱਥੇ ਹੁੰਦਾ ਹੈ। ਰਿਪੋਜ਼ਟਰੀ ਨੂੰ ਮਾਊਂਟ ਕਰਨ ਦੀ ਬਜਾਏ ਸੇਵਾ ਦਿਓ, ਅਤੇ ਸਿਰਫ਼ ਫ਼ਰਕ ਭੇਜਣ ਵਾਲੇ ਸਾਧਨ ਨਾਲ ਥੋਕ ਵਿੱਚ ਕਾਪੀ ਕਰੋ।

rsync -av --info=progress2 ./project/ [email protected]:/srv/share/project/

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

ਇੱਕੋ ਆਕਾਰ ਕੋਲ ਅਟਕਣਾ MTU ਦਾ ਲੱਛਣ ਹੈ

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

ping -M do -s 1400 -c 3 fileserver.example.net

ਸਫਲ ਜਾਂਚ ਦਾ ਅਰਥ ਹੈ ਕਿ 1428 ਬਾਈਟ ਦਾ IP ਪੈਕੇਟ ਟੁਕੜੇ ਬਿਨਾਂ ਰਾਹ ਪਾਰ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ICMP ਅਤੇ IP ਹੈਡਰ 28 ਬਾਈਟ ਜੋੜਦੇ ਹਨ। ਟੁਕੜੇ ਰੋਕਣ ਵਾਲੇ ਝੰਡੇ ਨਾਲ ਅਸਫਲਤਾ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਟਨਲ ਦਾ ਵਰਤੋਂਯੋਗ MTU ਸਰਵਰ ਦੇ ਅੰਦਾਜ਼ੇ ਨਾਲੋਂ ਛੋਟਾ ਹੈ। 9000 ਬਾਈਟ ਦੇ ਬਫਰ 1500 ਬਾਈਟ ਦੇ ਰਾਹ 'ਤੇ ਭੇਜਣ ਵਾਲਾ ਸਰਵਰ ਟੁਕੜੇ ਜਾਂ ਡਿੱਗਣ ਨੂੰ ਮਜਬੂਰ ਕਰਦਾ ਹੈ, ਅਤੇ ICMP ਫਿਲਟਰ ਹੋਣ 'ਤੇ ਰਾਹ ਦਾ MTU ਖੋਜ ਚੁੱਪਚਾਪ ਅਸਫਲ ਹੋ ਸਕਦਾ ਹੈ। ਟਨਲ ਦਾ MTU ਘਟਾਓ, ਸਮਰੱਥ ਕਰੋ mssfix OpenVPN 'ਤੇ, ਜਾਂ ਸਰਵਰ ਦੇ ਬਫਰ ਛੋਟੇ ਕਰੋ, ਫਿਰ ਪੁਸ਼ਟੀ ਲਈ ਉਹੀ ਸਥਾਨਾਂਤਰਣ ਦੁਬਾਰਾ ਚਲਾਓ।

ਜੋ ਅੰਤਰ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ ਉਹ ਮਾਪੋ

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

ਜਦੋਂ ਸਿਰਫ਼ ਸ਼ੁਰੂਆਤੀ ਮੈਗਾਬਾਈਟ ਖਿੱਚੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਮੈਟਾਡੇਟਾ ਵੱਲ ਦੇਖੋ; ਜਦੋਂ ਸਭ ਕੁਝ ਹੌਲੀ ਚੱਲਦਾ ਹੈ, ਤਾਂ ਸਮਰੱਥਾ ਅਤੇ ਨੁਕਸਾਨ ਵੱਲ ਦੇਖੋ। ਮੇਲ ਖਾਂਦਾ ਕਾਰਨ ਠੀਕ ਕਰੋ, ਅਤੇ ਇਹ ਉਮੀਦ ਛੱਡੋ ਕਿ WAN ਲਿੰਕ LAN ਕੇਬਲ ਵਾਂਗ ਵਿਵਹਾਰ ਕਰੇਗਾ।