VPN ਦੀ ਗਤੀ ਕਿਵੇਂ ਜਾਂਚੀਏ ਤਾਂ ਜੋ ਸੰਖਿਆਵਾਂ ਦਾ ਕੋਈ ਅਰਥ ਹੋਵੇ
ਜਾਂਚ ਸਰਵਰ ਨੂੰ ਸਥਿਰ ਕਰੋ, ਹੇਠਲੀ ਪਰਤ ਨੂੰ ਅਡੋਲ ਰੱਖੋ ਅਤੇ ਦੇਰੀ ਨੂੰ ਥ੍ਰੂਪੁਟ ਤੋਂ ਵੱਖਰਾ ਪੜ੍ਹੋ। ਟਨਲ ਕੁਝ ਵੀ ਮਾਪਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਰਾਹ ਬਦਲ ਦਿੰਦੀ ਹੈ।
ਗਤੀ ਦੀ ਜਾਂਚ ਕਦੇ ਵੀ VPN ਨੂੰ ਨਹੀਂ ਮਾਪਦੀ। ਇਹ ਇੱਕ ਰਾਹ ਮਾਪਦੀ ਹੈ, ਅਤੇ ਟਨਲ ਚਾਲੂ ਕਰਨ 'ਤੇ ਪਹਿਲਾ ਬਾਈਟ ਹਿੱਲਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਉਸ ਰਾਹ ਦਾ ਇੱਕ ਹਿੱਸਾ ਬਦਲ ਜਾਂਦਾ ਹੈ। ਇਸੇ ਲਈ ਇੱਕ ਲੈਪਟਾਪ ਇੱਕ ਸਾਈਟ 'ਤੇ ਸਿਹਤਮੰਦ ਅੰਕੜਾ ਅਤੇ ਦੂਜੀ 'ਤੇ ਮਾੜਾ ਅੰਕੜਾ ਦਿਖਾਉਂਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਦੋਵੇਂ ਪਾਸੇ ਕੁਝ ਵੀ ਨਹੀਂ ਬਦਲਿਆ। ਨਤੀਜੇ ਨੂੰ ਰਾਹ ਬਾਰੇ ਸਬੂਤ ਵਜੋਂ ਪੜ੍ਹੋ, ਕਿਸੇ ਉਤਪਾਦ ਦੇ ਸਕੋਰ ਵਜੋਂ ਨਹੀਂ।
ਤਿੰਨ ਗੱਲਾਂ ਤੈਅ ਕਰਦੀਆਂ ਹਨ ਕਿ ਤੁਲਨਾ ਦਾ ਕੋਈ ਮੁੱਲ ਹੈ ਜਾਂ ਨਹੀਂ: ਕੀ ਦੋਵੇਂ ਦੌੜਾਂ ਇੱਕੋ ਨਿਸ਼ਾਨੇ 'ਤੇ ਪਹੁੰਚੀਆਂ, ਕੀ ਪਹੁੰਚ ਨੈੱਟਵਰਕ ਅਡੋਲ ਰਿਹਾ, ਅਤੇ ਕੀ ਤੁਸੀਂ ਦੇਰੀ ਨੂੰ ਮਾਤਰਾ ਦੇ ਨਾਲ ਦਰਜ ਕੀਤਾ।
ਪਹਿਲੇ ਬਾਈਟ ਤੋਂ ਪਹਿਲਾਂ ਟਨਲ ਕੀ ਮੁੜ ਲਿਖਦੀ ਹੈ
ਕਲਾਇੰਟ ਹਰ ਪੈਕਟ ਨੂੰ ਇੱਕ ਹੋਰ ਹੈਡਰ ਵਿੱਚ ਲਪੇਟਦਾ ਹੈ, ਇਸ ਲਈ ਪ੍ਰਤੀ ਪੈਕਟ ਵਰਤੋਂਯੋਗ ਪੇਲੋਡ ਘਟਦਾ ਹੈ। ਖਰਚਾ ਪ੍ਰਤੀ ਤਬਾਦਲਾ ਨਹੀਂ ਸਗੋਂ ਪ੍ਰਤੀ ਪੈਕਟ ਹੁੰਦਾ ਹੈ, ਯਾਨੀ ਵੱਡੀ ਫਾਈਲ ਨੂੰ ਟਨਲ ਤੋਂ ਬਿਨਾਂ ਭੇਜੀ ਉਸੇ ਫਾਈਲ ਨਾਲੋਂ ਵੱਧ ਪੈਕਟ ਚਾਹੀਦੇ ਹਨ। ਅਜਿਹਾ ਵਾਧੂ ਭਾਰ ਦਿਸਦੀ ਸੈਟਿੰਗ ਵਜੋਂ ਨਹੀਂ, ਪੈਕਟਾਂ ਦੀ ਗਿਣਤੀ ਵਜੋਂ ਦਿਸਦਾ ਹੈ।
ਇਸ ਤੋਂ ਦੋ ਨਤੀਜੇ ਨਿਕਲਦੇ ਹਨ। ਵੱਡੇ ਬਲਾਕਾਂ ਨਾਲ ਬਣੀ ਜਾਂਚ ਪ੍ਰਤੀ ਪੈਕਟ ਖਰਚਾ ਮਹਿਸੂਸ ਕਰਦੀ ਹੈ, ਜਦੋਂ ਕਿ ਬਹੁਤ ਸਾਰੀਆਂ ਛੋਟੀਆਂ ਬੇਨਤੀਆਂ ਵਾਲੀ ਜਾਂਚ ਇਸ ਦੀ ਥਾਂ ਆਉਣ-ਜਾਣ ਮਹਿਸੂਸ ਕਰਦੀ ਹੈ। ਅਤੇ ਜੇ ਰਾਹ ਦੀ MTU ਖੋਜ ਕਿਤੇ ਰਾਹ ਵਿੱਚ ਰੁਕੀ ਹੋਈ ਹੈ, ਟਨਲ ਛੋਟੇ ਪੈਕਟ ਆਕਾਰ 'ਤੇ ਰੁਕ ਜਾਂਦੀ ਹੈ ਅਤੇ ਥ੍ਰੂਪੁਟ ਉਸ ਕਾਰਨ ਘਟਦਾ ਹੈ ਜਿਸ ਦਾ ਸਾਈਫਰਾਂ ਨਾਲ ਕੋਈ ਸਬੰਧ ਨਹੀਂ।
ਤੁਸੀਂ ਸੀਮਾ ਸਿੱਧੀ ਦੇਖ ਸਕਦੇ ਹੋ। ਲਿਨਕਸ ਵਿੱਚ ਟੁਕੜਿਆਂ ਤੋਂ ਬਿਨਾਂ ਲੰਘਣ ਵਾਲਾ ਸਭ ਤੋਂ ਵੱਡਾ ਪੇਲੋਡ ਮੰਗੋ, ਫਿਰ ਟਨਲ ਚਾਲੂ ਰੱਖ ਕੇ ਦੁਹਰਾਓ:
ping -M do -s 1472 -c 3 203.0.113.10
ਜੇ ਉਹ ਫੇਲ੍ਹ ਹੋਵੇ ਤਾਂ 1,400 'ਤੇ ਉਤਰੋ ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ। ਸਿਰਫ਼ 1,380 ਬਾਈਟ ਢੋਣ ਵਾਲੀ ਟਨਲ ਤੁਹਾਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਰਾਹ ਵਿੱਚ ਹੇਠਾਂ ਕੁਝ ਹੋਰ ਦਬਾ ਰਿਹਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ 'ਤੇ ਕੋਈ ਵੀ ਟਿਊਨਿੰਗ ਉਸ ਨੂੰ ਉੱਪਰ ਨਹੀਂ ਚੁੱਕੇਗੀ।
ਟਨਲ ਚਾਲੂ ਹੋਣ 'ਤੇ ਜਾਂਚ ਸਰਵਰ ਕਿਉਂ ਖਿਸਕਦਾ ਹੈ
ਬਹੁਤੇ ਸਾਧਨ ਉਹਨਾਂ ਨੂੰ ਦਿਸਦੇ ਜਨਤਕ ਪਤੇ ਦੇ ਆਧਾਰ 'ਤੇ ਨੇੜਲਾ ਸਰਵਰ ਚੁਣਦੇ ਹਨ। ਟਨਲ ਚਾਲੂ ਹੋਣ 'ਤੇ ਉਹ ਪਤਾ ਐਗਜ਼ਿਟ ਨੋਡ ਦਾ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਸਾਧਨ ਕਿਸੇ ਹੋਰ ਸ਼ਹਿਰ ਜਾਂ ਦੇਸ਼ ਦਾ ਹੋਸਟ ਚੁਣ ਸਕਦਾ ਹੈ। ਫਿਰ ਤੁਸੀਂ ਦੋ ਮੰਜ਼ਿਲਾਂ ਦੀ ਤੁਲਨਾ ਕਰ ਰਹੇ ਹੋ, ਅਤੇ ਉਹਨਾਂ ਵਿਚਕਾਰਲਾ ਫ਼ਰਕ ਐਗਜ਼ਿਟ ਤੋਂ ਜਾਂਚ ਹੋਸਟ ਤੱਕ ਦੀ ਦੂਰੀ ਵੀ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ।
ਪਹਿਲੀ ਦੌੜ ਤੋਂ ਪਹਿਲਾਂ ਸਰਵਰ ਨੂੰ ਨਾਮ ਜਾਂ ID ਨਾਲ ਸਥਿਰ ਕਰੋ ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਹਰ ਦੌੜ ਵਿੱਚ ਉਸ ਨੂੰ ਫੜੀ ਰੱਖੋ। ਜੇ ਸਾਧਨ ਉਸ ਨੂੰ ਨਹੀਂ ਫੜਦਾ, ਤਾਂ ਤੁਸੀਂ ਕੰਟਰੋਲ ਕਰਦੇ ਹੋ ਉਹ ਨਿਸ਼ਾਨਾ ਚੁਣੋ ਅਤੇ ਆਪ ਚਲਾਓ: iperf3 -c test.example.net -R -t 20 ਮੰਜ਼ਿਲ ਨੂੰ ਸਥਿਰ ਰੱਖਦਾ ਹੈ ਅਤੇ ਕੱਲ੍ਹ ਨਾਲ ਤੁਲਨਾ ਕਰਨ ਯੋਗ ਅੰਕੜਾ ਦਿੰਦਾ ਹੈ।
ਇੱਕ ਬਦਲ ਬਦਲੋ, ਅਤੇ ਹੇਠਲੀ ਪਰਤ ਇੱਕ ਨਹੀਂ
ਵਾਇਰਲੈਸ ਹੀ ਆਮ ਲੁਕਿਆ ਬਦਲਾਅ ਹੈ। ਲੈਪਟਾਪ ਹਿੱਲਣ 'ਤੇ ਸਿਗਨਲ ਦੀ ਤਾਕਤ ਬਦਲਦੀ ਹੈ ਅਤੇ ਗੁਆਂਢੀ ਦੇ ਕਾਲ ਸ਼ੁਰੂ ਕਰਨ 'ਤੇ ਚੈਨਲ ਦੀ ਰੁੱਝੀ ਬਦਲਦੀ ਹੈ, ਇਸ ਲਈ Wi-Fi 'ਤੇ ਦਸ ਮਿੰਟ ਦੇ ਫ਼ਰਕ ਨਾਲ ਕੀਤੀਆਂ ਦੋ ਦੌੜਾਂ ਇੱਕੋ ਜਾਂਚ ਦਾ ਦੁਹਰਾਅ ਨਹੀਂ। ਤਾਰ, ਜਾਂ ਸਿਗਨਲ ਪੱਧਰ ਲਿਖ ਕੇ ਰੱਖੀ ਸਥਿਰ ਥਾਂ, ਉਸ ਸ਼ੋਰ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਹਟਾ ਦਿੰਦੀ ਹੈ। ਹਰ ਦੌੜ ਦੇ ਸ਼ੁਰੂ ਅਤੇ ਅੰਤ 'ਤੇ ਸਿਗਨਲ ਪੱਧਰ ਦੀ ਟਿੱਪਣੀ ਆਮ ਤੌਰ 'ਤੇ ਦੋ ਦੌੜਾਂ ਇਕੱਠੀਆਂ ਹਨ ਜਾਂ ਨਹੀਂ ਇਹ ਦਿਖਾਉਣ ਲਈ ਕਾਫ਼ੀ ਹੁੰਦੀ ਹੈ।
ਯੰਤਰ ਦਾ ਭਾਰ ਵੀ ਉਸੇ ਟੋਕਰੀ ਵਿੱਚ ਹੈ। ਇੱਕ ਕੋਰ 'ਤੇ ਐਨਕ੍ਰਿਪਟ ਕਰਨ ਵਾਲਾ ਕਲਾਇੰਟ ਲਿੰਕ ਤੋਂ ਬਹੁਤ ਪਹਿਲਾਂ ਆਪਣੀ ਸੀਮਾ 'ਤੇ ਪਹੁੰਚ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਪਿਛੋਕੜ ਦਾ ਸਿੰਕ ਉਸ ਤੋਂ ਵੀ ਪਹਿਲਾਂ ਪਹੁੰਚਦਾ ਹੈ। ਦੌੜ ਦੌਰਾਨ CPU ਵੇਖੋ ਅਤੇ ਲਿਖੋ ਕਿ ਹੋਰ ਕੀ ਖੁੱਲ੍ਹਾ ਸੀ। ਪਾਵਰ ਸੈਟਿੰਗਾਂ ਵੀ ਇੱਥੇ ਡੰਗ ਸਕਦੀਆਂ ਹਨ, ਕਿਉਂਕਿ ਬੈਟਰੀ 'ਤੇ ਚੱਲਦਾ ਲੈਪਟਾਪ ਲਿੰਕ ਦੇ ਰੁੱਝਣ ਤੋਂ ਬਹੁਤ ਪਹਿਲਾਂ ਪ੍ਰੋਸੈਸਰ ਨੂੰ ਸੀਮਤ ਕਰ ਸਕਦਾ ਹੈ।
| Measurement | What it answers | What it misses |
|---|---|---|
| Download | Bulk capacity along the path | Any question about responsiveness |
| Upload | Capacity from client to exit | Download health |
| RTT to a fixed target | Distance plus queueing | Whether capacity is available |
| Jitter or loss | Stability under load | How much the link can carry |
ਹੇਠਲੀ ਪਰਤ ਦਾ ਔਸਤ ਲੈਣ ਦੀ ਥਾਂ ਉਸ ਨੂੰ ਅਡੋਲ ਰੱਖੋ। ਮਿਲਦੀਆਂ ਤਿੰਨ ਦੌੜਾਂ ਵੱਖ-ਵੱਖ ਕਮਰਿਆਂ ਵਿੱਚ ਲਈਆਂ ਦਸ ਨਾਲੋਂ ਵੱਧ ਦੱਸਦੀਆਂ ਹਨ।
ਦੇਰੀ, ਨੁਕਸਾਨ ਅਤੇ ICMP ਵੱਖ-ਵੱਖ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ
ਪਿੰਗ ਸਥਿਰ ਪਤੇ 'ਤੇ ਛੋਟੀ ਜਾਂਚ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਬਹੁਤੇ ਨੈੱਟਵਰਕ ICMP ਦਾ ਜਵਾਬ ਘੱਟ ਤਰਜੀਹ 'ਤੇ ਦਿੰਦੇ ਹਨ ਜਾਂ ਉਸ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹਨ। ਨਾ ਆਏ ਜਵਾਬ ਜਾਂਚ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹਨ, ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਪੈਕਟਾਂ ਦਾ ਨਹੀਂ। ਭਾਰ ਹੇਠ ਵਧਦਾ ਆਉਣ-ਜਾਣ ਸਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਦੱਸਦਾ ਹੈ ਕਿ ਕਤਾਰ ਭਰ ਰਹੀ ਹੈ, ਇਹ ਨਹੀਂ ਕਿ ਰਾਹ ਲੰਮਾ ਹੋ ਗਿਆ।
ਟਨਲ ਦੇਰੀ ਜੋੜਦੀ ਹੈ ਜਾਂ ਨਹੀਂ ਇਹ ਜਾਣਨ ਲਈ ਇੱਕ ਨਿਸ਼ਾਨੇ ਦੀ ਤੁਲਨਾ ਉਸ ਨਾਲ ਅਤੇ ਉਸ ਤੋਂ ਬਿਨਾਂ ਕਰੋ, ਜਾਂ ਇੱਕੋ ਪਹੁੰਚ ਨੈੱਟਵਰਕ ਤੋਂ ਪਹੁੰਚਣ ਯੋਗ ਦੋ ਐਗਜ਼ਿਟਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਜਾਂਚ ਵਾਰ-ਵਾਰ ਚਲਾਓ ਅਤੇ ਖਿਲਾਰ ਵੇਖੋ, ਕਿਉਂਕਿ ਔਸਤ ਠੀਕ ਉਸੇ ਬਦਲਾਅ ਨੂੰ ਲੁਕਾਉਂਦੀ ਹੈ ਜੋ ਕਾਲ ਨੂੰ ਨਕਾਰਾ ਬਣਾਉਂਦਾ ਹੈ।
ਜੋ ਕੰਮ ਹੌਲੀ ਲੱਗਾ ਉਸ ਵੱਲ ਮੁੜੋ
ਜੋ ਮਾਪ ਕਾਲ ਦੇ ਟੁੱਟਦੇ ਰਹਿਣ 'ਤੇ ਵੀ ਸੁਧਰਦਾ ਹੈ ਉਸ ਨੇ ਕੁਝ ਹੋਰ ਜਵਾਬ ਦਿੱਤਾ ਹੈ। ਜਿਸ ਕੰਮ ਨਾਲ ਜਾਂਚ ਸ਼ੁਰੂ ਹੋਈ ਸੀ ਉਹ ਦੁਬਾਰਾ ਚਲਾਓ, ਭਾਵੇਂ ਉਹ ਮੀਟਿੰਗ ਹੋਵੇ, ਫਾਈਲ ਸਾਂਝਾ ਕਰਨਾ ਹੋਵੇ ਜਾਂ ਦੂਰਲੇ ਡੈਸਕਟਾਪ ਦਾ ਸੈਸ਼ਨ ਹੋਵੇ। ਜੇ ਅੰਕੜਾ ਸੁਧਰਿਆ ਪਰ ਕੰਮ ਨਹੀਂ, ਤਾਂ ਰੁਕਾਵਟ ਉੱਥੇ ਸੀ ਜਿੱਥੇ ਜਾਂਚ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚੀ, ਜਿਵੇਂ ਟਨਲ ਪਿੱਛੇ ਦਾ ਸਰਵਰ ਜਾਂ ਤੁਹਾਡੇ ਪਾਸੇ ਦੀ ਅਪਲਿੰਕ।
ਹਰ ਦੌੜ ਨੂੰ ਯੰਤਰ, ਪਹੁੰਚ ਨੈੱਟਵਰਕ, ਅੰਤ ਬਿੰਦੂ, ਪ੍ਰੋਟੋਕੋਲ, ਨਿਸ਼ਾਨਾ ਅਤੇ ਸਮੇਂ ਨਾਲ ਦਰਜ ਕਰੋ। ਜੋ ਦੌੜ ਕਦੇ ਨਹੀਂ ਜੁੜੀ ਉਹ ਸਿਫ਼ਰ ਥ੍ਰੂਪੁਟ ਨਹੀਂ ਸਗੋਂ ਪਹੁੰਚ ਦਾ ਨਤੀਜਾ ਹੈ, ਇਸ ਲਈ ਉਸ ਨੂੰ ਮਿਟਾਉਣ ਦੀ ਥਾਂ ਉਸੇ ਲੇਬਲ ਹੇਠ ਰੱਖੋ।
ਅਗਲੀ ਤੁਲਨਾ ਤੋਂ ਪਹਿਲਾਂ ਛੋਟੀ ਸੂਚੀ
ਨਿਸ਼ਾਨਾ ਸਥਿਰ ਕਰੋ ਅਤੇ ਲਿਖੋ ਕਿ ਇਹ ਕਿਉਂ ਚੁਣਿਆ। ਰਾਹ ਜੋ ਪੈਕਟ ਆਕਾਰ ਦਿੰਦਾ ਹੈ ਉਹ ਦਰਜ ਕਰੋ, ਤਾਂ ਜੋ ਬਾਅਦ ਦੀ ਗਿਰਾਵਟ ਦੀ ਵਿਆਖਿਆ ਹੋਵੇ। ਪਹੁੰਚ ਨੈੱਟਵਰਕ ਇੱਕੋ ਜਿਹਾ ਰੱਖੋ, CPU ਭਾਰ ਲਿਖੋ, ਅਤੇ ਫ਼ਰਕ ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨ ਦੌੜਾਂ ਲਓ।
ਫਿਰ ਠੀਕ ਇੱਕ ਚੀਜ਼ ਬਦਲੋ ਅਤੇ ਦੁਹਰਾਓ। ਜਿਸ ਤੁਲਨਾ ਨੂੰ ਤੁਸੀਂ ਸਮਝਾ ਸਕਦੇ ਹੋ ਉਹ ਵੱਡੇ ਅੰਕੜੇ ਵਾਲੀ ਤੁਲਨਾ ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ।