ਕਿੱਲ ਸਵਿੱਚ ਪਰਖ: ਸਿਰਫ਼ ਦੁਬਾਰਾ ਕਨੈਕਟ ਨਹੀਂ, ਵਿਥ ਮਾਪੋ

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

ਦੋ ਨਿਰੀਖਣ, ਦੋ ਵੱਖਰੇ ਫ਼ੈਸਲੇ

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

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

ਅਜਿਹੀ ਪ੍ਰੋਬ ਬਣਾਓ ਜਿਸ ਦਾ ਸਮਾਂ ਮਾਪਿਆ ਜਾ ਸਕੇ

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

while true; do
  printf '%s ' "$(date +%H:%M:%S)"
  curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 2 https://example.com || echo "curl-exit-$?"
  sleep 1
done

ਸਿਰਫ਼ ਸਥਿਤੀ ਨਹੀਂ, curl ਦੇ ਐਗਜ਼ਿਟ ਕੋਡ ਪੜ੍ਹੋ। 28 ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਬੇਨਤੀ ਦਾ ਸਮਾਂ ਖਤਮ ਹੋ ਗਿਆ, ਰੋਕਿਆ ਹੋਇਆ ਰਾਹ ਇਸੇ ਤਰ੍ਹਾਂ ਦਿਸਦਾ ਹੈ। 6 ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਨਾਮ ਵਿਸ਼ਲੇਸ਼ਣ ਫੇਲ ਹੋਇਆ, ਇਹ ਵੱਖਰੀ ਖੋਜ ਹੈ ਅਤੇ ਅਕਸਰ ਵਧੇਰੇ ਦਿਲਚਸਪ। ਵਿਥ ਦੌਰਾਨ ਘੱਟ ਬੀਤੇ ਸਮੇਂ ਨਾਲ 200 ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਟ੍ਰੈਫਿਕ ਨੂੰ ਬਾਹਰ ਜਾਣ ਦਿੱਤਾ ਗਿਆ।

ਆਉਟਪੁੱਟ ਨੂੰ ਫਾਈਲ ਵਿੱਚ ਲਿਖੋ ਅਤੇ ਰੱਖੋ। ਟਰਮੀਨਲ ਦਾ ਸਕ੍ਰੋਲਬੈਕ ਸਬੂਤ ਨਹੀਂ ਹੈ, ਅਤੇ ਦਿਲਚਸਪ ਹਿੱਸਾ ਆਮ ਤੌਰ ’ਤੇ ਵਿਚਕਾਰਲੀਆਂ ਤਿੰਨ ਲਾਈਨਾਂ ਹੁੰਦੀਆਂ ਹਨ।

ਅਸਲੀ ਫੇਲ ਹੋਣਾ ਪੈਦਾ ਕਰੋ, ਸੁਥਰਾ ਨਹੀਂ

ਕਲਾਇੰਟ ਦੇ ਆਪਣੇ ਮੀਨੂ ਤੋਂ ਡਿਸਕਨੈਕਟ ਕਰਨਾ ਸਹਿਯੋਗੀ ਰਾਹ ਦੀ ਪਰਖ ਕਰਦਾ ਹੈ, ਜਿੱਥੇ ਕਲਾਇੰਟ ਕੋਲ ਆਪਣੇ ਰੋਕ ਨਿਯਮ ਲਗਾਉਣ ਦਾ ਸਮਾਂ ਹੁੰਦਾ ਹੈ। ਇਸ ਦੀ ਥਾਂ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਮਾਰੋ, ਜਾਂ ਹੇਠਲੀ ਕੜੀ ਤੋੜੋ, ਤਦ ਤੁਸੀਂ ਉਸ ਰਾਹ ਦੀ ਪਰਖ ਕਰਦੇ ਹੋ ਜਿਸ ਰਾਹੀਂ ਅਸਲੀ ਫੇਲ ਹੁੰਦੀ ਹੈ।

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

ਮਨਜ਼ੂਰ ਟ੍ਰੈਫਿਕ ਕਿਸ ਤਰ੍ਹਾਂ ਦਿਸਦਾ ਹੈ ਇਹ ਲਾਗ ਵਿੱਚ ਪੜ੍ਹੋ

ਵਿਥ ਦੌਰਾਨ 200 ਜਾਂ ਤੇਜ਼ ਕਨੈਕਸ਼ਨ ਫੇਲ ਇੱਕ ਲੀਕ ਹੈ, ਭਾਵੇਂ ਇਹ ਕਿਸੇ ਵੀ ਦਿਸ਼ਾ ਵੱਲ ਹੋਵੇ। ਪੂਰੀ ਵਿਥ ਦੌਰਾਨ ਸਮਾਂ ਖਤਮ ਹੋਣਾ ਰੋਕ ਨੀਤੀ ਦਾ ਉਮੀਦ ਕੀਤਾ ਰੂਪ ਹੈ। ਕਨੈਕਸ਼ਨ ਫੇਲ ਹੁੰਦੇ ਸਮੇਂ ਨਾਮ ਵਿਸ਼ਲੇਸ਼ਣ ਦਾ ਸਫਲ ਹੋਣਾ ਦੱਸਦਾ ਹੈ ਕਿ ਰਿਜ਼ੋਲਵਰ ਅਜੇ ਪਹੁੰਚਯੋਗ ਹੈ, ਜੋ ਦੂਜੀ ਕਿਸਮ ਦੀ ਲੀਕ ਹੈ।

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

ss -tunp | grep -E 'ESTAB|SYN-SENT'
ip route get 198.51.100.7
resolvectl status | sed -n '1,20p'

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

ਨਤੀਜਾ ਅਜਿਹੇ ਰੂਪ ਵਿੱਚ ਦਰਜ ਕਰੋ ਜੋ ਅਪਡੇਟ ਤੋਂ ਬਾਅਦ ਵੀ ਰਹੇ

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

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