ਕੇਬਲ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਪੈਕਟ ਲਾਸ ਕਿਵੇਂ ਪੜ੍ਹੀਏ

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

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

ਪਿੰਗ ਫ਼ੀਸਦੀ ਅਸਲ ਵਿੱਚ ਕੀ ਮਾਪਦੀ ਹੈ

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

ਪ੍ਰੋਬ ਦੇ ਨਤੀਜੇ ਨੂੰ ਰਾਹ ਬਾਰੇ ਸੰਕੇਤ ਵਜੋਂ ਰੱਖੋ। ਫਿਰ ਉਹ ਸਮਾਂ ਅਤੇ ਹੱਦ ਲੱਭੋ ਜਿਸ ਨੇ ਇਸਨੂੰ ਬਣਾਇਆ।

ਕਾਊਂਟਰ ਫ਼ਰਕ ਦੀ ਤੁਲਨਾ ਕਰੋ, ਜੀਵਨ ਭਰ ਦੇ ਜੋੜਾਂ ਦੀ ਨਹੀਂ

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

ip -s link show dev eth0
nstat -az TcpRetransSegs TcpExtTCPTimeouts
date -u +%Y-%m-%dT%H:%M:%SZ

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

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

ਗੁੰਮ ਹੋਇਆ ਖੰਡ ਲੰਬੀ ਉਡੀਕ ਕਿਵੇਂ ਬਣਦਾ ਹੈ

ਖੰਡ ਗੁੰਮ ਹੋਣ ਤੋਂ ਬਾਅਦ ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ ਫੇਰੀ ਤੋਂ ਕਿਤੇ ਵੱਧ ਸਮਾਂ ਉਡੀਕ ਸਕਦੀ ਹੈ। TCP ਯਾਤਰਾ ਦਾ ਸਮਾਂ ਅੰਦਾਜ਼ਾ ਲਾਉਂਦਾ ਹੈ, ਉਸ ਅੰਦਾਜ਼ੇ ਤੋਂ ਦੁਬਾਰਾ ਭੇਜਣ ਦਾ ਟਾਈਮਰ ਗਿਣਦਾ ਹੈ ਅਤੇ ਦੁਬਾਰਾ ਭੇਜਣਾ ਵੀ ਫੇਲ੍ਹ ਹੋਣ ’ਤੇ ਪਿੱਛੇ ਹਟਦਾ ਹੈ, ਇਸ ਲਈ ਗ਼ਲਤ ਪਲ ’ਤੇ ਗੁੰਮ ਹੋਇਆ ਇੱਕ ਖੰਡ ਬੇਨਤੀ ਨੂੰ ਦਿੱਖਣ ਵਾਲੇ ਅੰਤਰਾਲ ਤੱਕ ਰੋਕ ਸਕਦਾ ਹੈ। ਇਹ ਕਾਰਜਵਿਧੀ RFC 6298 ਵਿੱਚ ਨਿਰਧਾਰਤ ਹੈ, ਅਤੇ ਇਹ ਦੱਸਦੀ ਹੈ ਕਿ ਤੁੱਛ ਦਿਸਣ ਵਾਲੀ ਲਾਸ ਦਰ ਵੀ ਕਿਉਂ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ।

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

ਜਿੱਥੇ ਕੈਪਚਰ ਦੀ ਆਜਾਜ਼ਗੀ ਹੈ ਉੱਥੇ ਇਸਨੂੰ ਤੰਗ ਰੱਖੋ। ਤੁਹਾਨੂੰ ਇਹ ਚਾਹੀਦਾ ਹੈ ਕਿ ਉਮੀਦ ਕੀਤੇ ਪੈਕਟ ਜਾਂ ਪ੍ਰਾਪਤੀਆਂ ਕਿਸੇ ਖ਼ਾਸ ਹੱਦ ’ਤੇ ਰੁਕਦੀਆਂ ਹਨ ਜਾਂ ਨਹੀਂ, ਇਹ ਤੱਥ ਨਹੀਂ ਕਿ ਕਿਸੇ ਰੁੱਝੇ ਟ੍ਰੇਸ ਵਿੱਚ ਕਿਤੇ ਦੁਬਾਰਾ ਭੇਜਣਾ ਮੌਜੂਦ ਹੈ।

ਬਾਕੀਆਂ ਨੂੰ ਹਿਲਾਏ ਬਿਨਾਂ ਇੱਕ ਹੱਦ ਬਦਲੋ

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

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