ਵੱਡੇ ਡਾਊਨਲੋਡ ਬਨਾਮ VPN: ਬੇਨਤੀ 'ਤੇ ਹੀ ਰਾਹ ਚੁਣੋ

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

ਰਾਊਟਰ ਜਵਾਬ ਕਿਉਂ ਨਹੀਂ ਮਾਪ ਸਕਦਾ

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

ਪ੍ਰੋਟੋਕੋਲ ਦਾ ਆਪਣਾ ਮੈਟਾਡੇਟਾ ਵੀ ਦਿਸਣ ਨਾਲੋਂ ਕਮਜ਼ੋਰ ਹੈ। HTTP ਉਹਨਾਂ ਜਵਾਬਾਂ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਲੰਬਾਈ ਸਰੀਰ ਤੋਂ ਪਹਿਲਾਂ ਐਲਾਨੀ ਨਹੀਂ ਜਾਂਦੀ, ਅਤੇ ਇੱਕ ਵਰਤੋਂਕਾਰ-ਕਾਰਵਾਈ ਕਈ ਬੇਨਤੀਆਂ ਪੈਦਾ ਕਰ ਸਕਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਸਾਂਝੀ ਲਾਗਤ ਕਿਸੇ ਇੱਕ ਹੈਡਰ ਮੁੱਲ ਵਰਗੀ ਨਹੀਂ ਹੁੰਦੀ। ਹੈਡਰ ਨੂੰ ਕੰਮ ਦਾ ਆਕਾਰ ਮੰਨਣਾ ਰਾਊਟਿੰਗ ਗਲਤੀ ਤੋਂ ਪਹਿਲਾਂ ਮਾਡਲਿੰਗ ਗਲਤੀ ਹੈ।

ਜਾਂਚ 1: ਕੀ ਅਜਿਹਾ ਫ਼ੈਸਲਾ-ਬਿੰਦੂ ਹੈ ਜੋ ਰਾਹ ਚੁਣ ਸਕੇ?

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

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

ਜਾਂਚ 2: ਮੈਟਾਡੇਟਾ ਸੱਚਮੁੱਚ ਤੁਹਾਨੂੰ ਕੀ ਦੱਸਦਾ ਹੈ?

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

ਐਪਲੀਕੇਸ਼ਨ ਮੈਟਾਡੇਟਾ ਜਿਸ ਦਾ ਸਮਰਥਨ ਕਰ ਸਕਦਾ ਹੈ ਉਹ ਕੰਮ ਬਾਰੇ ਫ਼ੈਸਲਾ ਹੈ: ਇਹ ਵਰਕਫਲੋ ਬਲਕ ਸਿੰਕ ਹੈ, ਇਹ ਇੰਟਰਐਕਟਿਵ ਹੈ, ਇਹ ਜਾਣੇ ਸਰੋਤ ਤੋਂ ਸੌਫਟਵੇਅਰ ਅੱਪਡੇਟ ਹੈ। ਉਹ ਇਰਾਦੇ ਦੀ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੀ ਨੀਤੀ ਹੈ, ਅਤੇ ਪਰਖਣ ਲਈ ਕਾਫ਼ੀ ਸਥਿਰ ਹੈ। “ਇਹ ਜਵਾਬ ਚਾਲੀ ਮੈਗਾਬਾਈਟ ਤੋਂ ਵੱਡਾ ਹੋਵੇਗਾ” ਅਜਿਹੀ ਨੀਤੀ ਨਹੀਂ।

ਜਾਂਚ 3: ਕੀ ਪ੍ਰਵਾਹ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹੈ?

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

conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10

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

ਜਾਂਚ 4: ਕੀ ਅਸਲ ਲੋੜ ਦੇਰੀ ਹੈ, ਨਿਕਾਸ ਨਹੀਂ?

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

tc qdisc replace dev eth0 root cake bandwidth 100mbit

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

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

ਤਬਦੀਲੀ-ਰਿਕਾਰਡ ਵਿੱਚ ਜਾਂਚ-ਸੂਚੀ ਰੱਖੋ: ਫ਼ੈਸਲਾ-ਬਿੰਦੂ, ਉਸ ਨੂੰ ਚਲਾਉਣ ਵਾਲਾ ਖੇਤਰ ਜਾਂ ਕੰਮ, ਪ੍ਰਵਾਹ ਪਹਿਲਾਂ ਹੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਮਾਪਿਆ ਲੱਛਣ ਦੇਰੀ ਸੀ ਜਾਂ ਨਿਕਾਸ। ਚਾਰ ਸਵਾਲ, ਅਤੇ ਚਾਰਿਆਂ ਦਾ ਜਵਾਬ ਦੇਣ ਵਾਲੀ ਨੀਤੀ ਉਹ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਸੰਭਾਲ ਸਕਦੇ ਹੋ, ਕੇਵਲ ਬਚਾ ਨਹੀਂ ਸਕਦੇ।