ಒಂದು ಸೆಕೆಂಡಿನಲ್ಲಿ ಮುಗಿಯುವ ಮರುಸಂಪರ್ಕ ಕ್ಲೈಂಟ್ ವೇಗವಾಗಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ. ಟನೆಲ್ ಆಫ್ ಆಗಿದ್ದಾಗ ಏನಾದರೂ ತಪ್ಪಿಸಿಕೊಂಡಿತೇ ಎಂದು ಅದು ಹೇಳುವುದಿಲ್ಲ. ಒಂದು ನಿಮಿಷ ತೆಗೆದುಕೊಳ್ಳುವ ಮರುಸಂಪರ್ಕ ಕ್ಲೈಂಟ್ ನಿಧಾನವಾಗಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು ಅಂತರದಲ್ಲಿ ನೇರ ಸಂಚಾರಕ್ಕೆ ಅನುಮತಿ ಇತ್ತೇ ಎಂದು ಇನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಇವು ಎರಡು ಅಳತೆಗಳು, ಮತ್ತು ಮೊದಲನೆಯದನ್ನು ಮಾತ್ರ ವರದಿ ಮಾಡುವ ಕಿಲ್ ಸ್ವಿಚ್ ಪರೀಕ್ಷೆ ಸ್ವಿಚ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿಲ್ಲ.

ಎರಡು ಅವಲೋಕನಗಳು, ಎರಡು ಪ್ರತ್ಯೇಕ ತೀರ್ಪುಗಳು

ಲಭ್ಯತೆಯ ಪ್ರಶ್ನೆ ಸರಳ: ಟನೆಲ್ ಮತ್ತೆ ಯಾವಾಗ ಬಳಕೆಗೆ ಬಂದಿತು, ಮತ್ತು ಅಲ್ಲಿಗೆ ತಲುಪಲು ಸಂರಕ್ಷಿತ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಹೊಸ ಸಂಪರ್ಕ ಬೇಕಾಯಿತೇ. ಜಾರಿಯ ಪ್ರಶ್ನೆ ಬೇರೆ: ರಕ್ಷಣೆ ಬಿದ್ದ ಕ್ಷಣದಿಂದ ಅದು ಮರಳಿದ ಕ್ಷಣದವರೆಗೆ ಯಾವ ಪ್ಯಾಕೆಟ್‌ಗಳು ಯಂತ್ರದಿಂದ ಹೊರಟವು.

ಅವುಗಳಿಗೆ ಪ್ರತ್ಯೇಕ ದಾಖಲೆಗಳಿಂದ ಉತ್ತರಿಸಿ. ಒಂದು ಸಾಲು ಅಂತರವು ನಿರ್ದಿಷ್ಟ ಸಂಖ್ಯೆಯ ಸೆಕೆಂಡುಗಳು ಇತ್ತು ಎಂದು ಹೇಳುತ್ತದೆ. ಇನ್ನೊಂದು ಸಾಲು ಆ ಅಂತರದಲ್ಲಿ ರಕ್ಷಣೆಯಿಲ್ಲದ ವಿನಂತಿ ಯಶಸ್ವಿಯಾಯಿತೇ ಎಂದು ಹೇಳುತ್ತದೆ. ಅವುಗಳನ್ನು ಒಂದೇ ಉತ್ತೀರ್ಣ ಅಥವಾ ಅನುತ್ತೀರ್ಣವಾಗಿ ಸೇರಿಸುವುದು ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ಪ್ರಕರಣವನ್ನು ಮರೆಮಾಡುತ್ತದೆ: ಸೋರಿಕೆಯೊಂದಿಗೆ ವೇಗದ ಮರುಸಂಪರ್ಕ.

ಸಮಯವನ್ನು ಅಳೆಯಬಹುದಾದ ಪ್ರೋಬ್ ನಿರ್ಮಿಸಿ

ಅಂತಹ ವಿನಂತಿಯನ್ನು ಬಳಸಿ ಹಾನಿಕರವಲ್ಲದ, ಅಗ್ಗದ ಮತ್ತು ಟನೆಲ್‌ನ ಸ್ವಂತ ನಿಯಂತ್ರಣ ಚಾನಲ್‌ನಿಂದ ಸ್ವತಂತ್ರವಾದ. ಕೆಳಗಿನ ಲೂಪ್ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಒಮ್ಮೆ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್, 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'

ಸಾಕೆಟ್‌ನ ಪ್ರಾರಂಭ ಸಮಯವನ್ನು ಸಂಪರ್ಕ ಕಡಿತದ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ನೊಂದಿಗೆ ಹೋಲಿಸಿ. ಅಡಚಣೆಗಿಂತ ಹಳೆಯ ಸಂಪರ್ಕವು ಸೋರಿಕೆಯ ಅಲ್ಲ, ಸಾಕೆಟ್ ಮರುಬಳಕೆಯ ಸಾಕ್ಷ್ಯ, ಮತ್ತು ಅದನ್ನು ವೈಫಲ್ಯ ಎಂದು ವರದಿ ಮಾಡುವುದು ಮುಂದಿನ ವ್ಯಕ್ತಿಯನ್ನು ಇಲ್ಲದ ದೋಷದ ಹುಡುಕಾಟಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ.

ನವೀಕರಣದ ನಂತರವೂ ಉಳಿಯುವ ರೂಪದಲ್ಲಿ ಫಲಿತಾಂಶವನ್ನು ದಾಖಲಿಸಿ

ಟ್ರಿಗರ್, ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಅಂತರ, ತಡೆಯಾಗದ ಯಾವುದೇ ವಿನಂತಿ ಯಶಸ್ವಿಯಾಯಿತೇ, ಹೆಸರು ವಿಭಜನೆ ಯಶಸ್ವಿಯಾಯಿತೇ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಹಾಗೂ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂ ಆವೃತ್ತಿಗಳನ್ನು ಬರೆಯಿರಿ. ಈ ಐದು ಸತ್ಯಗಳ ಗುಂಪನ್ನು ಬಿಡುಗಡೆಗಳ ನಡುವೆ ಹೋಲಿಸಬಹುದು, ಒಂದು ಗದ್ಯ ಪ್ಯಾರಾಗ್ರಾಫ್ ಅದನ್ನು ಮಾಡಲಾರದು.

ಕ್ಲೈಂಟ್ ನವೀಕರಣ ಅಥವಾ ಪ್ರೊಫೈಲ್ ಬದಲಾವಣೆಯ ನಂತರ ಅದೇ ಪರೀಕ್ಷೆಯನ್ನು ಮತ್ತೆ ಚಲಾಯಿಸಿ, ಏಕೆಂದರೆ ತಡೆ ವರ್ತನೆ ಅನುಷ್ಠಾನದ ವಿವರ ಮತ್ತು ಅದು ಚಲಿಸುತ್ತದೆ. ದಾಖಲೆಯ ಉದ್ದೇಶ ಘಟನೆಯಾಗುವ ಮೊದಲೇ ಚಲನೆಯನ್ನು ಗಮನಿಸುವುದು, ಕ್ಲೈಂಟ್ ಅನ್ನು ಒಮ್ಮೆ ಪ್ರಮಾಣೀಕರಿಸುವುದಲ್ಲ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು